RAG 系统用图像替代文本解析
直接用图像而非文本解析用于 RAG,避免格式损失、提升检索质量的创新方案。328 points 热度验证其价值。
直接用图像而非文本解析用于 RAG,避免格式损失、提升检索质量的创新方案。328 points 热度验证其价值。
在 Morphik,我们构建 RAG 工具为开发者提供复杂文档的精准搜索功能。在本文中,我们解释为什么我们使用页面"图像"而不是进行 OCR/解析。
如果你曾经尝试从复杂 PDF 中提取信息——包含图表、图表和表格混合文本的 PDF,你会知道这有多痛苦。那份包含按季度细分的嵌套表的发票?研究论文中那些复杂的图表实际上包含关键发现?技术手册中注释的图表解释的内容比文本本身要多得多?或者根本没有文本的 IKEA 说明书?
我们都经历过,看着精心设计的解析管道又一次搞乱文档。这个行业的肮脏秘密是我们花费巨大的努力(和金钱)在 OCR、布局检测和解析管道上,但仍然丧失了最重要的信息。这就像通过读电影脚本来"观看"电影:你错过了所有使其有意义的视觉叙述。
例如,让我们以一个非常简单的全文本页面(未扫描,没有图表等)为例,如下所示:
Fig 1: Simple page showing Palantir financials
如果我尝试用常见的 OCR 工具解析它(数值可能会正确识别,但标题和数值会全部混乱,加上标准分块,我们在检索时可能无法发送正确的信息)
US commercial continues to accelerate in Q1 2025 alongside AIP revolution
US Commercial Revenue
US Commercial Customer Count
US Commercial Revenue
US Commercial Customer Count
US Commercial Remaining Deal Value
US Commercial Total Contract Value
US Commercial Deals Closed of $1M or Greater
US Commercial Remaining Deal Value
US Commercial Total Contract Value
2025 Palantir Technologies Inc.
We dene a customer as an organization from which we have recognized revenue during the trailing twelve months period.
这可能是最简单的文档之一,我们还没有涉及复杂的或技术性的文档。
注意/旁注:你可能仍然需要将文档转换为文本或结构化格式,这对于将信息同步到结构化数据库或数据湖至关重要。在这些情况下,OCR 是有效的(虽然有其怪癖),但根据我的经验,将原始文档传递给 LLM 会更好(我们在 Morphik workflows 中这样做,了解更多信息点这里)。
当我们开始在 Morphik 构建 RAG 时,我们做了每个人都在做的事:组装标准的文档处理管道。你知道的那个,它从 OCR 开始,以泪水结束。
这就是所谓的"最先进"管道实际上的样子:
对 PDF 运行 OCR(希望它正确读取数字)
部署布局检测模型(希望它们识别表格边界)
重建阅读顺序(希望它遵循视觉流)
使用专门模型为图表生成标题(希望它们捕捉细微差别)
"智能"分块文本(希望你不会分割相关信息)
使用 BGE-M3 或类似工具生成嵌入(希望含义得以保留)
存储在向量数据库中(希望你稍后能找到它)
以一份包含显示分项成本的表格的简单发票为例。首先,你的 OCR 可能会将"1,000"读为"l,0O0"(这些是字母,不是数字)。然后你的布局检测器可能会错过小计行实际上是表格的一部分。你的分块策略将表格从其标题中分离出来。当你搜索"Q3 总成本"时,你正在搜索与原始文档几乎没有相似之处的残缺文本。
我们曾花费六个小时调试为什么我们的系统找不到在财务报告中明确可见的信息。事实证明,解析管道将饼图的图例解释为正文,将百分比分散在不相关的段落中。
即使 OCR 完美无瑕地捕捉了每个字符,锁定在图像、图表和表格中的含义仍会消失。假设布局检测完美地确定了每个边界框;你仍然需要依赖图表标题,而标题不可避免地遗漏关键背景。混合方法——将文本馈送给文本嵌入模型,将图像馈送给图像嵌入模型——听起来很吸引人,但它打破了文档的位置背景。依赖空间关系的查询("图表中哪个部分标记了 Q3 总额?")变得不可能,文本和图像的嵌入存在于不同的空间,检索管道难以协调它们。位置丧失、模态差距和分裂的语义复合成感觉随意的答案。实际上,你仍然无法信任该管道。
启示来自于又一个调试会话。我的联合创始人(也是我的兄弟 🙂)阿尔纳夫提出了改变一切的问题:"为什么我们要解构这些文档只是为了重新构建含义?如果我们像人类那样对待它们:作为视觉对象呢?"
听起来几乎太简单了。但这正是最近的 ColPali 研究证明是可能的。Vision Language Models 已经悄然变得足够好,可以直接理解文档。没有解析。没有 OCR。没有重建。只是:文档 → 图像 → 理解。
优雅是令人震撼的。与其说七个脆弱的步骤,不如说你有一个健壮的操作。与其在每个阶段都丧失信息,你保留了一切:每个图表、每个表格关系、每个使文档对人类来说可以理解的视觉线索。
在 Fig 1 中,LLM 在这种情况下"看到"的是直接页面本身,保持所有位置信息!
现在变得在技术上有趣了。ColPali 模型不仅仅是"看"文档。它以与传统方法根本不同的方式理解它们。
这个过程简单得漂亮:
首先,我们将每个文档页面视为图像,本质上是对页面进行高分辨率屏幕截图。这个图像被分成补丁,就像在页面上铺一个网格。每个补丁可能包含几个单词、图表的一部分或表格单元格。
Vision Transformer(特别是 SigLIP-So400m)处理这些补丁,但这是巧妙的部分:它不是试图提取文本,而是创建理解上下文中文本和视觉元素的丰富嵌入。然后这些嵌入由已被训练以理解文档结构的语言模型(PaliGemma-3B)进行精化。
当你搜索"Q3 收入趋势"时,魔法通过所谓的"后期交互"发生。该模型不仅仅寻找那些确切的词语,它找到包含文本"Q3"的补丁、单词"revenue",还有显示上升趋势的图表的相关部分、包含季度数字的表格单元格,甚至指示性能的彩色编码元素。
这就像有一个人类专家能够立即扫描每一页并理解不仅仅是写下的内容,还有显示的内容。
阿尔纳夫对 ColPali 的有趣概述在这里。(更多满足技术需求)
Fig 3: Comparison of traditional pipelines vs ColPali
当我们构建 Morphik 时,我们实现了 ColPali,很快发现将其产品化比研究建议的复杂得多。当时没有向量数据库直接支持我们期望的相似性函数,每个提供商都提供了针对单个向量的优化,而不是多向量,这极其缓慢。我们添加了二进制量化和随后使用汉明距离进行计算而不是点积等优化,以及其他性能改进……每一部分都隐藏了复杂性。
但真正的测试来自于我们与现有解决方案的比较。
为了超越轶闻证据验证这些观察,我们与 TLDC(The LLM Data Company)合作,构建了一个开源的财务文档基准,包含 45 个跨 NVIDIA 10-Q、Palantir 投资者展示和摩根大通报告的具有挑战性的问题。TLDC 有一个复杂的多步骤过程来生成这些评估,他们的目标坦率地说是羞辱我们。他们想要能够暴露任何文档检索系统局限的问题。评估框架设计易于使用,任何人都可以针对这些相同的问题测试他们的 RAG 系统,看看他们的表现如何。
结果令人震惊:虽然其他端到端提供商的准确率峰值约为 67%,甚至精心优化的自定义 LangChain 管道(具有语义分块和 OpenAI 的文本嵌入大模型)达到了 72%,Morphik 在同一评估集上达到了 95.56% 的准确率。作为比较,OpenAI 的文件搜索工具代表了一个可靠的基线,在这些具有挑战性的财务文档问题上仅达到 13.33% 的准确率。
在 ViDoRe 基准上,第一个专为视觉文档检索设计的评估,我们的方法达到 81.3% nDCG@5,相比之下传统解析方法为 67.0%。但正如我们自己的评估所示,基准只讲述了故事的一部分。真正的区别在于以文档应该被理解的方式理解文档。
想要测试你自己的系统?整个评估框架已经准备好使用。只需克隆仓库,添加你的 RAG 实现,然后看看它在相同的具有挑战性的财务文档问题上的表现如何。
好吧,所以我们获得了真正的高准确率,但老实说:我们的第一个实现很慢。视觉理解是计算密集的,ColPali 的原始多向量方法意味着在规模上搜索数百万个补丁嵌入。在每个查询 3-4 秒的检索时间,这是令人印象深刻的,但对于查询数千份文档并要求快速的客户来说不是生产就绪。
突破来自于 MUVERA 论文。与其独立搜索所有补丁嵌入,MUVERA 使用固定维度编码将多向量搜索简化为单向量相似性。可以把它看作是创建一个"摘要指纹",在保留丰富补丁交互的同时速度快得多的搜索。
我们将其与 Turbopuffer 配对,一个为此用例构建的向量数据库。结果转变了我们的系统,我们的查询延迟从 3-4 秒降至 30 毫秒。
数学完美地发挥作用:我们现在可以搜索数百万份文档的速度比传统系统解析单个 PDF 还快。
忘掉与文档解析库的斗争。忘掉维护文本提取、表格检测和 OCR 的独立管道。忘掉每次文档不符合你的解析假设就丧失关键信息。
通过视觉文档检索,你只需将你的文档发送给我们——PDF、图像、甚至白板的照片——然后用自然语言搜索。它对以下情况特别有效:
财务文档:图表和表格讲述真实的故事
技术手册:图表值千言万语
发票和收据:布局和结构具有含义
研究论文:图表包含实际发现
医疗记录:视觉布局表示关系
API 特意设计得简单:上传你的文档,使用诸如"显示我所有包含超过 10000 美元罚款条款的合同"或"找到去年提案中的部署架构图"之类的查询进行搜索。
视觉文档理解解决了基础问题,但真实世界的文档工作流需要的远不止单次检索。我们正在构建的未来涉及真正理解背景、关系和复杂推理链的文档。
多文档智能:今天的系统将每个文档视为孤岛。明天的将理解你的 Q3 财务报告与上个月的董事会演示的关系,合同修正案如何引用原始协议,以及技术规范如何连接到实现指南。在 Morphik,我们已经在构建多文档检索,可以跨整个文档生态系统追踪信息,无缝地从页面跳到页面、从文档跳到文档,跟踪人类专家会追求的逻辑线索。
Agent 文档推理:简单的问答只是开始。我们正在开发可以跨文档执行多跳推理的 Agent 系统——找到合同条款,针对另一个文档中的监管要求进行检查,然后交叉引用技术手册中的实现细节。我们的知识图谱功能帮助这些 Agent 不仅理解文档中的内容,还理解不同信息片段如何相互关联。
工作流集成:最强大的应用出现在文档理解成为更广泛业务流程的一部分时。想象系统通过比较多个协议中的条款自动标记合同差异,或者可以从初始要求追踪技术决定直到设计文档再到实现指南。我们正在构建的工具不仅检索信息——他们理解它的程度足以采取行动。
我们仍在弥合的差距:尽管有这些进步,我们对局限性是坦诚的。当前系统,包括我们的,仍然达不到真正的专家级理解。人类财务分析师不仅仅是找报告中的数字——他们理解市场背景,识别微妙的含义,发现需要多年领域专业知识才能发现的不一致。虽然我们的视觉方法捕捉了传统解析遗漏的信息,但我们仍在努力开发可以提供关键决策所需的那种铁证保证的系统。
这不仅仅是关于技术;这是关于尊重人类如何创建和消费信息。文档是嵌入复杂工作流中的视觉产物,它们应该被理解的不仅仅是孤立的对象,而是作为驱动实际决策的丰富、相互联系的知识系统的一部分。
想看看这些功能如何能转变你的文档工作流?在 morphik.ai 免费试试 Morphik,与我们一起构建一个文档被理解而不是被解剖的世界。