AI 时代，零售商超如何用多模态数据“看见“每一排货架？-平芜编程栈

中国连锁零售行业正站在一个关键转折点。根据中国连锁经营协会（CCFA）与毕马威联合发布的《2026年中国便利店发展报告》[1]，2025年全国便利店终端网点数已达33.8万家，行业销售额触及4795亿元。另据CCFA统计数据，某头部连锁品牌门店数突破37000家（2024年达37943家），年增速超过12%[3]。然而规模扩张的红利正在收窄——行业平均单店日营业额降至4453元，坪效小幅下滑[1]，报告更预测未来三到五年内约30%的中小型连锁企业将面临被收购或出局[1]。行业核心矛盾已从"开更多店"转向"管好每家店"。

精细化管理的瓶颈，很大程度上是数据层面的。一家拥有数万家门店的连锁便利店，每天产生的数据量是海量的：货架照片、商品包装图、门店监控视频、消费者行为记录……然而据CCFA《2025年度中国零售数字化及新技术应用创新案例》[2] 报告观察，尽管AI技术如智能补货、智慧供应链、云值守等在零售业态的应用不断扩大，但绝大多数企业仍停留在"结构化数据分析"阶段——销售报表、库存数字看得很清楚，但占数据总量80%以上的非结构化数据（图片、视频、文档）却几乎处于"沉睡"状态。图片看了、视频存了，却没有办法系统性地"理解"和"利用"，这已成为制约零售企业从"规模化"走向"智能化"的核心瓶颈。

这篇文章，我们来聊聊零售商超企业如何借助 AI 和多模态数据技术，让货架"会说话"、让商品"有标签"、让顾客行为"可量化"，从而支撑更精细化的运营决策。

三个真实场景，看懂零售 AI 的核心诉求

在与多家零售企业的交流中，我们发现有三个场景的需求最为集中，也最具代表性。

场景一：商品数据治理——让 AI 帮你"认"商品

一家大型连锁便利店拥有数万个 SKU，每个商品都有名称、图片、品牌、品类、计量单位等属性。但在实际操作中，商品的品类归属、规格描述、计量单位的选择往往依赖人工判断，主观性强、一致性差。比如"康师傅经典红烧牛肉面(五连包)“，它到底属于"方便食品→拌面→碗装干拌方便面"还是"方便食品→方便面→多连包方便面”？不同录入人员可能给出不同答案。

AI 能做什么？结合商品名称（文本）和商品包装图片（图像），大模型可以同时理解文字信息和视觉信息，自动推断商品的品牌归属、品类层级、甚至包装计量单位。在实测中，品牌预测的主品牌准确率超过 92%，子品牌准确率超过 90%；品类预测的一级分类准确率也达到了 77% 以上。这意味着，原本需要大量人工核对的商品主数据治理工作，可以交给 AI 完成初筛，人工只需处理少量异常。

场景二：货架执行度监控——让 AI 帮你"巡店"

连锁便利店总部对门店有强管控要求：每个门店必须按照预设的货架模版进行商品陈列。但现实是，一个区域经理管几十家门店，不可能天天到店检查。门店是否按模版陈列、是否存在错放缺货，长期处于"无法衡量"的状态。

AI 能做什么？门店员工用手机拍下货架照片，AI 系统将照片与标准货架模版进行多模态比对——识别货架上每个位置的商品是什么、和模版是否一致、哪里缺了货、哪里放错了位置。最终输出结构化的差异清单：哪个货位、应该放什么、实际放了什么、是否合规。这让"巡店"从人力密集型工作变成了数据驱动的智能检测。

场景三：店内消费行为优化——让 AI 帮你"读懂"顾客

便利店不仅关心货架，也关心顾客在店内的行为。一位顾客走进店里，在某个货架前停留了很久，拿起了商品看了看，又放了回去——这个行为背后可能意味着价格犹豫、包装不满意、或者单纯找不到想要的口味。传统的监控系统只能录像，无法"理解"发生了什么。

AI 能做什么？通过门店视频流的关键帧抽取、事件识别、结合货架布局和商品数据，AI 可以将视频转化为结构化的行为日志——顾客在哪个货架停留了多久、拿起了哪些商品、最终是否购买。这些洞察直接支撑选品优化、陈列调整、促销策略等决策。

背后的技术：为什么需要一个"多模态数据底座"？

