多模态LLM审计超市货架：能，但不能全信

最近有个问题在零售技术和AI圈里被反复讨论“Can LLMs audit a supermarket shelf yet?”——大语言模型到底能不能干超市货架审计这活儿我的答案是能但不能全信。这句话不是绕弯子而是我实打实跑完一轮端到端流程后的感受。这篇文章想把“能用”和“好用”之间的差距掰开聊透从任务拆解、技术选型到提示词设计、结果校验、成本估算全是我自己操作的记录和踩坑总结。不管你是做零售数据的同学还是想试试多模态大模型落地场景的开发者这篇都值得你花十分钟看完。1. 先搞清楚“审计货架”到底是个什么活儿1.1 货架审计不是“拍张照片数数商品”这么简单很多搞技术的朋友第一次听说货架审计第一反应都是“不就是在货架前拍照、数数商品数量嘛”。真实情况要比这个复杂一个量级。货架审计在零售运营里大致拆成四类任务库存盘点、陈列合规检查、价格与促销核对、竞品信息采集。库存盘点要清点每个SKU在货架上的可见数量判断是否缺货、是否有空位陈列合规要看商品是不是放在系统分配的位置上、排面宽度达不达标、有没有被遮挡、有没有违反先进先出价格与促销核对则是找出价签和系统价不一致、促销价有没有执行、促销标识摆放正不正确竞品采集就更麻烦要记录对手品牌在货架上的铺货情况。这些事在过去基本靠理货员巡店时拿纸笔记录或者用一台手持终端边扫码边录入。问题不在于单个动作难而在于量大、重复、口径不统一。一家标准超市几千个SKU大型卖场能到几万个一个理货员完整盘点一遍可能要大半天中间还会漏看、记错。更麻烦的是巡店结果回到办公室之后还要二次录入系统等你把数据整理好货架上的情况早就变了。所以零售公司一直想找一个能自动、高频、低货架审计方案这就是问题的来源。1.2 传统自动化方案其实折腾了很多年过去十几年零售行业在货架审计上尝试过的主流路线是传统机器视觉目标检测模型负责找出货架上的商品框OCR模型负责读取价签文字最后用一套规则引擎把识别结果和系统数据比对。这套路子不是不能跑而是维护成本高到一个让人头疼的程度。首先是模型泛化问题。每个新包装、每个灯光变化、每次货架调整都可能让已训练好的检测模型准确率往下掉。你刚把某品牌薯片的新包装标注好训练完下个月人家又换了包装设计等于从头再来。超市的SKU数量又特别大靠定制训练去覆盖所有商品在时间和成本上都属于不可持续的事。其次是模块之间的割裂。目标检测、OCR、规则引擎三个环节各自独立工作没有统一的语义理解层。比如说检测模型框出了一个商品OCR在旁边读到了一个价格但这两个结果之间到底对应不对应传统方案很难自动判断。你经常会遇到一种情况商品识别对了价格也读到了但因为框稍微偏了一点系统把隔壁商品的价格算到了它头上。这种割裂问题在做规则比对时很难自动发现最后还是要人工看图确认。所以当多模态大语言模型出来之后很多零售技术团队都在琢磨同一件事能不能用一个大模型把识别、理解、推理这几步一口气全干了2. 多模态LLM凭什么能碰这块硬骨头2.1 “看懂”一张货架图对LLM意味着什么多模态大模型的工作方式和传统视觉模型有本质区别。它先用视觉编码器把图像切成小块、编码成视觉token再把这些token和文本token一起丢给语言模型做注意力计算最后生成自然语言或结构化输出。关键变化在于识别和理解被放在同一个网络里模型能结合整体上下文对模糊信息做推理而不是像传统方案那样每个模块各干各的、互相之间不通信。我举一个具体例子。货架上两个不同口味的商品包装几乎一样只差一个色条和一行小字。传统检测模型很容易把它们当成同一个SKU或者干脆无法区分。但多模态LLM不一样它会注意到旁边价签上的文字结合商品名称和包装上的说明推断出“这大概率是原味的旁边那包是辣味的”。这种跨模态的上下文推理能力是传统视觉方案最缺的东西。打个生活化的比方把货架审计交给LLM就像派了一个聪明但没上过货架的实习生去门店。他看东西快、能说会道但你得给他清晰的检查清单和验收标准而且他偶尔会自作聪明地猜答案必须有师傅在后面复核。不要指望他第一次独自巡店就做到完美。2.2 零样本与开放词表LLM最吸引人的两件事传统检测模型的天花板在于只能识别训练集里出现过的类别要新增一个SKU就得重新标注、重新训练。多模态LLM不一样它训练时见过海量的图文数据对市面上绝大多数食品、日用品、饮料的品牌和包装都有先验知识所以能做到零样本识别。新包装的薯片、新口味的汽水你不需要专门给它训练它直接告诉你它看到了什么。开放词表能力直接解决了零售行业最大的痛点SKU数量爆炸。一个门店里动辄几千个SKU如果每个都要建训练样本项目的启动成本高得吓人而LLM只需要一个提示词就能把“识别图中所有商品”这件事跑起来。我在实操中还发现一个细节哪怕某个商品模型认不出具体品牌它也倾向于给出一个合理的品类描述比如“看起来像一种苏打水”这已经能给后续的人工复核省下不少事。但这里我要给热情降个温零样本不等于零错误。它的错误风格和人类很像——看不清就编不确定就猜有时候还猜得一本正经。所以在设计整个流程时不能假装模型不会错而是要把“它会错”当成前提来搭架构后面我会详细讲怎么处理。3. 端到端跑通一次货架审计的实操记录3.1 数据采集环节最容易偷懒也最容易毁掉结果我做过一个模拟实验搭了一个货架区域放进去15种不同品类的商品打印了几张价签其中有两张故意贴错位置用来测试模型的纠错能力。整个实验做下来最大的感受是采图质量直接就决定了审计结果的上限提示词写得再好图拍得不行也是白搭。几个用真金白银换来的拍摄经验拍摄时尽量让镜头和货架保持平行平视着拍不要仰拍也不要俯拍。仰拍和俯拍会让商品之间互相遮挡模型很难数清楚后排商品的数量。光照要均匀不要开闪光灯直射否则价签反光会导致OCR全部失效。每一层货架单独拍一张图整排货架的分列拍不要妄图一张图装下所有内容。相邻图片之间留15%到20%的重叠区域这样后面合并结果时不容易丢东西。分辨率不要盲目开满先确认你用的模型对图像输入尺寸的上限在哪。拍摄只是第一步更麻烦的是图片预处理。货架照片往往有透视畸变尤其是用手机广角拍整条货架时边缘的商品会被拉变形。我的处理方式是先用简单的透视校正工具把图拉正再按层裁剪成子图。这一步看起来不起眼但能明显提升后面的识别精度。3.2 提示词设计的核心把“数货”翻译成模型能懂的指令很多人用LLM做货架审计上来就输入“帮我检查一下这张图有什么问题”这种问法模型只能给你返回一段散文式的描述根本没法直接进系统。正确的做法是要在提示词里把任务边界、输出格式、容错机制全定义清楚。我最常用的一套模板长这样你是一个超市货架审计助手。请查看输入的货架图片完成以下任务 1. 识别图中每个商品输出品牌和品名包含口味/规格信息。 2. 统计每个商品在货架上的可见数量只统计图中实际可见的商品。 3. 读取每个商品附近价格牌上的数字输出标价。 4. 检查货架上是否存在空位或空托盘并描述其位置。 5. 判断是否存在价格牌与商品明显不匹配的情况。 输出要求只输出JSON数组不要输出任何其他文字。每条记录包含字段 sku_name, category, quantity, shelf_position, price_tag, stockout, note。 如果某个信息无法从图片确认统一填 unknown不要猜测。这套提示词有几个设计要点值得展开说。强制JSON输出是为了让结果能被程序直接解析而不是让模型自由发挥写文章。明确留出unknown出口给模型一个“承认不知道”的空间我实测下来这一条能显著减少幻觉。数量统计要强调只统计可见部分否则模型会把被遮挡的商品也脑补进去。加few-shot样例也很重要模型看到符合格式的输出示例之后生成的格式会稳定非常多。我还会把temperature调到0到0.2之间降低输出的随机性。计数任务不是创意写作不需要模型做任何发散。这点用过几次你就知道同样的图片在高温下跑两遍结果经常不一样乍一看都是合理结果但数量就是对不上。3.3 大图拆小图一种务实但不性感的做法多模态模型对图像输入是有token上限的一整张超高清的货架全景图塞进去要么被压缩到看不清细节要么直接超出限制被拒绝。所以更务实的做法是把货架拆成多个子图分别处理再合并结果。我的合并流程是先把整条货架按层裁成子图每张子图在输入时带着明确的位置上下文比如“这是第一层左段”然后每张子图独立跑一次审计流程。最后把多张子图的结果汇总到一个表格里按SKU名加位置去重。还要注意相邻子图的重叠区域可能会导致同一个商品被识别两次这就要靠位置描述和坐标信息去重我在提示词里会让模型输出shelf_position字段就是为了这个目的。这个方案不够“性感”但非常稳妥。它的原理其实很简单子图里的每个商品相对像素面积更大模型看得更清楚同时每一张图的推理任务更简单生成结果的稳定性也会大幅提升。有些做工程的同学喜欢一上来就上全景图觉得这样更智能实际上我在测试中全景图的识别率远远不如拆图方案。3.4 让LLM给自己的结果“挑刺”双重校验思路LLM幻觉是绕不开的那我的应对办法就是多花一次调用成本让模型对自己的输出做交叉校验。做法是把第一次输出的JSON结果和原始关键区域的截图拼在一起让模型再来一轮检查。提示词可以这样写下面是一份货架审计JSON结果。请对照原始图片检查结果中的逻辑矛盾例如 1. 某个商品quantity填了0但price_tag有数字是否矛盾 2. 同一商品是否出现重复记录且位置重叠 3. 价签数量明显多于商品数量时是否有异常说明 如果发现问题输出修正后的JSON并附上reason字段说明修改理由。这一步能抓出不少第一轮的错误尤其是那种模型在货架很空时依然填了一堆商品的情况。它相当于给系统加了一个“质检员”岗位。成本确实会翻倍所以我不建议全量做抽样做或者只在低置信区域做就够了。4. 小样本实测与成本账数据说话的环节4.1 一个迷你实验15种商品的单层货架识别到什么程度我用自己的模拟货架跑了10轮测试结果汇总下来能看到很明显的规律。SKU识别这块15个商品里平均能正确识别14个左右但有两个外观相似的包装在部分轮次中会被搞混尤其当光线角度变化时。数量统计偏差在正负1以内的比例大概占七成误差主要出现在货架后排被遮挡的商品上。价签读取方面字体清晰的价签基本全能读对但倾斜角度大的价签错误率明显上升。缺货空位是检出率最高的几乎没漏过。陈列错放检测也能做对一半以上但这块对模型的空间理解能力要求高表现还不够稳定。我拿这个数据去跟做零售的朋友聊他的反馈很有意思SKU识别90%以上的准确率其实已经可以用了因为能被认错的商品往往集中在少数相似款上数量统计70%的准确率则完全不能用因为补货决策对数量误差非常敏感。这就说明LLM现阶段的角色更适合做“筛选器”而不是“账本”。它可以先把异常区域找出来再让人去看那些异常区域这比让人从头到尾看完一遍省力得多。4.2 token成本估算一次巡检要烧多少钱成本这件事不自己算一次账是没有体感的。我按主流多模态大模型的公开计价来粗略估算一张高分辨率货架子图编码成视觉token大约要消耗一两千个token加上提示词和输出JSON单张子图一次完整审计大概消耗两千五到四千个token。一条中型超市的货架如果按60条货架、每条拍5层来算就是300张子图整体跑一轮大约要消耗75万到120万token折合成当前的API价格大约在大几十到一两百元的量级。为了更清晰我把单层货架的成本结构列成了一个表成本项消耗量级说明图像编码约1500-2500 token/图高分辨率图按块切分token消耗较大审计指令约500-800 token/图提示词本身和few-shot样例审计输出约300-500 token/图JSON结果单图合计约2500-3800 token/图一次单层审计的总体消耗300图门店全量约75万-120万 token全店一轮巡检模型调用费用数十元至一两百元量级按当前公开API定价粗估这个数字和人工巡检比什么概念呢一次人工全店盘点需要大半天人力成本LLM方案在成本和速度上都占优势。但前提是你得接受它的准确率还不是100%需要配人工复核流程。算账的时候不能只看模型调用费还得把抽样复核的人工成本算进去。综合算下来现阶段用LLM做全店巡检的性价比依然不如“LLM预筛人工只查异常位”。4.3 延迟与实时性离线批量可行线上实时勉强延迟是我实测过程中体感最明显的瓶颈。单张子图从上传到拿到结果耗时大概在6到10秒左右。这还是一次调用的时间如果是批量跑300张图即使并发处理也得好几分钟。这个速度在“晚上打烊后集中跑一批数据”的场景完全没问题但如果你想让店员拿着手机在货架前边走边实时反馈体验会非常糟糕。实时方案不是没有出路我用过两个思路一个是换更小的开源模型做本地部署延迟能降到一两秒但识别精度会下降另一个是只对局部区域做实时分析比如针对某个特定的促销堆头只识别这一小块整个流程可以压缩到三秒内。所以实时性说白了是精度与速度的取舍你自己得想清楚业务上更需要哪个。5. 边界在哪里三个绕不开的问题与一个折中方案5.1 幻觉在货架场景会被特殊放大货架场景是幻觉问题的天然重灾区原因是它充满了大量相似目标。同系列商品不同口味之间的包装差异很多时候只有一个色条加一行小字塑料膜反光会让模型看不清文字货架深处的阴影会制造出虽然存在但难以辨认的商品轮廓。这些场景下模型特别容易启动“猜谜模式”。我踩过最深的一个坑是某个商品在货架后排只露出五分之一模型竟然根据前排商品的上下文把它脑补成了同品类的另一款味道还自信地填了具体规格。这种错误最危险因为它的输出看起来特别合理。应对办法有三招始终坚持unknown优先原则在提示词里要求模型“只描述有可视证据的信息”给每条识别结果加一个置信度标签低置信度的自动进入人工复核队列。这三招组合用下来幻觉对最终结果的影响能压到可控范围。5.2 数据安全与合规门店照片不能随便外传做实际落地项目时数据合规比模型精度更容易成为拦路虎。门店照片不是普通图片它可能拍到顾客、店员可能暴露内部促销计划、陈列布局、库存情况。不少零售公司对这类数据外发是高度敏感的如果把原图直接传到公开API服务上法务那关就过不去。我在设计流程时专门加了三道保险第一拍摄环节要求店员避开人员入镜拍完先本地预览一遍第二上传前在本地做预处理把画面中的人脸区域用检测算法自动打码第三只裁剪货架局部区域上传不要传全景图更不要传带门店门头、收银台等敏感地标的画面。如果你的客户要求更高那就要上私有化部署把模型部署在内网或者专有云环境从源头杜绝数据外流。5.3 混合架构传统检测网络做“眼睛”LLM做“大脑”前面讲了那么多LLM的亮点和坑点其实最务实的方案不是让LLM单干而是搞混合架构。我的落地建议是分三步走第一步用轻量级目标检测模型找出货架上的所有候选框这一步每秒能处理好几帧成本几乎可以忽略第二步把每个候选框裁剪成小图喂给多模态LLM让它识别框内商品、读取价签文字第三步用一个规则引擎汇总结果做去重、数量统计、置信度过滤和异常标记。这套架构的好处非常明显。它避免了大图上LLM的token爆炸和密集目标识别不准的问题因为模型只看小目标框精度更高、幻觉更少。同时保留了LLM的开放词表和语义理解能力新商品不需要重新训练检测器。最妙的是规则引擎兜底后输出结果可以做到完全结构化、完全可解释这在零售客户的验收环节简直是加分项。不要迷信“一个模型解决所有问题”工程上的最优解往往是组合拳。6. 它“yet”了吗我个人的判断与一条最务实的建议做完整轮实验之后我对开头那个问题的答案已经很明确LLM能不能审计超市货架能而且跨过了“能不能用”的门槛但它目前更适合当“审计助手”而不是“审计员”。它能用很少的成本把货架图快速过一遍把可疑位置筛出来但数量统计、相似包装区分这些精细活还不能完全托付给它。如果要给一个量化预期我会说现阶段它大约能替代人工巡检七成的工作量剩下三成需要人工复核来兜底。最后分享一个我很想强调的落地建议别一上来就追求全自动无人审计而是从一个小切口开始。比如先选一排黄金货架每周跑一次把每次的错误案例都存下来做成bad case集持续迭代提示词和校验规则等这套体系跑稳了再扩展到全店。零售项目的成败从来不取决于模型有多强而取决于流程能不能在真实环境中稳定跑起来。这个小切口策略是我在实操中觉得最值得参考的经验。