出品 | 智东西公开课
讲师 | 刘思伟 织点智能AI研究室负责人

导读：

6月1日晚，织点智能AI研究室负责人刘思伟在智东西公开课进行了AI零售合辑第二讲的直播讲解，主题为《商品识别算法在收银结算场景的应用与落地》。

在本次讲解中，刘思伟老师首先分析AI+零售存在的业态，然后针对结算收银场景中商品识别的难点，从商品识别落地中的模型选择、数据挑选与标注、前端和云端部署、模型改进等方面，进行了深入讲解。

本文为此次专场主讲环节的图文整理：

正文：

大家好，我是刘思伟，来自广州织点智能AI研究室，负责零售场景相关的AI产品的落地。今天分享的主题为《商品识别算法在收银结算场景的应用与落地》，主要分以下4个部分:

1、AI+零售
2、CVPOS自助收银的应用和商品识别的难点
3、商品识别算法落地的一般方法
4、商品识别算法工程落地步骤和应用实践

AI+零售

首先，AI+零售定义为以人工智能为核心技术，为零售行业降本增效，增强用户的体验。也就是人工智能在传统行业里，是为了提升它的效率、降成本、整合资源并增强体验。但在实践中发现，AI的能力并没有我们期待的那么美好，所以在落地的过程中，更需要脚踏实地的抓紧节省成本的关键指标。

近几年，接触到AI+零售的概念，大概是从16或17年的无人店开始，它确实是风靡一时，但是到后面主要是往自助结算、人脸支付、智慧营销及门店管理的方向发展。形态变得越来越沉稳，看到大家在风口前面慢慢冷静下来，回归到务实和理性，这是行业健康发展非常乐于看见的情况。为什么无人店不能够坚持下去，或者说现在越来越少？一个原因可能是人的诚信问题；另一个是管理、维护成本还很高，而体验却没达到非常极致的效果，所以大家也不再往这个方面去考虑。

目前AI+零售会有哪些业态呢？我们总结了4大产品业态。第一是自助结算，第二是无感购物，第三是新型支付，第四是智慧营销。

自助结算是在收银环节节省成本，从整个零售行来考虑，结算是在所有消费行为的末端，也是最容易想到并且场景最容易控制的，所以大家都愿意在这方面进行研发。自助收银产品主要是自助结算台，包括RFID的和视觉的，另外还有一些扫码设备，购物车以及冰箱等。实践证明，这些设备做的越简单，越易用，节省成本的效果就越显著。

第二是无感购物，拿了就走，这是最接近无人店的一种产品。他没有固定的结算的流程，挑完商品之后，出门就完成自动结算。它大概经历了两代，第一个是RFID的模式，第二个是完全基于视觉的模式。RFID相对比较简单，而且比较容易实现，只要在商品上加入特定的标签，出门时通过感应完成商品的检测，从而生成订单。RFID实际上完成了一种成本转移，把末端的结算的成本转移到中间用来贴标签、管理商品的成本。而视觉方案确实是解决了成本转移的问题，但是它本身造价比较高，要求的运算能力、传感器的精度、规模都非常的大，而且并非真的无人，还需要按照一定规则进行运营，所以真正达到无人落地还需要很长的一段时间，它涉及到成本、技术和客户顾客的习惯的问题。为什么还继续坚持做这样的产品？或许这是人类对未来的生活方式的期许和信仰。

第三是支付，自从诞生了扫码支付以后，我们携带现金的机会大大降低，这方面确实改变了我们的生活。下一步肯定会向无感支付的方向发展，它的第一阶段是人脸支付，我们在17年时借助微信的免密支付，率先推出了人脸支付+手势识别的模式，实现零接触的支付方式。随着人们对支付安全性的信心越来越强，人脸支付在未来必定成一个比较流行的趋势。

第四是智慧营销方面，可以通过一些会员识别的方式，对会员做精准的推荐，向商户提供合适的营销策略。门店可以借助布置的传感系统，比如用于人脸支付的人脸识别机，识别会员，然后通过室内的监控摄像头进行客流统计，并且获取一些购买行为的情况，做大数据的处理，就可以向门店提供供应链管理、门店运营、营销推荐等服务，让门店的经营更加省时省力。

这四个的产品模式都是围绕在提高效率，这也没有违背刚刚提到的人工智能就是为了节省成本这一点。下面从收银环节来介绍人工智能落地的应用情况。

