什么是多模态 RAG？

多模态 RAG 从文本、页面图像、插图、表格或音频等多种表示中检索证据，再交给能够理解对应模态的模型。生产系统通常会组合 OCR 文本、版面元数据、图片描述、图像向量和视觉页面向量，而不是押注一个所谓通用索引。

ColPali 能完全取代 OCR 吗？

ColPali 可以直接对页面图像进行视觉文档检索，因此这条检索路径不依赖 OCR。但精确引用、无障碍访问、关键词检索、合规审计和下游结构化系统仍可能需要 OCR。OCR-free 是一种架构选择，不是所有场景的通用替代。

多模态 RAG 应该如何评测？

应分别评测检索、证据归因、回答和运营表现。检索使用页级或区域级 Recall@k、nDCG；归因检查引用正确性与证据充分性；回答使用任务相关准确率；运营层评估延迟、存储、Token、成本和失败率。

多模态 RAG：生产级架构、检索与评测指南

2026-04-08 - QubitTool 技术团队

多模态 RAG 不是某个模型的名字，也不是一条固定流水线。它是一套证据检索系统：精确语言由文本承载，阅读顺序由版面承载，图表含义存在于页面像素中，而细粒度答案可能只存在于一块表格区域。

因此，架构设计的起点不应是“选哪个多模态 Embedding”，而应该是：

能完整承载答案的最小证据单元是什么？哪种表示能稳定检索到它？

本文以视觉丰富的 PDF 为主线，从数据接入一直讲到评测。相同原则也适用于商品图片、演示文稿、扫描表单、工程图、视频帧和其他混合媒体。关键技术结论最后核验于 2026 年 7 月 16 日。

核心结论

保留原始资产和来源链路；OCR 文本与 Caption 只是索引，不是事实源。
文本优先、视觉优先和混合检索解决不同问题，没有一种方案统治所有语料与查询。
页级命中对生成阶段通常过粗，应保留坐标，把候选页继续缩小到答案区域。
ColPali 类后期交互模型保留视觉版面，但每页需要多个向量，会改变存储和排序成本。
先根据证据类型路由查询，再融合不同检索器的排名，不要直接混合不可比的原始分数。
先评测检索，再评测回答。未被召回的证据，再强的 VLM 也无法恢复。
文档文本、OCR、Caption 和像素都属于不可信输入，Prompt Injection 可以藏在任何模态中。

多模态 RAG 到底是什么

检索增强生成（RAG）包含两个可以独立设计的阶段：

检索：从语料库选择证据；
生成：解释证据并组织回答。

只要其中一个阶段使用多种模态或表示，系统就可以称为多模态 RAG。例如：文本问题检索图片；通过 OCR 文本定位 PDF 页面，再把页面像素交给 VLM；或同时运行文本与视觉检索器并融合排名。

这个定义能避免两个常见误区：

PDF 聊天机器人在解析阶段丢掉了全部视觉元素，却仍被称为多模态；
认为共享文本-图像向量空间是唯一正确架构。

正确方案取决于证据类型。合同条款需要精确文字；营收图需要坐标轴、图例和数据标记；扫描发票既需要识别数值，也需要保留数值之间的空间关系；商品搜索可能只需要全局视觉语义，并不关心文档版面。

保留证据图，而不是单一文本

不要把源文件压扁为一种有损表示。应保存一张连接原始资产与所有派生单元的证据图：

text

文档
  -> 页面图像
  -> 文本块 + 坐标框
  -> 表格 / 插图区域
  -> OCR 文本
  -> Caption 或摘要
  -> 一个或多个检索器的向量

每个索引单元至少携带：

json

{
  "document_id": "annual-report-2025",
  "page": 42,
  "region": [0.08, 0.31, 0.91, 0.78],
  "modality": "chart",
  "source_uri": "s3://reports/annual-report-2025.pdf",
  "content_hash": "sha256:...",
  "parser_version": "layout-parser-3.2",
  "access_scope": ["finance-team"]
}

归一化坐标让生成阶段能够按需要裁剪高清区域；Hash 与解析器版本让重建索引可审计；权限范围必须随每个派生物传播，否则受保护文档可能通过二级索引产生越权结果。

五类检索架构

1. 文本与版面检索

提取 PDF 原生文本或 OCR，保留文本块和坐标，再使用关键词与 Dense Retriever 建立索引。

**适合：**精确条款、人名、编号、以段落为主的文档，以及需要原文引用的场景。

**主要失败模式：**图表、视觉分组、合并单元格和阅读顺序可能丢失或重建错误。

