Agentic AI 维基
AI 博客 / Docling、Unstructured、LlamaParse 与 Mistral OCR：别再按准确率挑解析器
AI 博客

Docling、Unstructured、LlamaParse 与 Mistral OCR：别再按准确率挑解析器

每一份文档解析器对比都以准确率排行榜的形式发布，而准确率恰恰是最难迁移到你自己文档上的那个维度。真正能迁移的有两件事：版面流水线会漏掉一个数字，但结构上编不出一个数字；以及自建与托管两条成本曲线，会在一个你五分钟就能算出来的量级上相交。

作者 智能体 AI 维基 30 分钟读完

一个视觉模型读财务报表时，可能返回一个页面上根本不存在的数字。一条版面流水线读同一页时，可能漏掉那个数字、把它排错位置、或把它所属的那一列搞乱——但它编不出这个数字，因为它从不生成文本，只搬运文本。决定你该用哪个文档解析器的，是这份不对称，而不是任何准确率分数；而这恰恰是所有排行榜都不报的那一项。

先看全貌

四个工具都能把 PDF 变成智能体可检索的文本，而它们分属两种根本不同的做法。

工具默认模式跑在哪里大致边际成本
Docling 版面流水线；另有可选的 VLM 模式 你自己的机器，CPU 或 GPU 只有算力
Unstructured 覆盖大量文件类型的版面流水线 本地库，或托管平台 算力，或托管按页计费
LlamaParse 模型驱动解析，多个质量档位 托管 API 点数制；大致每页几分钱起，往下走
Mistral OCR 逐页 VLM 托管 API；企业版可本地部署 大致每千页 1–2 美元量级

这些价格会变，档位变得更快；把这一列当成数量级，而不是报价。真正要紧的数字不是其中任何一个，而是"每页成本"与"一台机器的固定成本"之间的比值——那是下面成本一节的主题。

Capability matrix across the four document parsers A four-by-five grid scoring Docling, Unstructured, LlamaParse and Mistral OCR on running fully offline, fidelity on complex tables, handling of handwriting and scans, breadth of supported formats, and whether the tool can fabricate content that was not on the page. Where each one leans hardest Runs fully offline Hard tables and layout Scans and handwriting Format breadth Cannot fabricate Docling Yes — local by design Good; VLM mode better VLM mode needed Document-first Pipeline safe, VLM not Unstructured Library yes, platform no Solid OCR only, no reading Widest — the long tail Relocates, never writes LlamaParse Hosted only Strong on top tiers Strong Document-first Top tiers generate Mistral OCR Hosted; on-prem for enterprise Strong Strong Documents and images Generates — verify numerics Strong Workable Weak or not offered
最后那一列本该是承重的，却几乎从来不是。

为什么准确率排行榜迁移不过来

每家厂商都发基准，而这些基准大体上一致：模型驱动的解析在密集表格、多栏版面和扫描件上胜出，确定性流水线在速度和干净的数字化文档上胜出。这部分是真的。迁移不过来的是排名，因为一个解析器的分数是在该基准的文档构成上做的加权平均，而你的文档构成不一样，且这种不一样的影响盖过了厂商之间的差距。

想想"文档"在三份真实语料里分别意味着什么。一份来自六套 ERP 系统、数字化生成的发票语料，根本没有 OCR 问题——每个字符都已经在文件里了，整个任务就是表格结构。一份 1990 年代扫描合同的语料则全是 OCR，表格结构几乎不出现。一份科研 PDF 语料是公式与图表问题，而前两者都没测过它。一份主要由第三类构成的排行榜，对第一类几乎说明不了什么；而任一基准上厂商之间的差距，往往比任一厂商在这三份语料之间的差距还小。

所以有用的第一步不是读对比，而是凑出五十页长得像你最糟糕文档的东西，把四个都跑一遍。这要一个下午，而它是唯一真正关于你的证据。下面写的，都是你做完这件事之后仍然成立的决定——那时两个解析器分数接近到分数不再能决定。

