Kapa 构建 AI 助手，回答技术文档中的问题。我们处理的知识库包含数百万张图像：屏幕截图、架构图、电路图、注释的用户界面示例。我们花了几个月的时间来研究如何使它们在我们的 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 引用图像。这有效，因为繁琐的处理（实际上查看图像）只发生一次，在摄取阶段，而不是在每个查询时。对于说明性屏幕截图，标题是描述；对于支撑性图形，它是图形中包含的内容的抄录、表中的值、图表上的标签。无论如何，内容变为文本，其余的管道再也不需要看到像素。微软的研究团队也得出了同样的结论：在摄取阶段描述，作为单独的块存储。这就是支撑性案例起作用的原因，也是很多助手悄然失败的地方。颜色可用性矩阵是一面勾选标记的墙；防火等级表是一个评分网格。将一种变为简单文本