这不是天然“落后”的方案。对于精确匹配查询，干净文本上的 BM25 可能比视觉向量更准确，同时占用更少存储。

2. Caption 或摘要代理

为每张图片、图表、表格或页面生成描述，并对描述文本建索引；命中后再回到原始视觉证据。

**适合：**复用成熟文本搜索设施、为不透明图片补充语义，以及规模较小的语料库。

**主要失败模式：**Caption 模型可能遗漏细节、误读图表，或抹平未来查询真正关心的差异。Caption 只能作为召回代理，不能作为权威证据。

3. 共享文本-图像向量

CLIP 系列双编码器把文本和图片映射到兼容空间，用一个相似度函数支持文搜图与图搜图。

**适合：**商品、场景、艺术品和全局视觉语义。

**主要失败模式：**单个全局向量压缩了整张图片或页面，容易忽略小表格单元、脚注，以及依赖版面关系的局部含义。

4. 视觉文档检索

ColPali 将页面图像编码为多向量，并通过后期交互，把查询 Token 向量与页面视觉 Patch 向量进行匹配。其论文同时提出 ViDoRe 基准，并在视觉丰富文档的页级检索任务上优于论文所比较的文本中心方案。

**适合：**表格、版面、字体和插图本身承载语义的页面。

**代价：**多向量索引的存储和计算成本高于每页单向量；候选页仍可能包含大量无关区域；精确文本和引用通常仍需要第二条处理路径。

“OCR-free”只表示视觉检索路径能够直接处理页面图像，不代表 OCR 在整个产品中不再有价值。

5. 混合多索引检索

根据查询并行运行关键词文本、Dense Text、Caption、全局图像和视觉文档检索器，对结果进行归一化或排名融合，再对小规模候选集 Rerank。

**适合：**查询类型复杂、召回要求高的企业语料库。

**代价：**组件更多、候选重复、索引成本更高。是否值得，必须与强文本基线比较。

架构	精确文本	版面/视觉	索引成本	可解释性
文本 + 版面	高	中	低-中	高
Caption 代理	中	中	中	中
共享向量	低	全局视觉语义高	低-中	低
视觉后期交互	中	视觉丰富页面高	高	中
混合检索	高	高	最高	保留来源时较高

查询路由与排名融合

不是每个问题都需要运行所有检索器。轻量路由器可以识别证据需求：

编号、原文、错误码 -> 关键词文本检索；
概念性段落 -> Dense Text；
“图中”“表 3”“比较两张图” -> 视觉检索；
意图不明或高风险问题 -> 并行混合检索。

路由的目标是节省成本，而不是制造单点故障。应设置置信阈值，意图不确定时回退到混合检索。

不同模型的 Cosine Similarity 分布并未校准，不能直接求平均。Reciprocal Rank Fusion（RRF）只组合排名位置：

python

from collections import defaultdict
from dataclasses import dataclass


@dataclass(frozen=True)
class Hit:
    evidence_id: str
    rank: int
    retriever: str


def reciprocal_rank_fusion(
    rankings: list[list[str]],
    rank_constant: int = 60,
) -> list[tuple[str, float]]:
    scores: dict[str, float] = defaultdict(float)
    for ranking in rankings:
        for rank, evidence_id in enumerate(ranking, start=1):
            scores[evidence_id] += 1.0 / (rank_constant + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)


text_hits = ["page-12", "page-42", "page-09"]
visual_hits = ["page-42", "page-18", "page-12"]
print(reciprocal_rank_fusion([text_hits, visual_hits]))

该示例只依赖 Python 标准库，可以直接运行。生产环境还应在 Trace 中记录每个候选来自哪个检索器及其原始分数，在证据单元层去重，并使用适合业务语料的模型进行 Rerank。

从页面命中到有依据的回答

检索与生成之间应传递 Evidence Package，而不是一组没有来源的图片：

python

from __future__ import annotations

from dataclasses import dataclass


@dataclass(frozen=True)
class Evidence:
    evidence_id: str
    document_id: str
    page: int
    region: tuple[float, float, float, float] | None
    text: str | None
    image_uri: str | None
    retrieval_reasons: tuple[str, ...]


def validate_evidence(item: Evidence) -> None:
    if item.page < 1:
        raise ValueError("page must be one-based")
    if item.text is None and item.image_uri is None:
        raise ValueError("evidence must contain text or an image")
    if item.region and any(value < 0 or value > 1 for value in item.region):
        raise ValueError("region coordinates must be normalized")

生成 Prompt 应要求模型：

只能根据提供的证据回答；
每个关键结论都引用文档与页码；
区分直接观察到的数值和推断结论；
证据不足或互相矛盾时明确说明。