是两种模式，不是四家厂商

Layout pipeline parsing architecture A document is split into pages, a layout model detects and classifies regions, OCR runs only on regions with no embedded text layer, a table model recovers cell structure from geometry, and the output is assembled in reading order. Every output span traces back to a bounding box on a page. Layout pipeline — narrow models in a chain INPUT Page image Plus the embedded text layer, when one exists THE CHAIN Layout detection Regions boxed and classified by type OCR, selectively Only where there is no text layer to reuse Table structure Recovered from ruling lines and cell geometry Reading order Spans serialised into a linear document OUTPUT Structured text Every character came from somewhere on the page Each span traces to a bounding box Runs on CPU; marginal cost ≈ 0 How it fails: omission and disorder Dropped footnote · merged columns · cell in the wrong row · table split at a page break loud failures — a missing value looks missing
版面流水线搬运它找到的文本。输出里的每一个字符都来自输入的某处。

版面流水线模式是一串窄模型：检测区域、给区域分类、只在没有内嵌文本层的地方跑 OCR、从表格线与单元格几何里恢复表结构，最后把一切序列化成阅读顺序。Docling 与 Unstructured 都是这样搭的。它快、能在 CPU 上跑，而且输出可追溯——每一段文本都能指回页面上的某个包围盒。

Vision-language model parsing architecture Each page is rendered to an image and passed whole to a vision-language model, which generates Markdown directly from what it sees. There is no per-span provenance back to the page, so unreadable regions are completed with plausible content rather than reported as missing. VLM per page — one model, no chain, no provenance INPUT Page rendered to an image The whole page at once — no regions, no crops ONE MODEL CALL Vision-language model Reads layout, tables, charts and handwriting together Generates Markdown token by token, conditioned on the image Usually transcription. Sometimes completion. OUTPUT Clean Markdown Reads like prose, which is what retrieval wants No bounding boxes Nothing to check the output back against How it fails: plausible completion A smudged figure becomes a figure that fits · a total that did not sum is repaired · a header is normalised quiet failures — the output looks better than the input
VLM 是以页面为条件生成文本。多数时候那是转录，有时候那是补全。

VLM 模式把每页渲染成图像，让一个视觉语言模型把内容写出来，通常写成 Markdown。LlamaParse 的高档位与 Mistral OCR 都是这么做的。它能处理那些让基于几何的流水线崩掉的情形——没有表格线的表、旋转的扫描件、手写、一张需要"读"而不是"检测"的图表——而且不需要你写一条规则。

分界在模式，不在厂商；而把这一点体现得最清楚的是 Docling，因为它两种都给你：经典流水线，以及用文档专用视觉模型的可选 VLM 通路，同一套接口，跑在你自己的硬件上。这与另外三者是实打实不同的一份提议，因为它意味着你可以按文档类型分流——干净的那 90% 走流水线，不干净的那 10% 走 VLM——而不必多加一家厂商、多一份账单、多一条数据出境路径。

两种失败方式并不对称

这就是本文存在的理由。版面流水线的失败方式是遗漏与错序。它会漏掉一条脚注、把两栏并成一栏、让一张表在分页处断开、把单元格放到错误的行。这些都很难看，但每一个都可被检测——输出能与原始几何对照，而缺失的值看上去就是缺失。

VLM 的失败方式是合理的补全。让它转录一列糊掉的数字，它会产出一列数字，而它读不出的那些会被换成"合得上"的那些。它会把不规则的日期格式规整掉。它会把加不平的合计修好。它会悄悄把一个列名改成这类列名通常的写法。这些都不会有人提工单，因为输出看上去比输入还好。

不对称之处在于：流水线的失败是响的，VLM 的失败是哑的，而哑的失败会向下传播。一个漏掉的数字表现为智能体说"我找不到"。一个编造的数字表现为智能体在六周之后，向一个会照着行动的人，给出一个自信的错误答案。