上面三个场景有一个共同特点：它们都不是纯粹的文字处理，也不是纯粹的图片识别，而是需要将文本、图片、视频等多种模态的数据融合在一起进行分析和检索。

这就是"多模态数据底座"要解决的问题。传统的数据架构中，结构化数据存在关系型数据库或数仓里，图片存在对象存储里，视频存在另一个系统里——它们彼此隔离，无法联合查询和分析。要让 AI 同时"看懂"一张商品图片和"读懂"商品名称文本，再与品类体系、品牌库等结构化数据关联，需要一个新的技术架构。

具体来说，这个底座需要解决三件事：

第一，多模态数据的统一存储和感知。无论是对象存储上的商品图片、门店视频，还是数据库里的商品信息、品类清单，都需要在一个系统中统一管理。当对象存储上新增了一张货架照片，系统能自动感知并触发后续处理。

第二，AI 大模型的便捷调用。业务系统需要方便地调用多种大模型能力——图片理解（Qwen-VL 等多模态模型）、文本向量化（Embedding 模型）、内容生成（LLM 大语言模型）等。传统方式需要开发独立的 AI 服务、搭建推理集群、编写 API 接口，门槛高、运维复杂。

第三，向量检索 + 全文检索 + OLAP 分析的混合查询能力。仅仅把数据向量化还不够。实际业务中，经常需要"先用向量检索找到相似商品，再用全文检索匹配关键词，最后用 OLAP 分析做统计汇总"这样的混合查询。这要求底层引擎同时具备多种检索能力，且能在毫秒级响应。

Hologres 的方案：一条 SQL 打通 Data + AI

阿里云 Hologres 提供了一套面向 AI 时代的多模态数据解决方案，核心思路是“一份数据、一份计算、多模分析”。

Object Table负责感知和存储非结构化数据。它直接关联阿里云对象存储 OSS 上的图片、视频、文档等文件，当文件发生变化时自动同步，就像给对象存储建了一张"实时镜像表"。

AI Function让大模型调用变得像写 SQL 一样简单。ai_embed()把文本或图片转化为向量，ai_gen()调用大模型进行推理和内容生成，ai_parse_document()解析文档内容——这些函数直接嵌入标准 SQL 语句中，数据不出库，无需额外的 AI 服务开发。

Dynamic Table实现增量自动加工。当新数据进入系统，Dynamic Table 自动触发 AI Function 进行向量化、分类、标注等处理，并将结果与结构化数据一起存储，形成可供检索的多模态数据表。

混合检索引擎则在底层同时支持向量索引、全文索引和 OLAP 分析，一次查询可以同时走向量召回、全文召回，再通过 RRF（Reciprocal Rank Fusion）等算法进行重排序，返回最精准的结果。

整个链路，从数据入库、AI 加工、到多模检索，全部通过 SQL 完成。数据工程师不需要学习 Python、不需要搭建独立的 AI 推理服务，用熟悉的大数据开发方式就能构建 AI 应用。

零售客户实际效果显示

第一步: Object Table——让数据库"看见"OSS 上的商品图片

零售商的商品包装图片通常存储在 OSS 上。Hologres 通过 Object Table 直接关联 OSS 路径，当新增或更新商品图片时，系统自动感知变化，无需手动导入：

CREATE OBJECT TABLE public.goods_images WITH ( path = 'oss://bucket-name/product-images/', oss_endpoint = 'oss-cn-hangzhou-internal.aliyuncs.com', role_arn = 'acs:ram::xxx:role/hologres-oss-reader' );

执行 REFRESH OBJECT TABLE 后，数据库就能像查询普通表一样查询 OSS 上的图片文件。这一步解决了非结构化数据"进库"的问题。

第二步：Dynamic Table——增量构建品牌名向量索引

品牌库中有大量主品牌和子品牌的组合（如"康师傅-经典红烧"）。我们需要对这些品牌名做向量化，以便后续进行语义相似度匹配。Dynamic Table 的关键在于增量自动刷新——当品牌库新增或修改品牌名时，向量索引自动更新，无需全量重建：