CVPOS自助收银的应用和商品识别的难点

我们讲到的自助收银设备叫做CVPOS，从名称看出它是借助视觉的技术的POS机。首先从它的基本的需求开始介绍，作为一个自助设备，它的基本功能是要自己操作，输出订单并完成结算，而不需要其他人员参与，这是产品最顶层的需求。再往下探一些需求，相比于扫码支付而言，怎样提升体验呢？它可以一次识别多个，并且解决扫码不能解决的非标品问题。根据这两级的需求，产品的模式是尝试用摄像机拍摄结算台上的所有的商品，用视觉模型进行识别。当然也可以用别的传感器，但是视觉是最准确的。如果大家了解这个行业，可能会出现用重力传感器去识别，但是它的限制会高很多。

在现实的场景中CVPOS是会面临哪些困难呢？这个领域我们用到的是目标检测深度学习的模型。在深度学习中，作为有监督的算法，数据的一致性是相当重要的，而环境会对模型的输入数据产生一定的影响。我们必须保持训练数据和测试数据的分布要一致，这一点要求不需太过苛刻，尽可能保持环境的一致性，，不要是光太强或者太弱的环境，或者一些很极端的情形，剩下的环境因素交给模型自己去学习适应。

那为什么不要把环境给封起来，做一些隔绝？这样产品就会太复杂，完全违背产品设计的初衷，因为比较开放的环境会让顾客更加容易接受产品。所以，顾客的体验是第二个重要因素，除了刚刚所说的让顾客感觉舒服外，另一个涉及到顾客体验的是产品是否容易学习，怎么样去做结算，怎样摆放商品，而不容易遮挡。当然最极致的一种体验，是可以随意摆放，都能够识别这种商品。但是用视觉的方式，遮挡其实是不能完全解决的。所以后续产品的设计上是要尽量降低遮挡的概率。

第三是维护成本，在没有做任何优化之前，成本是相当高的。首先，商品有可能外观会很相似，外观相似对于视觉是一个非常高的风险因素。另外，在零售行业的更新迭代速度非常快，我们的运维以及模型训练的速度必须得跟上它们的运营效率，才能保证能够正常的使用这个设备。如果这三方面任意一点做的不好的话，都可能会出现顾客在买单时不能成功，造成后面有一堆人排队，这样的效果就非常差，导致顾客对产品的认同感以及复用的可能性降低。

上图是在应用过程中发现的一些问题。从顺时针开始，第一张，我们有个习惯就是喜欢用塑料袋，但是视觉上这种塑料袋实际上给物体带来很大的噪声，甚至改变了物体的外观，，让模型失效，第二张图是商品的外观极其相似，第三张出现了严重遮挡的问题，第四张是识别整体作为一个商品，还是识别单个商品。因为在真实的零售场景里，有很多情况是你意想不到的，都是需要亲身去经历才能发现。后面都是围绕在这些方面去进行改进和升级。

商品识别算法落地的一般方法

在介绍经验教训之前，先介绍下算法的一般落地方法。

现在优秀的开源算法已经很多了，如何让他们真正的助力自己的行业，成为产品的一部分，是需要方法论的。上图是经过实践总结出来的一些经验，首先要明确任务的目标，到底是一个CV的任务，还是一个NLP的任务？这比较明显，我们是一个CV的任务，但更重要的是要明确它的输出结果是一个绝对的决策，还是一个推荐的决策。绝对的决策要求他的精度是零容忍的，它的准确率绝对影响最终产品的性能，而推荐的决策只需要给出一个分数，让用户自己参考做决策。

显然CVPOS不是推荐式的决策，它对精度要求非常高，所以在第二步选择模型算法的步骤上，首先要根据精度的要求，再结合其他一些资源去挑选算法到底是用目标检测还是分割、分类，或是多种组合，用什么主干，选用什么网络架构，这些选择都需根据现场的需求决定。

第三步是数据准备，数据集刚开始可以用公开数据集，有助于去挑选合适的候选方案，随着业务场景成熟，不断引入业务数据，形成数据闭环，有助于快速提升模型精度。

