一个在基准测试中表现出色、却在实际文档上失败的解析器，会从源头上破坏你的 RAG 管道。评估文档解析器需要在真实、杂乱的文档集上进行测试，而不仅仅是在干净的演示样本上。Gartner 对 AI 项目的前景做出了严峻的预测：到 2026 年，由于数据未达到"AI 就绪"标准，预计有 60% 的 AI 项目将被放弃。本文探讨了如何针对生产环境对文档解析器进行基准测试，包括大多数对比评测中都会遗漏的关键测试。

大多数解析器评估从一开始就问错了问题。团队通常会问："它的准确率有多高？"而他们真正需要回答的问题是："当这个解析器出错时，我的管道会发生什么？"

这个答案的重要性超出大多数团队的想象。根据LlamaIndex 的 ParseBench 基准测试，即便是当今表现最佳的文档解析服务，在企业文档页面上也仅能达到约 90% 的内容忠实度——乍看之下还不错，但一旦考虑到幻觉和其他错误带来的影响，情况就不容乐观了。这意味着，在生成任何一个嵌入向量、回答任何一个查询之前，每十个页面中就有一个存在实质性遗漏或结构性错误。

摄取环节的解析质量不佳，是造成这一问题的主要原因。

部署前的评估，正是应当发现这类风险的环节，而不是等到生产环境中出现数周的错误输出之后才发现。真正有意义的对比，不是拿新解析器在最佳文档上的表现，去对比你当前解析器在最差文档上的表现。一次真实的解析器评估，应当从一套能反映你实际生产语料库（包括其中的疑难案例）的文档集开始。

本指南为你提供了一个评估框架，帮助你运行一次真正能够预测生产环境表现的评估，而不是一次只会验证供应商演示预设结论的评估。

为什么演示准确率无法预测生产环境表现

使用干净样本文件进行的演示会带来虚假的信心。

使用原生 PDF、单栏排版和结构良好的表格进行的演示，为每一个解析器都提供了理想的运行条件。而你的生产文档语料库几乎肯定不具备这些条件中的任何一个。

亮度不均的扫描合同、排版倾斜的传真发票、混合多种文字的多语言监管文件——这些情况会出现在生产环境中，而不会出现在评估集里。

演示表现与生产表现之间的差距，正是检索增强生成（RAG）管道出现问题的地方。糟糕的解析产生糟糕的分块。糟糕的分块导致薄弱的检索。而薄弱的检索会产生任何提示工程或模型调优都无法修复的幻觉，因为模型是在基于被破坏的证据进行推理，而不是缺乏知识。

发表于 CVPR 2025 的OmniDocBench 的研究直接印证了这一点：当解析器从干净的基准测试条件转向真实多样的文档集时，准确率会显著下降。如果你的评估无法复现你实际的文档条件，那么你收集到的分数也就无法复现你实际的生产结果。

一套真实的评估文档集应当包含哪些内容

你用来评估解析器的文档，应当取自你所在组织日常实际使用的文档类型。你的测试集至少应包含以下内容：

• 扫描文档：扫描质量、倾斜程度和噪点各不相同的纸质文档图像。这正是光学字符识别（OCR）质量区分商业级解析器与 Tesseract 等开源工具的地方。
• 多栏排版：以并列栏形式显示文本的财务报告、学术论文和新闻通讯。无法检测栏边界的解析器会将相邻栏的内容交错混合，产生事实上不连贯的文本块。
• 复杂表格：无边框表格、合并单元格，以及跨多页的表格。表格输出被"压平"是生产环境中最常见的隐性失败模式之一。
• 多语言内容：混合多种语言或使用阿拉伯语、中文、日语、韩语等非拉丁文字的文档。不同解析器之间的覆盖能力差异很大。ABBYY 支持 208 种语言，而许多开源工具则远远达不到这一水平。
• 长篇多页文档：合同、技术手册和报告，其章节层级跨越数十甚至数百页。跨页时的阅读顺序和结构连续性，是常见的失败点。
• 结构不一致的文档：真实文档并不总是规整一致的。标题可能出现在意想不到的位置；脚注会打断正文；乍看结构清晰的文档，往往在一些细节上并不规则，从而使为干净格式训练的解析器出错。

评估解析器如何处理结构上的模糊性，而不仅仅是格式清晰、一致的文档。如果没有涵盖这些文档类型的真实测试集，你的评估衡量的只是演示条件，而非生产环境的真实情况。

除了字符级准确率之外，还应测试哪些内容

字符级准确率——即正确提取的字符百分比——几乎无法告诉你一个解析器是否能够支撑可靠的 RAG 检索。一个解析器可以在字符准确率很高的同时，彻底破坏下游系统所需的信息结构。

