如何为 RAG 系统索引图像：Kapa 的工程实践与深度解读

在构建基于检索增强生成（RAG）的技术文档助手时，图像的处理往往是一个被低估的难点。Kapa 公司（专注于为技术文档构建 AI 助手）在近期的一篇技术博客中，详细阐述了他们如何高效地将数百万张截图、架构图和表格整合进 RAG 管道。

这篇文章不仅揭示了“一次性描述，文本检索”的工程策略，还深入分析了为何在查询时直接使用多模态模型在大规模生产中并不可行。以下是对该文章的完整解读。

背景

Kapa 构建的 AI 助手能够从技术文档中回答用户问题。其处理的知识库中包含了数百万张图像，包括截图、架构图、电路原理图以及带有注释的用户界面（UI）操作指南。为了让这些图像在 RAG 流程中真正发挥作用，Kapa 团队花费了数月时间进行技术攻关。

在技术文档中，图像主要承担两种角色：

1. 说明性图像（Illustrative）：大多数图像属于此类。它们展示了文本已经描述的内容，但更加直观。例如，文本说“点击设置图标”，旁边的截图则明确指出了是哪个图标、在哪里以及它长什么样。文字承载事实，图片降低操作门槛。
2. 承载性图像（Load-bearing）：部分图像是答案的核心来源。接线图、规格表、认证信息或颜色可用性矩阵等，其包含的具体数值或状态信息往往只存在于图中，其他地方找不到。在这种情况下，图片不是便利工具，而是答案本身。

Kapa 通过针对三个客户项目和两个模型的评估发现，引入图像上下文后，LLM 裁判（LLM Judge）给出的答案质量有统计学意义上的显著提升（McNemar's test, p < 0.05）。这种提升对用户而言是实质性的：从模糊的指引变为具体的路径加截图，直接决定了用户是自助解决还是提交工单。

然而，工程上的核心挑战在于：如何在不使用昂贵且低效的“查询时视觉处理”的前提下，利用这些图像提升回答质量。

核心内容

为什么“查询时多模态”在大规模场景下行不通？

大多数人的直觉做法是：检索相关文本块 -> 收集引用的图像 -> 将所有内容发送给具备视觉能力的模型（如 GPT-4o 或 Claude）。Kapa 使用 GPT 5.1 和 Claude 4.6 Sonnet 进行了测试，发现这种方法存在结构性缺陷：

1. 经济账算不过来：原始图像显著增加了单次查询成本。在 GPT 上增加了 27%，在 Claude 上增加了 51%（Claude 将图像 token 化约为 975 tokens，而 GPT 为 716 tokens）。对于每天处理数百万次查询的服务来说，为大多数不需要重新审视像素的答案支付高额费用是不可接受的。
2. 物理容量限制：典型查询会检索 10-30 个文本块，平均引用 20-30 张图像，长尾情况甚至超过 130 张。Claude 的负载限制为 30 MB，OpenAI 为 50 MB。大约 25 张图像就会接近 Claude 的上限。若强行限制图像数量，则失去了多模态检索的意义。
3. 领域不匹配：基于 CLIP 风格的嵌入向量会抹平图表、表格和带注释截图中至关重要的细微差别。此外，简短的技术查询（如“如何配置 X”）提供的信号太少，难以与图像向量有效匹配。

这些是当今生态系统固有的属性，而非可以通过工程调优修复的 Bug。这促使团队转向完全摒弃“查询时视觉处理”。

核心策略：索引时描述，检索时作为文本

可行的方案是逆转经济模型：在索引时支付一次成本，将每张图像转换为文本描述；之后，检索和生成过程完全基于文本进行。

• 索引阶段（Indexing Time）：使用一个低成本的多模态视觉语言模型（Vision Language Model, VLM）为每张图像生成标题（Caption）。这些标题作为文本块存储，并与普通文本块一起检索。
• 查询阶段（Query Time）：如果某个图像标题与查询相关，检索器将其拉入上下文。模型看到的是标题文本，而非原始图像，并通过原始 URL 引用该图像。

这种方法的本质是将“看图像”的重活放在摄入阶段完成。对于说明性截图，标题是描述；对于承载性图表，标题是对图中数值、标签的转录。无论哪种情况，内容都变成了文本，后续管道无需再处理像素。

生产环境中的关键工程细节

要在生产中落地这一策略，必须在以下三个环节做到极致：

1. 过滤：大多数图像是噪音

不能盲目地为数百万张图像生成标题。

• 启发式过滤：首先丢弃不支持的格式、尺寸过小或长宽比极端的图像。
• 零样本分类器：对于剩余图像，使用基于多模态嵌入的零样本分类器。它在清晰图像上的准确率达到 96.8%（F1 0.974），能剔除约 13% 的明显噪音（如 Logo、头像、装饰横幅）。
• 接受模糊性：对于歧义图像（如倒计时截图可能是装饰也可能是教程步骤），准确率会降至 59.8%。这是因为缺乏上下文时，像素本身不足以区分语义。团队选择接受这种边缘情况，并计划下一步引入上下文感知的分类。

2. 标题生成：上下文比模型大小更重要

标题质量取决于两个因素：

• 周围文本：将图像前后的段落喂给模型，标题质量显著提升。没有上下文，文件上传对话框可能只被描述为“一个带有文件上传表单的网页”；有了上下文，标题能结合具体产品、工作流和步骤，使其对检索极具价值。
• 模型选择：昂贵的模型并未带来显著收益。团队对比了从 Claude 4.6 Sonnet 到 GPT 5.4 nano 的五款模型。小型模型（GPT 5.4 mini）生成的标题几乎与价格高四倍的模型无异，只有 nano 版本表现下降。在大规模场景下，小型模型是最佳选择。

3. 存储：分离的标题块优于内联

有两种集成标题的方式：

• 内联（Inline）：替换文档中的 alt 文本，使某些块同时包含文本和描述。
• 分离（Separate）：将每个标题存储为独立的块，保持文档原样。

分离方案胜出。内联方案会膨胀所有包含标题的块，导致无论图像是否相关，这些块都会在每次查询时发送。分离方案仅在检索器判断标题相关时才将其加入上下文。

• 成本对比：在一个图像密集的项目中，内联方案使 GPT 的单次查询成本增加 19%，而分离方案仅增加 6%。对于 Claude，分离方案甚至略微降低了成本。

关键要点

• 策略核心：采用“索引时描述，查询时文本检索”的模式，避免在每次查询时调用昂贵的视觉模型。
• 成本效益：索引是一次性成本，查询时仅增加 1% 到 6% 的开销（相比纯文本），但答案质量有统计学意义上的显著提升。
• 图像分类：必须建立严格的过滤机制，利用启发式规则和零样本分类器剔除 Logo、装饰图等噪音，容忍部分歧义图像。
• 上下文至关重要：生成图像标题时，必须包含图像前后的文本上下文，否则标题缺乏检索价值。
• 模型选型：小型多模态模型（如 GPT 5.4 mini）在标题生成任务上性价比最高，无需使用顶级昂贵模型。
• 存储架构：将图像标题存储为独立的文本块，比内联到现有文本块中更能控制上下文窗口大小和查询成本。
• 承载性图像的处理：对于包含关键数据的表格或图表，必须在索引阶段将其内容转录为文本，否则助手可能会基于错误的理解生成答案。

意义与影响

Kapa 的实践为 RAG 系统中处理非结构化视觉数据提供了一个可复制的工程范式。其核心启示在于：**不要试图让 LLM 在每次