对于标注，要选择是手工标注、全自动标注还是半自动标注？显然半自动标注是最符合真实的工程应用的。最后还有一些数据生成的问题，因为总会想不可能获得更多的数据，总希望模拟出更多的数据分布去拟合模型。但模拟方法从效果来讲，这种数据增强不及业务数据闭环来得显著。

数据挑选和数据集准备完之后，就是训练调优步的方面，用什么样的网络？有没有预训练的模型？优化的策略是怎样？训练是用开源框架，还是要自己搭建一个训练平台。因为到了后期真正接近产品时，其实是需要固化一些参数，这时开发一个相对自动化的平台工具进行模型的训练和输出，而不需要更多的调参，减少人工参与，是必要的。对于预训练模型，可以根据商品的特定形态选择训练模型。比如说像烘焙，他的外观极其相似的，我们可以专门做一个预训练模型，为后续的训练提速做准备。

通过调参训练，再回到真实场景的业务数据循环中，不断优化模型，当它的性能达到一定要求时，可以选择上线部署，部署根据具体需求，选择在云端还是前端部署，最后一定要关心在应用上线之后的整个运营的状况，在运营过程中搜索更多的真实问题，再把新需求回馈到整个模型开发的流程当中，对模型进行更好的迭代。

上图是前端部署所需的一些工具以及模型，对于框架，基本上都是一些成熟的框架，而且他们的公开资源会比较多，方便大家去做实验研究。对于模型，我们以目标检测为例，会有一些带锚框的模型，还有不带锚框的模型，要根据真实场景去做决定。因为这是一个前端部署，我们尽量选用一些小的backbone，再配合一些模型压缩技术。在前端部署方面，有类似于TFLite、Ncnn的前端的架构。现在选用的主要是国内大厂的开源的架构，因为它们会对国内经常使用的芯片，有一些定制化的处理，而且工具链也比较完善。

上图是云端部署的罗列，框架是一致的，因为要充分利用模型的性能，就少一点考虑模型的小型化，可以用一些更深、更宽、准度更高的网络，也不是不做优化，因为在云端部署大部分使用的GPU是英伟达GPU，可以用TensoeRT去做优化，在正常情况下可以达到三倍左右的性能增益。API的部署可能会用到一些框架下自带的Serving功能，或自己开发一些API的接口。

上图是一个分类模型下的backbone的性能比较，开始可以通过这张表选择一个性价比较高的模型进行候选实验。由上图可以看到在ResNet50左右区间，性价比最高，所以可以考虑在这附近选用一些backbone。

下一种是目标检测的模型选择，把Anchor-Free和Anchor的一步或两步模型都做了验证，是在自建的数据集上进行的测试，发现在backbone上性能会低一点，YOLOv3的性价比较高，是否用YOLOv3，还是要根据当前的真实环境和验证实验而定。

商品识别算法工程落地步骤和应用实践

– 需求分析

下面进入商品识别落地的经验介绍，首先介绍下它的基本的需求。第一，它是一个自助的设备，自助完成完成订单并结算；第二，它的准确性的要求很高，结算是不能够有误的；第三，顾客要容易学习，使用方便。根据这三点基本的需求，我们确定产品的模式，是通过摄像机拍摄所有待识别的商品，利用CV进行检测，完成生成账单并结算。

根据场景需求，要考虑它的结构以及外观是否可以完全辅助我们的算法。第一点是结算台的区域设计，这关系到整个产品的大小，以及一次性检测商品的容量，根据我们所服务的便利店以及餐饮的模式，平均每人每单商品的数量大概是在4件左右，结算台的大小是按照这种标准去设计的，大概五六件商品，而且在摆放的过程中是留有充足的空间，不会挤在一起，从而去降低物品遮挡的可能性。对于我们应用场景，大小已经适合了，若面积更大，可一次性识别东西更多，根据购物习惯，更容易造成堆叠。

第二点是摄像头的选型，因为摄像头的位置是固定的，我们推荐是选择一个定焦的摄像头，因为变焦的摄像头很难去固定环境，这影响数据的稳定。另外要尽量用一些宽动态的模组消除对强光的影响。下一个选择是用2D还是3D的摄像头，3D有一个距离的信息，对于不在同一个面的物品，它的分割效果是可以的，但是也不能完全解决遮挡的问题，若被完全遮挡，3D也是搞不定的。从综合成本上考虑，最终选择2D摄像头。

