Shopee 末端物流智能提效之路

1,834 阅读17分钟

本文首发于微信公众号“Shopee技术团队”。

摘要

东南亚因语种多样、语料库缺失、GIS 地理信息薄弱等多种原因,其末端物流发展还处于依靠人工的初级阶段,导致效率低下、准确受限、拓展速度受限。本分享将介绍 Shopee 如何基于大数据、人工智能等技术,在东南亚各个市场实现末端物流分拣的自动化、智能化,从而支撑 Shopee 快速发展的最佳实践。

在上周举办的 ArchSummit 2021 深圳站中,Shopee 智能分拣团队负责人 Zewu 分享了 Shopee 在东南亚的智能末端物流提效经验。本文根据演讲内容整理而成。

1. 东南亚末端物流之痛

Shopee 是一个电商平台,业务覆盖新加坡、马来西亚、巴西等多个市场。在今年的 11.11 大促中,Shopee 售出超 20 亿件商品。大量订单在东南亚的派送会遇到什么样的特定问题?Shopee 又将怎样解决和提效?

1.1 背景

先来看看 Shopee 快递的业务模式。由于市场不同,业务类型不同,整个业务流比较复杂。对业务流进行抽象后,总体流程可以分为卖家、Shopee 快递和买家三个部分。其中,卖家又包括跨境卖家、本地大卖家(一般有自己的仓库),以及本地小卖家(仓库比较小)。

Shopee 快递大体也分为三个流程:首程、中程和尾程。

首程(First Mile,简称 FM)阶段主要是通过交通工具将货物从卖家处揽收并做好分拣,然后按照路由进入中程的 SOC。对于小卖家来说,首程也可以选择自寄服务,卖家将货物投递到自寄点后有工作人员揽收并统一到 Hub 进行分拣。

中程阶段主要是在分拣中心把首程送达的货物进行分拣和打包,从而进入下一个分拣中心,或者进入尾程。

货物从中程出发后进入尾程(Last Mile,简称 LM),到达 Hub(Last Mile Hub,简称 LH),拆包后根据路由信息分拣,最后交给司机派送。当然,派送也分为多种模式,包括送货上门,或是送到自提点,还有一些移动的分拣站。总的来说场景和业务比较复杂,接下来我们主要分享末端物流,也就是“最后一公里”的收货和派件。

刚刚过完双 11,大家可以想象一下,自己在商城下单后,货物是怎么来到家门口的。这个过程会经历哪些流程或操作?大概可以分为以下几点:

  • 买家在商城下单后,商户收到订单、打包货品,并按照买家填写的地址打印面单,等待司机上门取货;
  • 司机收到指令后上门取货,送到 First Mile Hub(简称 FH);FH 收到很多司机取回来的货后,根据地址进行打包,而后进入中程;
  • 中程把包裹送到 LH 后,进行拆包,并安排司机进行送货。

一个包裹对应的 FH/LH 可能会有多个,一个包裹对应的某个 Hub 的司机可能也有多个。对于包裹整体路由来说,如何选择 LM 是根据包裹时效和经济代价等多重因素决定;而对于 FH/LH 而言,如何选择哪一位司机到去取/送货则同样由包裹时效和经济代价等多因素决定。

对于首程和尾程来说,一个重要问题是安排哪一个 Hub 上的哪一个司机去取货或者送货?我们拥有的只有用户输入的地址,于是问题就转化为如何根据地址文本去匹配最合适的 Hub 及这个 Hub 下的最合适的司机

1.2 现状分析

在进行优化之前,我们对某市场部分站点和司机的服务范围及活动轨迹做了一些调研分析。

示意图,非真实业务地点与数据

第一张图对司机的派送范围做了圈定,可以看到,不同司机的派送范围有很大的重叠。

第二张图是对司机的派送点进行打点,除了能看到很多司机的派送点非常相近,有的司机的派送点居然横跨了 8km 的范围。

通过技术手段发现这个问题后,我们针对业务流程进行了分析。从 Hub 的层面来讲,其服务范围是按照行政区划来区分。而东南亚某些地区的行政区划范围比较粗放,有的完整标准行政区只划到 State、City、District 这三级。这会导致每个站点的服务范围比较大,Hub 内的司机管理难度也比较大,其分拣操作往往是由有经验的操作员查看地址的详细文本,根据自己的经验进行分拣成堆,然后按照堆来安排司机派送。

