ARTICLE · 1195148
OCR 大模型技术调研:从文字识别到文档理解,主流模型、评测体系与工程选型
字数 9376，阅读大约需 47 分钟
重点方向：OCR 大模型、中文识别、复杂表格、公开 Benchmark 与工程部署数据说明：引用官方公开评测结果，未在统一硬件和配置下独立复测
01. OCR 不只是把文字识别出来
假设有一张财务报表，记录了某家公司 2025 年和 2026 年的收入与利润：
OCR 模型正确识别了表格中的所有文字和数字，包括 100、30、150 和 45，却在结构化输出时，将业务 A 在 2026 年的收入 150 错误归到了利润列。
从字符识别角度看，文字和数字可能一个都没有错；但从业务角度看，这份报表已经不能直接使用。
这正是当前 OCR 技术面临的一个重要问题：识别文字正确，不代表文档解析正确；文档内容能够理解，也不代表结构和数据可以被可靠还原。
OCR（Optical Character Recognition，光学字符识别）最初主要用于将图片或扫描件中的文字转换成可编辑、可检索的文本。随着深度学习的发展，OCR 已经广泛应用于票据识别、证件识别、扫描 PDF、档案数字化等场景。
近几年，视觉语言模型（Vision-Language Model，VLM）的发展进一步扩展了 OCR 的能力边界。新一代专用 OCR 模型不仅能够识别文字，还可以处理复杂版面、恢复表格结构、解析数学公式，并生成 Markdown、HTML 或其他结构化表示。
不过，OCR 的任务目标也因此变得更加复杂。一张图片可以用于文字转写，也可以用于字段抽取、文档恢复或视觉问答，不同任务对准确性的要求并不相同。
例如，将一份包含中文、英文、公式和多级表格的扫描 PDF 转换为结构化数据，至少涉及文字检测、字符识别、版面分析、表格恢复、公式解析和阅读顺序判断。其中任何一个环节出现错误，都可能影响最终结果。
因此，评估现代 OCR 系统，首先需要回答三个问题：目前有哪些技术路线？公开评测究竟衡量什么？对于中文复杂文档，应该如何选择真正适合业务的模型？
下面围绕这三个问题展开，并进一步讨论工程部署、性能测试和业务验收方法。
02. OCR 的三类技术路线：从识别文字到理解文档
目前主流 OCR 技术大致可以分为传统 OCR 引擎、专用 OCR 视觉语言模型，以及通用多模态模型。三者在能力上存在重叠，但关注的核心问题不同。
2.1 传统 OCR：成熟、高效的文字识别方案
传统 OCR 系统主要解决两个问题：文字在哪里，以及文字是什么。
以 Tesseract 和 PaddleOCR 的 PP-OCR 系列为例，它们都属于成熟的 OCR 方案，但具体架构并不完全相同。
Tesseract 是完整的 OCR 引擎，包含页面分割和文字识别等功能，4.0 版本引入了基于 LSTM 的识别引擎。PP-OCR 则通常采用文本检测和文本识别组成的流水线，首先定位图片中的文本区域，然后对各区域进行识别。
这类方案具有模型相对轻量、推理效率高、部署方式成熟等优势，适用于清晰的印刷体、规则化表单、票据和普通图片文字提取。
不过，对于多栏文档、复杂表格和公式，仅依靠文本检测与识别通常并不足够，还需要额外的版面分析及结构恢复模块。
2.2 专用 OCR-VLM：从文字识别走向结构化解析
随着视觉语言模型的发展，一批专门面向文档解析的 OCR-VLM 开始出现。
代表方案包括 PaddleOCR-VL、DeepSeek-OCR、GLM-OCR、TeleOCR、OvisOCR2 等。
这类模型通常结合视觉编码器和语言解码器，通过多模态训练，从文档图像中生成文本及结构化表示。相比传统 OCR，它们可以利用更丰富的视觉上下文信息，完成表格解析、公式识别、复杂版面理解和阅读顺序恢复等任务。
典型输出形式包括 Markdown、HTML 表格和 LaTeX 公式，部分方案还支持 JSON 或带位置信息的结构化结果。
需要注意，专用 OCR-VLM 并不全部采用相同的架构。有的模型直接处理整页图像，有的方案会先进行版面检测，再对不同文档区域分别解析。
模型权重与完整文档解析系统也不是同一个概念。
例如，MinerU 是包含文档处理、解析和内容导出的完整系统；GLM-OCR SDK 也包含版面检测、区域识别及结果格式化等组件。某个模型标称 0.9B 参数，并不意味着整个解析系统只有 0.9B 参数规模，也不意味着显存开销仅来自这一模型。
因此，比较不同 OCR 方案时，需要明确实际使用的模型版本、解析模式、版面模块和推理后端。
2.3 通用多模态模型：从识别内容到理解与推理
另一条重要路线是通用多模态大模型，例如 Qwen-VL、MiniCPM 以及其他支持视觉输入的模型。
它们并非专门面向 OCR 而设计，但可以通过视觉理解能力读取图片中的文字，并完成信息抽取、文档问答和计算推理。
例如，用户上传一张财务报表，询问“2026 年哪项业务的利润增长最快”，模型需要识别表格文字、理解收入与利润的对应关系，并完成数值比较。
这类任务与完整还原原始财务表格不同。
前者强调获得正确答案，后者强调忠实保存所有内容和结构。一个通用多模态模型可能能够回答问题，却遗漏一些不相关的表格字段；而一个专用 OCR 模型可能能准确还原表格，却不擅长进一步解释业务含义。
因此，三类技术路线并不是简单的代际替代关系。
传统 OCR 擅长高效文字转写，专用 OCR-VLM 擅长文档结构解析，通用多模态模型则进一步扩展了视觉文字理解与推理能力。
实际工程系统应根据输入类型和交付目标，选择单一方案或组合使用。
03. OCR 准确率应该怎么看？建立完整的能力评测体系
随着 OCR 能力不断扩展，单独使用一个“识别准确率”已经很难全面描述模型表现。
现代 OCR 的评测至少需要覆盖五个方面：基础文字感知、文档结构解析、信息抽取与理解、复杂场景鲁棒性，以及工程交付性能。
3.1 基础文字识别：CER 与 WER
字符错误率 CER（Character Error Rate）是传统 OCR 中最常用的指标之一：
CER = (S + D + I) / N其中：
• S：替换字符数。 • D：删除字符数。 • I：插入字符数。 • N：参考文本字符数。
假设参考文本包含 1,000 个字符，经过最小编辑距离对齐，发现 5 个替换、3 个删除和 2 个插入，则 CER 为 1%。
CER 越低，表示字符编辑错误越少。但它不等于整页完全正确率，也不能无条件把 1 - CER 当作一个范围始终为 0～100% 的准确率，因为插入错误较多时，CER 可以超过 100%。
对于中文，CER 通常比依赖分词方式的 WER（Word Error Rate）更加直观。
不过，中文评测还必须明确标点、空格、简繁体、Unicode 归一化等规则。同样一段内容，采用不同规范化方式，可能得到不同结果。
此外，先合并所有页面的字符错误再计算 CER，与先计算每页 CER 后取平均，也可能产生不同分数。
因此，准确率报告必须同时注明指标定义、数据集和聚合方式。
3.2 从字符到文档，至少需要评测 12 类能力
不同指标解决的问题不同，不能相互替代。
例如，CER 可以衡量正文字符错误，但无法完整体现表格合并单元格是否正确；TEDS 可以评价表格 HTML 树的结构和内容相似度，却不能保证某个关键金额一定被正确归属。
对于固定字段抽取，更适合报告字段 Exact Match 和完整记录通过率；对于数量不固定的实体抽取，则需要定义实体边界、类别和值的匹配规则，再计算 Precision、Recall 和 F1。
同样，文档问答得分较高，不代表模型可以忠实输出整份文档。
因此，OCR 的准确率不是一个数字，而是一组与任务和交付结果对应的指标。
04. 四大 OCR Benchmark：它们分别在评测什么？
理解模型性能，不能只看某一张排行榜。
目前值得重点关注的评测包括 OCRBench v2、OmniDocBench、olmOCR-Bench 和 Real5-OmniDocBench。它们衡量不同层面的 OCR 能力，具有明显的互补关系。
4.1 OCRBench v2：视觉文字感知、理解与推理
OCRBench v2 于 2024 年底公开，并于 2025 年被 NeurIPS Datasets & Benchmarks Track 接收。
它关注的不只是文字能否正确识别，还包括文字定位、信息抽取、复杂元素解析、计算、理解和推理。
其英文任务包含 Recognition、Referring、Spotting、Extraction、Parsing、Calculation、Understanding 和 Reasoning 等维度。中文榜单采用的子项设置与英文并不完全相同。
在标记为 2026.09 的私有数据榜单中，部分代表结果如下：
需要注意，中文和英文测试集的任务构成并不完全一致，不能简单将两列的分数差解释为语言识别能力差距。
该榜单还包含沿用的 2026 年 6 月结果，以及 2026 年 10 月 4 日新增的模型评测，并非全部模型在同一天重新测试。
比综合排名更值得注意的是各项能力之间的差异。
例如，中文榜 TeleMM-2.0 的 Understanding 为 96.0，而 Parsing 为 37.6；MiniCPM-o-4.5 的 Parsing 为 48.8，在对应榜单中表现突出。
这些子项的任务及评分方式不同，不能直接将分数差解释成同一任务的准确率差距，但它们说明：文档内容理解和复杂元素解析是需要分别验证的两种能力。
尤其不能把 OCRBench v2 的 Parsing 直接解释为表格 TEDS 或表格完整还原率。
4.2 OmniDocBench：完整文档解析能力
OmniDocBench 更关注将文档页面转换为结构化内容的能力。
其评测覆盖文本、表格、公式和阅读顺序，适合比较专用 OCR-VLM 及文档解析系统。
以下采用官方公开的 v1.6_full 结果：
在该版本的评测口径下，综合分计算方式为：
Overall =[(1 - Text Edit Distance) × 100 + Table TEDS + Formula CDM] / 3阅读顺序单独评测，不直接计入上述 Overall。
这意味着，一个模型取得 96 分，并不代表字符识别准确率是 96%，更不意味着每 100 页文档有 96 页完全正确。
但榜单仍然体现出一个值得关注的技术趋势：参数量约 0.8B～1.2B 的专用 OCR 模型，已经能够在文档解析任务中取得很有竞争力的成绩。
相比模型规模，文档训练数据、视觉编码、结构化输出能力和解析流水线的设计，可能对最终效果产生更直接的影响。
4.3 olmOCR-Bench：关键信息是否被保留？
olmOCR-Bench 采用了与传统整页相似度不同的评测思路。
其公开数据包含 1,403 个单页 PDF 和 7,010 个测试案例，通过一系列可检查的条件验证解析结果，例如某段文字是否保留、片段阅读顺序是否正确、表格单元格之间的邻接关系是否保留，以及公式符号布局是否符合预期。
这与软件工程中的测试断言有些相似。
例如，将一个数学表达式中的 x 错写为 y，可能只造成一次字符错误，却改变了整个公式的含义。
对于重要的文档内容，仅依靠整体字符编辑距离可能无法充分体现这类错误的严重性，而针对性断言能够提供有价值的补充。
不过，断言通过并不意味着整份文档的所有信息都正确。它只能验证测试条件覆盖的内容，而且单页 PDF 测试也无法直接证明模型具备可靠的跨页表格恢复能力。
4.4 Real5-OmniDocBench：现实世界中的识别鲁棒性
实际业务输入往往不是标准的高清扫描 PDF。
手机拍摄可能产生透视变形，纸张可能弯曲，环境光照不均匀，屏幕拍摄还可能带来额外干扰。
Real5-OmniDocBench 在 OmniDocBench v1.5 的 1,355 个源页面基础上，构建了扫描、弯曲、屏摄、光照和倾斜五类物理采集条件，总计 6,775 张图像。
因为不同场景使用相同源页面，所以更适合观察采集条件变化对文档解析造成的影响。
截至本次资料核查，公开榜单中 PaddleOCR-VL-1.6 在五类场景下的平均 Overall 为 93.19，但不同场景的领先模型并不完全一致。例如，在屏摄场景中，OvisOCR2 的公开得分高于 PaddleOCR-VL-1.6。
因此，不宜将某次模型发布时的“所有场景领先”直接当作持续有效的结论，应该查看具体版本的分场景结果。
4.5 四套 Benchmark 如何结合使用？
这四套基准不是在争夺同一个“最权威排行榜”，而是在回答不同的问题。
OmniDocBench 上的高分不能证明模型擅长所有视觉文字推理任务；OCRBench v2 中的低 Parsing 分，也不能直接否定一个专用文档解析模型在 Table TEDS 上的表现。
公开 Benchmark 应用于缩小候选范围，而不是代替最终业务验收。
05. 主流 OCR 模型怎么选？从排行榜转向任务定位
随着 OCR 专用模型和通用多模态模型快速发展，单纯罗列十几个模型并按总分排序，已经很难给出可靠的技术选型结论。
更合理的方式，是先明确业务任务，再按照技术路线和公开评测结果选择候选。
5.1 代表性模型及其技术定位
上述定位是根据模型设计、公开资料和评测表现整理的候选方向，不是经过统一硬件实测得到的性能排名。
5.2 PaddleOCR-VL：中文复杂文档的综合候选
PaddleOCR-VL-1.6 于 2026 年 5 月随 PaddleOCR 3.6.0 发布，核心 VLM 参数规模约为 0.9B。
官方重点介绍了其在表格、公式、古籍、生僻字、印章和复杂文档解析方面的增强。
除了模型本身，PaddleOCR 的价值还在于其完整工程生态，包括图像处理、版面分析、模型部署及多种结构化输出能力。
对于中文扫描文档与混合版面，它适合作为综合评测的优先候选之一。
5.3 TeleOCR 与 OvisOCR2：高分文档解析模型
在 OmniDocBench v1.6_full 中，TeleOCR 和 OvisOCR2 都取得了很高的综合分。
TeleOCR 提供不同的版面处理方式；OvisOCR2 则采用约 0.8B 规模的整页端到端解析模型。
OvisOCR2 官方模型卡介绍了真实与合成文档数据结合，以及监督微调、强化学习和在线策略蒸馏等训练方法。
这些模型说明，专用模型通过训练数据和结构优化，可以在明确的文档任务上获得良好效果。
但实际使用时，仍需要测试中文长尾字符、复杂表格、输出稳定性、部署依赖及显存开销。
5.4 MinerU：关注完整 PDF 处理能力
MinerU 更适合以完整解析系统的角度评估。
对于批量 PDF 转 Markdown、论文处理或知识库建设，实际需求不仅是模型识别准确率，还包括页码关联、图片导出、多页处理、阅读顺序和异常文件恢复。
这类任务需要比较整个系统的有效吞吐、失败率和导出质量。
同时，必须区分 MinerU 应用版本、具体模型后端和解析模式。使用 MinerU 系统，并不必然意味着使用了某张榜单中的 MinerU2.5-Pro 权重。
5.5 GLM-OCR 与 DeepSeek-OCR 2：不同的技术价值
GLM-OCR 是约 0.9B 规模的专用模型，配套 SDK 支持本地和云端调用，并具备文档解析与格式化输出能力。
对于本地部署场景，可以重点测试其 GPU 占用、推理延迟、批量处理性能以及与现有服务架构的集成成本。
DeepSeek-OCR 2 的技术特点则更侧重视觉处理顺序、视觉编码与文本压缩等方向。
它既可以作为文档解析候选，也适合研究如何使用视觉 token 更高效地表达文字信息。但技术架构创新并不自动意味着在所有中文表格任务中准确率最高。
5.6 Qwen、MiniCPM：通用视觉文字理解路线
在 OCRBench v2 中文私有榜中，Qwen3.5-9B 的综合分达到 64.1，MiniCPM-o-4.5 在 Parsing 子项取得 48.8。
这些公开结果表明，通用多模态模型在中文视觉文字任务中具备值得关注的能力。
对于截图问答、指定字段抽取、图表理解等任务，可以将它们作为独立候选。
不过，如果任务目标是把数千页扫描 PDF 忠实转换成结构化数据，那么专用 OCR 模型和完整解析系统通常更值得优先测试。
5.7 形成按任务选择的模型矩阵
最终选择需要以具体模型版本和部署配置为单位，而不是仅凭模型系列名称。
06. 中文 OCR 与复杂表格：最值得关注的真实难点
6.1 中文识别的困难不只是汉字数量多
对于清晰的现代中文印刷体，成熟的 OCR 系统通常已经能够提供较好的识别结果。
但是，手写文字、生僻字、古籍、竖排、繁简混排、专业术语和低分辨率扫描件仍然存在挑战。
中文文档还经常混合英文、数字、日期、编号、金额及特殊单位，这些内容的错误代价往往高于普通正文。
例如，将“0.5 mg”识别为“5 mg”，可能只产生一个字符错误，却改变了实际剂量。
生成式 OCR 模型还可能根据上下文猜测模糊文字，将不确定内容补全为看起来合理但与原图不符的结果。
因此，提示词应尽量要求忠实转写，避免主动改写原文，同时为不可识别区域提供统一的异常标记方式。
但提示词只能改善模型行为，不能替代业务规则与人工复核。
建议中文 OCR 测试集将正文 CER 和关键字段 Exact Match 分开统计，尤其关注金额、日期、药物剂量、编号和单位。
6.2 表格需要分别验证三层能力
复杂表格的难点在于二维结构和业务对应关系。
例如，一张表格同时包含多级表头、跨行合并、跨列合并、无边框列和跨页续表。模型不仅需要识别文字，还需要恢复每个单元格所属的行、列及表头。
因此，建议从三个层面测试：
第一层：文字识别。 所有文字、数字和符号是否正确。
第二层：结构恢复。 行列数量、合并单元格、表头层级及阅读顺序是否正确。
第三层：业务归属。 每个数值是否关联到正确的项目、年份和字段。
例如，模型成功识别了“150”，也正确恢复了整张表的行列结构，却将该数字从“收入”列错误关联到“利润”字段。文字与结构指标可能仍然较高，但业务结果已经失真。
常用的 TEDS 指标基于 HTML 树的编辑相似度，通常同时评价表格结构和内容。TEDS-S 更侧重结构本身，不能将 TEDS 一概解释为纯结构准确率。
对于重要业务，建议额外计算关键单元格 Exact Match、表头关联正确率和整张表的业务通过率。
6.3 Markdown 不是所有表格的最佳输出格式
普通 Markdown 表格无法完整表达跨行跨列合并。
如果目标是可阅读的知识库内容，Markdown 通常很实用；如果需要忠实恢复复杂表格，更适合使用 HTML 保存 rowspan、colspan 等结构信息，使用 JSON 保存单元格位置、行列索引、原文及页码。
在实际项目中，可以同时提供 Markdown、HTML 和 JSON，分别满足阅读、结构恢复和程序处理需求。
对于跨页表格，还需要单独检查重复表头、续表归属、列对齐及漏行问题。单页表格得分不能证明跨页表格拼接能力。
07. 工程部署：为什么不能只比较模型参数量？
OCR 模型在公开榜单上的成绩，只反映部分能力。进入生产环境后，还需要解决文档预处理、推理性能、系统稳定性和可追溯性问题。
7.1 输入路由：并非所有 PDF 都需要 OCR
PDF 可以分为原生电子文档、扫描文档，以及两者混合的文档。
对于原生电子 PDF，可以优先检查文本层是否完整、编码是否正常、阅读顺序是否合理。
对于扫描文档和异常区域，再根据文档复杂程度调用传统 OCR 或 OCR-VLM。
完整流程可以采用以下结构：
PDF / 图片 / 电子文档 | v输入质量检测与文本层分析 | v 任务路由 | +----+----+ | | | v v v 文本 传统 OCR-VLM 提取 OCR 文档解析 | | | +----+----+ | v结果去重与坐标映射 | v结构化恢复与字段校验 | v异常复核与证据保存 | vJSON / HTML / Markdown / XLSX同一份 PDF 可以按页甚至按区域选择不同的解析路径。
不过，存在文本层并不代表文本层一定可信。一些扫描 PDF 包含过去 OCR 生成的隐藏文本，这些内容可能已经存在识别错误。
因此，输入路由需要检查文本质量，并处理多来源结果的去重和坐标映射。
7.2 模型参数量不等于实际显存占用
以 FP16/BF16 权重为例，理论权重大小可以近似计算为：
权重大小 ≈ 参数量 × 2 Bytes这里使用十进制 GB，仅表示模型权重的理论存储大小。
实际显存还包含视觉编码中间张量、KV Cache、推理运行时、版面模型以及 batch 和并发产生的开销。
高分辨率页面可能需要较多视觉 token 或多次裁剪，长篇 Markdown 生成还会增加解码成本。
因此，模型参数小并不必然意味着端到端解析速度快。
7.3 工程性能至少测量六类指标
除了模型推理，还需要将文件读取、PDF 渲染、预处理、版面分析、结果导出和重试计算在内。
尤其需要区分处理吞吐和有效交付吞吐。
一个系统即使每秒能够解析更多页面，如果存在大量漏页、截断、结构异常和人工返工，最终的可交付效率也可能更低。
另外，选型时还应核对代码、模型权重及依赖组件的许可证。代码仓库与模型权重可能采用不同许可条款，不能仅凭“开源模型”就判断它适合所有商业应用。
08. 如何建立真正有价值的 OCR Benchmark？
对于需要长期运行的 OCR 服务，公开 Benchmark 应作为候选筛选依据，而不是最终验收标准。
更可靠的方式，是建立一套与真实业务相匹配、可复现、可持续回归的评测体系。
8.1 首先定义交付结果
测试前应明确什么才算成功。
对于普通图片 OCR，输出正确文字可能已经足够。
但对于财务文档、医疗记录或需要导入数据库的表单，仅仅生成一个能打开的 Markdown 文件并不代表任务完成。
关键字段是否全部正确、表格结构是否完整、是否存在漏页，以及数据是否能够追溯到原图，都应该成为验收条件。
因此，可以分别定义字符级、字段级、页面级和整份文档级通过率。
8.2 建立业务代表集与压力集
建议第一阶段从数百至约 1,000 页具有人工真值的文档开始，覆盖真实业务中的主要类型。
代表集应尽量接近业务输入的真实分布，例如普通印刷文档、扫描 PDF、业务表格和中英混排内容。
压力集则单独包含模糊、倾斜、手写、密集数字、超长文档及复杂版面，用于测试模型的能力边界。
需要注意，测试页数本身并不能证明结果具有统计充分性。对于罕见错误，还需要增加针对性的样本。
训练、调参和最终验收数据应严格分开，同一文档的不同页面不应随意拆散到不同测试划分中，避免因重复内容造成评测偏差。
8.3 固定模型和评测配置
每次评测至少应保存：
• 数据集版本、原始文件哈希和真值版本。 • 模型权重 revision、解析系统与依赖版本。 • 图像分辨率、裁剪策略及预处理方式。 • 提示词、生成参数和输出格式。 • GPU 型号、推理后端、精度及量化方式。 • batch、并发数、超时与重试配置。 • 后处理、校验与人工复核规则。
对于完整解析系统，可以分别提供“统一资源约束配置”和“官方推荐配置”两类成绩。前者适合观察同等资源下的表现，后者更接近实际使用条件。
这样既能避免配置不公平，也能保留真实部署成本。
8.4 不只统计平均分，还应建立失败样本库
建议将 OCR 错误划分为字符错误、数字错误、漏检、重复识别、表格错位、阅读顺序错误、结构损坏、生成式幻觉及超时失败等类别。
特别需要防止一种情况：测试报告只统计成功请求的平均延迟和正确率，却将失败、超时或漏页样本排除在外。
完整报告应同时提供首次通过率、重试后通过率、整份文档完成率，以及对应的成本和耗时。
对于高风险字段，即使平均准确率较高，也应设置独立验收条件，避免大量容易识别的正文内容掩盖少数关键错误。
09. 从 OCR 输出到可核查的业务数据
现代 OCR 系统真正值得重视的能力，不只是生成文本，而是将解析结果与原始证据建立可追溯的关系。
例如，一张财务结算单中包含金额：
合计：￥12,345.67OCR 系统可以将其识别为结构化字段，同时保存原始文字、标准化数值、页码及原图坐标。
建议的业务数据结构如下：
{ "document_id": "sample-001", "page": 3, "field": "total_amount", "raw_text": "￥12,345.67", "normalized_value": "12345.67", "bbox": [112, 420, 386, 458], "coordinate_system": "rendered_page_pixels_top_left", "page_image_size": [1654, 2339], "evidence_image": "evidence/sample-001-p3-total_amount.png", "validation_status": "pending_review"}这里有几个值得强调的设计细节。
首先，raw_text 保存原始识别结果，normalized_value 保存用于计算和业务导入的标准化值。两者不应相互覆盖。
其次，bbox 保存原图区域的位置，并通过 coordinate_system 明确坐标系。如果原图经过缩放、裁剪或旋转，还需要记录映射关系。
再次，validation_status 用于区分未验证、规则通过、人工复核等状态。模型成功生成 JSON，并不意味着所有字段都已经通过业务校验。
需要注意，这是一种建议的业务输出结构，不代表所有 OCR 模型都天然支持字段级坐标。一些模型只提供版面块级位置，字段坐标还需要后续匹配和验证。
在实际工程中，可以进一步建立以下机制：
规则校验： 检查金额格式、日期、编号、单位及必要的合计关系。
异常路由： 将模糊区域、字段缺失、模型分歧、结构异常和规则校验失败的结果送入复核流程。
证据保留： 保存原图、字段区域和解析版本，使每个重要字段都可以回溯。
版本回归： 模型升级后使用稳定的验收集和错误样本库重新测试，避免修复一类问题却引入另一类错误。
这种做法更接近生产系统对数据可靠性的要求。
相比仅输出一段识别文本，包含证据关联、结构化字段和验证状态的 OCR 结果更容易被程序使用，也更容易进行审计、纠错和长期维护。
10. 结语：OCR 的下一阶段，不只是追求更高的识别分数
从传统 OCR 到专用视觉语言模型，再到通用多模态理解，OCR 技术的能力边界已经明显扩展。
从公开评测看，专用小模型在文档解析方面已经取得很有竞争力的成绩，通用多模态模型也进一步增强了视觉文字问答、信息抽取和推理能力。
但这些进展并不意味着 OCR 问题已经全面解决。
OCRBench v2、OmniDocBench、olmOCR-Bench 和 Real5-OmniDocBench 从不同角度说明，文字识别、结构恢复、内容完整性、复杂推理和真实采集鲁棒性，仍然是需要分别衡量的能力。
对于实际工程而言，最合理的方案未必是某一张榜单上的第一名，而是能够在目标文档上保持较高的文字忠实度、正确的结构关系、可接受的处理成本和稳定的交付质量。
未来 OCR 系统的竞争重点，将越来越多地集中在三个方向。
第一是高保真。 不仅正确识别文字，还要尽可能忠实保留原始结构、关键数字和文档内容。
第二是结构化。 将图像中的信息转换为可以检索、计算、存储和进一步处理的数据，而不只是生成一段可阅读文本。
第三是可验证。 让关键字段能够关联原始证据，让错误能够被发现、复核和修正，让模型升级后的结果可以持续回归测试。
对于需要处理中文扫描 PDF、财务报表、业务票据及复杂表格的系统，最终交付的应当是一条经过验证的完整处理链路，而不仅仅是一个 OCR 模型。
OCR 大模型真正的工程价值，不在于让机器更善于猜测图像中的文字，而在于让视觉信息能够被准确读取、完整还原，并转化为可信、可用、可追溯的业务数据。
参考资料
1. OCRBench v2 官方项目 2. OCRBench v2 私有榜单 3. OmniDocBench 官方评测与榜单 4. olmOCR-Bench 官方数据集 5. olmOCR-Bench 官方评测说明 6. Real5-OmniDocBench 数据集与榜单 7. Tesseract 官方文档 8. PaddleOCR 官方项目 9. PaddleOCR-VL-1.6 技术文档 10. MinerU 官方项目 11. TeleOCR 官方项目 12. OvisOCR2 模型卡 13. GLM-OCR 官方项目 14. DeepSeek-OCR 2 官方项目 15. TEDS / PubTabNet 原始项目