第三点是摄像头该如何布置？首先，多个摄像头可以提高在遮挡情况下的准确率，但是通过融合两个摄像头的结果来看，提升的效果并不多，因为系统不知道应该相信哪个摄像头多一点。这里用到一个集成算法的思路，但这种思路，最好是用在异构的算法或异构的数据信号上，也就是这些算法或信号具备的能力完全不同，这样效果会更明显一些。所以，还是先用一个摄像头进行设计。

对于角度问题，如果商品的特征集中在顶部，可直接采用一个垂直向下的角度，而且这种角度，遮挡的可能基本消除。但在便利店的场景中，需要识别很多瓶子类的商品，它的特征集中在侧面，就须架起一定的角度。以我们的经验，大概是用到70-80度的角度，既能够看到侧面，又不会增加太多的前后遮挡。

– 模型需求

下面进入模型选择的问题，选择模型首先要制定一个客观的指标，一般用常规的mAP、召回率、准确率，要客观的去评价待测的模型，帮助快速筛选出候选的模型，模型的选择可以遵循以下四个提示：

第一，预训练模型是否能够搞定，如果能搞定，就不需要再做多余的训练，其他的业务或场景是可以参考的，但显然在CVPOS上面是不可以的，我们需要更多的业务数据；第二，不能忽视传统的方法；第三，是要用多模型的组合，还是用一个端到端的模型；第四，是模型是否容易训练和部署。

第二到第四点其实是在做一种选择，我们是要选择一个端到端的模式，还是用多种方法组合的模式，端到端在研究领域上比较受欢迎，但是在工程上，端到端并不顺利，因为它的耦合性太强，兼顾到的功能会比较多，所以训练起来有点困难。但是在工程上追求的是灵活，所以很多时候问题是需要分开处理。比如可以将整个目标检测模型分成检测和分类两个模型，由于平常在工程上出问题，可能只会出现在其中一个模型上面，我们去优化去改进，就只需要关心那个模型就可以。这样可以大大简便后续的一些维护工作。所以，我们的模型是要用一个双模型的方式，即目标检测模型+分类或商品检索的模型，双模型组合。

– 数据需求

对于数据上的需求，可以先选用公开数据集或网上的数据，对模型进行训练和对比，评判模型的可行性。在了解产品具体的场景后，将自己的业务数据回流，去迭代自身的模型，形成一个自制的数据集。自制数据集还有另一种方式是自己生成组合的数据集，但实践上这两个其实都有效的，但是数据闭环的方式是短期内提升精度最有效的方法。对于数据增强，有一部分是凭借自己的猜测，所以不能完全模拟真实的数据的分布，它的效率并没有数据闭环高。第四点是标注的成本，分成三种，人工、全自动和半自动，人工和全自动显然是不可以的。若为全自动，就证明你的模型是正确的，就不需要再训练。

折中选择半监督的标注方法，用比较好的预训练模型去做预标注，然后通过人工把置信度比较低的标签修正过来。数据标注成本的另一方面考量是，它会直接影响到最终模型的选择。由于现在选定的是一个目标检测，为什么不选分割任务？因为分割的标签非常难打，而目标检测只需要一个框，所以优先要考虑用目标检测的模型。选择打框标签也发现另一个问题，因为在同一张图上可能会出现多个类别，这样打起标也非常麻烦。所以，双模型的方式可以很好的解决这个问题，打标签的时候只需要关注框的位置，而并不需要再去选择到底是哪一个分类。

下面介绍下我们的经验，一开始选用经验性能比较好的模型，然后在公开数据加上一点实验室数据，而实验室数据的产生如上图所示。左边两幅图是旷视在19年发布的一个商品的数据集-RPC，而我们的采集方式跟它类似，也是用各个摄像头的角度去拍摄商品，然后通过旋转的转盘把各个角度的信息录入，最后通过语义分割或实例分割，把他的掩膜mask给取出来之后，再进行商品的组合。

右图是在17年时做的一个组合，虽然没有RPC的阴影效果，但对于最终训练的作用是差不多的。最根本还是真实场景的问题。通过数据的训练，在实验室跑的成绩非常高，但放到了现场，下降30%是很正常的，从而证明了训练和测试的数据分布是不一致的。

– 落地的困难

落地的困难有以下3点，第一，与benchmark相距甚远；第二，商品种类繁多，在不同商户之间利用率是非常低，标注困难等；第三，维护的频率非常高，需要有相当高的及时性。那针对上面的这三个要求做了一些改进。

