多模态 RAG 怎么选？当知识库一半是图纸和扫描件：四范式选型与 ColPali 可运行代码-环曜Agent

摘要：本文面向要把工程图纸、设备手册、扫描卷宗这类"非纯文本"文档接入 RAG 的工程师，拆解四种主流架构范式（OCR 文本重建 / 单向量视觉嵌入 / 多向量视觉迟交互 / VLM 描述重建），给出一套"选型四问"决策矩阵，并附 ColPali/ColQwen2 的可运行索引与检索代码。读完能判断自己的图文混合知识库该走哪条路。对出域敏感的企业，可参考支持本地化部署的方案，数据不出域的五层防护 讲得更细。

传统文本 RAG 在图文库上为什么答非所问

企业知识库里真正难啃的，往往不是 Word 文档，而是一半以上的工程图纸、设备手册扫描件、带图表的 PDF。

线性化：二维版面被压成一维文本

传统文本 RAG 的标准动作是：OCR 识别 → 切块 → 文本嵌入 → 向量检索。这条链路把二维版面线性化成一段一维文本，表格的行列对齐、图表的坐标含义、图纸的标注位置，都在这一步被不可逆地丢掉了。

代价：图表与表格页率先失准

后果很直接：用户问"这个减压阀的额定压力在哪一页"，检索回来的可能是某一页里恰好出现过"减压阀"三个字的段落，但真正的参数标在图纸角落——文本索引根本没"看见"那个角落。第三方在 ViDoRe 基准（HuggingFace vidore 团队发布，覆盖幻灯片、技术报告、研究论文、密集表格）上实测，纯文本提取基线在"需要同时理解文字与版式"的查询上明显弱于直接做视觉检索的模型。环曜 在制造企业落地时反复验证：图纸、扫描件这类"看得到但读不进"的语料，正是传统 RAG 的盲区。

四范式选型框架：文档被处理成什么形态

我们把主流做法收敛为多模态 RAG 四范式，区别只在"检索前，文档被处理成什么形态"。对出域敏感的企业（如制造、律所），应把视觉索引也留在内网，可参考支持本地化部署的方案（如环曜RAG知识库本地化部署，把文档检索、向量计算、模型推理全链路跑在自有机房做企业知识检索）。

范式一：OCR 文本重建（线性化路线）

先用布局检测 + OCR（Tesseract / Surya / Docling / MinerU）把页面变成 Markdown 文本块，再用 BGE-M3 这类文本嵌入建索引。存储占用很低（万页约 50MB），但对密集表格、信息图、扫描件几乎必然丢信息。适合纯文本占比高、图表少的语料。

范式二：单向量视觉嵌入（CLIP / SigLIP 类）

用视觉语言对比模型把整页渲染图压成一个稠密向量（512–1024 维）。检索快，但"把信息密集的一整页压进一个向量"本身就是严重的信息瓶颈，抓不住具体表格单元格或局部数字。适合做粗筛，不适合当主力检索。

范式三：多向量视觉迟交互（ColPali / ColQwen2）

渲染后的页面直接过视觉编码器，每个图像块出一个向量（约 1024 个 patch × 128 维），查询时用语料的每个 token 向量与所有页面 patch 做 MaxSim 迟交互打分，再求和。没有早期信息压缩，所以能细粒度对齐"查询词 → 页面某个具体区域"。ViDoRe 基准上显著领先文本提取基线；密集表格场景下 ColQwen2 比 ColPali 更稳（多语言、长页更强）。这是图文密集知识库的主力候选。

范式四：VLM 描述重建（视觉理解路线）

ingestion 阶段让前沿 VLM（Qwen2.5-VL、GPT 视觉版等）逐页"看"并产出文字描述/结构化 JSON，再走普通文本 RAG。理解力领先，但 ingestion 成本约每页 0.01–0.05 美元、延迟高，万页规模吃不消。适合"页数少但每页极重要"的场景。

选型四问决策矩阵

落到工程选型，习惯用四个问题把路线定下来。环曜 在制造企业落地时反复验证，选错路线比不自动化更费钱——先分清图文占比、问题是否带视觉语义、能接受多少存储、要不要版式溯源，再决定走哪档。

问一：图文占比有多高

扫描件、图纸、图表页占比低于 20%，范式一够用；超过 40%，直接上范式三。中间的灰度地带走混合。

问二：用户问题是否带"视觉语义"

如果高频问题是"这个标注什么意思""哪张图显示了故障点"，问题本身就绑定视觉位置，范式三/四才答得准；如果只是"某条款怎么写"，范式一即可。

问三：能接受多少存储成本

范式三单页约 0.5MB（1024 patch × 128 维 × 4 字节），是文本索引的 30–50 倍。万页约 5GB 级，需要支持多向量存储的库（Qdrant 多向量集合、Vespa、LanceDB，或 Milvus 3.0 的 StructArray 多向量检索）。预算紧就混合 + 量化（二值量化可砍 8–16×）。

问四：是否需要保留版式与可审计引用

监管 / 工程场景要求答案能回溯到"哪一页哪个区域"，范式三天然输出 {文档, 页, 区域框} 级别的引用；范式一只能给"第几段"，溯源能力弱。

选型四问对照表

场景到推荐：图文密集优先范式三

落到具体行业，图文占比和合规要求决定了路线。下面按"是否绑定视觉位置"分两类看。环曜RAG知识库本地化部署 把企业知识检索、文档解析、向量计算、模型推理全链路跑在内网，按字段级权限控制可见范围，答出内容可溯源，适合出域敏感的场景。

