迟发不是发货当天才发生

摘要：用预测把迟发挡在前面

很多自配送卖家处理迟发，是从红灯亮起开始的。

订单已经超过 ship-by date，后台开始报 Late Shipment Rate，买家已经在催，客服开始解释，运营开始补救。

但迟发真正发生的时间，往往不是后台判定迟发的那一刻。

它可能在订单生成后几小时就已经埋下了：仓库当天爆单、承运商截单早、目的地偏远、包裹太重、SKU 需要特殊包装、危险品需要额外处理、历史上同线路就经常慢。

今天拆的是 2026 年 arXiv 论文：Uncertainty-Aware Delivery Delay Duration Prediction via Multi-Task Deep Learning。

它不是 Amazon 官方 Late Shipment Rate 规则论文，也不是亚马逊账号健康模型。

但它非常适合解释一个卖家应该立刻建立的能力：

不要等订单迟发后再解释，要在 ship-by date 之前预测哪些订单可能迟发、可能迟多久。

论文信息卡

论文标题：Uncertainty-Aware Delivery Delay Duration Prediction via Multi-Task Deep Learning

作者：Stefan Faulkner, Reza Zandehshahvar, Vahid Eghbal Akhlaghi, Sebastien Ouellet, Carsten Jordan, Pascal Van Hentenryck

来源：arXiv:2602.20271，2026 年 2 月

机构：Georgia Institute of Technology、Kinaxis

研究对象：大规模物流网络里的交付延误时长预测

本文使用文件： 02_订单缺陷率_ODR_迟发_取消预测/05_Predicting Late Shipment Risk in E-commerce.pdf

清单题名是 “Predicting Late Shipment Risk in E-commerce”。实际 PDF 研究的是供应链交付延误时长预测。本文会把它翻译成 Amazon 自配送卖家的迟发风险预警方法。

一句话结论

这篇论文对卖家的最大启发是：

迟发率是结果指标，运营要管理的是提前量、承运商稳定性、仓库处理能力和订单风险区间。

Amazon 官方的 Late Shipment Rate 关注的是：卖家确认发货晚于 expected ship date 的订单，在一定时间窗口内占所有自配送订单的比例。官方政策要求卖家保持低于 4%。

所以对 Amazon 卖家来说，关键不是“迟发后怎么写解释”。

关键是把管理动作前移：

• 哪些订单可能赶不上 ship-by date？
• 最可能迟多久？
• 风险区间有多宽？
• 现在还有没有时间换承运商、加急拣货、拆单或主动沟通？

论文到底解决什么问题

论文研究的是交付延误时长预测。

不是只判断“会不会迟”，而是要回答更难的问题：

如果会迟，大概会迟几天？

而且模型还要告诉你，它对这个判断有多确定。

这在真实物流里很重要。因为延误数据有一个很麻烦的特点：

绝大多数订单是准时的，真正延误的订单很少，但一旦延误，运营影响很大。

论文的数据来自工业合作方，覆盖 2022 年 9 月到 2024 年 1 月的 1000 万+历史发货记录，包含四个主要发货地。四个发货地的延误率在 3.28% 到 10.79% 之间。

这就是典型的“不平衡数据”。

如果模型只追求整体平均表现，它很容易学会一件事：大部分订单都准时，所以都预测成准时。

整体看起来不错。

真正该抓的迟发订单却漏掉了。

卖家日常运营也一样。

如果你只看整体发货率，可能觉得店铺还行。但少数高风险订单，正是最可能带来买家投诉、差评、A-to-z、迟发率警告和账号健康压力的订单。

为什么“先分类，再回归”

论文的模型采用多任务深度学习。

它先做一个分类任务：判断订单是否会延误。

然后再做回归任务：估算延误时长。

更细一点，它设计了两个回归头：

• 一个专门处理准时或提前到达的订单
• 一个专门处理延误订单

卖家可以把它理解成仓库里的两条处理线。

普通订单走常规通道。

高风险订单走加急通道。

如果你用同一套逻辑处理所有订单，高风险订单很容易被正常订单淹没。论文的做法，是先把“可能迟”的订单识别出来，再用更适合延误样本的模型估算会迟多久。

