Chapter 01

视觉文档检索为什么崛起

企业里 80% 的文档长得不像 markdown:扫描合同、财报 PDF、科研论文、产品手册……这些页面充满表格、图表、图文混排。传统 OCR+Chunking 的 RAG pipeline 在这里水土不服。ColPali 给出了另一条路:别解析,直接看

老 pipeline 的七宗罪

┌──────────┐ ┌──────┐ ┌──────┐ ┌─────────┐ ┌────────┐ │ PDF / 图 │→│ OCR │→│切块 │→│文本 Embed│→│向量索引 │ └──────────┘ └──────┘ └──────┘ └─────────┘ └────────┘ ↓ 每一步都在丢信息 表格结构丢了、图表描述丢了、多栏顺序错了、字体重音丢了、图里文字识别错了、段落边界猜错了、跨页引用断了
扫描文档 OCR 错误率
印刷品 OCR 到 98%+ 听着不错,但财报/合同里一个数字、一个币种符号识别错,下游答错的概率就是 100%。
图表/表格难 serialize
把表格变成 CSV 要再跑一个布局分析模型,折线图要 chart-to-table,每一层都是误差源。
多栏 / 杂志版式
PDF 的文本流 ≠ 阅读顺序。两栏论文被错按行拼接,一段话分到两个 chunk。
长公式 / 代码 / 非拉丁文
OCR 对 LaTeX、代码缩进、中日韩混排错误率飙升。
工程复杂度
生产 RAG pipeline 常堆了 OCR 引擎、布局分析、表格抽取、图像描述、切块 heuristics——每个组件都要维护、升级、监控。

ColPali 的冷思考

2024 年 Illuin Technology 团队发表论文《ColPali: Efficient Document Retrieval with Vision Language Models》,提出一个简单到刺眼的想法:

核心洞察
VLM(视觉语言模型)已经能"读"图像中的文字、图表、公式,而且内部已经把视觉和语言对齐到同一 embedding 空间。既然如此,何必把文档先过一遍 OCR 再索引?直接把页面图像扔进 VLM,拿 patch-level embedding 做检索不就行了?

实验结果震撼——在 ViDoRe benchmark 上,ColPali 比当时最强的"OCR + BM25 + 语义重排"流水线 nDCG@5 高出 20+ 个点,且索引代码从几百行降到几十行。

ViDoRe 基准

ColPali 团队同时开源了 ViDoRe(Visual Document Retrieval) benchmark,涵盖十大类视觉文档:

数据集文档特点典型 query
ArxivQA论文图 / 公式"图 3 的 y 轴是什么?"
DocVQA表单 / 发票"总金额多少"
InfoVQA信息图 / 海报"图标代表什么"
TabFQuAD法语表格法语业务问答
Shift Project环保报告表格图"2050 年预测 CO2 排放"
Energy能源报告"核电比例"
Government Reports政府文件扫描版政策条款查询
Healthcare医疗图表"图中哪种药疗效最好"
Artificial IntelligenceAI 论文幻灯片"Transformer 结构图"
ViDoRe v2(2025)更难、更长、中英混合多页跨文档引用

ColPali 吊打 OCR pipeline 的三张硬牌

① 无解析环节

输入只有 image.png。没 OCR 引擎、没布局分析、没表格抽取——输入越少,误差源越少。代码简化到 ≤ 50 行。

② 视觉信息保留完整

图表的形状、颜色、字体大小、表格结构在像素里还在。模型"看到"了,文本 pipeline "看不到"。

③ Late Interaction 灵活

每页输出 1024 个 patch 向量,query 也是多 token 向量。查询时算 MaxSim——每个 query token 找最相近的 patch。相当于"眼睛扫描全页,只盯相关部分"。

④ 跨语言白送

PaliGemma 本来就多语言训练。中文 PDF、日语技术文档、阿拉伯法律文件,同一个模型通吃。

谁不该用 ColPali

不是银弹——以下场景先别上:

本章小结