从一次真实的图文问答测试出发聊聊多模态 RAG 中的图文召回、证据选择、LLM 图片引用以及一些工程实践中的思考。0. 一个让我重新思考多模态 RAG 的问题之前在做多模态 RAG 的过程中我一直比较关注检索效果。毕竟如果连正确的图片都检索不到后面的图文问答自然也无从谈起。所以在开发过程中我折腾过不少图文召回方案统一 Top-K、分模态检索、意图动态配额以及通过文本关联图片等。但后来遇到的一类现象让我发现自己可能把问题想得太简单了。有些时候相关图片已经进入检索结果最终生成的答案却依然没有展示它们。举个实际测试时遇到的例子。我在实习中参与过企业内部知识库的多模态 RAG 建设涉及从离线文档解析、数据清洗、向量化入库到在线检索和图文回答的完整链路。为了测试系统效果我找了一些图文并茂的公开 PDF主要是软件操作手册、开发板使用手册这类文档。其中有一份《EVM-RK3588 用户手册》。我向系统提了一个很简单的问题「如何进行 SSH 网络登录」原文相关内容在 PDF 第 1213 页涉及查询开发板 IP、配置 SSH 会话和验证登录三个环节并配有三张相关截图。然而最终生成的答案只展示了其中两张SSH 登录配置界面和登录成功界面。查询 IP 地址的终端截图没有出现在回答中。有意思的是回答中的文字并没有明显偏离原文SSH 登录的核心步骤基本都介绍到了。如果只是想知道怎么登录这个答案其实已经具备一定的实用性。但如果我们的目标是根据操作手册生成相对完整的图文教程那么这样的输出还存在改进空间。而且这种现象并不只在这一个问题上出现过。在之前的测试中我也遇到过相关图片已经进入 Top-K但最后只有部分图片被展示的情况。一开始我很自然地把注意力放在检索上。是不是 Top-K 太小是不是图片被文本挤掉了是不是需要给图片分配更多候选名额但在尝试不同方案之后我逐渐意识到多模态 RAG 的图片检索和最终图片展示其实是两个不同的问题。这篇文章就想结合实际项目中的设计聊聊一张图片从进入知识库到最终出现在答案中需要经历哪些环节以及为什么单纯调整 Top-K 未必能够解决漏图问题。1. 我最开始关注的是怎么把正确的图片召回先简单介绍一下项目的整体思路。系统主要分为离线和在线两个阶段。离线阶段我使用 MinerU 解析 PDF提取其中的文本、图片和表格再进行清洗、结构化处理和向量化。图片原文件存储在 MinIO 中文本及图片的语义表示则通过 Embedding 构建索引使用 PostgreSQL pgvector 支持向量检索。在线阶段根据用户问题检索相关知识组织文本和图片证据再交给 LLM 生成答案。1.1 图片不是存进 MinIO 就结束了图片处理是我在离线阶段比较关注的一块。对于普通文本清洗、Chunk 划分和向量化之后就已经具备了基本的语义检索能力。但图片不太一样。图片本身存进 MinIO只是解决了文件存储的问题。用户用自然语言提问时系统还需要知道这张图片讲了什么、属于哪个章节以及它与周围文本有什么关系。因此我尝试通过 Caption 和 VLM 描述为图片构建两种语义表示。Caption 路径主要利用原始图题、章节信息等内容描述图片在文档中的语义位置。VLM 路径则利用视觉模型分析图片本身提取界面文字、关键元素和操作信息等内容。举个例子一张 SSH 配置截图Caption 可能是“SSH 登录配置”VLM 描述则可以进一步补充 MobaXterm、Remote host、用户名、端口等界面信息。我的理解是Caption 更关注“这张图在文档中承担什么作用”VLM 描述更关注“这张图实际包含什么信息”。这两类信息可以相互补充增加图片被不同查询命中的机会。当然双路索引也意味着额外的处理成本和检索融合复杂度并不代表它天然优于单路检索。但至少在设计上它避免了图片的可检索性完全依赖一条简短图注。1.2 从统一 Top-K 到动态配额到了在线阶段我又遇到一个问题文本和图片应该怎么一起召回我前后探索过几种思路。召回策略核心思路主要取舍统一 Top-K图文候选统一排序简单但可能出现模态间候选挤占分模态 Top-K文本和图片分别召回能控制模态比例但固定配额不够灵活意图动态配额根据问题类型调整图文数量更灵活但依赖意图判断文本关联图片先召回文本再查找关联图片适合图文关联明确的文档但受文本命中效果影响这里还有一个容易忽略的细节。不同检索通道返回的相似度分数并不一定具有直接可比性。如果文本和图片描述使用不同的 Embedding 模型就不能简单地把分数混合排序。即使使用同一个模型不同类型文本的分数分布也可能存在差异。因此统一 Top-K 看起来简单实际也需要考虑分数融合和候选分布的问题。后来我又尝试根据问题类型分配不同的图文配额。比如对于“如何配置 SSH”这样的操作类问题希望保留更多截图对于“SSH 和 Telnet 有什么区别”这样的概念解释问题则不一定需要很多图片。这些方案各有适用场景也确实能从不同角度改善候选的组织方式。但它们主要解决的其实是同一个问题如何让相关图片进入最终检索上下文。而在这之后还有另外一道关卡。2. 图片进入 Top-K为什么最终还是可能不展示这是我认为整个问题里最值得深入拆解的部分。最开始我习惯把图文问答简化成这样一条链路检索图片 → 把图片信息给 LLM → LLM 输出图文答案。但实际实现远没有这么直接。以我的项目为例从初始检索到最终展示中间至少有五个阶段。第一阶段初始检索命中用户问题首先与文本、Caption、VLM 描述等检索表示进行语义匹配。在这一阶段图片可能通过 Caption 路径命中也可能通过 VLM 描述路径命中。但此时得到的只是初始候选并不代表这些图片最终都能进入模型上下文。第二阶段候选配额组装系统需要综合文本、图片、表格候选根据问题类型、Top-K 预算等条件决定保留哪些结果。例如某张图片虽然进入了初始候选但在最终 Top-K 组装时因为排序较低或配额不足被排除。那么后面的 LLM 自然也无法引用它。第三阶段图片证据过滤即使图片通过了 Top-K也可能需要进一步检查。例如图片是否具有有效的存储信息相似度是否满足相关性阈值图片描述是否满足必要的匹配规则图片是否属于当前允许引用的证据集合。如果没有通过过滤图片同样无法进入最终的可引用集合。这里要特别注意“初始召回图片”“最终 Top-K 中的图片”和“允许 LLM 引用的图片”可能是三个不同的集合。第四阶段LLM 选择引用假设相关图片已经通过了前面的筛选并且作为证据提供给了 LLM。这时问题就变成了模型会不会在答案中主动引用它在我的实现中LLM 需要根据图片对应的文本证据判断是否有必要引用再输出约定好的图片引用标记。即使某张图片是正确的如果模型最终没有生成对应引用图片依然不会出现。第五阶段后端引用解析与渲染最后后端需要解析模型输出中的图片标记查找对应的图片资源并替换为真正的图片地址。如果标记格式不符合约定、Asset ID 不合法或者图片资源不可访问也可能影响最终展示。所以图片没有出现在最终答案里并不能直接说明向量检索失败。反过来也一样图片出现在 Top-K 里并不代表系统已经完成了全部工作。3. 一个具体实现通过 IMAGE_REF 控制图片引用为了让图片引用更加可控我的项目没有让 LLM 直接生成图片 URL而是使用 Asset ID 作为中间标识。整体思路比较简单。每张图片在入库时都关联一个可以定位原始资源的标识例如image_001在构建 Prompt 时将图片的 Caption、VLM 描述等文本化证据以及对应的 Asset ID 提供给 LLM。然后要求模型在引用图片时输出特定格式的标记[IMAGE_REF: image_001]后端再根据这个 ID 查找实际图片地址例如[IMAGE_REF: image_001]转换为这样做的好处是LLM 不需要自己生成存储地址。图片的身份、资源地址以及最终渲染都由程序进行管理。但问题也恰恰出在这里。3.1 当模型没有输出 IMAGE_REF会发生什么假设检索后系统得到三张可引用图片allowed_image_ids {image_001, image_002, image_003}其中分别对应image_001查询开发板 IPimage_002配置 SSH 会话image_003SSH 登录成功。但 LLM 最终只输出[IMAGE_REF: image_002][IMAGE_REF: image_003]那么后端即使知道还有一张image_001也不能凭空判断它应该插入哪段回答。对于基于模型引用标记的渲染机制最终展示的图片一般取决于模型实际生成的引用以及后端允许引用的集合。可以简化理解为最终展示图片 模型引用图片 ∩ 合法图片集合当然实际实现还需要经过标记解析、资源校验和 URL 替换。这就解释了一个现象检索模块负责提供候选图片但真正决定哪些候选图片被写进答案的还包括生成和渲染环节。3.2 为什么不能直接让 LLM 引用所有图片看到这里一个很自然的想法是既然相关图片已经提供给模型为什么不在 Prompt 中直接要求它把所有图片都展示出来问题在于检索相关不等于回答必需。例如用户问“SSH 协议是什么”系统可能召回多张 SSH 配置界面截图但这些图片对于解释协议原理的帮助非常有限。如果强制展示就容易出现大量冗余配图。反过来对于“请根据手册完整介绍 SSH 登录步骤”每个关键操作可能都值得保留对应截图。因此最终图片数量不应该只由检索结果数量决定而应该结合用户的问题类型和证据作用来判断。另外我之前为了避免乱配图也在 Prompt 中对引用行为做过一些约束例如图片需要直接支持对应步骤、避免重复引用等。这些约束有助于控制无关图片但未必能保证关键操作截图的完整覆盖。这里实际上存在两个不同的目标图片引用准确性展示出来的图片是否真正支持答案必要图片覆盖率那些确实应该展示的图片最终有没有被遗漏这两个目标不能简单混为一谈。4. 强制绑定图文能不能解决这个问题在探索过程中我也尝试过一个比较直接的思路既然图片和文本有对应关系那就把图片和相关文本绑定起来。例如一段操作步骤命中之后直接将对应的图片一起返回。对于操作手册这种图文关联比较明确的文档这种方式确实能够缓解部分漏图问题。但很快我又发现它并不适合所有场景。4.1 操作类问题比较适合图文关联例如“如何设置 SSH 连接”这类问题有明确的操作步骤。如果步骤一对应图片 A、步骤二对应图片 B那么根据步骤关联图片是比较合理的做法。系统可以减少对 LLM 自主选择图片的依赖。4.2 跨章节问题可能出现冗余配图但如果用户问“这个开发板有哪些远程管理方式分别适合什么场景”这个问题可能需要检索多个章节综合串口登录、SSH 登录等不同内容。如果直接把命中文本所关联的所有图片都展示出来很容易出现大量截图而用户真正需要的是不同方式的比较和解释。对于一些比较宽泛的问题强制绑定图文同样不够合理。因此我不太认可“每召回一个相关 Chunk就把所有关联图片全部展示”这样的通用方案。它提高了图片展示的确定性却可能牺牲答案的简洁性和相关性。5. 一个我更想尝试的方向证据选择与答案生成解耦后来我开始思考是否可以换一种方式。不要把“哪些图片应该展示”和“答案应该怎么写”完全交给一次自由生成。而是先进行证据规划再组织自然语言答案。这个思路并不复杂。第一步先确定回答需要覆盖什么例如对于操作指导类问题可以先抽取需要覆盖的关键操作步骤。SSH 登录这个例子里可以得到查询开发板 IP配置 SSH 会话验证登录成功。第二步为步骤关联证据对每个步骤分别选择对应的文本和图片证据。例如操作步骤文本证据图片证据查询 IP网络连接与 IP 查询说明image_001配置 SSHMobaXterm 配置说明image_002验证登录SSH 登录成功说明image_003这里的 ID 是示意实际应该使用系统中可追溯的 Asset ID。如果某一步没有充分的图片证据可以不分配图片也可以触发补充检索而不是强行指定一张看起来相关的截图。第三步生成答案并校验证据将规划好的步骤及其证据交给 LLM 生成回答。后端再检查引用的 Asset ID 是否存在图片是否属于允许使用的证据关键步骤是否遗漏必要图片是否被正确关联是否出现重复或无关引用。最后由后端负责把图片插入到对应步骤附近。这种方式的核心是将原本混合在一次生成中的两个任务拆开先决定“什么证据应该用于回答”再决定“怎样把回答组织得自然”。相对于完全依赖 LLM 自主输出IMAGE_REF这种设计至少可以让图片选择过程变得更容易检查和追踪。但它也会引入额外的证据规划成本并且不保证规划结果一定正确。对于跨章节问题、开放性问题和概念解释问题证据规划也需要采用不同的策略。所以这更像是我接下来希望进一步尝试和验证的工程方向而不是一个已经被证明的最优解。6. 多模态 RAG 的图文效果到底应该怎么评测做这些探索时我还遇到了另一个问题我们到底应该用什么标准判断一张图片有没有必要出现在答案里以前测试时很多时候会直接查看最终回答主观判断图片是否完整、位置是否合理。但这种方式很难支撑系统性的方案对比。例如文章开头的 SSH 案例。原文有三张相关截图最终只输出了两张。如果我们把三张截图全部标注为必要证据那么图片覆盖率就是 2/3。但如果某个用户只是想快速了解 SSH 连接方式那么查询 IP 的截图可能并非必需。这两种评判方式会得到不同的结论。因此我觉得评测至少应该区分几个维度评测维度关注的问题图片召回率应当检索的图片有没有被找到图片引用覆盖率必要的图片最终展示了多少图片引用精确率展示的图片有多少真正支持答案关键步骤覆盖率操作流程是否遗漏重要步骤其中图片引用覆盖率和精确率都需要建立相对明确的人工标注标准。仅仅知道一张图片来自相关章节还不足以判断它是否属于必需证据。另外如果要评测不同召回方案也不能只看最后生成的图片数量还需要检查中间候选集合。否则就很容易把检索、证据过滤和 LLM 引用阶段的问题混在一起。对于这篇文章中的 SSH 案例目前我只能确认最终回答少展示了一张相关截图并不能仅凭结果确定它究竟在哪个环节被排除。这也是我接下来希望进一步完善的部分让整个图文引用链路更可观测而不是只看最终答案猜测原因。7. 最后几点实际做下来才有的感受回头看这段多模态 RAG 的实践我发现自己最开始有些过于关注召回策略了。因为检索是最容易被单独观察和调整的一环。Top-K 不合适就调整 K图片太少就给图片增加配额某些问题召回不稳定就尝试动态分配或者关联检索。这些优化并没有错。但后来我发现一个图文问答系统的最终效果取决于多层不同的工程决策离线阶段决定我们保存了什么样的知识。检索阶段决定哪些证据能够进入候选集合。生成阶段决定模型最终使用哪些证据。渲染阶段决定用户最后看到了什么。每个环节都可能导致图片遗漏也可能引入错误配图。所以我现在依然很重视 MinerU 解析之后的数据清洗、图文关联以及 Caption/VLM 描述的质量。但同样不认为只要离线阶段的数据足够好就能自动解决所有在线生成问题。对于操作手册类问答我更希望答案能够覆盖关键操作和必要截图。而对于概念性、综合性问题我更希望模型能够选择真正有用的视觉证据而不是机械地展示所有相关图片。多模态 RAG 真正难的也许不是把图片检索出来而是让系统知道哪些图片值得被使用以及怎样可靠地使用它们。这是我目前做下来比较深刻的一个感受。当然很多方案还需要更系统的实验验证这篇文章更多是在分享自己遇到的问题和工程思考。后面也准备继续围绕 MinerU 文档解析、Caption/VLM 双路索引、图文召回策略和 RAG 评测做一些更深入的实践。如果你也做过多模态 RAG比较好奇你们是怎么处理最终图片引用的是让 LLM 自主选择图片还是在业务层提前确定图片与文本的对应关系理解有限欢迎大佬指正。