企业官网建设流程全解析

最近有个问题在零售技术和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价格大约在大几十到一两百元的量级。

为了更清晰，我把单层货架的成本结构列成了一个表：

这个数字和人工巡检比什么概念呢？一次人工全店盘点需要大半天人力成本，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集，持续迭代提示词和校验规则，等这套体系跑稳了再扩展到全店。零售项目的成败从来不取决于模型有多强，而取决于流程能不能在真实环境中稳定跑起来。这个小切口策略，是我在实操中觉得最值得参考的经验。