闭集多模态检索：为什么不是再做一个 RAG

标注员在第三方 SaaS 里做纸品陈列审核：货架、端架、物料画面里，要把每个可见对象关联到正确的 SKU。SaaS 不能改、DOM 不能动，关联动作只能在原界面完成；系统里真正好用的定位方式，往往是复制某个检索键（平台内部字段，下文统称检索键），回到 SaaS 搜索框里精准命中。

业务给的是闭集：例如「纸品陈列审核 09 月批次」里，大约三百个允许关联的候选，正确答案只能从中选。主数据库里 SKU 很多，但检索范围被批次死死卡住。查询侧更麻烦：标注员用系统截图工具框出目标，常见只有一百到两百像素宽，压缩、反光、遮挡一应俱全——和标准商品图不是同一种分布。

在这种约束下，如果第一反应是「再接一个向量库 + 大模型做 RAG」，或者「查询时让 VLM 描述一下图再搜」，很容易把问题定义错。下面先拆三种常见误判，再给出我们 POC 里真正要解的问题，以及第一版刻意不做什么。

一、场景里实际在发生什么

典型一轮工作流是这样的：

业务下发当日批次，候选 SKU 列表固定（约三百条），批次一天一换。
标注员在 SaaS 里看到待审画面，对某个卷纸、抽纸、湿巾包装截取一小块图。
在本地辅助页粘贴截图，可选补几个字（规格、版式、渠道话术里残留的片段）。
系统在当前批次里给出一小屏候选，附带「为什么排到这里」的简短证据。
标注员点选后复制该 SKU 的检索键，回到 SaaS 粘贴搜索，人工确认关联。

注意边界：辅助工具不替 SaaS 提交、不自动选中兜底项、不改写主数据。它只做一件事——把「在全量名称里瞎搜」变成「在三百个里先看最像的几个，并让人能看见依据」。

二、三种容易走偏的方案

1. 把闭集商品图检索当成开放域文档 RAG

企业 RAG 的经典链路是：文档切片 → 向量化 → 检索段落 → 拼进上下文 → 大模型生成答案。知识边界模糊、答案可以组织成自然语言，用户也习惯「问一句、答一段」。

闭集标注场景完全不同：

候选集合是已知的，不是从百万文档里捞相关段。
输出不是一段话，而是一个 SKU 身份（最终仍要落到检索键）。
错误成本是关联错货，不是「答得不太优美」；宁可多列几个让人选，也不要编造不存在的规格。
查询往往是极糊的局部图，和清晰商品主图之间的域差，比「两篇 Word 文档措辞不同」大得多。

硬套 RAG，常见后果是：聊天框很漂亮，但 Top 列表不稳定；或者模型用流畅语言「解释」了一个错误 SKU，反而拖慢标注。检索层该做的是排序与证据，生成层并不是默认必选项。

2. 在查询热路径上默认挂 VLM「先描述再搜」

查询侧多模态大模型很诱人：自动读出包装上的字、颜色、版式，再转成文本检索。POC 里我们把它放在建库建档一侧——用清晰参考图离线生成描述与属性，进入索引文本。

查询路径上则刻意默认不做这件事，原因很现实：

每次搜索多一次云端多模态调用，延迟和失败面都放大；标注是高频动作，秒级等待会直接伤体验。
糊截图上 VLM 的读取不稳定，描述噪声会污染文字通道。
很多线索标注员本来就知道（「12 卷」「家庭装」「电商专供」），可选输入框比自动描述更可控。

不是永远不做查询 VLM，而是：在第一版问题定义里，它不是默认解法；需要文字线索时，优先让人补几个字。

3. 用云端 Top-K 精排「再帮模型选一选」

另一种冲动是：本地向量先召回二十个，再把候选图和查询图一起发给云端大模型重排。听起来像「给检索加一层智慧」。

在闭集、小候选规模（约三百）的场景里，精排常常对不上成本：

候选图数量 × 查询频率，云端费用和超时都会上来。
精排分数和本地通道分数量纲不同，产品上还容易诱导「模型说第一就对」——但标注规范要求的是人确认。
弱匹配时更需要的其实是显式降级（提示「整体匹配较弱」、固定展示兜底区），而不是再烧一次 API 赌排名。