– 改进

首先，当然是数据闭环的问题，我们对环境做了一定的要求，限制场景，并开发采集工具及结果的错误检查工具，可以让现场的数据快速回流到模型的基础训练集里面，及时地更新学习。数据采集方面，直接放弃了实验室环境，直接开放给店员采集，用现场的数据。在采集的过程中，对于相同的商品，可以通过不同角度、方位，按照一定规则进行采集。如果有多家门店有相同的上新需求，可以把采集任务分配到各个门店，平均每一个门店的采集任务就降到比较低，基本没有增加额外的成本。对于标注，采用半监督检测标注，用一个比较好的预训练模型去做预标注，在通过人工的筛选，把置信度低的样本给调整过来。

第二个是多模型组合，上图有两个模型，一个是检测模型，另一个是分类模型，除了可以解耦合，让标注更简单，对数据模型更容易的管理以外，还可以解决目标检测上样本不平衡的状态，我们只需维护一组专门用来拟合检测模型的训练数据，其他的平衡的问题交给分类模型进行处理。

另外一个问题是样本需要时间的管理，假设在同一年里有三段时间，它的外形是不一样的，这时需要商品的时间管理，利用时间的管理进行样本的平衡，可以针对不同时间加不同的权重，比如近期的数据会多一点，远期的数据少一点，生成一个适应较长时间段的训练集。

第三是建立一个商品的预训练模型，可以根据不同种类建立不同的预训练模型，这可以加快fine-tuning的速度。第二个是困难样本的反馈训练，这是一个闭环的fine-tuning过程，及时将这种出错的样本回收到训练集里面，通过这种fine-tuning的方式，把这一部分没见过的数据拟合过去。最后，要开发一个管理工具去管理训练任务，做好任务的排序以及资源上的调度。

– 落地的其他事

第一点是部署，开始是从云端开始部署，然后慢慢就变成前端，因为前端可以节省成本；第二点是模型的压缩，可以利用一些比较成熟的框架，比如飞桨，进行模型的压缩，可以发现在精度没有下降的情况下，收益都非常可观；第三点是检测和分类模型上的优化，检测方面发现一些Anchor-Free的效果比在Faster-RCNN的效果要好，所以尝试用一些Anchor-Free的模型验证自己的数据集，在分类方面，主要是用损失函数去加大分类之间的margin，可以参考一些人脸识别相关的损失，这些都可以加大类间的距离；第四点是习惯的培养，习惯培养反而是最困难的，因为习惯比较难培养，这也是在很多地方没推广起来的一个原因。

我们有两点比较实用的建议，第一，可以提示一个摆放的位置，虽然不高级，但一次成功识别率应该是会大大提高。第二，不去培养顾客，专门培养店员，让店员使用这个产品，尤其是对烘焙、餐饮这种非标品，店员就不需要专门的手工录入信息。从这个层面来讲，它确实也是可以提升最后的结算效率。

对于产品的鲁棒性问题，因为一些客观原因，识别率做不到100%，所以必须要有一些辅助工具去保证模型的更新速度，包括采集、标注、训练、验证部署等，都要通过工具去管理，通过工具让我们发现错误。另外还有一个恢复机制的问题，第一种恢复机制是机器上的恢复，可以用一些校验的手段，比如加重力传感器去校验识别结果，或者用多个摄像头的集成思路去投票等，置信度较低时，可以提示下客户去重新摆放。另一个是要有一个人工快速介入的管理机制，不要让使用失败的顾客等。所以收银机不只是一个产品或是一个算法，它需要整个运营系统相互配合。

– 总结

总结主要分为以下几点：首先，大目标减成本是不变的，所有产品的设计都要围绕着总成本不变的目标，然后我们依据这个目标以及一些资源需求选择合适的模型，第3到第5点，是算法维护而产生的一些新功能需求，也就是在产品的设计中要保留数据闭环的机制，也要有相应的开发效率的工具，查错的工具，能够快速训练迭代等，另外产品要有自校验、自恢复的机制，不管是机器自己完成还是人工干预，我们的整个运营模式里必须包含这一块才能保证整个产品有序的运作下去。最后是产品是易用的、习惯可培养的。

https://zhidx.com/p/216094.html