这样明显带来了一些问题:

  • 每个包裹需要花费大约 10 秒人工读取地址文本,分拣效率低下;
  • 依赖人工和已有经验知识,难免出现人为的错误和认知的偏差;
  • 依赖有经验的分拣员,人员培训成本高,特别是大促临时增加分拣员难度比较大;
  • 因为司机派送范围重叠和个别司机派送范围跨度大,影响司机的派送效率。

亚当·斯密的《国富论》提到一个重要概念——分工。凡是能够分工的工作,一旦使用分工制,就能够相应地增加生产力。一个国家的产业和劳动生产力如果极高,那么各行各业的分工通常也能达到极高的程度。此理论毫无疑问同样适合物流领域。

2. 东南亚末端物流解决方案

根据分工理论,要解决此问题,行业通用的做法是将 Hub 的服务范围规划得更小,从而提升站点的分拣效率;同时在站点内部,将站点的服务范围按照司机的维度进行划分,从而提升司机的派送效率。

2.1 业务挑战

前面讲到,东南亚很多地区的行政分区很粗放甚至经常发生变化,我们按照行政区划来设置站点或者司机派送范围是难以实现的。

在仅拥有用户地址文本及派送记录的情况下,我们的想法是从是地址出发。但是从地址出发在东南亚会遇到什么问题?

非常直接的思维,就是拿地址文本去地图上去搜索到对应的经纬度,然后根据 Hub 和司机的服务范围进行派送。

最突出的困难是地址填写不标准,特别是特定的用方言撰写的文本,由于专用词库缺乏,导致文本匹配效果比较差。举两个例子,用户地址一:Jalan Petinggi Umar, RT.23, Depan Kantr Desa Loa Duri Ilir, Loa Janan.。翻译为中文是 Jalan Petinggi Umar, RT.23,位于 Loa Janan 的 Loa Duri Ilir 村办公室前。 此地址用 Google Map 查到的结果把真正有效的地址信息(Jalan Petinggi Umar, RT.23)匹配失败,反而把辅助信息(Depan Kantr Desa Loa Duri Ilir, Loa Janan)作为匹配结果,偏差比较大,对于物流投递来说会非常影响订单分拣和人员调度。

用户地址二:Jl marsma r iswahyudi RT 15 (masuk 75 M dari Jembatan sungai sepinggan rumah didepan sungai tingkat warna pink biru)。翻译为中文是 Jl marsma r iswahyudi RT 15(从河桥 sepinggan 房子入口 75M 在河面,粉蓝色)。 此地址用 Google Map 搜索到的结果显示其对信息匹配处于混乱状态,主体信息和辅助信息交错,难以区分,对于包裹投递来说无所适从。

除此之外,我们也会遇到其他挑战:

  • 缺乏语料库情况下的多语言问题;
  • 行政区划粗放或者发生变更,导致用户对自己所属的行政区认知混乱,填错地址;
  • 在缺乏词库的情况下,对于用户输入错误的地址,如何识别和纠正?
  • 由于 SOP 的执行度不一,对于已有的大量历史地址,如何判断一条地址的可信度?
  • 当站点服务范围或者司机服务范围逐渐精细化后,如何解决经纬度偏移导致的地址定位失败?
  • 对于重复下单的地址,具有多个经纬度,如何屏蔽和确认?

2.2 业务架构

回归初衷,我们先回想一下人解决问题的方式和方法。一般分为如下几个步骤:

  • 读取地址面单;
  • 根据已有知识,在大脑中搜索地址文本对应的地理位置;
  • 根据已有知识,根据地理位置搜索并明确对应的服务范围;
  • 完成分拣,并安排此服务范围的司机进行派送。

根据上述步骤,我们朴素的解决方案如下图:

主要包括两个部分:

(1)离线训练

  • 根据历史地址订单进行清洗,形成可信地址库;
  • 根据验证数据,基于可信地址库进行训练,得到合适的匹配模型。

(2)在线推理

  • 下单时获取线上地址,进行预处理,形成标准地址文本;
  • 根据离线训练的地址库和匹配模型,进行在线推理,获取推理结果;
  • 根据推理结果进行分拣和投递。

可以看出,离线训练所得的可信地址库和匹配模型是基础。

