资讯动态

LLM如何落地零售货架审计?人机协作的实践与踩坑

发布时间:2026/10/18 17:37:49 来源:尧图企业网站定制
1. 先搞清楚一件事货架审计到底在审什么很多零售项目的需求方对货架审计四个字的理解其实完全不一样。有人以为货架审计就是拿手机拍张照数一下货架上有没有东西真正在一线管过门店的人会告诉你远没这么简单。货架审计至少包含三个层级SKU级的排面识别——这个位置到底摆的是哪个商品缺货状态判断——这个空格是暂时卖完了、根本没上架、还是本来就该空着以及陈列合规性——摆放位置和数量是否符合品牌方花钱买下的陈列规则。三个层级出错的代价完全不同。排面识别错了最轻的后果是系统里多一条无效记录全量扫完之后也没人去看。缺货判断错了问题就麻烦了系统报了一个缺货店长跑过去一看货其实在仓库还没补补货员白跑一趟还算是小事系统漏掉了真缺货那就是实打实的销售损失——尤其碳酸饮料、牛奶这类销量波动大的品类缺货一小时和缺货一天差距是数量级的。陈列合规错了受影响的是品牌方的排面权益这在零售里是一笔很大的隐性收入很多促销合同都签死了必须摆满两排面必须放在黄金视线层之类的条款违规是要被扣费的。我们在接到项目需求后做的第一件事不是选模型而是拉着门店运营、采购和品牌方三方坐下来把审计这个词逐条翻译成可量化的检查项。这个步骤容易被技术团队跳过但跳过的后果就是后期模型做完了业务方却说不清楚它有没有做对。1.1 缺货损失之外还有三本账很多行业报告都会提一个数据快消品缺货率一般在4%到8%之间缺货带来的销售损失能占到个位数百分比。但门店层面的真实压力是三本账这三本账在报告里通常看不到却是老板真正关心的东西。第一本是补货效率账。如果补货员每天要凭空判断哪些位置缺货他就得在货架之间反复来回走。我们跟踪过某社区超市的一个区域人工巡检一个区域平均要15到20分钟一天巡三次光是走路的时间就占掉一个小时。如果能把巡检范围缩小到只去疑似缺货的位置这个时间可以压缩到原来的三分之一。可别小看这个数字门店人力成本基本都花在这种重复走路上。第二本是陈列合规账。品牌商和零售商签的陈列合同规则非常细比如某款口香糖必须在收银台前三层、某饮料必须保证垂直陈列两个排面。人工检查的时候很难做到每个SKU逐个核验所以大多数门店的合规检查是抽查而且往往只看头部品牌。LLM要是能把每个排面完整过一遍相当于把抽查变成普查——这个能力过去只有大牌区域经理巡店的时候才能勉强做到。第三本是库存数据可信度账。门店的库存系统跟实际库存经常对不上差异源头往往就是货架状态没及时更新。缺货位置补了货系统没有回写库存就会虚高反过来商品已经清完下架系统还挂着库存也会虚低。货架审计的副产品就是修正这些差异让补货预测和订货计算更稳。这第三本账最容易被技术团队忽略但实际价值往往比前两本还高因为整个供应链计划都建立在库存数据可信这个前提上。三本账串起来货架审计在决策者眼里就不是一个门店内部事务而是直接影响周转率和毛利的事。这也是为什么用AI看货架是一个值得认真投入的商业问题而不只是拿来发论文的技术Demo。1.2 人工巡检为什么是一个值得被替代的活人工巡检的问题不在人懒而在人做不到稳定。一个店的SKU动辄上千每个SKU要看位置、看数量、看价签、看生产日期纯靠眼睛扫一遍前十分钟还能保持专注到了后半程就开始走神这是生理规律不是培训能解决的。我们曾经把同一个人对同一排面的两次巡检结果做对比间隔只有半小时漏看率都能差出好几个百分点。缺货这种状态本身也是时间敏感的晚发现一小时可能就少卖好几件商品。人工巡检做不到实时一般门店一天最多巡两三次很多缺货要等到下一次巡检才能发现。如果再叠加人员流动问题就更大了——老员工一走巡检标准也跟着走新员工对陈列规则不熟经常会看着满满当当的货架就当没事实际却存在大量错排。这些恰恰是技术最擅长补的一致的标准、高频的扫描、自动留痕的记录、跨排面的比对。所以从业务逻辑上讲货架审计被AI改造的条件早就成熟了。之前的瓶颈不在业务需求而在底层模型对复杂货架场景的识别能力以及识别结果之后该做什么的判断。这两件事前者靠视觉模型后者正好是LLM的主场——这也是我们真正想验证的问题LLM到底能不能把这两件事顺畅地接起来。2. LLM想端到端搞定货架审计得先过感知这一关我们团队对这个问题的探索是在一次原型验证里扎扎实实踩过坑之后才走上正轨的。最早的思路很直接把货架照片整张丢给多模态大模型让它直接输出这排有没有缺货。试了一个月效果远没有想象中好。原因是货架照片的信息密度太高了。一排货架上有几十个商品包装颜色相近、瓶型相似模型很容易把某款红色包装饮料和另一款深色酱料搞混再加上价签、促销立牌、照明反光、顾客的手臂等大量干扰多模态模型在同一张图上做密集目标识别准确率会明显下降。这不是模型能力差而是任务形态不合适——货架审计本质上是一个密集检测结构化推理的组合问题不应该让单一模型一口吞下。2.1 感知层的现实视觉模型管看见LLM管看懂我们最终的方案是拆分先用一个专门训练的目标检测模型把货架图里的每个排面、每个SKU候选框找出来再用OCR把价签文字读出来。这一步输出的是货架上有什么、在哪个位置的中间结果。然后把这些结构化的中间结果以文字形式喂给LLM让它基于这份清单做判断。换句话说LLM看到的不是一个像素网格而是一份类似这样的清单排面号: A-03-2 层号: 3 位置: 左起第4个 商品编码: SKU-78012 识别名称: 某品牌柠檬味碳酸饮料 库存量: 3 价签OCR: 某品牌柠檬味碳酸饮料 500ml 售价5.5元 货道编号: STA-03 货道库存: 0这个拆分有两个好处。第一目标检测模型可以在我们自己的标注数据上微调把漏检率压到很低第二LLM拿到的是干净的、结构化的输入它的任务是组合判断——比如A缺货但旁边B正常且A货道库存也为0说明是真实售罄或者A缺货但是促销立牌在说明可能正在做堆头调整。这种逻辑判断目标检测模型做不了但让LLM读结构化清单做推理是它最舒服的姿势。经验之谈不要指望用一个模型做完所有事。单模型方案在货架这种高密度场景里既不会省钱也不会省事调试周期会成倍拉长。拆分后每一层的问题都变得容易定位和替换。感知层还有一个容易忽略的点摄像头选型。我们一开始想直接复用门店现有的监控摄像头理由很充分——省钱、不用新装设备。但实际去门店看了一圈就放弃了监控摄像头的安装角度、分辨率、帧率都是按安防场景设计的不是按货架拍摄设计的。货架顶层和底层之间的视角差异很大监控很难同时拍清整个排面而且帧率是摄像头的不是我们可以远程控制的。后来改成人工用手机按固定路线拍摄反而稳定得多。这个结论有点反直觉在货架审计场景移动端随手拍加固定拍摄规范比安装固定摄像头的方案更靠谱也更便宜还更容易在不同门店复制。2.2 推理层的挑战什么叫缺货得先定义清楚就算感知层拿到了完美的结构化清单LLM要做的事也远不止数量是否为0。门店里一种常见情况是某个SKU在排面上数量为2但这2件商品其实是从隔壁排面被顾客拿过来随手放下的。只按数量判断系统会认为正常按SKU归属判断它属于错排。LLM需要结合上下文——相邻排面的商品是否一致、货道编号与商品名的匹配关系、该位置的历史犯错概率——才能给出正确的结论。这种跨排面的逻辑人工一眼能看出来模型要靠推理才能做对。还有一种更微妙的情况我们内部管它叫幽灵缺货排面上看着是空的但这不代表卖完了。可能是商品在仓库有货、还没来得及上架也可能是因为促销规则调整这个位置本来就被留空。如果系统没有活动日历信息LLM很容易把所有空格一律报成缺货造成很高的误报率补货员跑两趟空路之后就不会再信任系统。所以我们在方案里把缺货判定拆成了好几层推理先看这个空格是否在尾货清仓区再看该SKU在系统里是否处于活动期禁上架状态然后看同一系列商品是否已经补过一轮货最后才结合货道库存判断应该是补货延迟还是真实断货。LLM读结构化清单和状态数据之后输出的不是一个简单的缺货/正常标签而是一个带原因的判断。这个带原因的输出是整个项目信任度提升的关键——人工核验的时候看到判定缺货货道编号5在系统内库存为0距上次补货超过6小时且同排面左右商品均为正常状态就愿意相信系统如果只有一串红字判断没有任何解释店长很容易产生抵触。2.3 幻觉与数值敏感性LLM做审计的第二个坑结构化输出能解决不可用的问题但解决不了幻觉的问题。LLM在生成JSON的时候可能会编造一个清单里并不存在的SKU编号也可能把数量从3写成5。纯文本场景里这算不上大事但在审计场景里任何一个幻觉出来的记录都会进入下游系统轻则污染统计重则误导补货决策。我们针对这个问题做了三件事。第一提示词里明确规定只能使用输入清单中出现过的商品编码不得自行创建或改写。第二在代码层做了一道强校验LLM返回的JSON里所有sku_id必须能在当次输入清单中匹配到匹配不到的直接整条丢弃并标记为识别失败。第三把温度参数调低虽然生成结果会变得保守一些但可预测性明显提升。说实话这三件事里最起作用的是那道硬校验。LLM的推理能力再强在数值上仍然不是一个可靠的计数器。让LLM做逻辑判断让规则代码做数据校验两者各管一摊这是我们在试点中反复验证后最稳的组合方式。3. 我们在某社区超市跑了一次八周试点理论拆解得差不多了真正能说明问题的还是落地实验。我们联系到某社区超市规模不大不小SKU数大概两千出头选了饮料区和零食区作为试点范围合计约四百个排面每周采集两次数据总共跑了八周。先说清楚这次试点并不是把全部判断都交给LLM做一个黑箱。我们搭了一条流水线目标检测模型负责出框OCR负责读价签LLM负责汇总推理最后人工抽检复核。LLM不是决策的全部而是决策链路里最核心的一段。这个定位从一开始就要跟门店讲明白——AI是辅助工具不是无人系统。3.1 数据采集方案一部手机加一份拍摄规范拍摄这一步看起来最没有技术含量实际上是决定整个项目成败的一环。我们一开始让大家随手拍结果照片角度、距离、曝光差异巨大目标检测模型的漏检率从5%直接跳到20%以上。后来我们定了一份拍摄规范核心就三条手机站在货架正前方镜头与目标层平行距离控制在1.5米左右每层排面单独拍一张不要试图用一张照片拍完整个货架拍摄时间固定在早间开门后和晚间补货前。为什么强调镜头与货架层平行因为俯拍或者仰拍会让商品标签发生透视变形OCR识别率会明显下降。平拍的时候把每层排面的上下边缘都留一点余量既能保证对齐全层商品又不至于把地面和天花板拍进去太多。拍完之后数据先经过目标检测模型做初筛把明显的空排面和正常排面直接分流只有存在争议的排面才带着结构化信息进入LLM。这样做的原因是控制成本如果每个排面都交给LLM处理API调用量会很大只让LLM处理争议样本平均每次巡检需要LLM参与的图不到总量的三分之一。成本这关要在这个环节就开始设计而不是等账单出来了再想办法。3.2 提示词与结构化输出的设计细节LLM的输出格式是我们反复调过的重点。第一次测试我们让模型自由描述货架状态输出结果像一篇自然语言散文准确率不低但下游系统完全没法用。后来所有输出都限定为JSON结构字段固定为sku_id、位置编号、预测状态、置信度、原因说明、建议动作。原因说明用简短文本建议动作只能在补货、调整陈列、待观察、无需动作四个值里选一个。字段固定之后人工复核和后续的系统对接都顺了很多。提示词里有一句话我们反复验证过值得单独分享明确告诉模型宁可标注不确定也不要硬猜。不确定状态会进入人工复核队列而硬猜的错误会直接污染系统状态。这个让模型有认怂权限的设计直接降低了误报率也避免了AI系统在门店里被快速弃用的悲剧。另一个发现是关于上下文窗口的用法。一开始我们试图把历史巡检记录全部塞进去想着让模型更了解这个货架的脾气。结果输出反而飘了模型可能因为历史数据里的某个异常事件对正常排面产生过度反应。后来改成只传最近一次巡检的状态加上当天的库存系统数据效果稳定很多。上下文不是越多越好这条经验我们在很多场景里反复验证过LLM对上下文里诱因性信息的处理目前远没有想象中聪明。3.3 踩坑记录促销立牌、货架遮挡与光线反光八周试点攒了一堆具象的坑每一个都能单独写一篇踩坑复盘。这里说三个最典型的。促销立牌是最普遍的干扰源。饮料区经常挂着大面积的活动立牌直接挡在商品前面。目标检测模型还算争气框能出来但OCR会把促销立牌上的大号文字当成价签导致LLM拿到一份SKU名称为买一送一的奇怪清单推理自然就乱了。我们的解法是加一道过滤规则OCR出来的文本先跟库存系统的SKU名称做模糊匹配匹配不上且文本长度又明显不符合SKU命名规则的直接标记为促销物料不参与后续推理。这一步加上之后因为幻觉SKU导致的错误直接清掉了大半。货架遮挡出现在垂直方向。下层货架如果放着高一点的箱子上层货架的底部光线会被挡住形成一条阴影带。商品明明没有缺但目标检测模型容易把阴影带误判成空排面。我们试过用图像增强算法提亮阴影效果一般后来发现最省事的办法是控制拍摄时间在门店已经开灯、又没有顾客进出干扰的早间时段采集阴影问题基本消失。光线反光则主要发生在小包装零食的铝箔包装上。金属反光会让目标检测模型把同一个商品框出两个不完整的框数量统计直接翻倍。这个问题在后处理里加了去重逻辑解决两个框的重叠面积超过50%且SKU相同合并为一个。这些都是感知层的琐事但实际项目里这类琐事占掉了我们大约一半的开发时间。这也就是为什么LLM审计货架这件事不能在提示词层面单点发力——真正的工程复杂度都在数据管道和容错设计上。3.4 冷启动的另一个问题没有历史数据怎么校验还有一个经常被忽略的问题一个门店之前从没有做过AI巡检凭什么让店里的人相信AI的输出是对的我们的办法是搞了对照周前两周不启用AI巡检人工按老办法巡检并记录结果同时AI方案在后台静默跑两边结果只做对比、不对外发布。对比之后发现AI在排面数量这类硬指标上已经接近人工在缺货原因判断这类软指标上还存在分歧但有意思的是分歧大多来自人工之间本身就不一致——两个人对同一个排面的判断也有差别。这算意外的收获AI不只是替代人工还成了统一标准的参考坐标系。有了这两周的对照正式启用时店长对输出结果的接受度明显高了因为大家已经看到AI跟老师傅的判断基本在一个水平线上。4. 实测结果与三个意料之外的数据八周试点结束之后我们整理了一份内部评测报告。这里可以把主要结果放出来但先提醒一句所有数字都来自这一个样本门店不代表行业普遍水平仅作方案对比参考。4.1 评测口径准确率不是唯一指标我们一共统计了三个指标排面识别准确率、缺货召回率、缺货精确率。排面识别准确率衡量模型说的位置和商品是否真的对得上缺货召回率衡量真实缺货里有多少被系统找出来缺货精确率衡量系统报出的缺货里有多少是真的缺货。后两个指标之间的平衡对落地体验影响最大。召回率太低漏报缺货精确率太低天天虚报缺货补货员跑麻木了整个系统就会被弃用。在这个口径下排面识别准确率大约96%比预想的好缺货召回率大约87%缺货精确率大约82%。人工复核一批误报样本后发现精确率上不去的主要原因是定义分歧——有些排面货架看起来确实是空的但门店觉得反正补货员马上就到就不算缺货。这种业务定义上的问题单纯靠改模型解决不了需要系统设计时留出人工复核入口把争议样本交给店长用业务逻辑裁决。4.2 各品类SKU的表现差异不同商品在LLM审计里的表现差异非常大这一点经常被技术团队忽略。试点里饮料类表现最好因为瓶型标准、标签材质稳定、视觉特征明显零食类表现中等问题集中在多语言包装、小尺寸标签表现最差的是散装称重区因为同一个SKU可能被分装成完全不同的包装形态目标检测和OCR都容易翻车。另一个反直觉的发现是SKU数量多的排面反而好判断因为模型能从多个同类商品中互相验证这是一个正常排面反而是单个SKU独享一整个排面的时候只要有一件商品放歪了或者被顾客碰倒模型就倾向于判成异常。这个观察告诉我们审计系统要针对不同类型货架设计不同的阈值和容忍度一刀切的标准是走不远的。4.3 与人工巡检的横向对比成本对比让我印象很深。按这家超市原来的习惯饮料和零食两个区域每天巡检三次每个区域一次人工巡检平均耗时18分钟折算下来每天约1.8小时人力。AI方案每天早间和晚间各采集一轮每轮从拍照到生成报告大概20分钟人工只负责拍摄和最后抽检识别与推理全由流水线完成。按门店总面积放大到全店约5000个排面估算AI方案的人工时间大约是传统方式的五分之一。需要说明的是AI方案省的是重复巡检的时间而不是区域决策的时间——缺货发现后的补货决策、陈列调整、供应商沟通依然需要人来执行。这个边界必须在项目立项阶段就跟业务方讲清楚否则上线之后的预期一定会错位业务方以为AI能解决所有问题结果发现还要保留人工环节心理落差会很大。4.4 翻车样本画像四类典型错误评测报告里最有价值的部分是错误样本归类。我们把所有误判样本拉出来一帧一帧看最终归成了四类。第一类是促销干扰典型场景就是大号促销立牌遮住了商品主体OCR读到的全是活动文案。第二类是白牌商品——超市自有品牌或新上架的无品牌包装在训练数据里几乎没有类似形态检测模型很容易把它框成未知对象LLM拿着这个未知也没辙。第三类是高相似包装两款不同品牌的商品主色调、瓶型几乎一样只靠包装角落的小字区分检测模型给出的置信度普遍偏低。第四类是时空混淆同一排面两次拍摄时间相隔较大中间发生过补货AI在对比时把状态差异误判成异常。每一类对应不同的解法促销干扰靠过滤规则白牌商品靠冷启动标注高相似包装靠追加训练样本时空混淆靠缩短采集间隔并引入补货日志。这个分类方法后来成了我们内部复盘的标准模板——以后再遇到新误报先归类再定方案而不是头痛医头。5. 结论现在到底能不能用回到标题的问题Can LLMs audit a supermarket shelf yet?我们八周试点的结论是离全自动审计还有距离但已经在人机协作审计的实用范围内了。LLM真正解决的不是看的问题而是把看的结果变成业务判断的问题。如果你的目标是建立一套高可信度的感知层用LLM自动生成带原因的缺货清单和陈列问题清单那现在完全够用如果你的目标是完全去掉人工抽检让机器全包恐怕还要等视觉模型在复杂货架场景里的鲁棒性再上一个台阶同时也需要门店业务流程本身更标准化。5.1 现在就能落地的三个场景第一个是高频缺货监测。饮料、牛奶、纸巾这类销量波动大且陈列规律的商品LLM加检测模型的组合已经能做到每天两次的自动对比及时捕捉缺货状态。第二个是陈列合规普查。品牌方和零售商签了陈列合同但没有足够人力逐店核验用LLM把排面照片批量比对陈列规则可以在不增加门店工作量的前提下完成合规审计相当于把抽查升级成普查。第三个是供应链数据修正。货架状态跟库存系统经常对不上用巡检结果反向回写系统补货逻辑能让补货预测和订货建议都更稳。这三个场景有一个共同点都允许人工复核存在。争议样本进人工队列而不是直接进系统自动执行这是目前最稳妥的落地边界。5.2 如果要复刻这套方案我建议的最小配置硬件方面一部拍照清晰的中端手机加一个固定拍摄支架就够不用采购专业采集设备如果门店数量多给店员配一个带固定高度的拍摄夹子能显著提升照片一致性。软件层面目标检测模型用开源模型在自有数据上做微调OCR用成熟的文本识别方案LLM接主流大模型的API。所有中间数据落在门店本地只把结构化结果传到云端。有几个配置建议我觉得值得写下来拍摄规范必须写成SOP并且每季度复核一次防止门店操作变形所有LLM输出必须结构化输出格式在代码层做强校验不允许自由文本进入系统系统保留最近三次巡检结果用于上下文参照但不要无限堆积历史评审初期就接受不确定作为合法输出并预留人工复核通道团队配置上一个算法工程师加一个熟悉门店业务的产品经理就能跑起来。关键是产品经理能不能把店长的口头经验翻译成规则——这个能力决定了系统的最终上限。5.3 给需求方的预期管理清单跟业务方沟通的时候我建议把下面几条作为默认预期而不是让人家自己猜AI每天能稳定巡检但判断结果仍然需要门店侧确认关键动作缺货召回率可以做到85%以上但做不到100%极端情况比如货架被推车整个挡住任何视觉方案都会漏系统部署前期需要一到两周的对照期用于建立信任和校准阈值切换到AI巡检之后人的工作会从走现场变成看报告处理争议这对店长的能力要求反而提高了预期管理做得好项目推进就顺做不好模型再准也会被业务的失望情绪淹没。这一点我认为比技术参数更重要。5.4 接下来半年值得盯的方向一个是视觉语言模型本身的进步。如果多模态模型的密集识别能力继续提升几年后真有可能把看见和看懂收敛到一个模型里审计链路会大大简化。另一个是货架动态数据的建模比如促销临时变化、堆头、试吃台这类非结构化状态未来会有更细的状态模型来处理而不会像现在这样被我们简单过滤掉。第三个是多门店聚合学习在保护各门店数据隐私的前提下把不同门店的货架特征做联合建模让新门店冷启动不再需要对照周。我的建议是不要等完美模型先把手头的巡检流水线跑起来。数据会不断积累模型会不断迭代但业务闭环一旦转起来后面的优化才有真实有效的抓手。这次试点给我最大的体会是零售场景里的技术突破很少是单一模型的功劳更多是感知、推理、流程和人的信任机制一起转动的结果。LLM目前的定位更像是给这套机制补齐了判断和组织语言的那一环——这一环补上之后货架审计这个存在了不知道多少年的老问题确实到了一个可以正式动手改的阶段。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