上一篇文章中介绍了配送这个事情，以及一些模块的理解，现在看来还是有些天真的模样，不过对于更多的人理解这个业务还是挺有帮助的。今天就到了讨论这个业务的深水区啦（框架体系）。了解一个业务做的事情十分简单， 但是真正想要看清楚一些业务做的好坏，就会遇到更多的问题。做模型的时候，我们一般会谈论技术指标，例如MAE或者MSE等等，无疑是衡量一个模型学习好坏的指标，但是对于业务来讲衡量一个事情的好坏就是十分复杂的，如果我们不能站在一个全局的视角看待一个事情，就容易犯以偏概全的错误。
也想通过这个过程，认真的看看整个配送的过程， 到底有哪些因素需要做平衡，哪些仅仅是最优化的问题。
一个陈年旧事
下面想讲一个故事说明业务指标的难以衡量的事情，在地图领域有一个POI挖掘的任务， 这个任务是挖掘出一些热点位置，能够让接驾和送驾或者是外卖的交餐更快达成一致。这个业务的经典衡量指标就是“交餐误差”。
交餐误差=∣点击送达位置−POI位置∣(1.1)
可以粗略的认为，点击送达位置和挖掘的POI越近，说明挖掘的POI越准确，听起来还是十分合理的。突然有一天，我们发现，这个指标在什么也没有做的情况下，竟然优化了很多，这对于算法团队可是一个值得高兴的事情，赶紧把近期做的事情往上靠呀。最终遗憾的事情是从很久以前就开始优化了，很难找到一些事情与其对应。
经过深度分析以后发现这样的一个事情，当业务处于收敛状态，且市场上有类似的产品，交餐误差大的用户（区域）已经流失掉了，虽然在指标上是向好的，实际对于业务确实是萎缩的状态的。
这件事情，给我的提醒更多是业务框架以及指标完备性的重要性，如果你做业务的时候，不关注业务指标的衡量的定义，就带团队卷起来， 那么最终就是卷的越累，消失的越快。
配送回归
做了配送这么久，虽然仅仅负责其中一个部分的工作， 但是逐渐也摸清楚了这个业务的复杂。 想写点东西，用自己的粗浅的理解，希望能给其他人一些启发。
缘起（最终目标）
对于框架体系这种东西，从指标拆解看其实更加直接（就是你认为什么样的状态是一个好的状态）。如果你有一个配送公司，要养活300人的团队， 那么你这个公司能够盈利的底层逻辑是什么呢？
max 规模s.t.成本约束(2.1)
咱们还是先以规模作为出发点，抢占市场份额作为从新手村走出来的第一目标是十分有互联网范的。当然你是有成本约束的，你要用一定的成本达成最大的规模。这样才能保证整个商业模式是通的。
缘进(目标拆解)
直接放出最终目标，没有目标的拆解，在工作中无疑是一种“耍流氓”的行为。 面对上面提到的宏伟的目标， 咱们进一步明确指标的定义，这样方便我们进一步落地。
规模=当前规模+未来规模(2.2)
这里经常会有一个误区，就是大部分理解的规模都是当前规模， 所以发现提升当前规模的抓手有很多，但是一旦提升思考维度加入了未来规模， 很多抓手其实无效的，甚至是可笑的。 例如我们做补贴增长的， 花钱无疑是能将用户量迅速拉升的抓手，但是拉上来人的留存如果不好，那么就发现这个钱花的不值。
对于配送来讲也会遇到这样的问题， 从配送视角来讲，最大化当前规模无疑是提升当前转化最直接，也就是说当供需紧张的时候， 我不做任何动作，放任订单流入，超出配送极限以后，大量订单体验极差，导致用户流失。 这个时候发现流进来的订单，不仅不能真正的完成当前转化，甚至连未来留存都保不住。 这就不是规模最大的话，所以这里有一个平衡的概念。 当供需紧张的时候，系统要在平台视角，对供需进行调整，例如缩圈这样的动作，一方面让用户能够在近处完成当前转化，损失一部分远单需求，另一方面，通过更好的体验，通过留存的方式弥补规模的丢失。就产生下面的公式，这里暂时不做详细的描述
这就是配送系统需要做的第一个“平衡”，是当前转化和未来留存的“平衡”。
这部分是比较难以完成的， 抛开系统设计不谈，要解决的最大的问题是平衡点的位置所在。然后才是设计一个系统完成这个平衡点。
成本约束
横着看是成本约束， 这里的成本约束分成几个部分，一部分是我们进行分单的时候，使用的成本。 这个成本包括给骑手的配送费，以及耗费骑手的时间成本。如果是一个低效的系统， 就会导致系统给出一个十分低效的匹配，浪费骑手人力，最终导致系统承载订单的能力很弱，从而导致单均成本巨大，商业模型跑不通。这部分一般以效率作为衡量标准。
max 效率s.t.体验约束(2.3)
另一方面是给骑手的补贴成本，平台在某些区域或者某些时间具有充足的骑手数，让该时空的订单能够被更多的完成，进而产生更大的GMV，就要用补贴的手段撬动人力，这个时候要考虑钱效，解决钱怎么花的问题，是一个优化问题，一般以公式2.4作为目标。
max ROIs.t.成本约束(2.4)
比较幸运的是咱们上面面对的问题都是类优化类问题， 这类问题是比较容易解决，例如公式2.4的落地是要通过一个模型建模钱给谁（时空）的问题，就能提升钱效。 这类问题解决的思路是明确的。
缘待（ETA的角色）
通过上面的图能够看出来，咱们还有一大块没有介绍，就是ETA的部分。ETA的复杂是来源于角色的复杂，ETA对于用户侧来讲是一个预期， 长期能够晋升到用户心智，但是ETA还有一个角色对于平台侧来讲是分单的一条约束。低估和高估本身对于分单就有不同的影响。甚至是约束分单达成高效的“拦路虎”。
鉴于这么复杂的角色， 是不是也存在一个平衡呢，我的理解是这样的， 对于用户侧来讲，“准”是第一诉求，但是“准”是有引号的， 到底怎么叫准，如果我估计100min，那我就晚点给分单就可以了，也能达成，如果我估计的20min，那就单独给他一个骑手配送。所以我们能够发现，这个准不是一个模型学习的问题，是一个干预的问题，也是一个系统设计的问题。我的理解是所谓的准是根据目前的环境状况下， 分单体验约束内最高效的配送方式需要多长时间就估计多长时间。所以对于分单来讲，ETA是一个软约束， 还是按照自己体验约束高效派单，最终形成的结果也能让ETA进一步估计的分单的能力。
有了上面这个假设， 你会发现这里缺少了一个平衡的关系，ETA就是作准，且是分单高效分单的ATA即可。这里强调的是准。 至于在准的基础上确实产生了一些业务的不同，例如如果我们知道这个”准“的时间，是否可以高估或者低估改善系统的能力。我认为是可以的。
这里要插入另一个认知，分单所谓的提效，是相对于供需紧张的场景的，也就是说如果我们当前的高效的影响是能够为真正的高峰期节省很多的运力，并承载更大量的订单的。
基于上面的认知，就产生了个性化的需求，一些供需好的场景，是否可以低估，这样能够提升转化，也能保证一个好的体验，但是对于一些供需紧张的场景，要尽可能高估，这样即使当前能单飞配送，也尽量合单，为高峰期预留运力。
当然这里ETA还有另一种呈现的形式，就是区间预估，区间预估的物理含义是【体验， 效率】。 就是给出一个最快配送的体验值，给出一个最大效率的体验值， 这样让下游的分单决策，当前状况下，如果不能合单就快速分配，如果能合单就要压单等待，这样也能让用户预期得到一定的满足。
另一种“平衡”
图中确实还存在一个“平衡”， 但是这个平衡是发生在分单内部的， 如果上面我们的假设是对的， 是不是说所有的订单我都需要压单完成呢，反正只要符合了体验约束就可以的。 这样做在分单侧看是不对的， 如果未来有提效空间，我们是可以压单的，这样能够产生体验约束内的更多人效释放。但是如果未来没有提效的空间，那么直接分出去就是最大的效率， 所以在分单内部最重要的决策就是是否压单的判断，以及对未来判断的一部分能力。
所以这部分中， 我们可以不将他理解成平衡，也没有所谓的平衡点，而是系统能力的判断，和对效率的落地的好坏。应不应该压单，能不能提效，都是分单对系统能力，时空特点认知的理解。 对物理世界理解的越透彻，决策就越个性化，而不是一味的压或者不压。
缘尽(总而言之)
其实能够看出来， 看起来一个配送系统，中间竟然存在这么多的“坑”，又有平衡，又有优化，一个想不明白，可能就率领团队直奔“地狱”，经受无尽的灵魂拷问， “指标这么好，为什么口碑还是那么差”。可能随着时间的推移， 认知上还会有修正，敬请期待啦。