这并不意味着 VLM 解析是错的。它意味着未经核验的 VLM 解析是错的；而一旦你知道要建，这份核验很便宜：把同一页用两种方式各解析一遍再对齐数字，或者换个温度重跑 VLM 并标出分歧，或者干脆要求智能体引用的每个数字都能在同一页的确定性抽取结果里作为字面串被重新找到。最后这个检查每份文档只多跑一遍流水线，却能抓住整整一类问题。为什么"模型说的"算不上出处，见幻觉与接地；这件事非做不可的领域，见金融场景智能体。

在数字并不要紧的地方——政策文库、知识库、支持工单归档——算法完全反过来。能把脏扫描件变成干净可读 Markdown 的 VLM，明显优于产出"正确但被撕碎"文本的流水线，因为检索质量取决于分块读起来像不像正常文章。按语料选一种你付得起的失败方式，而不是按公司选。

成本曲线，以及它们在哪相交

Monthly parsing cost by volume, three cost regimes Illustrative monthly cost on a logarithmic scale for a hosted VLM API, a self-hosted GPU VLM and a self-hosted CPU layout pipeline, at fifty thousand, five hundred thousand and five million pages per month. The hosted bill grows in a straight line with volume while the self-hosted costs stay nearly flat, so the two cross somewhere in the hundreds of thousands of pages. Monthly cost to parse, at three volumes (log scale) 50,000 pages / month Hosted VLM API $100 Self-host GPU VLM $700 Self-host CPU pipeline $60 500,000 pages / month Hosted VLM API $1,000 Self-host GPU VLM $700 Self-host CPU pipeline $120 5,000,000 pages / month Hosted VLM API $10k Self-host GPU VLM $2,100 Self-host CPU pipeline $600 $10 $100 $1,000 $10,000 The CPU pipeline is only in the running for documents it can actually read — capability first, then this chart.
示意图，算术在正文里。要点在形状：一条线是平的，另一条不是。

托管解析的固定成本近乎为零，而每页有实打实的边际成本。自建解析有实打实的固定成本——一台一直开着的机器——而在你把它跑满之前，边际成本接近零。这样两条曲线只会相交一次，而你用一次除法就能找到交点。

取一个大约每千页 2 美元的托管 VLM，即每页 0.002 美元。取一台能跑文档 VLM、全成本约每月 700 美元的 GPU 实例。交点是 700 ÷ 0.002 = 每月 35 万页。在这之下，托管更便宜，你不该开着一台 GPU。在这之上，自建胜出并会一直胜出，因为固定成本是阶梯式增长，而托管账单是直线增长。

再对根本不需要 GPU 的 CPU 版面流水线算一遍：两个 worker 每月约 60 美元，交点落在每月 3 万页附近。这是个很低的门槛——一个团队的文档积压就能越过它——这也是为什么"用托管 API 就行"对试点确实正确、对任何在干净文档上达到生产量级的场景确实昂贵。

把你自己的数字代进去；上面这些是示意，每一项输入都会变。不变的是形状：这是一个固定成本对边际成本的取舍，因此由量决定，而量恰恰是你早就知道的那个输入。任何不问你页数就推荐解析器的人，推荐的是感觉。同样的推理往上挪一层，就是单位经济。

上面的算术漏掉了两项成本，而它们都比人们预期的更偏向自建。一是重解析：当你改动分块策略时会把整份语料重跑一遍，而用托管 API 就等于每次都为整份语料再付一次钱。二是数据出境：把文档送给第三方是一项带审批的数据保护决定，对某些语料来说，那道审批才是真正的拦路虎，与价格无关。参见数据驻留与主权。

四个工具，各说几句

Docling

MIT 许可，出自 IBM Research，现归于 LF AI & Data 基金会；也是四者中唯一在同一套接口后面、在本地同时给你两种模式的。它完全离线运行，因此只要文档不能出你的网络，它就是默认答案。代价是运维归你：吞吐调优、模型下载，以及走 VLM 通路时的 GPU 容量。

Unstructured

