我们如何为RAG索引图像

# 我们如何为 RAG 索引图像 - kapa.ai - 技术问题的即时 AI 答案 来源：https://www.kapa.ai/blog/how-we-index-images-for-rag Kapa 构建的 AI 助手能够回答来自技术文档的问题。我们处理的知识库包含数百万张图像：截图、架构图、电路原理图、带标注的 UI 操作指南。我们花了几个月的时间，研究如何让这些图像在我们的 RAG 流水线中发挥作用。 简单来说：我们不会在查询时将图像发送给模型。我们在索引阶段，使用廉价的视觉模型，一次性描述每张图像，将描述以文本形式存储，并在检索时与普通文本块一同获取。索引是一次性成本；此后，每个查询的开销比纯文本模式增加 1% 到 6%，而答案在可衡量和统计意义上都显著更好。这篇文章将解释我们是如何做到的。 *两个答案都是正确的。但显示截图的答案能让用户无需寻找设置即可直接操作。* ## 图像在技术文档中的实际作用 我们研究了硬件、半导体和开发者工具领域的数千个真实客户问题，以了解图像在答案中的价值。它们分为两类。 大多数是说明性的。它们展示文本已经说明的内容，但更清晰：指南中说“点击设置图标”，旁边的截图显示了是哪个图标、在哪里、长什么样。文字承载了事实；图片让操作变得容易。 有些是承载性的。接线图、规格表、认证或颜色可用性矩阵可能包含仅存在于图片中、几乎别无他处的值。这时图片不是方便，而是答案的来源。 我们证实了无论哪种情况都有提升：在图像上下文可用的情况下，LLM 评判员在三个客户项目和两个模型上都更偏好带有图像的答案，差异具有统计显著性（McNemar 检验，p < 0.05）。 这种改进是用户能感受到的。不再是“寻找控制该设置的配置部分”，而是给出具体路径加上一个截图，精确显示点击位置。相同的事实，操作起来却容易得多。对于支持助手来说，这决定了用户是自助解决还是提交工单。 无论哪种情况，图像都实质性地改善了答案。工程问题——也是本文剩余部分要讨论的——是如何在不每次查询都支付视觉账单的情况下使用它们。 ## 为什么查询时多模态在大规模下不可行 大多数人首先想到的方法是：检索相关块，收集它们引用的图像，然后将所有内容传递给具有视觉能力的模型。 我们使用 GPT 5.1 和 Claude 4.6 Sonnet 在数百个生产问题上进行了测试。这些问题本质上是结构性的，而不是可以通过微调工程细节来解决的。 **经济性不可行。** 原始图像使 GPT 上的查询成本增加了 27%，Claude 上增加了 51%（Claude 将一张图像标记为大约 975 个 token，而 GPT 为 716 个）。我们处理数百万次查询；在大多数答案不需要重新查看像素的情况下，为所有查询支付如此高的额外成本，是我们无法承受的权衡。 **图像物理上放不下。** 一个典型问题通常会检索 10-30 个块，平均引用 20-30 张图像，长尾超过 130 张。Claude 的有效载荷限制是 30 MB，OpenAI 是 50 MB；大约 25 张图像就已经接近 Claude 的上限了。你必须严格限制图像数量，这违背了初衷。 **多模态检索不适合这个领域。** CLIP 风格的嵌入恰好会抹去图表、表格和带标注截图中重要的细节，而且简短的技术查询（“如何配置 X”）给出的信号太弱，无法与图像向量匹配。 这些是当前生态系统的属性，不是需要修复的 bug。它们引导我们完全放弃查询时的视觉处理。 ## 在索引时描述一次，以文本形式检索 有效的方法颠倒了经济性。不是每次查询都为处理图像付费，而是在索引时一次性付费，将每张图像转换为文本描述。之后，检索和生成完全在文本领域进行。 在索引时，视觉语言模型为每张图像编写标题。标题与普通文本块一起存储和检索。在查询时，如果标题相关，检索器就会将其拉入；模型看到的是标题，而不是原始图像，并通过原始 URL 引用图像。 这是可行的，因为繁重的工作——实际查看图像——在摄取时发生一次，而不是每次查询。对于说明性截图，标题是描述；对于承载性图形，则是对图形所包含内容的转录——表格中的值、图表上的标签。无论哪种方式，内容都变成了文本，流水线的其余部分无需再看到像素。 微软的研究团队（https://devblogs.microsoft.com/ise/multimodal-rag-with-vision/）也得出了相同的结论：在摄取时描述，作为单独的块存储。 这就是使承载性案例可行的原因，也是许多助手悄悄失败的地方。颜色可用性矩阵是一面勾选框的墙；防火等级表是评级网格。使用通用提取器将其扁平化为纯文本，结构就会消失，结果就是助手自信地告诉客户一款面板有某种颜色，而实际上没有。在摄取时转录，同一个矩阵就变成了可检索的文本，答案仍然基于图形实际显示的内容。 *对于数据表密集型产品，图形有时可能就是答案。不过，根据生产环境中的真实用户问题，这种情况很少见。* ## 生产中必须做对的事情 ### 过滤：大多数图像是垃圾，有些无法分类 你不能不加选择地为数百万张图像生成标题。大多数是噪声：标志、头像、社交预览卡片、装饰性横幅。启发式方法处理第一轮（丢弃不受支持的格式、微小图像、极端宽高比）。对于剩下的，我们构建了一个基于多模态嵌入的零样本分类器。它的成本足够低，可以在整个语料库上运行。 在清晰的图像上，准确率达到 96.8%（F1 0.974）。在模糊的图像上，准确率骤降至 59.8%，原因是根本性的。一张倒计时截屏可能是装饰性横幅，也可能是关于计时器的教程的第 3 步。像素完全相同；没有周围文本，就没有足够的信息来决定，而且没有任何嵌入模型可以解决这个问题。所以我们接受这一点：分类器移除明显垃圾（约占启发式筛选后图像的 13%），我们容忍模糊的边缘情况。上下文感知分类显然是下一步。 ### 生成标题：上下文比模型大小更重要 两个因素驱动着标题质量。首先，周围文本：将模型前后段落喂给模型，质量会大幅提升。没有上下文，文件上传对话框是“带有文件上传表单的网页”；有了上下文，标题基于特定的产品、工作流程和步骤，这对于检索更有用。 其次，昂贵的模型买不来多少好处。我们比较了五个模型，从 Claude 4.6 Sonnet 到 GPT 5.4 nano。一个小模型（GPT 5.4 mini）生成的标题与价格是其四倍的模型几乎无法区分；只有 nano 表现下降。在我们的规模下，小模型是显而易见的选择。 ### 存储：单独的标题块优于内联 有两种集成标题的方式。内联：替换文档中图像的 alt 文本，因此某些块同时包含文本和描述。单独：将每个标题存储为自己的块，保持文档不变。 我们原以为内联会胜出，因为标题位于其文本旁边。结果单独胜出，在成本和图像使用上都是。内联标题会膨胀它们所在的每个块，而无论图像是否相关，这些块都会在每次查询时被发送出去。单独的块只有在检索器判定相关时才会进入上下文，因此只有必要时才为图像付费。在一个包含大量图像的项目上，内联使得 GPT 的查询成本提高了 19%；单独模式提高 6%。对于 Claude，单独标题比纯文本的成本略低。而且它们确实发挥了作用：重新排序器在 51% 的查询中将它们提升到前 15 名，而整体排名保持稳定（Spearman ρ = 0.905）。 ## 结果 在三个客户项目上，使用 GPT 5.1 和 Claude 4.6 Sonnet 进行端到端测试： | 指标 | 纯文本基准 | 带图像标题 | |------|-----------|-----------| | 答案中引用的图像 | 0% | 10% 到 64% | | 答案质量（LLM 评判） | 基准 | 显著更好（p < 0.05） | | 每个查询成本 | 基准 | +1% 到 6% | | 延迟（到第一个 token 的时间） | 基准 | 亚秒级增加 | | 模型不确定性 | 基准 | 不变或略有降低 | | 索引成本 | 不适用 | 一次性，之后没有重复的图像成本 | 在每个实验中，图像的放置正确率达到 94% 到 99%。 这是一个不如“使用多模态模型”那么华丽的答案，而这正是重点所在。它之所以有效，是因为它将视觉处理放在了它该在的地方：一次，在摄取时，将图像包含的任何内容转换为文本，而不是每次查询都重新检查像素。无论图像是澄清文字还是直接承载答案，只阅读一次更便宜，也更适合流水线其余部分的工作方式。我们遇到的那些限制并非需要绕过的工程障碍，它们本身就指向了这种架构。 现在以预览版形式推出。