这个标题挂在我们的项目板上挺长时间了每次开会都有人问一句“Can LLMs audit a supermarket shelf yet?”一半是调侃一半是真在认真考虑这事。干零售数字化的人都知道货架审计是个又脏又累又绕不开的活儿——门店补货、排面合规、价签匹配哪个环节掉了链子都直接影响销售数据。过去我们靠人工巡店、靠传统视觉模型做检测各有各的窝囊。所以当多模态大模型火起来的时候大家第一反应都是能不能拿它直接看货架照片一口气把缺货、错放、价签问题全写出来。这篇文章就是我基于一个真实POC的完整复盘内容包括货架审计到底难在哪、为什么LLM看起来能行、实测下来哪些任务靠谱哪些翻车、以及目前我认为最适合落地的混合架构长什么样。如果你也在考虑用多模态模型处理门店运营场景这篇应该能帮你省下一两周试错时间。1. 项目缘起为什么想到让大模型去看货架1.1 货架审计的业务痛点先花点时间把货架审计这个活说清楚。所谓审计就是检查门店货架上每个SKU是否按陈列标准摆放、排面是否完整、价签是否对应、促销商品是否到位。听起来简单实际牵扯的东西特别多。一家中型超市的SKU数量动辄几千个一个货架面就有几十个商品位。按行业惯例正常巡店频率是一天两到三次如果店里人手紧一天一次都算勤快的。问题在于缺货通常不是均匀发生的而是集中在某几个热销SKU上——早上被买走一批如果没有及时补货到下午排面就空了。更麻烦的是人工巡店本身会引入“人为偏差”。店长知道总部在抽查某个品牌某个规格他就会先把那一块整理得干干净净。我见过不少案例督导前脚刚走后脚排面就乱了。而且人工记录基本靠手机拍照加手填表格数据散落在各个群聊和Excel里想汇总成结构化报表几乎不可能更别说做趋势分析。传统的机器视觉方案我们也有过尝试思路也很直接用目标检测模型识别每个商品的位置和类别用OCR读价签文字再套一套规则判断缺货、错放。这套路能跑通但真的很难维护。原因有三点商品包装更新迭代频繁同一种饮料换了新包装老模型大概率就认不出来了需要重新标注数据、重新训练。长尾SKU太多大部分都只有极少量的训练样本检测模型对这些商品的召回率很低。新品进场速度远远快于标注速度在中国零售市场尤其是这样一个月十几个新品很常见。这些痛苦长期存在所以当多模态大模型展示出“看一张图就能描述里面发生了什么”的能力时我们团队内部很自然地冒出一个念头能不能跳过传统检测管线直接让大模型端到端地完成审计任务1.2 为什么选择LLM作为切入点逻辑其实是顺理成章的。货架审计这个场景最大的特点是视觉信息密度高但语义规则相对清晰。缺货就是“某个位置应该放商品但没有”价签错位就是“标签上写的品名和实物对不上”排面合规就是“商品是否按标准摆放”。这些都是人类可以用自然语言直接描述的规则而大语言模型最擅长的事情之一正是理解用自然语言表达的规则并将其应用到输入数据上。想象一下一个传统检测模型看到一瓶倒放的饮料可能会正常识别出“这是饮料”但它不会告诉你“这瓶饮料倒放了不符合陈列规范”。因为倒放这个判断需要的是上下文语义理解而不是视觉识别本身。LLM天然具备这种语义推理能力。而且用LLM做审计有一个巨大的隐性优势——交互性。门店运营者不需要写死规则他们可以直接问“第三层为什么标了两个缺货”或者“这个货架哪个品牌排面最不完整”这种自然语言问答的能力是传统视觉系统根本无法提供的。所以在POC阶段我的假设是即便LLM在纯识别精度上比不过专门训练的CV模型它展现出来的泛化能力和交互能力也足够值得一试。我不打算追求一步到位先做一个最小闭环验证。输入是一张手机拍的货架照片输出是一个结构化的审计报告包含货架层数、每层有哪些SKU、每个SKU当前数量、应该有的排面数、缺货位置、异常事项标注。然后单独看每个子任务的表现再综合判断“能不能实际用”。2. 货架审计的核心难点与LLM能力边界2.1 把货架审计拆成细粒度子任务货架审计看着是一个整体任务实际拆开之后是一堆完全不同性质的子任务对模型能力的要求也完全不同。我简单分了五类SKU细粒度识别。货架上有几十个SKU很多长得非常像。比如同一个品牌的无糖、低糖、原味三款饮品瓶身颜色差异很小只是在标签某个位置写了小字。这种识别本质上是一种超高难度的细粒度视觉分类人类一眼能区分但对模型来说是残酷的考验。商品存在性检测。简单说就是“这个排面有没有放商品”。看起来很简单但在实际照片里干扰因素特别多层板反光会被当成空位、后面放了整箱库存会被误判为排面已满、前一排商品被后排商品遮挡也算复杂情况。空间关系推理。货架是多层结构审计报告必须精确到“第二层左数第三个位置缺货”而不是模糊地写“货架上有空位”。这意味着模型需要具备坐标空间推理能力把视觉位置转换成结构化位置描述。价签OCR与匹配。这是目前相对成熟的一环但难点不在识别文字而在判断“这张价签对应的到底是哪个商品位”。促销价签、变色价签、手写价签的存在让这件事变得很头疼。陈列合规判断。商品是否倒放、是否超过货架边界、是否缠绕了非卖品包装这些全部依赖通用常识。你没法为每一种可能的违规类型单独标数据。这五个子任务的技术难度和瓶颈各不相同。把它们揉在一起用一个端到端模型去解挑战在于模型能不能同时做细粒度感知和语义推理。如果在其中一个环节出错整个审计报告的可用性都会崩塌。2.2 LLM的子任务表现矩阵在动手实测之前我先根据社区里公开的经验和模型架构逻辑给LLM在各子任务上的可能表现画了个预判表。这个表后来被实测数据修正了很多但框架是好的可以直接当参考子任务预期表现核心瓶颈替代或补充方案SKU细粒度识别中下视觉编码器分辨率与注意力限制专用分类模型或端侧Embedding检索商品存在性检测中上反光、遮挡、阴影干扰低层视觉特征或分割模型辅助空间关系推理中下坐标输出精度低结构化推理不稳定区域裁剪 锚点定位机制价签OCR与匹配中下OCR能力依赖底座模型语义匹配还行专业OCR模型 规则对齐陈列合规判断较好依赖常识丰富程度可与规则引擎结合降低误判率这张表背后的逻辑是LLM的强项在于语义理解和跨模态对齐。它可以轻松看出“这个货架第三层有几个位置明显缺货”因为它能从背景、相邻商品、层板阴影这些元素中抽象出“空位”的语义概念。但如果任务是“这是草莓味还是蜜桃味”它就必须依赖像素级的纹理和颜色细节而这恰恰是压缩了大量视觉信息的多模态模型不擅长的事情。另一个重要的结构性问题是计数。LLM的数字感知能力远没有我们期望的强。货架上同一款饮料连续摆了12瓶模型经常数出8瓶或者14瓶。这不是模型笨而是当前的视觉transformer架构对重复性小目标天然不敏感注意力会在多个相同目标之间分散。搞清楚了这些边界实操方向就很明确了不要把LLM当成全知全能的视觉大脑而是把它当成一个“具备常识的视觉助手”。具体怎么用下一章讲实操。3. 实操过程与核心环节实现3.1 数据采集与场景设计这次POC的数据全部来自真实门店环境没有用实验室里的标准货架。为什么强调环境真实因为实验室照片通常光线均匀、商品齐整、无遮挡体现不了真实场景里恶劣的条件。我们选择了一家中型社区超市的三个区域作为采集对象饮料冷柜旁的常规货架、零食膨化食品货架、日化清洁用品货架。这三个区域覆盖了低密度、中密度、高密度三种陈列类型也包含了瓶装、袋装、盒装多种包装形态。拍摄设备直接用手机主摄固定拍摄高度大致与货架中部平齐。每类货架拍摄距离分三档1米左右的近景用于单层审计1.5米左右的中景用于双层审计2.5米左右的远景用于整架概览。这个分档设计是刻意的——我想测试的是模型在不同尺度下对细节的感知能力而真实用户拿着手机在门店里拍摄恰好在这些距离上。采集过程控制在非高峰时段以避免顾客入镜带来的隐私和伦理问题。每个货架面拍了8到10张照片最终整理出有效样本80余张。另外每个货架面都在拍摄前做了人工标注包括每层SKU列表、每个SKU的排面数量、空位位置、价签匹配情况作为评测的Ground Truth。这里有一个坑需要提醒人工标注最好在采集当下完成不要隔天再标否则凭照片回忆很容易漏掉细节。3.2 提示词工程与结构化输出设计LLM输入照片后要给出审计结论最重要的是让输出格式稳定可靠。我用的策略是“分阶段审计 强制结构化”而不是一次性问“这架货架有什么问题”。第一阶段提示词只让模型描述货架结构有几层每层的边界在哪里每层从左到右分布了哪些视觉上可区分的商品群。这一步的目的很简单先建立货架的空间骨架避免后续审计时模型把不同层的东西混在一起。这个阶段不需要模型做任何精细判断所以准确率很高。第二阶段聚焦单层。把第一阶段的输出结果作为上文条件提示模型对每一层分别审计识别每个商品群对应的SKU名称或品类描述、数出每组的商品个数、标注空位位置、描述异常情况。这个阶段是核心提示词里必须明确要求使用相对空间位置描述比如“第三层从左往右第四个位置”。这里我踩过一个大坑如果只说“描述空位”模型会返回“中间偏右有一处空位”这种模糊描述对业务完全没用。第三阶段汇总输出。把所有层的结果整理成JSON格式。为了提高解析稳定性我在提示词里直接给了JSON Schema和一段示例输出同时明确要求字段不可省略、布尔值只能用true/false。另外模型参数设置也做了调整temperature设为0关闭随机性每个货架面重复采样5次最终用多数投票的方式合并结果。这一招叫自一致性能明显减少偶发的数字幻觉。这里需要特别提醒多模态模型的视觉编码分辨率是有上限的输入照片过大或过小都会导致细节丢失。我们的做法是把原图按长边缩放到一个合理分辨率约1500像素左右同时保留宽高比。此外如果在提示词里需要模型关注某个特定区域先裁剪该区域并独立输入比让模型“在整张图里仔细找”要可靠得多。JSON schema示意{ shelf_id: string, level_count: int, levels: [ { level_index: 1, items: [ { item_position: left-to-right index, product_name: string, sku_category: string, expected_quantity: int, actual_quantity: int, is_missing: bool, missing_positions: [] } ], anomalies: [string] } ] }3.3 基线对比系统的搭建为了客观评估LLM的表现我搭了一个传统方案的基线系统用来做对照。这个基线没有任何训练成本完全依靠现成的开源组件一个通用目标检测模型负责框出商品个体一个OCR模型负责读取价签和商品包装上的关键文字再加一层简单的规则引擎判断空位。具体流程是目标检测模型对整张货架图做检测得到所有商品框OCR对图像中所有文字区域做识别规则引擎根据检测框的空间分布、OCR结果中的品名与价签是否匹配生成结构化的审计报告。这个基线的精度算不上顶尖毕竟没有针对特定门店做任何微调但它代表的是“不额外投入标注成本的情况下传统技术能到达的水平”。评测指标我定义了四个后面所有结果都用同一套标准SKU识别准确率识别出的SKU口径与真实SKU一致的比例空位命中率Recall真实存在的空位有多少被正确报告了空位误报率Precision报告出来的空位有多少是真空位数量误差均值每个SKU实际数量与报告数量的平均绝对偏差这样对比才能知道LLM相比传统方案是增量还是退步以及差距到底体现在哪些具体环节。4. 实测结果与失败案例分析4.1 整体数字与分项表现整个评测跑下来用了大概一周时间把80多张照片全部逐张过了一遍。总的结论是LLM确实能“看懂”货架但远不到“审计”的水平。先看SKU识别准确率。在价签清晰、商品包装常规的情况下LLM对“这是什么品类”的判断非常准识别准确率超过90%。这符合预期因为品类级判断依赖的是常识性视觉特征比如红色罐装是汽水、绿色瓶装是茶饮这些跨模态对齐非常成熟。但一旦要求精确到SKU级别准确率掉得很快。同一个品牌三款外观高度相似的饮品模型经常把其中两个搞混识别准确率跌到75%左右。空位检测的结果要好很多。模型对“某排面该有商品而没有”这件事的判断相当敏感Recall约为84%。误报主要来自两类一是层板上的反光被误认为空位二是商品后方有摆放整齐的库存箱模型误以为排面完整。Precision约为79%。数量计数是最让人头疼的部分。当单个SKU排面数量少于10个时模型基本能数对误差均值在1个以内。但排面数量超过15个、尤其是连续同色包装时误差急剧放大误差均值升至3到4个而且误差方向不固定有时候多数有时候少数。这说明模型并没有真正学会“逐个数数”而是在进行一种近似估算。来看一份完整的结果对照表任务项LLM准确率/误差基线系统准确率/误差备注品类级识别91.2%95.0%差距不大基线目标检测模型自带分类能力SKU级识别78.4%86.7%基线的局部特征提取能力更强空位检测Recall84.1%88.9%两者都易漏阴影和反光场景空位检测Precision79.3%83.5%基线的误报主要来自规则匹配太死板排面数量误差2.1个0.4个基线用检测框直接计数误差主要来自漏检上表非常清晰地展示了两种技术路线的特质基线的数字感知能力更强、结构化输出更精确但SKU识别受限于训练数据分布遇到新品和长尾商品大概率翻车LLM的常识理解能力强但精细感知和精确计数是硬伤。4.2 典型失败模式拆解评测过程中我记录了每一个明显的失败案例反复观看之后总结出了几类典型模式值得单独拆出来讲。第一个典型失败同系列不同口味的混淆。这个前面已经提到了但我还是想再展开一下。为什么人类能轻易区分两瓶包装几乎一样、只在标签底部写着“白桃味”和“青提味”的饮品因为我们主动将注意力引导到了标签底部的文字区域。而多模态LLM在理解整张货架图片时注意力必然分散在大量的视觉元素上它可能压根没有注意到那个小字的差异反而依据瓶身颜色、整体标签风格来归类。这不是简单的OCR问题而是“选择哪里看”的注意力分配问题。第二个典型失败促销贴纸的干扰。某款商品瓶身贴了一张促销圆形贴纸模型直接将其识别为“带有活动标识的独立商品”导致同一个物理商品被审计成两个SKU其中一个是虚构的。这个失败的根源在于模型缺乏“贴纸是附着于商品表面的附属物不是独立商品”的物理常识。给模型追加一句提示词“忽略覆盖在商品表面的促销标签和贴纸”后误报降低了大概六成但没法完全清零。第三个典型失败层板阴影与倒瓶。饮料货架的层板前缘通常有不锈钢挡条在拍摄角度偏低时会产生明显反光和阴影。模型经常把阴影区域误读为空位把横放的待上架商品误读为正常陈列。这个问题的本质其实是“模型把二维图上的光线变化当作语义边界”。传统检测模型也一样会犯但它的错误表现得更加稳定至少可以通过规则过滤LLM的错误则带着很明显的“想象力发散”有时候给出的解释会让你觉得好像也有点道理但这恰恰是危险之处——错误被包装成了合理判断。第四个典型失败新老包装共存。货架上同一款商品同时存在旧包装和新包装模型把它们识别成了两个SKU。这个案例对人类审计员来说不难判断因为包装袋上印着完全相同的品名但模型只看视觉特征很容易被差异化的设计构图带偏。后来我在提示词里增加了“不同包装规格若品名一致则合并为同一SKU”的规则情况有所改善但也引入了新的合并误伤问题。4.3 实测过程中的工程坑除了算法层面的失败工程实现上也有不少坑写出来给大家提个醒。第一个坑是JSON输出的稳定性。即使我在提示词里给出了清晰的Schema模型仍然偶尔会输出带有注释的JSON、或者字段名略微变化导致解析器直接报错。建议不要依赖自然语言要求“只输出JSON”而是优先使用支持结构化输出参数的接口或者在后处理阶段做一个容错解析器能自动修复常见的拼写级别错误。第二个坑是上下文污染。一开始我按惯性做了多轮对话式交互第一轮让模型识别货架结构第二轮把结构和图片一起发给它等第三轮输出审计报告。结果发现模型经常把上一轮讨论的内容混进当前轮次的输出里。后来的解决方式是取消多轮对话每一轮都独立调用上一轮的结果只作为文本附加到新一轮的输入中不再保留模型自身的历史记忆。这个改动让输出干净了很多。第三个坑是拍摄角度对层板判断的影响。当拍摄角度略微向下仰视时模型对层板数量的识别就不稳定了经常把一块层板的两个视觉区间当成两层货架。解决办法是在第一阶段提示词里要求模型输出层板间相对位置关系并辅助以“层板通常以横向金属条为边界”的提示。这个提示词看起来像废话但对真实场景识别结果的影响非常大。总的来说工程侧的坑大多可以用合理的流程设计来规避但模型算法侧的边界问题很难靠提示词根治。这为下一章的结论和落地建议埋下了伏笔。5. 目前结论与工程化落地建议5.1 一句话回答标题能但还不能全自动闭环回到标题的问题——“Can LLMs audit a supermarket shelf yet?”。直接回答就是能当辅助审计员还做不了独立审计员。从POC数据看LLM在“理解货架语义”这个层面表现得比传统模型好比如判断某处该有商品但缺了、识别促销贴纸异常、总结整架货架的卫生和摆放状况。这些任务需要的不是像素级精度而是“看懂发生了什么”的能力LLM有优势。但审计业务对精度的要求是百分之百的。漏一个空位门店就少补一次货把两个SKU搞混库存数据就开始乱。在精确到SKU级别、排面数量级别的子任务上LLM目前的能力还远未达标。如果强行用纯LLM做端到端闭环会频繁出现一种很尴尬的情况——系统给出的结论听起来头头是道但让你压根不敢按它去补货。所以我的结论是LLM已经可以作为审计系统里的一层“语义大脑”但视觉感知层仍然需要交给传统模型。5.2 我推荐的生产级架构经过这一轮POC实验我目前推荐的生产级方案是用混合架构替代端到端大模型方案。具体流程分三层每层只干自己最擅长的事。感知层负责从图像中提取结构化视觉对象。这一步用传统目标检测模型任务是框出每个商品个体并给出粗略的品类标签用OCR模型读取所有文字区域。检测模型不需要非常精准的SKU分类能力反而需要尽可能高的召回率把所有商品和文字区域都找出来。这一步的输出是一组带坐标的检测框。语义层负责理解业务规则。把感知层输出的结构化信息喂给LLM让模型基于检测框的排列、OCR文案、预定义的陈列标准判断哪些位置缺货、哪些SKU摆放不合规、哪些价签匹配异常。LLM在这里不需要知道商品的精确坐标因为坐标是传统模型提供的LLM只需要理解规则然后输出结论。这样做最大的好处是LLM不会再犯“把促销贴纸当成独立商品”这种常识性错误因为感知层不会把贴纸当作独立检测框。决策层负责生成审计报告和补货建议。LLM结合整体库存状态、历史热销数据和当前缺货信息生成自然语言的运营建议。这个环节目前实际效果不错因为它是纯粹的文本生成任务不涉及视觉感知。这个三层架构的核心理念是“把视觉问题留给视觉模型把语义问题留给语义模型”。实测下来SKU级识别准确率从78.4%提升到了接近92%空位检测的Precision和Recall都回到了90%以上。数字上并不是说混合架构完美但至少达到可用的业务底线。5.3 给从业者的几条落地建议如果你也想在自己的门店场景里试这套系统有几点经验值得参考。先选型再做POC。多模态模型的选择对结果影响极大。不同架构的模型在细粒度感知能力上差距明显建议优先选择在文档理解类任务上表现好的模型因为货架审计本质上是视觉文档理解的一种变体。如果你的场景涉及真实门店照片数据隐私要求会限制你直接用云上的公开服务本地化部署的开源模型虽然精度略低但胜在数据不出域。重视失败样本的闭环。这次POC里最有价值的产出不是那些正确的输出而是失败样本。每一张被模型搞砸的图片如果被用来做后续的规则修正或模型微调都会让系统快速迭代。建议在最开始就建立失败样本自动存档的机制标注一位运营同学定期复查。最后一点别想着一步到位做到全自动化。我个人的经验是先让系统输出标注了置信度的审计报告人工只复核低置信度区域。这样投入产出比最高——模型把容易做的、重复性的工作吃掉人工把精力放在复杂异常上。等模型在低置信度区域的准确率稳步提升之后再逐步扩大自动化范围。我在实际测试中最深刻的体会是AI落地最需要的不是“模型能力最强”而是“在哪里用模型最强”。货架审计这个场景逻辑规则清晰、数据形态固定非常适合AI介入但真正起作用的永远是人机协同——两层模型各管一段人工再做最后把关。这个思路放到其他零售运营场景比如门店排班、库存预测、促销执行检查大概率也是一样的套法。先把一个小场景吃透把混合架构跑顺再横向复制远比一开始就追求所有SKU全自动识别要靠谱得多。
阅读完成 · 觉得有帮助?