你花了两周调 chunk size，换了三种 embedding 模型，reranker 也加上了——《Rerank 在 RAG 中的角色：Bi-Encoder vs Cross-Encoder》里讲的那些优化你全做了。但回头一看，技术文档里的截图、架构图、参数表格，这些图片承载的信息，你的系统压根没碰。

这不是小问题。kapa.ai 的团队最近在 Hacker News 上分享了他们的生产实践（89 points），标题直白：How we index images for RAG。他们服务 200+ 客户，知识库里有数百万张图片，每天处理百万级查询。这篇文章把他们的方案拆开来看，顺便聊聊 ColPali 等另一条路线，以及你到底该选哪条。

图片在技术文档里到底干了什么

kapa.ai 把文档图片分成两类，这个分类非常实用。

说明型（illustrative）：文字说"点击设置图标"，旁边的截图标出了图标在哪、长什么样。图片让答案更直观，但信息本身在文字里也有——用户不看图也能做事，只是要多找一会儿。

承重型（load-bearing）：接线图、参数规格表、认证矩阵、颜色可选表——这些图里的数值只存在于图片中。你不看图，就根本不知道答案。

他们跑了上千条真实客户问题验证：有图片上下文时，LLM 评委（McNemar 检验，p < 0.05）显著偏好带图片的答案。效果不是微调能弥补的那种——是用户能感知到的质变。

但问题来了：怎么把这些图片喂给 LLM？

查询时看图：一个看起来对、实际上贵到用不起的方案

直觉反应是：检索到相关 chunk 后，把它们引用的图片一起丢给多模态模型（GPT-5.1、Claude 4.6 Sonnet 等）。kapa.ai 测试了这个方案，发现三个结构性问题：

1. 贵得离谱。 原始图片让 GPT 单次查询成本增加 27%，Claude 增加 51%（Claude 把一张图编码成约 975 tokens，GPT 约 716）。kapa.ai 每天百万级查询，这笔钱根本花不起。

2. 塞不进去。 一个典型问题检索 10-30 个 chunk，平均引用 20-30 张图片，长尾能到 130 张。Claude 的 payload 上限 30 MB，OpenAI 的 50 MB——超过 20 张图就撞墙了。

3. CLIP 式嵌入在技术文档上失效。 CLIP 这类视觉嵌入模型擅长的是"这是一只猫"还是"这是一条狗"，不是"这个表格第三行的耐火等级是多少"。短技术查询（“how do I configure X”）和图表细节之间，语义鸿沟太大。

kapa.ai 的结论很干脆：这些不是工程细节能调掉的问题，是今天多模态生态的结构性限制。于是他们换了一条路。

索引时描述一次，查询时当文字检索

核心思路反过来：重活在索引时干一次，查询时完全不碰图片。

流程很清晰：

1. 索引阶段：用视觉语言模型（VLM）给每张图片生成一段文字描述（caption）
2. 存储：caption 作为独立的文本 chunk 存进向量数据库
3. 查询阶段：检索器照常做文本检索，如果 caption chunk 被命中，就把它放进上下文

这样查询时的成本几乎不增加（纯文本检索），延迟也几乎不变。“看图"这个昂贵操作只发生一次——在文档摄入的时候。

听起来简单，但生产环境里有三个关键细节决定了成败。

关键细节一：大多数图片是垃圾，过滤是第一步

你不能给知识库里的每张图都生成描述。Logo、头像、社交预览图、装饰性横幅——这些占了大多数。

kapa.ai 用启发式规则做第一轮过滤（丢掉不支持的格式、过小的图片等），然后用分类器做第二轮过滤。在明确的图片上，分类器准确率 96.8%（F1 0.974），但在模糊图片上准确率暴跌到 59.8%。

原因很根本：一张倒计时截图，你分不清它是装饰性横幅还是功能性内容。图片分类在边界情况下就是很难。

关键细节二：上下文比模型大小更重要

给 VLM 喂图片时，把图片前后的段落一起喂进去，caption 质量会大幅提升。没有上下文时，一个文件上传对话框的描述是"一个有文件选择按钮的网页”；有上下文后，描述变成"项目配置页面中的文件上传对话框，用于导入自定义规则集"。

另一个有意思的发现：贵的模型几乎不值得。 他们测试了五个模型，从 Claude 4.6 Sonnet 到 GPT-5.4 nano。小型模型（GPT-5.4 mini）生成的 caption 和四倍价格的大模型几乎无法区分。