CREATE DYNAMIC TABLE good_br_indexs WITH ( auto_refresh_mode = 'incremental', freshness = '1 minutes', table_group = 'tg_1' ) AS WITH br_distinct_table AS ( SELECT DISTINCT main_br_name, sub_br_name FROM good_br_info ), full_br_name_table AS ( SELECT main_br_name, sub_br_name, main_br_name || '-' || sub_br_name AS full_br_name FROM br_distinct_table ) SELECT main_br_name, sub_br_name, full_br_name, ai_embed('text-embedding-v4', full_br_name) AS embedding -- 调用 Embedding 模型生成向量 FROM full_br_name_table; -- 同时在品牌名上建立全文索引 CREATE INDEX idx1 ON good_br_indexs USING FULLTEXT (full_br_name);

这里 ai_embed() 直接调用 text-embedding-v4 模型，将品牌名转化为高维向量。一条 SQL 就完成了"读数据→调模型→建索引"的全流程。

第三步：双路召回 + RRF 重排——精准匹配候选品牌

对于每个待预测的商品，系统需要从品牌库中找到最相关的候选品牌。单纯用关键词匹配（全文检索）或单纯用语义匹配（向量检索）都有盲区——比如"椰树"和"椰汁"关键词不同但语义相关，而"银鹭"和"银鹭花生牛奶"语义相近但可能属于不同子品牌。Hologres 的方案是双路召回 + RRF 融合排序：

WITH -- 路径一：全文检索，按关键词匹配品牌名 text_recall AS ( SELECT main_br_name, sub_br_name, row_number() OVER(ORDER BY text_search(full_br_name, '康师傅经典红烧牛肉面') DESC) AS rank_text FROM good_br_indexs LIMIT 20 ), -- 路径二：向量检索，按语义相似度匹配品牌名 vector_recall AS ( SELECT main_br_name, sub_br_name, row_number() OVER(ORDER BY approx_cosine_distance(embedding, ai_embed('text-embedding-v4', '康师傅经典红烧牛肉面')) DESC) AS rank_vec FROM good_br_indexs LIMIT 20 ), -- RRF 融合：1/(k+rank_text) + 1/(k+rank_vec) union_recall AS ( SELECT main_br_name, sub_br_name, rank_text, NULL::int AS rank_vec FROM text_recall UNION SELECT main_br_name, sub_br_name, NULL::int AS rank_text, rank_vec FROM vector_recall ) SELECT main_br_name, sub_br_name, (CASE WHEN rank_text IS NOT NULL THEN 1.0/(60+rank_text) ELSE 0 END) + (CASE WHEN rank_vec IS NOT NULL THEN 1.0/(60+rank_vec) ELSE 0 END) AS rrf_score FROM ( SELECT main_br_name, sub_br_name, min(rank_text) AS rank_text, min(rank_vec) AS rank_vec FROM union_recall GROUP BY main_br_name, sub_br_name ) ORDER BY rrf_score DESC LIMIT 10;

RRF（Reciprocal Rank Fusion）的核心思想很简单：两路召回各取 Top 20，按 1/(k+排名) 计算融合分数，k 通常取 60。这样在全文和向量两路都排名靠前的品牌，融合分数会显著高于只在一路中表现好的品牌。实测中，这种混合召回策略能有效避免单一检索方式可能遗漏的候选品牌，为后续的 AI 推理提供更全面的候选集。

第四步：AI Function 多模态推理——结合文字和图片做最终判断

双路召回给出了候选品牌列表（Top 10），但最终判断还需要"看懂"商品包装图片。ai_gen() 函数在这里发挥了关键作用——它将商品名称、候选品牌列表作为文本上下文，同时将 OSS 上的商品包装图片作为视觉输入，交给 qwen3.7-plus 多模态大模型进行综合推理：

INSERT INTO suggested_good_br_mix SELECT gd_gid, gd_name, gd_code, object_uri, brand_list, ai_gen('qwen3.7-plus', 'You are an expert classification analyst...' || '\n- `product_name`: ' || gd_name || '\n- `brand_enum` (Candidate List):' || '\n' || brand_list || '\n# Algorithmic Decision Process ...' -- Prompt 包含详细的分类规则、评分逻辑和示例 , file) AS result -- file 来自 Object Table，即商品包装图片 FROM goods_images left join RRF_recall on...;

Prompt 的设计很讲究：不是简单地问"这个商品属于哪个品牌"，而是给模型定义了一套算法化的决策流程——先拆解商品名中的关键词，再逐个评估候选品牌的匹配度，最后按"完整关键词匹配优先于部分匹配"的原则选出最优解。这种结构化的 Prompt 让模型的输出更稳定、可解释。