因此第一版排名止于本地多通道融合；弱匹配用状态和兜底区表达不确定性，而不是假精确。

三、正确的问题定义：缩小范围、给出证据、人做确认

把目标写成一句话：

在用户选定的批次闭集内，根据查询图（和可选文字），给出少量可解释的候选排序；用户确认后复制检索键回 SaaS，系统记录这次选择供后续评测与索引增强。

拆开看有四个硬要求：

闭集约束：任何通道、任何融合，不得越出当前批次候选；兜底 SKU 单独展示，不参与和正常商品的抢排名。
多模态输入：允许仅图、仅文、图文组合；没有某种输入就关闭对应通道，而不是硬凑特征。
可解释证据：每个候选至少能说清「哪路召回、命中哪张参考图、哪几个 token 对上」——例如假数据里 sku_101 因结构相似排前，sku_207 因用户输入的「12 卷」命中规格字段而并列靠前，而不是只给一个神秘总分。
人在回路：点击候选 = 复制检索键 + 记真值；系统不替代人工判断，只减少无效浏览。

这和 RAG 的「检索服务于生成」不同，更接近交互式检索 + 审计轨迹：每次确认都是一条可回放样本，为后面调通道权重、加参考图、做相对评测留数据。

四、第一版非目标清单（后文会反复引用）

下列能力在 POC 阶段明确不做，避免范围悄悄膨胀：

非目标	说明
生成式问答 / 聊天主界面	不做「问这个图是什么商品」的对话式答案；列表检索为主。
查询热路径 VLM 描述	VLM 用于离线建档；查询时不默认读图转写。
云端 Top-K 精排	融合在本地完成；弱匹配靠状态与兜底，不靠二次云端排序。
修改第三方 SaaS	不注入脚本、不改页面、不自动读任务 DOM（操作面可以是本地辅助界面，但边界不变）。
自动提交关联	检索键复制到人手里，回 SaaS 仍手工点选。
假置信度百分比	不展示未经校准的「92% 像」；用相对状态（整体匹配较弱 / 候选集中 / 候选接近）。
一次性全量主数据入库	按批次导入候选即可；不必先把上万 SKU 全部向量化。
查询侧多主体检测与自动裁剪	用户自己框目标；系统不对粘贴整图做自动抠图。
领域微调 / 自训练	先用通用视觉与文本编码器 + 规则化文字匹配；效果问题优先查分布与通道。
多用户、权限、高可用	单人本机验证链路；不为 POC 叠运维复杂度。

若有人提议「加一个能力」，可以先问：它是在缩小候选、还是在替人下结论？后者默认进非目标。

五、本系列地图

闭集多模态检索系列总览：从问题定义、建库对齐、多通道召回、加权融合、人机闭环到相对评测，围绕小闭集、糊查询和人终审展开

本系列按「问题 → 建库 → 召回 → 融合 → 人机闭环 → 评测」展开，共六篇。本篇定闭集形状、第一版非目标与「缩小范围、人做终审」的心智模型；后五篇各啃一块实现与运营：

本篇 — 为什么不是再做一个 RAG：闭集 vs 开放域、查询热路径边界、相对状态而非假置信度。
第 2 篇 — 建库与分布对齐：多参考图、clear / lowres、letterbox 统一规则；VLM 仅离线建档，不进查询热路径。
第 3 篇 — 多通道召回：按糊图、近形、缺字等失败模式拆通路，每路独立有序列表，单路失败可降级。
第 4 篇 — 加权 RRF 融合与弱匹配降级：多路名次投票成总榜，用「整体匹配较弱 / 候选集中 / 候选接近」提示人眼裁决。
第 5 篇 — 人机闭环：点选记真值、复制检索键回 SaaS；确认截图回流为附加参考图，兜底区不参与排序。
第 6 篇 — 相对评测与刻意不做：以确认会话为 ground truth、回放各通道与融合轨迹；何时才值得再开 OCR / 查询 VLM / 云端精排 / ANN。

六、相关阅读

企业级 RAG 怎么落地？不只是向量检索和大模型 —— 开放域知识问答的工程全景；和闭集检索共享「混合检索、评估、运营」等词汇，但问题形状不同。
RAG 入门：为什么大模型需要查资料再回答 —— 若需要回顾 RAG 经典定义，再对照本文的闭集差异会更清晰。