这很符合直觉——描述一张截图不需要博士级推理，需要的是看清图片内容并用准确的语言表述。小模型就够了。

关键细节三：独立存储优于内联替换

两种存储 caption 的方式：

• 内联（inline）：替换图片的 alt text，让 caption 和原文混在一起
• 独立（separate）：每个 caption 作为单独的 chunk 存储，原文 chunk 保持不变

直觉告诉你会内联更好——caption 和上下文紧挨着嘛。但实际测试中，独立存储在成本和图片使用率上都赢了。

原因：内联 caption 会膨胀每个它所在的 chunk，而这些 chunk 每次查询都要发送。独立 chunk 只在相关时才被检索到，不相关的查询根本不会为它付 token 费。

生产环境数据

端到端测试（三个客户项目，GPT-5.1 和 Claude 4.6 Sonnet）：

用 1%-6% 的成本换来 10%-64% 的图片引用率提升，且图片放置正确率 94%-99%。这笔账怎么算都划算。

另一条路：ColPali 的视觉检索方案

kapa.ai 的方案是"把图片变成文字再检索"。ColPali（2024，illuin-tech，2652 stars）走了完全不同的路：直接在视觉空间做检索。

ColPali 用 PaliGemma-3B 的 ViT 输出作为多向量表示，按 ColBERT 的方式训练。它跳过了 OCR 和版面分析，直接把文档的视觉特征编码成嵌入，查询时在视觉空间里做相似度匹配。

ColPali 的优势在于：

• 不需要 OCR 或版面识别管线——端到端一个模型搞定
• 对图表、表格等视觉信息天然友好——不像 CLIP 那样丢失细节
• 在 ViDoRe benchmark 上表现优异

但 kapa.ai 在生产中对 CLIP 类方法的批评同样适用于 ColPali：

• 短查询 vs 长文档的语义鸿沟——用户问"how do I configure X"，和一张架构截图之间的匹配，视觉嵌入很难做好
• 推理成本——每次查询都要对所有候选文档做视觉编码比对，在百万级查询场景下不现实
• 工程复杂度——需要维护专门的视觉检索基础设施

说白了，ColPali 更适合文档问答场景（比如你有一个 PDF 库，每份文档都要理解图表），而 kapa.ai 的方案更适合大规模知识库检索场景（技术文档 RAG，查询量大，成本敏感）。

实操建议：你的 RAG 管线怎么选

根据你的场景，选择不同的路线：

场景 A：技术文档 RAG，查询量大（>1 万次/天） → kapa.ai 方案：索引时用 VLM 生成 caption，独立 chunk 存储，查询走纯文本。成本可控，延迟低，效果有保障。

场景 B：文档问答，查询量小，但文档图表密集 → ColPali 方案：直接在视觉空间检索，跳过 OCR 管线。适合研究、法律、金融等需要理解复杂图表的领域。

场景 C：预算有限，只想快速验证 → 先用 OCR + 图片 alt text 提取文字，和文本 chunk 一起存。效果不如前两种，但零额外成本。

场景 D：已有成熟文本 RAG，只想补上图片能力 → 按 kapa.ai 的方案做增量：给已有文档的图片批量生成 caption，作为新 chunk 加入向量库。不需要改动现有管线。

几个容易踩的坑

1. 别用大模型生成 caption。 前面说了，小模型就够。用 GPT-4o 描述截图是拿大炮打蚊子。

2. 一定要喂上下文。 没有前后文的图片描述质量差两个档次，这个投入绝对值得。

3. 过滤比生成更重要。 大多数图片是噪声，不过滤的话 caption chunk 会严重污染检索结果。

4. 独立存储，不要内联。 这个反直觉，但实测数据很清楚。

5. 别把图片当文本的附属品。 在 RAG 管线设计时就把图片处理作为一等公民，而不是"后续优化"。

写在最后

RAG 领域的优化已经卷到了 text chunking、embedding、reranking 这些层面，但图片处理一直是个被忽视的角落。kapa.ai 的方案之所以有价值，不是因为技术多新，而是因为它在生产环境里跑通了——百万级查询、200+ 客户、有数据支撑。

如果你在做技术文档类的 RAG，我建议认真考虑这个方案。投入小（1%-6% 成本），回报大（10%-64% 图片引用率），且不需要重构现有管线。

相关阅读：

