2023年夏天，某二线城市生鲜平台日均订单2.4万单，配送超时率11%。他们原以为问题是骑手不够，加了30%运力，超时率只降到9%。真正的问题在派单排序：系统按「距离最近」派单，忽略了出餐时间和楼层。改成按「预计完成时间」排序后，超时率降到6.5%，运力没再加。
推荐排序和派单排序逻辑相通：都是给候选集打分再取TopK。区别在于派单的「用户」是骑手和顾客两方。常见错误是只优化单侧。某平台只按顾客等待时间排序，骑手空驶率涨到22%；后来加权：顾客等待占60%，骑手顺路度占40%，空驶率回落到15%，超时率基本不变。权重怎么定？用网格搜索，步长0.1，跑14天。
数据统计上，超时率的分母要写清楚。是「超时订单数除以总订单数」，还是「超时订单数除以已送达订单数」？两者能差1.5个百分点。某次周报用了后者，看起来达标，实际有约800单取消未计入。建议固定口径：分母用当日应履约订单，取消单单独列一栏，每周一对账。
概率角度：单均配送时间近似正态分布，均值38分钟、标准差9分钟。承诺「45分钟送达」，理论超时概率约22%。要降到10%，承诺时间得放到50分钟，或者把标准差压到6分钟。压标准差靠的是出餐准时率和路径规划，不是催骑手。某门店把出餐时间从12分钟压到8分钟，超时率直接降了4个百分点。
模型评估用三个指标就够：1）超时率，按周统计，目标小于7%；2）平均配送时长，目标小于40分钟；3）骑手日均单量，目标12到15单，太高会推高取消率。某平台只盯超时率，骑手单量冲到18单，投诉率涨了2倍。三个指标要一起看，任何一个越界都要停。
案例对比：A方案按距离排序，B方案按预计完成时间排序，C方案加楼层特征。同一周20万订单测试：A超时率10.8%，B为8.1%，C为6.9%。C的代价是计算耗时从80毫秒涨到210毫秒，需要缓存预估结果。步骤：1）离线算好每单预估时长；2）每5分钟刷新一次；3）高峰期限流，只对3公里内订单实时算。
成本账：路径排序服务部署3台8核机器，月成本约4500元。加楼层特征后需要多存约12GB特征数据，存储月成本增加约300元。相比每减少1个百分点超时率带来的约2万元赔付和复购损失，这笔投入3个月能回本。上线前先跑两周影子模式，对比新旧排序的预估误差，误差小于5分钟再切流量。