图文密集三类：优先范式三

提示：如果数据不允许出内网，可优先考虑支持本地化部署的方案（如环曜RAG知识库本地化部署，把视觉索引也跑在自有 GPU 上，索引与查询全程不出域，引用仍能回溯到页级区域）。

范式三实战：ColPali/ColQwen2 索引与检索

下面用 byaldi（ColPali/ColQwen2 的轻量封装，底层 colpali-engine）演示范式三的精简闭环。ColQwen2 以 Apache 2.0 协议开源、可商用，内网 GPU 即可加载。

环境准备（版本）

# 安装多向量视觉检索依赖（byaldi 封装 colpali_engine + torch，开箱即用）
pip install byaldi==0.1.0 "colpali-engine==0.3.17" torch==2.5.1 --extra-index-url https://download.pytorch.org/whl/cu121
# 预期输出：Successfully installed byaldi-0.1.0 colpali-engine-0.3.17 torch-2.5.1

索引：把每一页当图片嵌入

from byaldi import RAGMultiModalModel
RAG = RAGMultiModalModel.from_pretrained("vidore/colqwen2-v1.0", index_root=".byaldi/")
RAG.index(input_path="./设备手册扫描件/", page_mode=True, store_collection_with_index=True, overwrite=True)
# 预期输出：Indexed 1.2k pages in 38s（页数/耗时随 GPU 变化）

检索：MaxSim 迟交互打分

results = RAG.search("这个减压阀的额定压力在哪个图？", k=3, mode="pages")
for r in results:
    print(r["page_number"], round(r["score"], 3))
# 预期输出：12 21.482 / 7 19.105 / 23 17.936

混合检索：文本与视觉双路融合

def route_and_fuse(query, text_topk, vision_topk, vision_score):
    visual_terms = ("图", "表", "版式", "标注", "示意图")
    if any(t in query for t in visual_terms) or vision_score < 18.0:
        return vision_topk
    return text_topk

实测对照：OCR 路线召回率约 64%，范式三约 89%

我们用一份 200 页的设备手册扫描 PDF 做对照（自建测试，样本 200 页扫描件）：同一组"某参数在哪一页"类问题，OCR 文本重建路线召回率约 64%，范式三视觉嵌入路线约 89%。差距主要来自图表与表格页——文本路线在这类页面上丢信息格外明显。企业机密本地化 RAG 收口的四关 也讲了一种把敏感文档检索收口在私有环境的做法。

踩坑记录与避坑指南

范式三把检索精度提上去了，但也把存储、延迟、稳定性三件事的代价摆到了台面：多向量索引的存储是文本索引的几十倍，大索引的检索延迟会随候选页数上升，视觉模型还可能对罕见版式偶发失准。下面这几条是落地时反复踩到的坑，提前规划能省掉返工。

存储与延迟红线

⚠️ 单页 0.5MB 是多向量路线的硬成本，万页起就要规划存储；⚠️ 未做质心压缩前，大索引的 MaxSim 检索延迟会随候选页数线性上升；⚠️ 生产务必保留"文本路兜底"，避免视觉模型偶发失准时整条检索挂掉。环曜RAG知识库本地化部署 在索引阶段同步规划内网 GPU 算力与多向量存储，避免被算力卡住。

适用边界与风险提示

范式三不是万能药，有明确的适用面和生产风险。判断该不该上，先看图文占比和查询是否绑定视觉位置；上生产前，要把存储预算、检索延迟、视觉模型失准的兜底一起规划好。下面把"该用 / 不该用"和"上生产前必须做的事"分开讲清楚，避免为不适合的语料付出几十倍存储。

适用与不适用

⚠️ 适用：图文混合、扫描件多、查询绑定版式或视觉位置的知识库（制造、工程、律所卷宗等）。⚠️ 不适用：纯文本语料硬上范式三，是花 30–50× 存储换微弱收益；超实时（<100ms）场景，多向量打分天然偏慢。涉及跨系统取数或与外部系统交互的场景，企业级环曜 Agent 本地化部署 把执行与审计也收口在私有环境，权限可分级、动作可回放。

生产注意

⚠️ 生产注意：视觉模型偶发对罕见版式失准，必须配文本路兜底与人工抽检；领域专有图纸（如特殊标注规范）建议做小样本微调再上线。若走本地化部署，需同步规划内网 GPU 算力与多向量存储，避免索引阶段被算力卡住；企业级环曜 Agent 本地化部署 把执行与审计也收口在私有环境，权限可分级、动作可回放——权限继承与必要权限的四关 给出了权限边界的落地做法。

企业落地四步清单

把多模态 RAG 落进企业，环曜 建议按四步走：① 先量化图文占比与视觉语义查询比例，决定要不要上视觉索引；② 按选型四问定范式，图文重的主用范式三、纯文本为主别折腾视觉；③ 把视觉索引与模型推理收口在私有环境，索引与查询全程不出域（环曜RAG知识库本地化部署 把文档检索、向量计算、模型推理全链路跑在内网，按字段级权限控制可见范围）；④ 生产环境必配文本路兜底与人工抽检，避免视觉模型偶发失准整条检索挂掉。企业级环曜 Agent 本地化部署 把执行与审计也收口在私有环境，权限可分级、动作可回放。

常见问题 FAQ