对于图表和密集页面，可以同时传入页面缩略图与相关区域的高清裁剪。不要使用“固定带上周边 200 词”这类经验数字：真正的上下文边界可能是 Caption、表头、跨页章节或被引用的脚注。

评测：四道独立门禁

只看端到端回答，无法定位多模态 RAG 的问题。至少要分四层评测。

1. 数据接入保真度

代表性扫描件上的 OCR 字符或词错误率；
阅读顺序准确率；
表格结构准确率；
插图与 Caption 关联准确率；
带有效来源和权限信息的资产比例。

2. 检索质量

以系统实际使用的粒度建立标注：文档、页面、区域或资产。

Recall@k：候选集中是否包含答案证据；
MRR 或 nDCG@k：有效证据排位是否足够高；
模态切片：段落、表格、图表、示意图、扫描件、多语言页面；
查询切片：精确、语义、视觉、比较、多跳。

ViDoRe 适合评估视觉文档检索，但公开基准无法替代业务自身的版式、语言和真实查询分布。

3. 证据归因与回答

引用正确性：被引用区域是否支持结论；
引用完整性：关键结论是否全部有引用；
证据充分性：Evidence Package 是否足以推导答案；
任务准确率：Exact Match、数值容差、Rubric 或专家评审；
证据缺失时的拒答质量。

4. 运营指标

索引吞吐和失败率；
每页索引字节数与向量数；
检索和生成的 p50/p95 延迟；
图片 Token 与输出 Token；
缓存命中率和每个正确答案的成本；
权限过滤与删除传播延迟。

所有复杂方案都应与强基线比较。如果视觉混合流水线在真实查询上只提升一个点的 Recall@10，却让延迟翻倍、成本变为三倍，它未必是产品改进。

安全与隐私

多模态输入会扩大攻击面：

恶意指令可以藏在正文、OCR Layer、图片、二维码或元数据中；
检索文档可能试图覆盖系统指令；
图片可能包含人脸、签名、账号或位置数据；
原文件删除后，Caption 与向量仍可能保留敏感信息。

检索内容只能作为引用证据，不能被当作指令执行。检索前和生成前都要鉴权；解析器应在沙箱运行；限制文件大小和页数；扫描 PDF 主动内容；记录所有派生物的血缘；删除操作必须传播到文本、裁剪图、Caption、缓存和向量索引。

生产决策清单

定义查询类型和最小答案证据单元；
增加视觉索引前，先建立文本 + 版面强基线；
保留原件、坐标、来源、版本和权限；
按查询类型选择检索器，不确定时回退到混合检索；
使用排名融合或校准分数，不盲目平均相似度；
在昂贵 VLM 调用前完成检索、Rerank 和区域裁剪；
强制页级或区域级引用，并允许拒答；
分别评测接入、检索、归因、回答和运营；
对所有派生表示测试 Prompt Injection 与删除传播；
模型、解析器或权限策略变化时可复现地重建索引。

常见问题

文本 Embedding 能直接处理图片吗？

不能。文本 Embedding 只能处理文本表示。可以把生成的 Caption 建入文本索引，但检索上限取决于 Caption 保留了什么。直接文搜图需要兼容的多模态编码器或独立视觉检索模型。

ColPali 一定优于 OCR + 文本检索吗？

不一定。ColPali 面向视觉丰富的页级检索，并在 ViDoRe 上表现突出。精确引用、编号、干净段落、低存储部署和合规流程仍可能更适合文本或混合检索。必须在自己的语料上对比。

向量数据库应该存图片字节吗？

通常不应该。不可变原始资产放在对象存储，索引中保存 URI、Hash、坐标、权限和模型版本。这样能避免索引膨胀，也让生命周期管理更清晰。

如何控制多模态 RAG 成本？

把纯文本问题路由离开视觉生成；先检索再调用 VLM；只裁剪答案区域；限制候选数和图片分辨率；缓存不可变派生物；用“每个正确答案的成本”而不是“每次请求成本”衡量效率。

总结

生产级多模态 RAG 是一套证据架构，而不是把 PDF 截图发给视觉模型的演示。系统质量取决于是否保留多种表示、选择正确的检索单元、组合互补检索器，并证明最终回答由可定位证据支持。

从能够保留用户所需信息的最简单基线开始。只有真实评测暴露了文本方案的不足，才引入视觉检索并承担其存储、延迟与运维成本。

一手资料

上一篇:RAG 分块策略：如何评测 Chunking 是否有效

下一篇:长上下文时代 RAG 还有必要吗？成本 vs 准确性的决策框架