这一组里格式覆盖最广的——与其说是 PDF 解析器，不如说是一层文档接入层，带着连接器，并且处理那些 PDF 优先的工具会忽略的办公格式、邮件与 HTML 长尾。如果你的语料是杂而不是深，这份广度比任何单文档准确率差值都值钱。它同时以库和托管平台两种形态提供，所以"自建还是托管"这个决定不必换工具就能做。

LlamaParse

四者中最有产品形态的一个：分档位让你只在需要的页上多花钱，输出也刻意设计成能顺利落进下游的分块步骤。它是从"我们有一桶 PDF"到"检索能用了"的最短路径，而代价是永远按页计费。

Mistral OCR

把"逐页 VLM"这个赌注表达得最干净的一个：一个端点、一件事、激进的按页定价（走批处理通路更便宜），以及给那些需要这个模式但不能有数据出境的企业准备的本地部署选项。当语料是真的难——扫描件、手写、没有线的表格——而量还没到自建规模时，去拿它。

什么时候选哪个

你的处境先试因为
文档不能离开你的网络Docling，或自建的 Unstructured在谈准确率之前，托管选项就已经出局了。
输出里的数字会被拿去行动流水线；VLM 只在有对账时才用编造是你看不见的那种失败。
每月 3 万页以下，格式混杂托管 API在交点以下，自建基础设施才是贵的那个。
数百万页，且多为干净的数字化 PDF自建 CPU 流水线不需要 GPU，而托管账单会永远线性增长。
扫描件、手写、没有表格线的表某个 VLM 模式，厂商随意基于几何的抽取在这里无从下手。
异质语料——邮件、Office、HTML、PDFUnstructured当长尾才是问题时，广度胜过单文档准确率。

成熟流水线最后大多收敛到分流而不是二选一：先用便宜的确定性通路扫一遍全部，做一次置信度检查，再只对没通过的那些页跑昂贵的模型驱动通路。这只多一个分类步骤，却把平均每页成本压到接近便宜通路的水平——比任何"单一解析器"的决定都更好。

常见问题

我能不能直接把 PDF 丢给前沿模型，完全跳过解析器？

文档只有几份时可以，而且效果不错。到了语料规模它就不合理了，理由与托管解析一样——永远降不下来的按页成本——而且你继承了编造风险，却没有专用解析器能给你的那种逐段出处。

这几个里哪个最准？

这个问题没有可移植的答案，这正是本文的论点。模型驱动的解析在难版面上通常领先，流水线在干净数字文档上领先，但你不同文档类型之间的差距比厂商之间的差距更大。拿你自己最糟的五十页去测。

Docling 的 VLM 模式和托管 VLM 一样好吗？

接近到通常由运维而不是质量来决定——本地跑一个文档专用视觉模型，和 API 后面一个通用前沿模型，是两种不同的下注，而本地那种要你规划 GPU 容量。在你的语料上都跑一遍；这个差距每次模型发版都会变。

我怎么知道解析器有没有在编造？

取一份样本用两种方式各解析一遍，把每一个数字词元对齐。凡是出现在模型输出里、却不在同一页确定性抽取结果里的，要么是从不可读区域里的真实恢复，要么是编造——而不看你分不清是哪一种；这恰恰说明这个检查该待在流水线里，而不是待在一次抽查里。

解析器的选择会影响分块吗？

影响很大。保留标题层级与表格边界的解析器让你能按结构分块；返回一堵扁平文字墙的解析器则把你逼回定长窗口，而那是一次可测量的检索退化。判断输出时要看它有没有带着结构，而不只是看它有没有带着字符。

这里没写到的那些呢？

Marker、PyMuPDF4LLM、Reducto、Azure Document Intelligence、Google Document AI 以及各种开放权重 OCR 模型，都落进同样这两种模式。给任何新入场者定位，只需问两个问题：它是生成文本还是搬运文本？它的成本是固定的还是边际的？这两个答案几乎能预测其余的一切。

延伸阅读

本站相关：

项目来源：