## 画像在同城物流调度系统的实践 文/梁福坤 >在同城物流的服务品类多样化、多角色参与场景下，能够做到精细化细分给角色贴“标签”，通过一系列算法和规则进行挖掘，得到的数据能够比较好的理解和运用，最终达到服务私人订制、完善产品平台、提升服务质量的关键支撑。 ### 引言 随着互联网技术的蓬勃发展，“互联网+”影响着人们生活的方方面面，网购的繁荣和移动支付的持续多场景的渗透，O2O 的模式是众多互联网的必争之地，更有大量传统企业开启向互联网模式的变革进程。消费模式升级的促使人们把 O2O 逐步成为常态，而在领域做得细分最早的行业就是外卖场景的同城物流，如果移动互联网+O2O 是对外卖行业的变革，那么同城物流则是展示提升餐饮服务质量和服务能力的重要落地指标。随着外卖的商品从餐饮扩展到商超、鲜花、蛋糕、生鲜等，同城物流的模式也在推波助澜的适应多种形态，从专送到众包、从商圈配送到全城送、从跑腿到专人专送，都是同城物流在适应向新零售靠拢、成本压力降低、服务升级的需求满足。而在同城物流的服务品类多样化、多角色参与场景下，能够做到精细化细分给角色贴“标签”，通过一系列算法和规则进行挖掘，得到的数据能够比较好的理解和运用，最终达到服务私人订制、完善产品平台、提升服务质量的关键支撑。 因为外卖的同城物流场景下的调度是一个时空最优解的模型评估，模型演进的过程中，都有重要的特征来支持着物流变革，边界非常清晰。模型演进对于画像部分，是开始在配送服务精细化运营的落地步骤；画像是为了满足个体的真实差异而对个性化的支撑方式。无论是时间预估、距离预估、最大能效预测最终都会落实到三方参与角色主题：商户、用户、骑士；主体之外，还有很多附加：骑士配送工具、写字楼/小区、红绿灯、地铁上下层、立交桥、天气风云变幻、交通管制突发情况等都在默默的参与着、影响着配送过程。 百度外卖智能调度系统持续优化迭代运力能力的提升送达以满足用户体验。智能调度从1.0版本到5.0的逐步演进，生态化的研发了调度台、实时监控、时光机回放、虚拟仿真和寻宝物流场景精细化服务支撑，而画像贯穿在整个生态当中，在大刀阔斧的业务版本演进同时，能够细致入微的解决落地场景的问题。 图1 物流系统生态 图1 物流系统生态 为了能够较为清晰的了解外卖在同城物流应用场景，以及在这个场景下多角色参与情况下的变化，我们通过一个形式的最简版本到复杂的场景介绍，然后再延伸出不同角色画像在调度精细化中细微却精细化的主导作用；最后对画像的基础数据收集、行为建模、构建画像、画像价值输出阐述画像在同城物流调度系统的实践。 ### 调度模式的演进史 #### 抢单 抢单模式的策略是在同城物流平台、商家、用户、运力三方场景的模式下最基础的形态，因为运力自主且有一定灵活性，意义重大并且是一直贯穿在调度的始终。 图2展示的是来自2个不同用户收货地址，针对2个商家下单的行为，周边提供运力的有3个骑士，当前3个骑士的身上被单均为0，场景很简单。当系统在一个周期内（比如5s）的新订单和未抢单的订单进行合并后进行推送周边3个骑手，骑手针对获取的推送信息进行抢单行为。 合适场景：抢单非常适合供需双方能够对等的情况下进行单项选择，在外卖的众包模式、同城快送、汽车出行模式下应用的非常高频。 图2 抢单模式 图2 抢单模式 交互：常见的交互方式有：Tc2C（Transport capacity to Client）和 Tc2S（Transport capacity to Service）两种； Tc2C：一种是运力（例如骑士、司机）对用户用户在外卖下单/用车下单之后，平台进行相应的推送，运力提供方的骑士或者司机选择认可比较合适的订单，一般会基于时间和距离、方向进行比较后作出是否抢单的动作。这个过程始终是骑士/司机从个体角度出发，选择合适的最优或者次最优。最终也存在订单因没有骑士接单最终无法履约，如果系统为了保证用户体验会有相应的兜底方案，选择一些其他运力池进行补充，最终实现履约服务能力。 Tc2S：是针对已经确定运力，通过转嫁的方式给到其他运力或者服务大厅，供其他服务提供者进行抢单的方式，这是在非常规的情况下，能够对突发情况进行的一种灵活的运力支撑；例如骑士装载设备故障、电瓶没电等导致无法履约，或者在角度、距离不合适的情况下进行自主的选择其他意向的运力，通过转单的方式完成。如果转单是 Tc2Tc 的个体行为，那么转单到服务大厅就是 Tc2P、然后 P2Tc 的结合模式，服务大厅作为容器和暂存点，提供短时间的服务能力中转。 约束和优化：在抢单模式下为了保证有效信息传递、合适人员的候选、提升服务质量，一般会通过以下方式进行约束。 全局扩散：抢单模式初期，进行一定范围初筛之后，就进行全局的扩散传播，运力在判断合适之后进行抢单；全局模式能够在整体上短时间完成抢单，同时接起率相对高，但是在系统层面参与度较少，存在骑士得到不合适的订单，或者在订单上没有被相对较优的骑士拿到。 多级轮播扩散：一般按照商家订单隶属商圈作为基础运力选择，然后通过商家的距离和运力位置、运力身上顺路单、运力完成身上订单最后位置进行候选；这样在商圈为基准的配送和全城配送下略有不同，针对跨运力配送范围的和长短距离结合的全城配送有差异化的选择。多级轮播是为了保证服务质量和缩小扩散范围常用的方式；多级轮播是优化的大策略方向，它在提升订单和骑士匹配度，在运力相对充裕的情况下非常适用，缺点是接起率和接起时长会下降。 抢单的候选：系统平台在针对抢单模式下选择 First 互斥模式或者通过候选时间窗口+N 选一的模式，针对选择 First 是按照抢单的速度在服务端进行互斥操作，类似秒杀的行为；后者则强调在等待一个周期之内，通过候选 N 个运力进行抉择，系统可以在候选中在进行优化特征选择，比如按照运力的服务能力、骑士空闲时长、用户 UGC 评价等较优选择。N 选1是优化的小策略方向，这种选择能在双方供需都能正常履约的情况下做一个范围的优化，对于运力对在线时长、UGC 评分的重视程度有很好的激励措施，系统在中后期具有整体抉择权。 非合适单的指派，是指在运力评估来看，收益为负数的订单，一般会选择规避抢单。例如距离偏长但是配送费少；目的地偏远、绕路；预订单在非主流时间段；而运力倾向于收益为正的抢单选择，为了能够很好的权衡服务能力，一般常用的方式有： - 远近组合单：订单收益为负的，则通过和同方向、期望时间合适的进行组合分组，通过在路径距离/单的配送路程的下降来提高接单率。在汽车出行通过顺路单充分提升履约能力。 - 长距离加价：对于收益为负的订单，则采取增加打赏来提升接单的空间，在配送费中倾斜运力的利益；在汽车出行领域可以通过加价、打表来接的方式来激励运力完成订单。 针对抢单模式下，用到的画像比较简单，例如运力的综合指标、UGC 评价、运力速度等，对于用户、骑士、路径规划、商户等基本上没有太多参与。 图3 抢单模式下的骑士画像 图3 抢单模式下的骑士画像 抢单模式存在上述骑士角度最优的方式任务分解，接起率不能完整覆盖，从全局来看会有运力的浪费和体验的打折扣，同时也存在途中抢单的安全隐患，所以在后续的版本演进中，推出了利用系统给到展示指标和图形化方案，由调度员进行人工指派，提升服务体验。 #### 人工派单 人工派单是介于运力抢单和系统自动派单的过渡阶段，在负责分配订单和运力之间的调度员，是整个系统的灵魂选手，他的个人能力的优劣决定这最终的考核指标，百度外卖运力调度系统的最初版本是基于人工派单开发相应调度台。 图4 人工派单场景 图4 人工派单场景 场景跟最近的抢单相仿，不同的是增加了空间的信息，如果把商户出餐时间和用户期望时间增加，这就变成了一个时空的问题，但是这些在人工派单模式下考虑相对欠缺的地方，因为订单不存在压单，有订单就进行分配，如果时间上来不及在整个时间预估上就认知有偏差，所以时空问题再人工派单上只是一个空间的问题，但是有经验的调度员需要考虑的空间之外场景也非常多，在人工调度意识中会有一个相对完整的画像雏形，如图5所示。 图5 人工派单大脑画像 图5 人工派单大脑画像 调度员对商家出餐速度慢的有感知，因为在日常调度中经常出现骑士到达出单久等导致身上其他单也超时情况，商户的集中区域例如 CBD 在调度中非常受欢迎，因为能够形成集中取餐，相似角度送餐。 调度员熟知运力的使用交通工具、每个人的年龄和职业能力，并且对经常调度小区的熟悉程度在新老骑手上会有所倾向。 调度员通过运力反馈的楼宇等电梯、小区步行通过等特殊 case 场景，小区之间能否穿越都有一个判断，这是在路径规划中有些无法数据准确化的描述，但是调度员信息充分却能做的很好。 人工派单场景考虑权重很大的两个特征就是距离与方向，系统在下发订单到调度台之后，站长会优先选择订单周边运力，查看运力当前方向是否与目前订单商户到用户的方向是否大致匹配，如果符合心理预期则进行相应的派送；调度员会在除两大特征之外有以下动作不会考虑并单分配（假设订单被商家确认时间相同情况下）： - 两个商户的出餐速度相差比较大，按照以往经验进行分配并单分组会导致其他订单有延迟送达情况。 - 骑士对于用户的收货地址所在区域有不同的认知程度，分配给2个骑士不会延迟。 - 收货地址虽然空间距离很近，但是从商家到2个用户非常绕。 - 收获地址隶属不同的学校分校区，校区许可的交通方式只有步行，一个骑士能在送分离上最大程度并单，但是对于不同校区 AOI 则是互斥关系。 - 调度员在后续发现有其他合适单或者节约运力应对高峰期，可以针对已经分配订单进行改派，无需骑手确认。 人工派单需要在平台层面提供较多配套的支撑，图形化站点骑士总览和单个骑士目前被单情况便于站长判断，骑士小休上报与审批，闲事运力推荐路线等。 人工参与派单的方式一般不会对订单进行压单，因为提前分配导致不合理路线订单可以通过上述提到的改派进行纠错，调度员因为在大脑中有相关经验构成画像，能够从个人的角度统筹站点内的资源，做到一个比抢单模式下相对优化。人工派单也存在一定的弊端，需要调度员不间断服务跟进调度、在高峰期人为判断能力捉襟见肘（人力调度派单峰值为每人800单/天）、在分配策略上存在感情因素倾向性派单，同时调度员岗位成本也是一项支出，所以需要能够从上述弊端解决，需要借力于系统模式的自动派单。 #### 系统自动派单 鉴于人工派单存在的效率低下、岗位成本等上述因素，系统自动派单应运而生，系统自动派单2.0版本综合考虑配送距离、骑士运力、期望送达时间等因素进行自动派单。在自动派单场景下，订单进入系统后，系统选择最优骑士进行分配，即对每个订单采用贪心的方式选择骑士。 系统自动派单中最核心的部分为订单与骑士打分模型的构建，其中主要包含以下几步： - 对骑士已有订单进行配送顺序规划形成配送序列Seq0；配送顺序规划的结果是骑士在商户（Businesses）和用户（Customer）角色对应的取（Take）送（Delivery）动作顺序，例如针对商家的取取送送的顺序如下：[{'businesses':1001,'seq':0},{'businesses':1002,'seq':1},{'costomer':2001,'seq':2},{'costomer':2002,'seq':3}]； - 配送顺序的规划在进行完成身上被单的时间 T 和距离 Dist 有非常大的影响，配送顺序比较经典的2种规划是：贪吃蛇和鸡爪模式，能够在按时履约的同时提升骑士对短距离的体验。 - 对于待分配的订单，按照步骤1的规则插入到 Seq0，形成 Seq1。 - 计算 Seq0 和 Seq1 的订单插入后的时间、距离变化情况，得到时间变化 δ(T)=T'-T 和距离变化 δ(Dist)=Dist'-Dist。 - 综合打分：根据 δ(T) 得到 ScoreT，根据 δ(Dist) 得到 ScoreDist，附加骑士是否空闲，订单的商户、用户位置等因素对之前得分进行调整记为 θ。因此，可以得到订单与骑士的得分： ``` score = f(ScoreT, ScoreDist, θ) ``` 通过上述步骤，打分模型构建完成后，对每个待分配的订单，选取得分最高的骑士进行指派。 打分模型构建过程中，多次涉及对骑士已有订单进行配送顺序规划，这里涉及到①相似订单的合并分组②组间订单路线规划③组内订单路线规划④订单完成时间/所走路程的预估。 订单间的相似度计算主要考虑这几个因素：商户位置、用户位置、订单期望送达时间。 ``` sim_score(order1, order2) = f(dist_shop, dist_user, delta_expect_time) ``` 系统自动派单2.0的优点：模式简单、容易理解、计算复杂度低，可以做到即时分配。 系统自动派单存在的问题： - 订单采用贪心的方式选择骑士，而不是从全局考虑，导致整体效率不是最优。 - 订单进入系统后，直接分配给骑士，导致骑士身上积压订单过多，订单越多，线下不可预估的异常情况也越多，对骑士的路线预估、时间预估越不准确，影响后面订单打分的置信度，最终影响整体派单效果。 系统自动派单在画像上考虑的情况比较少，相对人工派单场景相对欠缺，在人效不高的情况下没有太好优势，但是自动派单能够通过贪心算法简单、直接的解决自动派单部分问题，是一个过渡过程不可或缺阶段。 #### 云端分组派单 随着系统自动派单的模式推广，逐渐暴露出一些问题： 订单采用贪心的方式选择骑士导致整体效率不是最优；订单即时分配导致部分骑士积压订单过多，订单或骑士一旦出现异常情况，导致骑士身上所有订单都受影响。 为了解决系统自动派单出现的问题，有针对性的进行升级为订单先云端分组，与骑士打分后再进行全局最优分配，骑士以组为单位配送订单，只有快完成身上的已有订单组，才能从云端获取新的订单组，云端的订单每一轮调度都会重新计算分组，选取合适的候选骑士，分配给骑士也采用虚拟队列的方式分配，即每个骑士除了身上已有订单列表，还有一个不可见的虚拟任务队列，只有在骑士快完成身上的订单后，才能从虚拟队列中获取订单。在每一轮调度开始时都会回收骑士的虚拟队列订单，进行重新计算。 云端分组派单中每一轮调度的主要计算步骤如下： - 判断新订单是否需要以并联的形式追加给骑士，如需要则直接分配给骑士，更新骑士任务。 - 参考商圈订单压力情况，将所有待分配订单分成订单组。 - 预估/更新每个骑士预计完成已有订单的时间和地点。 - 分商圈计算候选骑士与待分配订单组的打分矩阵。 - 计算全局最优的订单分配方式，为骑士计算候选订单组。 - 当骑士已有订单完成时，自动将候选订单组内的订单分配给骑士，并生成任务。 整体计算流程如下： 图6 云端分组派单流程 图6 云端分组派单流程 云端分组派单基于基础数据、数据预估模型、基础算法和并行计算框架，在同城物流配送的场景下可以支撑多种业务形态。整体架构如下： 图7 云端分组派单整体架构 图7 云端分组派单整体架构 整体架构从底层到上游分为基础数据、预估模型和算法、并行计算框架、支撑业务4大模块。 基础数据是面向不同数据主题的基础原始数据和业务指标数据，后者可以认为是浅层次的数据 ETL 操作，作为下游整体计算口径的输出。基础数据除了满足业务基本需求之外，最重要的是能够支撑参与角色画像数据的素材采集，通过对历史数据的离线计算和数据挖掘，交付出可以优化路径规划、时间预估模型的画像标签。 预估模型和算法是比系统自动派单重点演进的方向，预估的模型设计的方面比较多，最终落地的均为时间的预估模型，这也是在同城物流方向时空问题重要维度之一。 针对时间预估专项的分析，需要看一下在外卖的同城物流方面整个履约链条的过程： 图8 云端分组派单-外卖场景履约时间序列 图8 云端分组派单-外卖场景履约时间序列 - 下单：从客户下单开始，是一个订单的生命周期的开始，同时在时间轴推进的情况下订单密度是在商圈范围预测的重要因素，会根据历史单量、节假与工作日周期、天气等因素建立预测模型，可以有预期的协调众包人力的支持满足供给需求。 - 接单：商户接单操作，分为人工确认和自动确认，在通常场景下，订单被确认的时间比较短。 - 商户出单：从商户接单到商户出单的时间预估，是影响配送体验很重要的一个因素，商户出餐一般是没有商户对此进行显性的操作，而是通过骑士到店之后取餐则认为出餐时间，但是这种会存在差异性，如果商户出餐早于骑士取餐，则按照骑士取餐时间作为出餐时间，反之，则认为商户真实的出餐时间。在商户出餐预估模型会使用如下四种数据作为特征数据： 表1 特征与分类示例 表1 特征与分类示例 通过特征的综合计算，针对在不同特征下会给到一定的分值域，会得到 fscore 特征分数，特征得分针对上述的不同特征方式的的分布。 图9 特征得分 图9 特征得分 特征得分根据公式得到不同的权重之后，通过 DNN 或者 Xgboost 的方式对出餐时间进行预估，最后预估数据准确性通过预测误差在 xmin 之内数据所占比例、预测值大于/小于真实值所占比例、平均绝对误差来判定。 到店和送单时间预估属于骑士当前位置到目标位置的路径规划和取送模式的范畴，两种时间没有差分的去建立预估模型。 交付时间预估：交付时间是骑士到达送餐地点，等待用户取餐的过程，在具体实现过程中会通过划分网格，在多样本订单数据的情况下进行统计特征的离线模型计算。 图10 云端分组派单-交付时间架构 图10 云端分组派单-交付时间架构 基础数据的取餐位置定位、送餐位置非常依赖地图的精准定位，通过设备自动定位和用户辅助选择地址等方式逐步优化，在增加对期望时间的需求，最终输出取送逻辑顺序，同时骑士最终的行为轨迹也是真实取送逻辑的反馈，通过路径规划采纳率进一步校对模型。 历史数据也是上面提到的基础数据，进行离线建模和计算，并辅助实时动态预测功能的数据微调，最终输出在商圈压力、用户、商户和骑士画像，最终这些数据在循环的反哺到取送逻辑和时间预估，形成良好的正向循环。 在云端分组派单会综合考虑各种因素选取全局最优解，解决了在系统自动派单的场景下对骑士体验的提升，而在时间预估和路径规划上是画像重要特征的体现。在后续的智能调度动态规划、全城调度针对多场景配送、多品类商品、多运力池融合、多种配送工具协作都是基于云端分组派单对画像的刻画，每个版本的迭代是更加精细、丰富的完善画像标签的数据，在此不再一一展开，我们看下画像在研发过程中是如何构建的。 ### 画像数据架构实践 对角色的刻画均基于大数据的方式模型的分析、挖掘最终得到业务方需求，下图是一个画像系统常见的架构实践，通过对数据的采集、处理，借助统计分析平台、机器挖掘平台丰富标签，同时能够对画像的准确度、完整性有完整的校验方式。 图11 画像架构图 图11 画像架构图 画像架构平台一般有大数据平台支撑、数据生命周期处理、评测体系组成，对照图11的左、中、右三部分，针对生命周期的过程，一一展开。 #### 业务需求制定 在开发画像的起初，需要明确业务场景的具体需求，一般分为通用化素材标签库的构建、特殊场景业务解决方案需求两种，前者一般由专门的研发部门专项阶段性的跟进，在业务方有较少固定需求的情况下启动项目，通过逐步丰富标签库，多角度多层次的深度刻画的方式演进；后者一般由具体业务方基于业务场景的痛点，提出需求，明确目标，最终在业务方应用。必须从业务场景出发，解决实际的业务问题，例如之所以进行用户画像要么是获取新用户，或者是提升用户体验，或者是挽回流失用户等有明确的业务目标。 在骑士的路径规划中，比较依赖在骑行、电动车模式下的导航距离，但是在一些高架桥、高速路、河流跨越场景下出现的 BadCase 比较多，一般是因为规划错误、路途不通、可穿梭未被感知等，导致看似相邻、相近的2个 POI 点，在实际的骑行距离上却有很大偏差，距离的偏差会导致骑士在并单配送的体验变差、配送时间预估不准确的场景，为了能够满足项目特殊场景下的需求，需要针对区域跨越 POI 进行刻画。 #### 数据的采集 通过业务需求制定的目标标签类目，确定数据的来源，一般情况下画像的数据分布在不同的业务库、行为日志、开放 API、爬虫等方式获得粗粒度的数据源，数据存在结构化和非结构化的方式，而数据的采集可以是周期同步的方式，也有通过依赖触发的方式获取数据。 行为日志采集存在模块化分散多机器部署、日志格式随意、上下游埋点信息不统一、注入或脏数据导致数据源置信度偏低，一般通过 Flume 工具采集最终数据源推送到 Kafka，供下游的 APP 对数据质量、数据 ETL 进行处理。日志在业务方是一个横向统筹工程，日志从随意的文本化，尽量转 ProtocolBuffer(PB) 化，因为 PB 格式 是一种结构化数据存储格式，在数据的序列化方面有很好的支持，同时能够对接下来的 ETL 处理提供便捷；同时，日志在不同模块和版本之间的数据字典、埋点规范也尽量统一，否则这一切都给数据使用方适配带来阻力。 数据库的采集可以通过 Sqoop 工具导入到 HDFS、也可以通过 Tungsten Replicator 来解决异构系统之间的数据交换；虽然这些工具均能提供一些便捷的内容交换和传递，但是对于数据从哪里来、到哪里去、字段映射等需要工程化的解决，因为随着数据采集繁多，数据链路的梳理逐步变的不可维护，百度外卖通过自研的开放式 SQL 平台，很好的把数据路由，工程编码进行剥离，在数据的读写上更加抽象后变得通用、灵活，更为后期再数据血缘关系分析、生产链条依赖自动解析上做了支撑性铺垫；最后在数据同步工具、数据来往路由、大数据分布式调度三方统一协作来完成数据库数据采集。 第三方 API 的采集一般分为开放、验证的方式，最终能够拿到结构化的数据，例如每天的城市天气预报就能够辅助队城市配送压力提供指导，第三方 API 适合数据量不大，交互低频的场景。 一般数据采集通过已有接口、数据交换协议（thrift、jdbc 等）、爬虫的方式获取，还有一些通过画像数据需要通过第三方数据服务商获取，数据的采集对画像的丰富度和精度至关重要。 #### 数据的 ETL 处理 数据的处理环节根据采集数据的质量，会校验、过滤、转换、分组聚合处理，满足明细数据和聚合数据的入库操作。数据的 ETL 的操作也存在跟采集在一个过程完成，这些在数据置信度比较高的数据库、Elasticsearch、Redis、MongoDB 等。但日志、网页抓取数据或者实时要求高的数据在大数据场景下一般选择 Kafka 作为中间介质，下游通过 SparkStreaming APP、自定义消费端服务来完成数据的解析 ETL 过程。ETL 的处理过程尽量能够平台化、配置化减少数据和代码工程的耦合，代码工程类似装载货车，数据就像货品，各司其职。 画像的数据一般来源广，需要对用户多渠道的身份打通、商户不同平台整合判重服务，在数据 ETL 过程需要通过多属性特征，例如用户身份打通需要系统账号、手机号属性，用户 WiFi SSID、IMEI 号码、网络 IP。ID-Mapping 的最终目标是找到一个自然人的多个 ID，所以，如何区分同一个 IP 下的多个自然人的设备使用也会是一个技术挑战。类似这种在数据ETL层面也需要关注到，ETL 处理完的数据大部分都可以作为基本特征标签使用。 #### 数据统计分析 统计分析的数据是通过数据运算的方式，得到在数据层面给到的事实分布情况，统计的方式包括平均值、最大值、最小值、标准差、求和、Last、First，也有关于数据分布的分析：正态分布/卡方分布/F 分布/T 分布，这些在上述的出餐时间预估中用到的比较多。上面的统计分析的方式大部分数据库引擎均支持，所以在数据采集、ETL 处理之后一般通过输出存入 HDFS、HBase 后，以 SQL 的方式对数据进行查询分析，能够实现快速、标准化的交互，较为复杂的统计也可以通过 UDF 的方式处理。 #### 建模分析和预测 建模分析把数据域分为不同的主题，每个主题域下分为基础属性、角色分级、兴趣偏好等，下面的每个标签都是观察、认知和刻画角色的一个角度，但是这些标签之间并不孤立，之间存在关联，角色的画像正是由多个主题域下面的标签组成。 角色行为来建模预测，例如通过骑士的平均速度个性化定制配送时长。物流产品中对角色的行为信息不太一致，提取的特征以及方法也不一致。对于外卖用户，提取的特征通常是这个订单信息，比如你点了星巴克，系统会给打上一个“咖啡“的标签作为其中一个特征。对于外卖的指南频道资讯用户，提取的特征就是该指南文章的主题，关键词等信息。提取的特征来自于结构化信息和非结构化信息。对于结构化信息（数据库表、xml、json 等），容易抽取。但是对于非结构化信息，就需要自然语言处理和文本挖掘的方式来抽取。 对于抽取的这些信息，就可以当做用户的基本行为特征，其实也可以当做一部分用户画像的维度了。文本建模一般有 TF/IDF、Word2Vec、Bag of Words、VSM、CountVectorizer 方式，复杂的数据需要 PCA 等降维处理；通过 SVM、Bayes、KNN 训练多个模型，选择最为贴合实际的机器学习算法，通过 Boosting 对不同属性值线性加权不断的对参数进行调整，也需要放置过/欠拟合；损失函数的选择对于问题的解决和优化，非常重要。最后交叉验证、小流量实验的方式快速试错，在数据上形成闭环不断完善数据对画像标签的认知与刻画。 #### 画像标签应用 画像标签的运用在同城物流的场景下非常广泛，运力能力预测、运费/代金券价格敏感度分析、商户营销影响分析、用户流失/拉新/促活/留存/召回概率分析、配送时长预估、红绿灯等待预估分析都有多方面的应用。除了上面提到的离线分析的场景标签化，一般在外卖场景下会有场景化画像的应用，场景化刻画，也称为上下文的刻画，根据用户当前浏览、检索、查看的相关信息，能够更为精准的贴合当前需求提升转化率、用户体验，场景化的标签一般处于实时性要求做轻量级的挖掘，辅助离线标签的内容，在权重上动态调整。 画像随着社会大数据信息的激增，可以说越来越丰富，越来越精细，画像也被应用到垂类行业营销，以标签、画像为基础的精准定向投放短信或者广告。通过对人群基本属性、徐办兴趣习惯、商业价值等多种维度信息数据综合分析。 ### 总结 本文主要通过外卖行业的同城物流配送场景下，伴随着调度系统的逐步升级，都有画像参与的重要身影，伴随着精细化服务升级，画像服务的深度与广度都在逐步演进，后半段针对如何构建画像展开讨论，能够从场景出发利用技术发掘创新领域。 在众多同城物流配送场景下技术逐步提升并完善之后，能够支撑在外面履约链路上继续提升的除了线下的服务体验，最终都在针对性的解决配送体验的痛点，包括路线规划、时间预估、决策模型、分配方案、供需平衡这五个维度表现决定了智能调度能否替代甚至优于人工调度，最终都需要画像在同城物流领域不断推陈出新、差异化服务不间断引领智能调度前沿。