• 《Rerank 在 RAG 中的角色：Bi-Encoder vs Cross-Encoder》 — 如果你还没加 reranker，先看这篇
• 《Stash：开源 AI 记忆层的工程实践》 — RAG 之外的另一种知识管理思路

信源：

• kapa.ai: How we index images for RAG
• ColPali: Efficient Document Retrieval with Vision Language Models (GitHub)
• ColPali Paper (arXiv: 2407.01449)
• Unstructured: Document ETL (GitHub)
• HN Discussion

2025 年中，某金融科技公司在内部知识库问答系统中引入 RAG（检索增强生成）。系统上线后，用户反馈普遍不错——直到某天，一个风控团队的用户问：“我们有哪些客户曾经有过信用违约记录？”

RAG 系统检索返回了三条"高相关"文档，AI 基于这些文档给出了自信满满的答案。风控经理看完后直接冷汗：系统返回的内容全是关于"信用良好客户"的正面案例，和用户的查询意图完全相反。

事后排查发现，问题出在向量检索阶段。用户的查询"信用违约记录"和文档中大量出现"信用"“违约"字眼的高频正面记录产生了极高的余弦相似度，而真正描述违约事件的文档因为语言表达更隐晦，反而相似度偏低，被 Top-N 过滤掉了。

这是一个典型的向量检索只看词不看语义关系的失败案例。¹

向量检索的物理课：两个不相识的学生在各自考试

理解为什么向量检索会"看走眼”，需要先理解它的工作原理。

向量检索的核心是Bi-Encoder（双编码器）架构。当你把文档存入向量数据库时，每个文档都会通过一个 Encoder 被压缩成一个固定长度的向量——通常 768 维或 1024 维。这个过程发生在入库时，与用户未来的查询完全无关。

当用户发起查询时，查询文本同样通过 Encoder 生成一个查询向量。然后，数据库在高维空间中做最近邻搜索（通常用余弦相似度或内积），找出与查询向量"距离最近"的 N 个文档。

这个过程有一个非常关键的特征：Query 和 Document 的编码是独立完成的，它们从未"见面"。

斯坦福大学 NLP 组有一个很直观的比喻：就像两个学生分别在不同的考场同时参加考试，学生 A（Query 编码器）看了一眼题目后把答案写成压缩笔记，学生 B（Document 编码器）提前把教科书内容写成压缩笔记。考试结束后，系统只是比较这两份笔记的"形状"有多像，而不知道题目问的是什么。

这解释了为什么"信用违约记录"的查询会匹配到"信用良好客户"文档：两份文档都高频出现"信用"字眼，它们的向量在语义空间中距离很近，而模型根本不知道"违约"和"良好"是反义词。

重排模型：让 Query 和 Document 当面对质

Cross-Encoder（交叉编码器）采用了完全不同的策略。

它不做"独立压缩"，而是把**[Query + Document] 拼接成一段完整文本**，一次性通过一个深度神经网络（如 BERT）。在这个过程中，模型的注意力机制（Self-Attention）会在每一个 token 层级做交叉比对——当读到 Query 中的"违约"时，它会立刻去 Document 中寻找是否存在"违约"、是否存在语义矛盾、是否存在否定结构。

这种"当面对质"的方式，让 Cross-Encoder 能捕捉到 Bi-Encoder 完全无法处理的关系：

• 语义否定：Query “如何不用 Python” vs Document “Python 教程”——Bi-Encoder 会给高分，Cross-Encoder 能识别"不"的否定作用
• 长距离依赖：查询涉及某个条件组合，文档在开头提到条件A、结尾提到条件B，Cross-Encoder 的注意力能跨越全文找到同时满足两个条件的文档
• 细微差异：两份文档语意相近但立场相反（如上面的违约案例），Cross-Encoder 能识别出差异

用一个直观的对比表总结：

工程正解：先召回后重排的两阶段架构

理论上最准确的方案是让所有文档都过 Cross-Encoder，但这是不现实的——Cross-Encoder 的计算成本比向量检索高出 2-3 个数量级。如果对全量文档做 Cross-Encoder 重排，一次查询可能需要几十秒甚至几分钟。

生产环境的正确做法是先快后准的两阶段流水线：

用户查询
    │
    ▼
┌─────────────────────────┐
│  Stage 1: Bi-Encoder    │  ← 向量检索，毫秒级，从百万文档中召回 Top 100-500
│  (向量数据库: FAISS/     │
│   Milvus/Qdrant)         │
└────────────┬──────────────┘
             │ 粗筛候选集（可能包含语义噪声）
             ▼