这比传统的两步模型更进一步。

传统做法是先训练一个分类器，再单独训练回归模型。两个模型各学各的，前一步错了，后一步就跟着错。

论文把它做成端到端模型，让分类和回归共享同一套特征表示，减少误差传递。

模型看哪些信号

论文使用的是高维表格数据，包含类别特征和数值特征。

类别特征包括：

• 发货地 ID、城市、邮编、国家
• 目的地 ID、城市、邮编、国家
• 起终点国家组合
• 发货类型
• 首选承运商
• 是否危险品

数值特征包括：

• 包裹重量
• 包裹体积
• 商品件数
• 目的地经纬度
• 距离

此外还有计划出发、计划到达、实际到达等时间信息。

换成卖家语言，迟发预警不是只看“今天有没有发货”。

它应该至少看六类信号：

• 发货地负载：仓库人手、拣货积压、截单时间
• 目的地区域：远距离、偏远地区、跨境路径
• 包裹属性：重量、体积、件数、危险品
• 承运商表现：揽收稳定性、首扫延迟、线路波动
• 订单余量：距离 ship-by date 还剩多久
• 历史模式：同 SKU、同线路、同承运商是否经常异常

预测区间比单个 ETA 更有用

论文还有一个卖家特别值得学的点：不只给一个预测数字，还给预测区间。

它使用分位数回归和 conformal calibration，目标是让模型输出类似这样的信息：

这个订单最可能迟 1.5 天，但合理风险区间可能是 1 到 3 天。

对卖家来说，这比“预计 1.5 天”更有用。

因为运营决策不是数学题，而是资源分配题。

如果一个订单预测可能晚 0.2 天，且区间很窄，你可以正常跟进。

如果一个订单预测可能晚 2 天，且区间跨到 3 天以上，你就要提前处理：换承运商、升级服务、催仓库、拆包、主动沟通，或者调整未来类似订单的 handling time。

论文结果也显示，经过校准后，模型能给出更可靠的预测区间。对延误订单来说，模型在四个发货地上的延误样本覆盖率从校准前的 63.6%-69.8%，提升到校准后的 68.6%-74.2%，并且在延误样本上保持更好的 Winkler Score。

注意，这不是说模型对所有延误订单都能达到 80% 覆盖。论文也承认，由于时间序列数据存在分布漂移，conformal prediction 的严格假设并不完全成立。

这正是卖家要学的地方：

预测不是保证，预测是提前行动的理由。

实验结果说明了什么

论文把自己的多任务深度学习模型，与 XGBoost、CatBoost 的单步模型和两步模型做了比较。

结果很清楚：

在延误订单上，论文模型的 MAE 达到 0.67-0.91 天。

相比单步树模型，延误订单误差降低 41%-64%。

相比两步“先分类再回归”的树模型，误差降低 15%-35%。

这说明一件事：

在迟发这种少数但高影响事件上，只优化整体平均误差是不够的。

卖家也不要只问“我整体发货准不准”。

你要专门盯住那一小撮最可能迟发的订单。

因为账号绩效不是被平均订单毁掉的，而常常是被少数异常订单拖下水。

放到 Amazon 自配送，该怎么做

Amazon 的 LSR 是结果统计。

你真正要做的是建立一个迟发风险预测看板。

这个看板不用一开始就很复杂。哪怕用表格，也可以先做起来。

每个自配送订单至少记录这些字段：

• 订单号
• SKU
• 下单时间
• expected ship date
• 当前剩余小时
• 仓库预计处理时长
• 承运商当天截单时间
• 首选承运商
• 备选承运商
• 目的地区域
• 包裹重量和体积
• 是否危险品或特殊包装
• 同 SKU / 同线路历史延误次数
• 当前风险等级
• 下一步动作

最简单的风险公式可以先这样做：

动态余量 = 距离 ship-by 的剩余小时 - 仓库处理时长 - 承运商截单缓冲

如果动态余量小于 0，就是红灯。

如果动态余量小于 12 小时，就是黄灯。

