code前端网微信扫码识别物体的“切”“搜”手法大揭秘
微信扫码识别物体是典型的“离线写作，在线阅读”。保存公司信息和建立搜索数据库都是在离线模式下完成的。我们通过索引系统将产品图片收集到小程序的生态系统中。上传后，我们对图片进行检测和裁剪，提取搜索特征，最后构建搜索数据库并交付到Web环境。本文主要介绍这部分工作。
0什么是物物
物物以图像或视频为输入，挖掘微信生态中的产品、物品等有价值的信息。这里我们基本覆盖了微信上的全品类优质小件电商，覆盖上亿个SKU。我们从搜一搜、搜狗等微信信息中收集信息，最终合并后呈现给用户。百度看图、阿里图片淘宝也都是基于该技术开发的。
在工程工作中，物体识别的工作主要可以分为三个部分，如如图一所示： 
图1
- 算法模型
主要关注连续检测模型的算法细化。多类别搜索模板。 ，识别模型必须返回图像中物体的准确位置；搜索模型必须保证同一对象的属性表达式尽可能接近。
- 线下策划
认可是典型的“线下写作、线上阅读活动”。公司数据的存储和搜索库的构建都是在离线环节完成的。我们通过索引系统将产品图片收集到小程序的生态系统中。上传后，我们对图片进行检测和裁剪，提取搜索特征，最后构建搜索库并交付到Web环境。本文主要介绍这部分作品。
- 在线部署
离线创建的算法模型和搜索数据库终于实现并可供外部服务。当用户识别一个对象时，搜索库会返回一组相似的对象，然后经过一组复杂的排序和过滤逻辑，最终返回用户看到的结果。
1挑战
- 数据版本
数据版本主要分为两类。一是算法模型版本。我们有10多个商业模型，平均每周有2-3个模型迭代更新。第二个是搜索库版本。当模型不迭代时，每天都会组合新的数据，即增量迭代；每次算法模型发生变化，特征表达就会发生变化，搜索库就必须根据新的特征重新构建，即全迭代。 。
在版本频繁变更的情况下平衡公平性和安全性。
- 计算能力
目前，我们已经收集了约10亿张图像，平均每天新增1500万张。除了大量的图像之外，还有很多任务流程，比如下载如图电影、物体检测、特征提取等任务。每个任务每天都需要数千万次的数据处理运算。
如何有效处理数据，提高业务迭代效率。
- 复杂的流程
随着业务的发展，简单的业务流程已经无法满足我们日益复杂的业务需求。为了提升业务指标，我们可能还需要图像质量、文本语义、死链接、下架产品过滤等任务。
当进程数量增加时，如何避免整个系统的臃肿。
- 数据质量
离线规划是一项流程繁重的业务。数据从生成到实现要经过九个或八十一个循环。任何一个环节的错误都会导致结果出现问题。问题发现得越晚，解决问题的成本就越高，评估其对业务的影响也就越困难。
如何科学地监控和管理数据质量，使系统具有良好的可维护性。
2 数据版本
数据版本存在多个维度，如模型版本、特征版本、搜索库版本等。上游链接的版本变化会触发后续链接的变化，最终导致搜索库版本更改。 
图2简化数据流图
2.1搜索数据库
在我们的业务场景中，搜索数据库的迭代是一个高频次的操作。一般情况下，每天都会逐步更新，模型变化会触发搜索库全面更新。从数据规模上来说，我们的图片总数是几亿级，划分类别之后，每个类别也是几千万级。
我们探索了主要在工业中用于搜索图像的技术，如《如图》3 所示。经过多方考虑，我们选择了faiss-ivf作为我们的索引建库算法，该算法更加灵活，内存占用也更小。 
图3 图片搜索库选择
对于日常附加信息，我们每天为每个类别（10+类别）构建对应的当日数据搜索库。通过组合N天搜索库（faiss-ivf功能），创建每个类别的完整搜索库。连接2000w数据仅需4分钟。基于这样的设计，我们可以灵活选择时间窗口区域。如图3展示了与窗口2的合并方法。
这样做的好处是，如果某一天的数据有问题，只需要修正当天的数据即可进行合并；如果您需要丢弃一些数据，例如旧数据，则不能在合并过程中仅选择它。 ？模型。当新的搜索数据库上线时，基本上是新旧信息之间的过渡。通常，复杂的系统旨在确保新旧数据切换时的数据一致性。
2.2.1 模型变更检测
严格来说，在这个场景中我们并没有实现数据库变更时新旧数据的一致性。我们只是用一个简单的方法来做，即使新旧数据同时存在。不影响用户体验。
这主要涉及建立我们的映射关系。我们为每个观察到的结果分配一个唯一的单调递增 ID。改变模型后，同一图像的识别结果会发生变化。手术的位置可能会改变，可能会缩小不同的目标，或者可能会缩小多个目标。
如图 5表示搜索库v1只有顶部部分，对应的Search ID为1；更改检测模型后，搜索库v2可以同时检测上半部分和下半部分，对应的搜索ID为2和3。这样在线模块可以逐步更新搜索库，旧的和下半部分没有影响。新的搜索数据库同时在线存在。如果请求命中旧数据库则返回1，如果命中新数据库则返回2，但最终还是返回了正确的结果， 与 一致。 
图5 感知模型变化
2.2.2 搜索特征模型变化
该场景下的搜索数据库变化要复杂得多。搜索存储库的属性来自搜索属性模型。改变搜索模型后，同一物体图像的特征表达完全不同，甚至维度也发生了变化，如如图6所示。
我们需要同步搜索特征模型服务和新搜索库的变更，通过双缓冲区实现新旧数据共存，并实施严格的路由协议以保证请求在同一版本的特征搜索服务和搜索库上执行。 
图 6 搜索特征模型变更
2.3 数据版本控制系统
在开发过程中，算法必须将各种模型交付到离线和在线模式，离线模式下创建的搜索库也必须交付到在线模式。而数据版本迭代还必须考虑版本可逆性。为了分离多方之间的依赖关系，避免同步过程中直接访问文件带来的风险，开发了数据版本控制系统。
如如图7所示，资源发布者将资源连同相应的公司、版本号和md5一起上传到系统。资源使用者只需要了解对应公司当前的版本号，版本控制系统就会返回对应的资源文件。在线模块在实际在线使用时，定期训练特定公司对应的数据版本文件的md5与本地文件的md5是否兼容。如果不一致，则拉取最新文件。获取完成后，将检查 md5 的一致性，最后应用更新。
当业务模型或搜索库需要恢复时，只需更改配置文件并重新启动服务即可。 
图7 数据版本控制系统
2.4 对接
物体识别、提取搜索属性等是典型的图像深度学习任务。领域内有各种深度学习框架，如caffe、pytorch、tensorflow、tensorRT等，有些框架无法保证向上兼容性。炼丹学员的首要任务就是追求影响力指标。我们在尝试各种稀奇古怪的技术时所修炼的丹药，通常与微信的网络环境不太兼容。
总之，一个有算法的设计系统不仅有业务代码的更新，还有设计环境的迭代。这对于使用docker来封装和迭代企业环境来说非常有用。 Docker的采用让我们可以更方便的部署更多的开源组件来支持业务，同时也让我们在一些框架的选择上更加灵活。
对于我们自己的业务场景，我们也可以利用微信深度学习任务平台（piha）的计算资源。这部分是公共资源，应该予以考虑。院子里还停靠着执行任务。这为我们尝试使用公共院子资源临时扩展工作节点铺平了道路。
3分布式计算
我们平均每天新增数据1500万条，数据总量达到数十亿。单机可能无法满足处理效率，只有分布式计算才能满足要求。
3.1 共享数据
就像mapreduce一样，我们需要在map阶段共享数据。划分原则不仅考虑平均值，还考虑划分后的数据传输时间。 如果划分太细，GPU性能会下降，如果划分太粗，纠错的时间成本会增加 3.2 数据的并行计算 共享数据的并行计算对应于归约阶段。这里我们重点讨论共享数据如何分布在多台机器上进行计算。另外，我们也希望公共资源闲置时能够灵活扩展使用，提高并发处理能力。 我们结合zookeeper的分布式锁特性，实现了一个可靠的分布式任务队列。员工使用草稿模式从队列中检索任务。这样做的好处是扩展性好，可以灵活增减堆场的机器资源。如图 8、当有新员工挂职时，将任务从队列中拉出来直接执行，这样可以实现另一个层面的扩展。 图8 良好的可扩展性 在我们的场景中，任务必须被可靠地消费。可靠性在这里有两个含义。 首先是避免重复任务。我们使用动物园管理员呼吸锁，通过心跳保持锁处于活动状态。在如图9的时刻1和2中，worker只有成功从队列中抢到锁后才能完成任务；如果机器停机，则在如图9的第三个时刻自动解锁。 第二个是完全消耗。我们只有在任务完全消费完之后，才将对应的任务从队列中移除，比如时间4的task2。在时间3，task1由于机器宕机，还没有完全消费完，所以它仍然存在，以后可以使用。 图9 可靠消费 理论上，我们的消费模型至少包含一次消费（至少一次）。极端情况下，如果worker完成任务后崩溃，尚未恢复状态，则任务仍处于该状态。如果没有被成功使用，仍然可以被后续的worker消耗。这里需要保证赋值的幂等性。 公共计算资源的引入提高了我们的处理能力，但也给我们带来了一些小问题。比如公共集群的机器配置就比我们自己的集群好很多。为了让不同的集群能够最大化GPU性能，我们支持不同的集群使用不同的全局参数配置。另外，公共集群和文件系统不在同一个IDC，导致网络IO时间过长，降低GPU使用时间。我们在公共集群的同一个IDC中实现了文件预取系统。根据任务队列中的任务，系统可以提前进行预绘制。将消耗性文件同步到同一IDC的文件缓存系统中。 为了提高GPU的使用率，我们也做了很多技术上的优化，这里不再赘述。基于分布式计算的参考框架极大地提高了我们的计算能力。我们以计算能力最低的目标识别任务为例。目前，我们集群的处理能力可以达到每天5600万张图像。如果加上公共计算资源，可以达到1.2亿张图像/天（集群12个P4双卡，公共集群yard-g7a集群平均10个双卡，深度学习框架使用的tensorRT）。 虽然我们每天有大约 1500 万张原始图像，但最终填充搜索数据库的产品还不到一半。因为为了保证检索到的信息的质量，我们会进行多个维度的数据过滤。现在我们的图片从上传到数据库创建总共经历了30多个中间任务。图10仅展示了主任务的流程模型。 图10任务流程 4.1任务体系 随着任务的增多，尤其是多个任务之间存在复杂的依赖关系，每个任务都不是一个独立的个体，每个任务的成败取决于意志和执行者的意愿。最终结果。为了更好的管理每个任务的状态，理清任务之间的依赖关系，让项目的复杂度不随任务数量的增加而增加，我们开发了自主研发的任务调度系统。 调度系统主要由以下几部分组成： 图11 任务调度系统 在容灾方面，调度系统相关模块已在多台机器、多个园区实现。只要特定模块没有完全失效，整个任务调度序列就可以正常执行。 4.2 结合在线服务 日常工作效率不敏感。提前几个小时或晚几个小时对业务影响不大。但是GPU资源非常宝贵，所以我们将一些GPU机器和在线GPU服务部署在一起。结合网络流量保护策略，可以在高峰时段借用在线服务的资源，并在高峰时段以外运行离线任务。 如如图12所示，它是一个在线模块，参与离线任务的空闲时间调度。我们建议每天0:00 AM-7:00 AM的低峰时间为离线使用时间，7:00 AM-12:00 AM的高峰时间为在线模块。服务时间。最大限度地利用宝贵的机器资源。 图12 分时调度功能 前期工作以任务的准确性保证了我们项目的可靠性，但任务的成功并不能保证公司数据的完整性，例如数据丢失、代码逻辑问题等。为了在数据维度监控业务质量，我们构建了基于ELK的信息系统，主要用于收集重要的基础数据、业务数据、运营结果等。 5.1 数据可视化 我们已经开发了多个版本。迭代过程中会检测到数据错误，但检测错误的成本非常高。因此，我们希望随时观察离线系统是否正常工作，数据流向是否符合预期。当出现问题时，可以及时干预和纠正，降低错误成本。 我们报告与数据流相关的核心任务的数据结果，以便我们可以通过数据漏斗发现是否存在问题。当 以完整信息 重新运行时，这个问题尤其重要。图 13 显示了有关该项目核心任务的信息。 图13数据漏斗可视化 上图看起来像是每日任务级别的数据跟踪，但实际上我们的计划扩展到**每个任务级别（这里由planid定义），**既可以是每天或者它可以是一次涵盖几天的最新一期。我们根据图 14 中的字段报告业务结果。前4个字段形成共同的唯一索引，并且planid用作逻辑字段来分隔每个动作。这样，即使不同时期运行同一个任务的结果不同，我们仍然可以区分每次运行后的实际数据结果。这种设计对于保证每次重大发布数据迭代期间数据的整体运行质量得到控制是非常重要和有效的。 图14 报表字段 5.2 一致性检查 数据可视化可以更方便地检查问题，但并不能帮助我们发现问题。当数据出现问题时，我们还需要能够提供及时的警报和快速修复。最重要的是数据的一致性。这里的一致性主要是一些核心任务的知识漏斗。结果和输出必须一致。图 15 显示了一些相关任务，彩色线段代表数据的比例。 满足不同维度的统计和认证，同时可以快速支持新任务的审核。我们封装了核心统计和验证逻辑，并定义了警报任务，以确保经过层层处理后的结果是准确的。 ？问题不能及时发现，存在巨大隐患。基于这种情况，我们开发了自动测试系统。我们事先收集并组织了一些标记数据样本，每次更新都需要在测试环境中自动评估，如如图16所示。我们根据某些指标（关键数据的编码）来分析本次迭代能否安全启动。 图16 评估体系 5.4 数据剔除 平均每天有超过1000万条数据流过，且数据膨胀速度非常快，给我们带来了巨大的存储和迭代成本。但当你看公司本身时，实际上很多产品信息随着时间的推移而变得过时、链接和下架信息。最简单的方法就是用一个窗口期来维护我们的数据，这样窗口之外的数据就会被自动删除。我们在选择 faiss 搜索库时也考虑到了这一点。 但我们也认为直接暴力删除旧数据也会带来致命的问题。哪些信息对我们的业务很重要？普遍受欢迎的产品很重要，但相对冷门的长尾产品也同样重要。后者决定了长尾产品库的多样性。如果你删除一个产品，搜索数据库可能就没有这个产品了，这是一件非常糟糕的事情。 因此，我们在删除数据的时候，一定要考虑保留有价值的长尾产品。图 17 显示了我们的数据消除方法。这样我们窗口期内的数据质量就越来越高，数据总量的增长也比较可控。 图17 窗口期K的数据剔除 以上，我们大致实现了离线系统“扫描对象”相关的一些关键点，还有一些模块还在优化中。在中间。未来，扫描物体识别将实现多场景识别，将物体拓展至更多维度，追求“万物皆可扫描”的目标。。我们的目标是在 1 小时内完成每个共享任务，最终共享粒度为每个数据包 10 瓦左右。
4 任务计时
5 数据质量
6 总结
版权声明
本文仅代表作者观点，不代表Code前端网立场。
本文系作者Code前端网发表，如需转载，请注明页面地址。