另外,面对上述挑战,我们记录两个事实和两个优势。

两个事实:

  • 虽然存在 SOP 执行不一、地址偏移等多因素,但从概率上来说,签收时刻采集的经纬度相对比较准确;
  • 地理位置相近的地址文本,其相似度也比较高。

两个优势:

  • 拥有海量的历史订单数据,自然也拥有海量的地址数据;
  • 拥有强大的线下团队,可以对地址进行验证和纠偏。

因此,基于这些条件,我们的业务架构如下:

有两个主要的数据来源:商城订单的历史地址和线下团队贡献度的地址库。

首先,对这些地址文本进行格式化等预处理后,得到标准的统一的地址文本。

其次,尽可能使用行政区划等信息,对格式化的标准文本进行分割,形成格式化地址文本,将格式化地址进行 AOI 的聚合,形成 AOI 集合,同时根据策略进行地址清洗,形成可信地址库。

再次,基于 AOI 集合和可信地址库,使用训练地址库进行监督式学习训练,得到匹配模型。

2.3 技术架构

根据上述业务架构,系统也自然分为两大系统:在线地址推理服务和离线训练服务。

在线推理服务主要包含三个部分:

  • 地址服务:主要提供能使用的地址库和匹配模型,使用各种策略进行地址服务,包括行政区划服务,基于规则匹配,基于相似度匹配,基于关键词匹配以及 local 标注数据匹配,同时还需要对匹配结果进行评分、比较和推荐。得到这部分是线上推理服务的核心;
  • 分拣服务:对外提供 OpenAPI 服务,包括地址分单服务、文本分割服务等。其面对的客户不仅仅是 Shopee 自建物流,也包括对外的 3PL(3rd Party Logistics,第三方物流);
  • 运营平台:对外通过 Zone 生成工具、local 标注数据上传、系统监控、策略配置等等功能。

离线训练服务:

  • 主要是对各种数据来源(Shopee 自有数据、地图数据、第三方数据等),按照各种规则进行地址训练,包括地址清洗和 AOI 聚合服务,主要有基于规则的训练、基于相似度的训练、基于关键字的训练;
  • 其训练完后形成可信地址库和 AOI 集合,存储在存储层;并且为了使在线地址服务随着时间不断优化地址库和匹配模型,同时也为了能解耦在线推理服务和离线训练服务,在线推理服务和离线训练服务使用消息队列进行数据的传输。

技术架构确定后,根据面临的问题,我们的技术选型也就确定了下来。如下图所示:

2.4 最佳实践

2.4.1 构建可信地址库

可信地址库的构建,面临比较大的挑战。

一是如何确定地址的可信度?

  • 对于同一个文本地址,其经纬度出现一定的离散现象,如何从中挑出可信度不高的点?离散度如何选择?
  • 我们认为同一个地址投递多次,其可信度会比较高。那如何定义投递多次?
  • 对于同一个地址,其最新一次的投递与多次投递的可信度对比如何选择?
  • 对于同一个地址的不同的离散点,采用中心节点与随机节点的可信度如何选择?

典型的分布图如下:

二是假如用户输入了错误的地址:

  • 在缺乏行政区划或者行政区划混乱的情况下,对于用户输入的不完整的地址,如何补全?
  • 在缺乏行政区划或者行政区划混乱的情况下,对于用户输入的错误地址,如何识别和纠正?
  • 怎么样区分用户输入的是错误地址还是新的地址?

三是对 local 人员标注的数据的使用:

  • 为保证其准确度和覆盖率,不同地区的地址密度阈值如何选择?
  • local 标注的数据如何有效鉴别?
  • local 标注的数据如何高效使用?

还有,在缺乏语料库的情况下,怎么样去训练多语言的问题?

为此,我们设计了如下图所示的清洗流程。原始数据经过预处理、清洗引擎、验证引擎到输出几大步骤后,就能够进入可信地址库。

(1)策略中心:数据清洗中的预处理。清洗引擎有多种策略,通过配置中心进行配置,再通过验证引擎得到的结果对配置中心形成反馈,从而做出调整

(2)预处理:主要有标准化格式、文本分割、批量处理等,其算法和策略可通过配置中心完成。输出清洗引擎需要的格式数据;

(3)清洗引擎:主要有多种技术流派,包括基于规则、基于深度学习、基于机器学习等。采用一种还是多种,由配置中心来决定;

