RAG 系统中的图像索引最佳实践

我们如何为 RAG 索引图像

为 LLM 阅读技术文档中的截图、图表和表格

编者按：参与 Hacker News 的讨论（已上首页）。

Kapa 构建 AI 助手来回答技术文档中的问题。我们处理的知识库包含数百万张图像：截图、架构图表、电路原理图、注释式 UI 演练。我们花费了几个月的时间来研究如何在 RAG 管道中有效地利用这些图像。

简短版本：我们不在查询时将图像发送给模型。我们在索引时用一个廉价的视觉模型对每张图像进行一次描述，将描述存储为文本，并将其与普通文本块一起检索。索引是一次性成本；之后，每次查询的开销仅比仅文本增加 1% 到 6%，答案在统计学上明显更好。这篇文章解释了我们是如何做到这一点的。

两个答案都是正确的。显示截图的那个答案是用户可以直接操作而无需寻找设置的答案。

图像在技术文档中的实际作用

我们查看了来自硬件、半导体和开发工具账户的数千个真实客户问题，以了解图像如何在答案中发挥作用。它们分为两类。

大多数是说明性的。它们展示文本已经说过的内容，只是更清楚：指南说"点击设置图标"，旁边的截图显示了哪个图标、在哪里，以及它的样子。文字表达事实；图片使其易于实施。

有些是承载性的。布线图、规格表、认证或颜色可用性矩阵可以包含仅存在于图表中的值，基本上不在其他地方。在这种情况下，图片不是便利，而是答案的来源。

我们确认了两种方式的效果提升：有图像上下文时，LLM 评判器在三个客户项目和两个模型中都倾向于选择答案，差异在统计学上显著（McNemar 检验，p < 0.05）。

改进是用户能感受到的那种。与其说"寻找控制该设置的配置部分"，不如给出具体路径加上显示确切点击位置的截图。相同的事实，但行动变得容易得多。对于支持助手来说，这是用户自助解决和开启工单之间的区别。

无论哪种方式，图像都能显著改善答案质量。工程问题是本文的核心：如何使用它们而不必在每次查询时支付视觉模型的费用。

为什么查询时多模态不适合大规模应用

大多数人首先采取的方法：检索相关块，收集它们引用的图像，并将所有内容传递给支持视觉的模型。

我们在数百个生产问题上用 GPT 5.1 和 Claude 4.6 Sonnet 进行了测试。问题是结构性的，而不是可以调整的工程细节。

经济学不适用。原始图像使 GPT 的每次查询成本增加 27%，Claude 增加 51%（Claude 将图像标记为大约 975 个令牌，而 GPT 为 716 个）。我们处理数百万次查询；当大多数答案都不需要重新查看像素时，在所有查询上都支付这么多更高的成本是我们无法承受的。

图像在物理上放不下。典型的问题检索 10-30 个块，平均引用 20-30 张图像，长尾超过 130。Claude 的有效载荷限制为 30 MB，OpenAI 为 50 MB；大约 25 张图像已经接近 Claude 的上限。你必须严格限制图像数量，这违反了初衷。

多模态检索不适合此领域。CLIP 风格的嵌入会消除图表、表格和注释式截图中重要的细节，而简短的技术查询（"我如何配置 X"）提供的信号太少，无法与图像向量匹配。

这些是当今生态系统的属性，不是需要修复的错误。它们引导我们完全放弃查询时的视觉处理。

在索引时描述一次，作为文本检索

有效的方法反转了经济学。与其在每次查询时都支付处理图像的费用，不如在索引时一次性支付费用将每张图像转换为文本描述。之后，检索和生成完全在文本中进行。

在索引时，视觉语言模型为每张图像编写字幕。字幕与普通文本块一起存储和检索。在查询时，如果字幕相关，检索器将其拉入；模型看到字幕，而不是原始图像，并按其原始 URL 引用图像。

这之所以有效，是因为繁重的工作（实际查看图像）在摄入时进行一次，而不是在每次查询时进行。对于说明性截图，字幕是描述；对于承载性图表，它是对图表内容的转录、表格中的值、图表上的标签。无论哪种方式，内容都变成了文本，管道的其余部分永远不需要看到像素。微软的研究团队也得出了相同的结论：在摄入时描述，存储为单独的块。

这就是承载性案例有效的原因，也是许多助手悄悄失败的地方。颜色可用性矩阵是一堵复选标记的墙；防火等级表是一个等级网格。用通用提取器将其平展为纯文本，结构就会崩溃，这就是助手最终会自信地告诉客户一个面板有它没有的颜色的方式。在摄入时转录，相同的矩阵变成可检索的文本，答案仍然基于图表实际显示的内容。

对于数据表密集型产品，图表有时可能就是答案。不过，根据实际生产中的用户问题，这种情况很少出现。

生产中必须做对的事

过滤：大多数图像是垃圾，有些无法分类

你不能不分青红皂白地为数百万张图像添加字幕。大多数是噪音：徽标、头像、社交预览卡、装饰横幅。启发式方法处理第一遍（删除不支持的格式、微小图像、极端宽高比）。对于其余的，我们在多模态嵌入上构建了零样本分类器。它足够便宜，可以在整个语料库上运行。

在清晰的图像上，它达到 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：

在每个实验中，图像被正确放置的时间为 94% 到 99%。

这是一个不如"使用多模态模型"那样耀眼的答案，这正是重点。它之所以有效，是因为它把视觉放在该放的地方：在摄入时进行一次，将图像所包含的任何内容转换为文本，而不是在每次查询时都支付重新检查像素的费用。无论图像是澄清文字还是直接提供答案，读一次都更便宜，也更适合管道其余部分的工作方式。我们遇到的限制不是需要绕过的障碍；它们指向了架构。

现在推出预览版。

Silicon Labs 随便问...

Silicon Labs 随便问...

Logitech 随便问...

Logitech 随便问...

monday.com 随便问...

monday.com 随便问...

将技术文档转化为面向客户的 AI 助手