请针对以下每一项进行测试：

• 结构保留：标题、章节和文档层级是否被正确识别并标注？遵循真实文档结构的分块方式，比靠猜测边界进行的分块效果更好。
• 阅读顺序：提取出的文本顺序是否与人类读者的阅读顺序一致？多栏文档和复杂排版经常会导致解析器输出顺序错乱的文本。
• 表格保真度：输出中是否保留了行与列之间的关系？被压平成一串文本的表格，会失去让它对下游模型有意义的那些关系。
• 字段与标签关系：在表单和结构化文档中，解析器是否正确地将字段值与其标签相关联？值与标签脱节，是 RAG 输出中事实性错误的常见来源。
• 输出格式的实用性：输出格式是否承载了足够的语义信息，以支持分块和检索正常工作？纯文本会剥离掉使检索准确所需的上下文。

像 DocLang 这样的结构化格式——由 ABBYY 与 IBM、Nvidia、Red Hat 和 Linux 基金会共同创建的开放、原生面向 AI 的文档标记标准——为标题、段落、表格单元格、脚注和表单字段承载语义标签。正是这种结构，才使输出真正做到"AI 就绪"。

实验室表现与实际运行表现的区别

实验室表现是解析器在经过精心筛选的基准测试上取得的分数。实际运行表现，则是它在你自己的文档、你自己的处理量、你自己的约束条件下所展现的表现。

最有效的解析器，是那些能够在各种不同文档类型中都产生高效、可预测的数据结构的解析器；而评估工作也需要超越单纯的 OCR 准确率，去衡量其语义理解能力。

"足够好"在生产环境中忽略了什么

有一类评估结果会带来真正的问题："在大多数文档上表现足够好。"

问题的关键并不在于你的解析器是否能很好地处理干净的文档，而在于它是否能可靠地处理你的语料库，在不引入会沿管道向下游传播的错误的前提下。

"足够好"忽略了局部错误的累积效应。一个能正确提取文档 98% 内容、却始终将所有表格压平的解析器，在大多数查询上可能产生可用的输出，但在任何需要表格数据的查询上都会彻底失败。98% 的综合准确率数字，并不能反映在依赖表格的查询上 100% 的失败率。

如果这些错误涉及关键的财务条款、日期或责任条款，那么下游产生的后果绝不是抽象的。

这正是为什么，针对与你的使用场景最相关的具体文档类型和结构特征进行评估至关重要。如果你的管道依赖表格提取，就要专门评估表格保真度。如果你处理多语言文档，就要按语言分别评估准确率。如果你的分块依赖章节层级，就要评估章节边界是否被正确识别。

疑难文档会揭示出真正的性能上限。

如何与你当前使用的解析器进行公平对比

直接对比能给你提供最具可操作性的信号。用同一批文档分别通过你当前的解析器和你正在评估的解析器进行处理，然后在与你的管道相关的维度上，并排比较两者的输出结果。

具体步骤如下：

1. 第一步：选定一个包含 50–100 份文档的基准测试集。优先选择你实际语料库中复杂、有挑战性的文档，而不是简单的文档。
2. 第二步：用两种工具分别解析每份文档。保存完整输出，以便进一步评估。
3. 第三步：抽取 10–20 份文档样本，人工检查其结构、阅读顺序和表格保真度。不要仅依赖字符级指标，因为它们无法凸显出对性能影响最大的结构性失败。
4. 第四步：准备一组答案已知、能在你的文档中找到的问题，运行检索测试。对每种工具解析出的输出分别建立索引，评估检索是否能召回正确的段落。
5. 第五步：比较输出格式，判断你当前解析器的输出格式是否包含足够的语义结构，以支持你的分块逻辑正常工作。如果不够，可以考虑采用像 DocLang 这样带有语义标注的格式，它能显著提升分块和检索的效果。

目标并不是找到一个在排行榜上得分更高的解析器，而是找到一个能在你自己特定的管道、你自己特定的文档上带来更好结果的解析器。

从你最难处理的文档开始

了解一个解析器在生产环境中能力上限的最快方法，是先把你最具挑战性的文档交给它——那些当前在你的管道中制造麻烦的文档，那些会产生幻觉、破损表格或错乱阅读顺序的文档。

借助 由 ABBYY 提供技术支持的 FineParser，你可以拉取 Docker 容器，直接在那些已经造成问题的文档上运行，并将结构化输出与你当前解析器产生的结果进行比较。

你的解析器返回的结果，与一个能够保留结构的解析器返回的结果之间的差异，比任何基准测试分数都更能说明你的管道可靠性的真实上限。

在你的真实文档上测试 ABBYY，现已开放早期试用。