如果目的地偏远、承运商近期异常、SKU 需要特殊处理，再把风险上调一级。

这不是论文里的深度学习模型，但它是卖家可以明天就落地的版本。

先把风险看见，再谈自动化和模型。

迟发风险处理 SOP

第一，下单后立刻算剩余时间。

不是等打单时才看。订单进入系统后，就计算 ship-by 剩余小时、仓库处理时长、承运商截单时间。

第二，发货前 24 小时筛高风险订单。

如果订单还没真实交接给承运商，但余量已经很薄，就要处理：换承运商、加急拣货、拆单、升级服务，或者调整内部优先级。

第三，揽收当天确认真实交接和首扫。

不要为了躲 LSR 虚假确认发货。Amazon 官方论坛里的官方说明也强调，健康 LSR 的做法包括在 expected ship date 前发出订单，并在把包裹交给承运商后尽快确认。

第四，异常发生时保存证据。

承运商未揽收、系统故障、天气或不可控异常，都要保留工单、截图、聊天记录、揽收预约记录、标签购买记录和实际交接证据。

第五，每周复盘重复延误根因。

按线路、承运商、SKU、仓库、包装类型、危险品属性去看。不要只处理单个订单，要找“为什么同类订单反复慢”。

一个可复制的预警表结构

建议卖家先建一个表，字段不用多，但要能直接指导动作。

第一组，订单基础信息：

订单号、SKU、数量、下单时间、expected ship date、配送方式、承运商。

第二组，风险输入：

仓库处理时长、截单时间、目的地区域、包裹重量、包裹体积、是否危险品、是否特殊包装。

第三组，历史模式：

同 SKU 过去 30 天迟发次数、同承运商过去 30 天揽收异常次数、同目的地区域过去 30 天延误次数。

第四组，风险结果：

剩余小时、动态余量、风险等级、建议动作。

第五组，处理闭环：

责任人、动作时间、是否已交接承运商、是否首扫、是否通知买家、是否需要更新未来 handling time。

这个表的核心不是“统计漂亮”。

它要让运营一眼看到：哪几个订单今天必须优先处理。

不要误读这篇论文

第一，这不是 Amazon LSR 官方计算模型。

论文研究的是工业物流延误时长预测，不是 Amazon Seller Central 的迟发率评分机制。

第二，不要把“预计会迟”当成虚假确认发货的理由。

如果包裹没有真实交给承运商，不要为了指标提前确认。这样会制造更大的履约和诚信风险。

第三，预测不能替代后台规则。

Amazon LSR 仍然按官方规则统计。卖家的预警表是为了提前处理风险，不是为了改写平台口径。

第四，别只优化平均表现。

迟发订单少，不代表不重要。对账号健康来说，少数异常订单往往比多数正常订单更需要管理。

结论

迟发不是发货当天才发生。

它在订单进入系统、仓库排队、承运商截单、目的地线路、包装处理和历史异常里提前出现。

这篇论文给卖家的启发，不是让每个店铺马上训练深度学习模型。

真正要学的是它的思路：

先判断会不会迟，再估算会迟多久，并用预测区间决定要不要提前行动。

对 Amazon 自配送卖家来说，迟发率是结果。

你能管理的是提前量、真实揽收、线路稳定性、承运商备选方案、SKU 包装复杂度和异常证据。

把这些信号做成日常看板，才能在 ship-by date 之前把高风险订单拦下来。

账号健康不是靠事后解释守住的。

它是靠事前预警守住的。

参考资料

• 论文：Uncertainty-Aware Delivery Delay Duration Prediction via Multi-Task Deep Learning
• arXiv: https://arxiv.org/abs/2602.20271
• Amazon Seller Central：Late Shipment Rate https://sellercentral.amazon.com/help/hub/reference/external/G200285190
• Amazon Seller Central：Order Performance program policy https://sellercentral.amazon.com/help/hub/reference/external/GGJVNFDXQT8C3RA8
• Amazon Seller Forums 官方帖：Let's talk Late Shipment Rate https://sellercentral.amazon.com/seller-forums/discussions/t/889ff08e-5b57-441f-af71-94fc42c29054