(4)验证引擎:主要对清洗的结果进行准确率和覆盖率的验证,并输出 bad case 以便进行分析,根据准确率和覆盖率的表现对配置中心做出反馈;

(5)可信地址库:对输出满足要求的地址库做版本管理,包括时间维度、地区维度等,以便进行更新和回滚。

在此,针对部分区域地址,以基于距离为例做清洗策略,主要根据训练调优相关阈值,包括距离阈值、重复地址阈值等等。

2.4.2 AOI vs POI

因为行政划分比较大,所以站点和司机的服务范围需要远小于最小行政区划。那么如何形成呢?一个办法是在地图上去区划,另外一个办法是通过某种方法自动化生成。这里有两个粒度,POI 或者 AOI。也就是说我们进行地址匹配时,是去匹配 POI 的文本还是 AOI 文本。POI 就是地图上的一个点,AOI 是地图上的一个区域。

生成 POI 和 AOI 各有利弊,下表分别从收集难度、地址匹配准确度、维护成本和指导价值做出了分析:

AOIPOI
Collection DifficultyMiddleHigh
Matching PerformanceHighMiddle
Maintenance CostsMiddleHigh
Guidance ValueMiddleHigh

针对我们物流的场景,不需要精准匹配到一个点,只需要匹配到站点服务范围和司机服务范围即可,所以 AOI 成为优先选项。

根据输入地址进行信息抽取,可以形成一些关键字,从而形成 AOI。根据抽取的纬度不同,可以形成不同层次的 AOI。在关键词提取的时候,我们具体用到了 tfidf、BM25、textRank 等方法。

同时,这里存在一个多语言多模型的问题。每个地区因为行政区划和语言不同,其应用算法不同,会产生多模型管理与维护的问题。目前我们是分开管理的,如何高效融合是我们正在进行的尝试。

得到不同纬度的 AOI 后,又可以根据业务需要进行 AOI 层级的聚合:

  • 根据业务需要,可以产生不同粒度的站点和司机,比如有的地方 ADO 比较高,可以采用低一级的 AOI,ADO 比较少的可以采用高一级的 AOI;
  • 对于站点或者司机的服务范围的变更,可以非常简单地通过 AOI 或者 AOI 聚合纬度进行调整,远比 POI 纬度高效得多。

AOI 本身也需要知道它在地图上的位置。如何界定呢?我们采用 AOI 里面蕴含的 POI 的经纬度聚合方式进行。由于 AOI 的位置不需要特别精确,所以用这种方式能够基本满足需求。

对于手动划的站点或者司机服务范围,如何与 AOI 形成匹配,则需要业务介入。比如上图,特别的区域(Zone)可以增加优化手段,除了聚合外,还可以增加 local 给的数据的距离最小点,与聚合中心点进行相互校验,同时落在 Zone 里面即匹配成功。

一旦确认下来,基本上 Zone 不发生变化,后续就几乎不会再出错。

按照上述方案,不但可以将现有的服务范围按照不同的司机进行区分,同时还可以根据单量将区域拆分得更细,从而增加分工度,提升效率。

另外,有了准确的划分范围后,可以上一些高速自动化设备,进一步提升效率。

3. 东南亚末端物流未来展望

Shopee 对于末端物流的展望主要分为“人、货、物、场”四个维度。

17.png

首先是人员的效能和安全;第二个是货品,比如说货品的路径和货物的安全;第三个“物”包括运输的安全性,和车辆本身的运输效率;第四个“场”即场地能效,包括垛口使用率、场地的使用情况和安全情况等。

围绕以上这些,Shopee 将会用人工智能技术做更多的尝试。

本文作者

Zewu,Shopee 智能分拣团队负责人,来自 Shopee 供应链快递服务(SPX)团队。

加入我们

Shopee Express 是我们的自营快递产品,致力于提供贴合东南亚本地市场的优质快递服务。目前已在东南亚、拉丁美洲多个市场铺开,支持日千万级订单的配送,是构建 Shopee 高效低成本供应链服务的核心能力之一。

目前团队大量岗位持续招聘中,海量 HC 涵盖后端、前端、产品、测试、算法等,感兴趣的同学可将简历发送至:karen.lin@shopee.com(亦可进行咨询,注明来自 Shopee 技术博客)。