本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.
导读：
得物App是新一代的潮流网购社区，正品潮流电商和潮流生活社区是平台的两大核心服务。
得物平台商品品类已经覆盖潮鞋、潮服潮搭、手表、配饰、潮玩、3C数码、家居家电、美
妆、汽车等。
作为新一代潮流网购社区，得物聚集了新、潮、酷、炫的各类商品，也是各类潮流品牌发售和运营的首选阵地。
对于
业务种类多样，
我们
如何实现仓储
系统上架
推荐呢？
又有哪些
库位推荐方案适合得物呢？
本文将来
揭晓
。
1. 前言
得物仓储管理系统（简称WMS），整体流程图如下：
在优化仓库操作时，仓库管理员通常会忽略上架过程，但这是提高仓库运营效率的关键步骤。因为货物的初始放置直接影响后续所有的仓库流程，尤其对拣配的效率起到决定性作用。如果未将货物存储在合适位置，则会增加拣选和包装货物所花费的时间，而且还容易出现找不到“货”情况，白白增加库存成本。因此，优化上架流程是提高仓库运营效率的首要任务。
1.1 工业推荐系统整体架构是怎样的
一个典型的工业级推荐系统整体架构可以参考上图，一般分为在线部分、近线部分和离线部分。
对于在线
部分来说，一般要经历几个阶段。首先通过召回环节，将给用户推荐的物品降到千以下规模；如果召回阶段返回的物品还是太多，可以加入粗排阶段，这个阶段是可选的，粗排可以通过一些简单排序模型进一步减少往后续环节传递的物品；再往后是精排阶段，这里可以使用复杂的模型来对少量物品精准排序。对某个用户来说，即使精排推荐结果出来了，一般并不会直接展示给用户，可能还要上一些业务策略，比如去已读，推荐多样化，加入广告等各种业务策略。之后形成最终推荐结果，将结果展示给用户。
对于近线
部分来说，主要目的是实时收集用户行为反馈，并选择训练实例，实时抽取拼接特征，并近乎实时地更新在线推荐模型。这样做的好处是用户的最新兴趣能够近乎实时地体现到推荐结果里。
对于离线
部分而言，通过对线上用户点击日志的存储和清理，整理离线训练数据，并周期性地更新推荐模型。对于超大规模数据和机器学习模型来说，往往需要高效的分布式机器学习平台来对离线训练进行支持。
1.2 仓储系统的库位推荐
相比于标准的推荐模型。仓储系统的上架库位推荐有一些比较突出的地方;
货品品类多且数量大
得物很多仓库单仓库位已达百万级，货品数量大，且品类繁多，因此人工很难分辨出货品的最佳摆放位置，我们需要更加精细化的管理。
空间与效率的权衡
想要精细化管理有许多需要攻克的难关，比如，在一个货架上摆放货品的数量，多则影响查找的效率，少则浪费了空间资源；再比如，像香水口红等差别微小的货品，人工很难快速分辨出香型色号，仓库工作人员容易出现将A品牌的口红误放在B品牌的货架上的情况。
业务限制
上架作业的场景需要商品类目和库区的校验和限制，比如：某些库区只能存放某些特定的商品类目，某些库位只能放同一类SKU以及一定数量的商品等。
涉及实操
仓内作业人员众多，并且人员流动较大，因此存在不同库区商品库存不均衡，上架员乱上架等情况。
针对上述的问题，适合得物的推荐方案又是什幺样的呢？以下我将介绍两种库位推荐方案。
2. 库位推荐方案
推荐引擎模型
主要包含: 构建标签索引、 召回、排序(权重平衡)、 推荐模型等四大模块。每个模块我会对应简单介绍下，然后在重点介绍下「召回」和「排序」。
（
1）
推荐模型：
包含
两个模块分别是「库区库位信息」和「标签索引信息」，库区库位信息存放着库位的基础属性和限制属性还有库存属性、 标签索引信息包含限制分类、限制分组的具体信息等。
（2）
构建标签索引:
一般推荐模型里面都存储着海量数据。如何快速过滤数据成了推荐系统召回模块的核心问题。标签索引用于辅助快速过滤。
（3）
从海量模型数据里过滤出可用信息。
（4）排序：
基于召回的信息根据策略或者规则进行排序，然后取排序过后最优的库位信息。
架构图
本文主要描述召回方案和排序方案。标签索引和推荐模型会在召回模块里带入。因标签索引和推荐模型主要是根据各自系统业务的不同从而可选择的方向不同
2.1 召回
在推荐系统里召回是推荐系统的第一阶段，主要根据用户和商品部分特征，从海量的物品库里，快速找回一小部分用户潜在感兴趣的物品，然后交给排序环节。这部分需要处理的数据量非常大，速度要求快，所有使用的策略、模型和特征都不能太复杂。
2. 1. 1 快速过滤与推荐模型
仓库管理人员对仓库的管理方式起了很关键的作用。就拿得物来举例：在各种各样的场景下的限制复杂繁多：不同的货品应该放在哪些库区、哪些库位能混放、哪些库区需要严格划分区域、库位的最大空间容量…….都是指定管理方式时需要考虑的。站在程序设计的角度来说，将以上仓库管理人员的管理进行建立库位限制模型。
库位限制
根据库位限制模型已经库位库存标签构建出标签索引。以便于提前过滤出一批库位。在根据过滤出的库位精细化过滤。最后达到召回效果。
标签索引
一级标签key代表仓库库区，值为当前库区下的所有标签分类：比如我们根据实际业务摆放场景识别出四个标识性比较大的业务限制：SKU 、货主、质量等级、业务类型；根据实际情况的不同进行标签分类以及标签组合、我们抽象出三大类：完全限制、部分限制、无限制。比如库位A以上4种限制都设置了为完全限制，某一个没设置为部分限制、完全没设置为无限制。部分限制则需要继续进行细化、比如 是否限制了SKU，是否限制了货主，质量等级和业务类型因为标识性很高则可以组合成一个限制。
{"仓库_库区": ["完全限制" ,"sku限制","货主限制","质量等级+业务类型限制","无限制"]}
二级标签key是一级的某一个value加上一级的key,比: 仓库_库区_完全限制，值则是限制具体值得集合，因为考虑到空库位的存在，所以我们用*代表空库位。
{"仓库_库区_完全限制":["A_B_6_100", // skuId：A 货主：B .bizType:6,质量等级100"B_B_6_100",// skuId：B 货主：B .bizType:6,质量等级100"*",//空库位],"仓库_库区_sku限制":["SKU1", //sku:1的"SKU2","SKU3","*", //空库位],"仓库_库区_货主限制":["小A",//货主小A"小B","小C","*", //空库位],"仓库_库区_质量等级_业务类型":["100_6",//质量等级：100 业务类型：6"200_7","100_1","*_3",//质量等级无限制 业务类型限制3"100_*"//质量等级100 业务类型无限制"*", //空库位],"仓库_库区_无限制":["库位A", //无限制直接到达库位成面 无限制没有三级索引"库位B","库位C"],}
三级索引的key则需要继续上面俩个索引继续累加 ，value则到库位级别。
{"仓库_库区_部分_skuidA_货主A_bizTypeA":["库位A","库位B","库位C"]}
库位详细属性：
{"仓库_库区_AB010101":{//仓库_库区_库位"locationCode":"AB010101","limitCode"：8, //限制位图"currentQty": 20, //当前库容数量"bizType": [200,100,900] //库存业务类型集合"skuList": ["123","12355"] //"maxCommodityQty": 8,"warehouseCode":"仓库","aeraCode":"AB","upperSeq":"1"}}
匹配示例
召回匹配示例
如果召回库位很多，比如有上百个，但是上架员肯定不想要这幺多。于是就诞生了排序。对召回的库位进行打分排序，取最优库位再返回。
2.2 排序
排序是推荐系统的第二阶段，从召回阶段获得少量的商品交给排序阶段，排序阶段可以融入较多特征，使用复杂模型，来精准地做个性化推荐。排序所强调的是快和准，快指的是高效的反馈结果，准指的是推荐结果准确性高。其作用主要是在于召回之上给仓库作业人员提供一个最佳
的库位坐标。
如何定位最佳：
假设小玲玩一个游戏需要根据不同的副本改变其装备、打法以及技能树加点：A副本的boss：攻击高血量薄，那幺玩家需要选择一套灵敏且有容错率的策略；B副本的boss：血量高攻击低，那幺玩家需要选择的是穿甲流，也就是直接打boss消耗他血量的策略。但此时我们面临了一个棘手问题：小玲无法用一套策略来满足所有的副本！同样这样的思路转换到精准推荐时，系统无法判断出哪个库位是最佳。但从中也能够得出解决方案：那就是由小玲来选择使用哪套策略，小玲选择时需要做到问题权重平衡，通俗来讲就是我们看问题时需要从各个角度去衡量,然后得到一个均值，也就是最优解。当我购买一台汽车时，我需要考虑价格、性能、外观等各种因素。每个因素在我们心中的占比不一样。同样的，不同的视角看货品应该放的库位也不一样。类似于以上的问题系统无法精准地判断出一个仓库目前最优解，于是产生了问题权重平衡问题。
从最大空间利用率来看，货品的占用空间越少越好，同类的货品都放在一起是最节省空间的方法，但是这
样做往往会使其他视角的满意度无法满足。
而有些问题是需要根据实际场景来做调整的：
比如有些仓库面积大、楼层多，则需要考虑路径问题，可能会出现因为找一件货品从仓库的第一层跑到仓库的最后一层，这样浪费人力物力且效率低；
有的仓库在大促期间为了方便挑拣货品，把销量好的商品放在容易拿的位置，节省寻找的时间……
2.2.1 权重平衡
那幺究竟如何解决权重问题呢？小玲玩游戏的事例也说明了没有绝对的最佳策略，只有小玲选择出的最佳策略。此时系统能做的只有帮助小玲计算出他的装备、打法以及技能加点。
从某些角度来看，仓库管理员就是游戏玩家小玲，不同场景下的货品上架方案是他要攻克的副本，那幺需要使用怎样的装备等只有仓库管理员最清楚。在仓库作业时，系统给出一个点数图，仓库管理员来分配，从系统推荐的众多库位中选择出一个最优解，即最佳的位置。计算方法如下：
1. 先通过召回，召回出一批能够存放货品的库位；
2. 计算库位各视角得分；
3. 计算综合得分；
4. 取综合得分第一的库位 ,即为最佳库位，然后根据最佳库位得出最佳库区。
由上图配置得出 目前管理员想要的空间占比为50，想要的时间占比为30 假设 A,B,C三个库位 分别的分数为：
A : 空间 （50） , 时间 （20）， 销量 （100）
综合得分为 = （50* (50/100)） +(30*(20/100) ) +(0*(100/100)) = 31
B : 空间 （100） , 时间 （20）， 销量 （50）
综合得分为 56
C : 空间 （20） , 时间 （100）， 销量 （50）
综合得分为 40
由此得出优先推荐B库位
。
2.2.2 最大空间利用率
主要是由程序帮助仓库实现最大化的空间利用， 在保证货物经过召回库位之后。推荐既将放满的库位， 如果实现这个功能， 公式如下：
得分=（已有库容+准备放进库容）/ 最大库容
那幺最难求的则是最大库容（因为根据商品大小的不同 可放进去的东西完全是两个概念，比如口红和鞋子）
这个值其实可以分三步走：
1. 前期可由仓库管理员来设置库容最大值 ，仓库管理员在规划库区的时候。理应考虑某个区域放一类的商品，比如A区域放鞋子。鞋子的最大库容很容易看出来就是8双。
2. 到了中期 可通过一些强管控的手段。比如库位只能放一种类型的商品。比如这个库位已经放了一双鞋了。这时候我们可以默认其他的类型必须是一样的鞋子。这样我们可以拿到商品的体积 和库位的体积做比较相除取整就能得出最大库容。
3. 后期就能借助更加智能化的机械臂，或者扫描机器来帮助计算库位空间
2.2.3 最优路径得分计算方式
最优路径，从另一个角度看，就是花费的上架时间最少。这个时间应该是整体上架时间。而不是单个或者一批上架时间。由此诞生问题如下：
问: 上架员A面拖着一车鞋。在A,B库区(A,B库区相连 并且都是放鞋子)中间需要进行选择。那幺小A如何选择最佳？首先我们需要考虑几个问题。1:货架是有高层货架。高层货架是需要人借助工具爬上去的。比如楼梯2:如何知道上架员的起点。如果定位不到上架员的坐标。则无法有效推荐最短路径3:如何知道俩个库位相邻关系 如何知道俩个库位的高低层关系4: 需要考虑层级问题。因为高层货位上架员需要楼梯爬上去。我们可以对以下场景进行建模，考虑以下理想情况：假设人的起始坐标是(0,0,0),需要将货上到通道P（通道间隔为a），列数Q（列间隔为b），层数R（层高为c）的货架上。人与货架的三维坐标关系如下图所示:
若不考虑碰撞问题，人可以不借助梯子将货上到1～2层货架。人在平面的运动速度为vx，人攀爬货架的速度是vz，所需行走的路程为：
S=aP+bQ+c(max(R,2)-2)
则需要花费的时间为：
T = （aP+bQ)/vx + c(max(R,2)-2)/vy
上架所需花费的时间越短，对应的得分越高。
2.2.4 销量得分计算方式
我们可以根据大数据统计出各类商品近段时间出库量和入库量，从而计算出各类商品的销量，并预测出未来一段时间商品的出库概率，从而换算出对应的销量得分。对于热门商品，可以将这些商品放在低层货架上，对于冷门商品，可以放在高层货架上。
3. 总结
上架作业的库位推荐。主要作用还是便于管理库存，方便快速出货。从无形中节约时效和成本。
召回模块主要是用于对仓库的库位进行筛选。选出可上架库位。这个阶段索引标签的构建和存储方式选型特别重要。个人建议是如果频繁更新的情况下就用redis。如果仓库到了智能化阶段，则可以上ES。本文主要介绍了两种库位推荐方案，如果也同样适用你的项目，欢迎留言和转发。
*文
/巢原
Be First to Comment