中国连锁零售行业正站在一个关键转折点。根据中国连锁经营协会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 分析一次查询可以同时走向量召回、全文召回再通过 RRFReciprocal 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/(krank_text) 1/(krank_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/(60rank_text) ELSE 0 END) (CASE WHEN rank_vec IS NOT NULL THEN 1.0/(60rank_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;RRFReciprocal 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 中通过 CTECommon 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月.https://aigc.idigital.com.cn/djyanbao/【中国连锁经营协会】2025年度中国零售数字化及新技术应用创新案例-2025-11-30.pdf[3] 智研咨询.《2026年中国便利店行业发展背景、产业链图谱、门店数量、销售额分析》.https://www.chyxx.com/industry/1256468.html 引用了CCFA数据某头部品牌37943家门店、增速12.1%
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 分析一次查询可以同时走向量召回、全文召回再通过 RRFReciprocal 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/(krank_text) 1/(krank_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/(60rank_text) ELSE 0 END) (CASE WHEN rank_vec IS NOT NULL THEN 1.0/(60rank_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;RRFReciprocal 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 中通过 CTECommon 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月.https://aigc.idigital.com.cn/djyanbao/【中国连锁经营协会】2025年度中国零售数字化及新技术应用创新案例-2025-11-30.pdf[3] 智研咨询.《2026年中国便利店行业发展背景、产业链图谱、门店数量、销售额分析》.https://www.chyxx.com/industry/1256468.html 引用了CCFA数据某头部品牌37943家门店、增速12.1%