┌─────────────────────────┐
│  Stage 2: Cross-Encoder  │  ← 重排模型，对 Top 100-500 做精细排序
│  (如 BGE-Reranker、      │
│   Cohere Rerank 3)        │
└────────────┬──────────────┘
             │ 精排结果（Top 10）
             ▼
        LLM 生成答案

这个架构在 2025-2026 年已成为 RAG 系统的事实标准。背后的核心洞察是：速度和准确性是一对矛盾，但它们的适用场景不同。向量检索负责从海量数据中快速筛选候选集（追求召回率），重排模型负责从候选集中精确选出最好的 N 个（追求精确率）。

2026 年的重排模型格局

当前生产环境主流的重排模型有几个选择²³：

BGE-Reranker（智源开源）

• 基于 BAAI/bge-reranker-v2-gemma 模型
• 支持中英文双语，在中文语义理解上优于西方开源模型
• 提供 v1（纯 Transformer）和 v2-gemma（更大参数量）两个版本
• 可直接通过 Sentence Transformers 库调用

Cohere Rerank 3 -闭源 API，按调用次数计费

• 在多语言场景下表现稳定，有完善的评估体系
• 优点是不需要运维，缺点是数据需要经过第三方

Mixedbread mxbai-rerank

• 开源可自托管
• 专注文档相关性排序，适合企业内部私有知识库场景

性能对比：数字不会说谎

在 Hugging Face 的 MTEB（Massive Text Embedding Benchmark）排行榜上，Bi-Encoder 和 Cross-Encoder 在不同任务类型上的表现差异非常显著⁴：

差距最大的场景是问答匹配——这恰恰也是 RAG 系统最核心的场景。这组数字印证了前文那个金融风控 Bad Case 的根因：Bi-Encoder 在"问什么"和"答什么"的语义匹配上天然存在短板。

工程实践中的常见陷阱

陷阱 1：召回数量设得太少

很多团队把 Top-N 设成 5 或 10，看起来"够用了"。但研究发现，在复杂查询场景下，正确答案经常出现在 20-50 名之后——特别是当文档库很大、正确答案的表述方式与查询query差异较大时。推荐起始值设为 50-100，留给重排模型足够的候选空间。

陷阱 2：重排后不再过滤

Cross-Encoder 给出的相关性分数是相对的，不是绝对的——它只能告诉你"这篇比那篇更相关"，不能告诉你"这两篇到底有多相关"。如果重排后 Top 10 中出现了明显不相关的文档，需要设置一个相关性分数阈值做二次过滤，而不只是信任重排模型的排序。

陷阱 3：把重排模型和 Embedding 模型混用

Cross-Encoder 的重排效果和它用的 Encoder 有耦合关系。BGE-Reranker 在 BGE 生成的 Embedding 基础上表现最好，换成 OpenAI 的 text-embedding-3-large 后效果会有明显下降。重排模型和向量编码器最好来自同一个模型族，或经过联合调优。

什么时候不需要重排

两阶段架构不是银弹。如果你的场景满足以下条件，可能不需要重排：

• 文档结构单一、表述标准：比如内部 FAQ，Query 和 Answer 通常高度匹配，Bi-Encoder 的召回准确率已经足够
• 实时性要求极高：比如流式对话场景，重排增加的 50-200ms 延迟可能不可接受
• 文档量级较小：如果你的向量数据库只有几千篇文档，完全可以对全量做 Cross-Encoder 重排

延伸：多路召回的崛起

2025 年下半年，一个更复杂的架构开始流行：多路召回（Multi-Retrieval）。它不只是向量检索 + 重排，而是同时调用多种检索路径——向量检索、BM25 关键词检索、GraphRAG 的知识图谱检索——然后用重排模型统一对各路结果做二次排序。

这种架构背后的洞察是：没有任何单一检索方式在所有 query 类型上都表现最优。向量检索擅长语义匹配但对专有名词不敏感，BM25 对精确匹配很强但不懂语义，多路召回通过让各路"投票"，能显著提升召回的鲁棒性。

相关链接：
¹ Stanford HAI RAG Evaluation: https://hai.stanford.edu/
² BGE-Reranker v2 on Hugging Face: https://huggingface.co/BAAI/bge-reranker-v2-gemma
³ Cohere Rerank Documentation: https://docs.cohere.com/docs/rerank
⁴ MTEB Leaderboard: https://huggingface.co/spaces/mteb/leaderboard