模型返回的是标准 JSON（如 {“main_brand_name”: “康师傅”, “sub_brand_name”: “经典”}），直接写入结果表，后续用 SQL 即可批量校验准确率。

品类预测：逐级缩小范围的链式推理

品类预测比品牌预测更复杂——需要从"食品/饮料/生活用品/服务/其他"5 个大类，逐级细分到中类（如"方便食品"）、小类（如"拌面"→"碗装干拌方便面"），总共 60 多个小类。Hologres 的方案是逐级预测、逐层缩小范围：

第一次 ai_gen() 调用：根据商品名+图片，从 5 个大类中选出大类（如"食品"）
根据大类结果，动态关联出该大类下的中类列表（如食品下的"休闲素食、方便食品、烘焙糕点…"）
第二次 ai_gen() 调用：在中类列表中做选择（如"方便食品"）
同理继续缩小到小类

每一级预测都以上一级的结果为范围约束，候选集越来越小，判断越来越精准。整个链式推理过程全部在 SQL 中通过 CTE（Common Table Expression）串联完成，一次查询跑完四级分类。

计量单位预测：图片是关键信息源

计量单位预测（盒/包/瓶/罐/箱等 36 种单位）的技术路线与品牌预测类似，但更依赖图片信息。Prompt 中定义了每种单位的包装形态定义（如"盒=刚性容器，保持固定形状"、“包=小型柔性密封袋，<200g”），并要求模型结合图片中的包装外观做出判断。这意味着即使商品名称中没有明确的包装信息（如"乐而雅超瞬吸纤巧特长夜用卫生巾 350mm"），模型也能从图片中识别出扁平袋状包装，正确输出"包"。

通过 Object Table + Dynamic Table + AI Function 的全 SQL 链路，商品数据从入库、向量索引构建、多路召回到多模态推理，全程无需搭建独立 AI 推理服务或编写额外代码，开发运维复杂度大幅降低；双路召回 + RRF 融合排序机制有效弥补了单一检索方式的盲区，结合多模态大模型的图文联合理解能力，商品属性预测的整体准确率达到可规模化应用的水准，验证了"数据不出库、AI 即 SQL"这一架构在零售多模态场景下的工程可行性。

从"存数据"到"懂数据"：零售 AI 的下一步

零售商超行业正在经历从"数字化"到"智能化"的转型。过去十年，企业解决了"数据有没有"的问题；未来十年，核心命题是"数据懂不懂"——能不能真正理解图片里的商品信息、视频里的顾客行为、文档里的运营知识。正如CCFA报告所警示的，当行业从扩张期进入精耕期，技术能力不再是"加分项"，而是"生死线"[1]。

Hologres 的多模态数据方案，本质上是把 AI 大模型的能力"下沉"到了数据底座层面，让企业不需要重建一套 AI 系统，而是在已有的数据架构上自然延伸出智能分析的能力。对于零售商超企业来说，这意味着：

商品管理从"人工标注"升级为"AI 自动识别 + 人工抽检"，效率提升数倍；货架巡检从"区域经理跑腿"升级为"拍照即出报告"，覆盖率从抽样变为全量；顾客行为从"看监控回放"升级为"结构化行为日志"，洞察从定性变为定量。

更重要的是，这一切的实现门槛正在快速降低——当 AI 能力被封装成 SQL 函数，数据工程师就能直接上手，业务迭代的速度将远超传统模式。在30%的中小连锁面临出局的窗口期[1]，率先把"沉睡"的非结构化数据转化为可分析、可决策的智能资产，或许就是拉开差距的关键一步。

如果你的企业也在面对多模态数据的管理和分析挑战，不妨了解一下 Hologres 的 AI Function 能力。从一个小场景的 POC 开始，也许就能看到 AI 为零售业务带来的真实改变。

引用来源

[1] 中国连锁经营协会（CCFA）、毕马威.《2026年中国便利店发展报告》. 2026年5月.

报告原文：https://kpmg.com/cn/zh/insights/2026/05/china-convenience-store-development-report-2026.html
报告摘要解读：https://mp.ofweek.com/iot/a456714483687 （引用了单店日营业额4453元、30%中小连锁面临出局等数据）

[2] 中国连锁经营协会（CCFA）.《2025年度中国零售数字化及新技术应用创新案例》. 2025年11月.