OCR-VLM能阅读天城文吗？一个压力测试基准与后校正研究

# OCR-VLM能阅读天城文吗？一项压力测试基准与后校正研究
来源：https://arxiv.org/html/2606.29213
\(2026\)

###### 摘要

从传统引擎到专门的OCR视觉语言模型（OCR-VLM）以及前沿多模态大语言模型，OCR系统在英文和中文文档基准上报告了强劲的结果，但它们在印度语系文字上的表现尚未得到充分描述。我们对天城文（印地语）进行了基准测试，涵盖十个系统：传统EasyOCR；开放VLMs（Qwen2.5-VL-3B、Qwen3-VL-8B、olmOCR-7B）；专用OCR-VLMs（DeepSeek-OCR、Unlimited-OCR）；以及前沿闭源模型（Gemini 2.5 Flash、Claude Opus 4.7、GPT-5.5、Mistral OCR），在四种合成退化条件和300张真实印刷扫描图像上进行了评估。我们报告了四项发现。首先，在清晰渲染文本上，所有十个系统的chrF++得分集中在91到98之间，因此合成文本无法区分它们。其次，在退化条件下，专用的OCR-VLMs最为脆弱：DeepSeek-OCR会出现罕见但灾难性的重复失败（输出长度可达参考长度的71倍），这严重拉低了其语料均值，尽管其中位数是所有系统中最好的——这也是我们报告中位数和灾难率而非均值的原因。第三，在真实扫描图像上，十个系统中有九个表现崩溃（EasyOCR从chrF++ 93.6降至58.3），各系统得分分布在一个76点的范围内，因此合成渲染严重高估了天城文的质量。第四，强大的英文OCR性能并不能预测印地语OCR：GPT-5.5的chrF++降至58.5（与传统EasyOCR持平），而olmOCR-7B（olmOCR-Bench背后的模型）降至40.5，但开放的Qwen3-VL-8B（75.2，可在单个24GB GPU上运行）超越了GPT-5.5并接近Mistral；Gemini和Claude领先，分别为86.3和82.2。一项错误分类将表面错误（数字、标点）与结构性错误（合字、元音符号、努克塔符号）区分开来，一个字节级（ByT5）后校正器在其自身错误分布上改善了一个廉价引擎（chrF++提升+1.2到+1.5），但不能跨引擎迁移。我们发布了基准、代码和模型。111https://github.com/Aditya-PS-05/devanagari-ocr-benchmark

## 1 引言

最新一波端到端OCR视觉语言模型（OCR-VLM），包括DeepSeek-OCR[1 (https://arxiv.org/html/2606.29213#bib.bib1)]、其继任者DeepSeek-OCR 2以及最近发布的Unlimited-OCR[2 (https://arxiv.org/html/2606.29213#bib.bib2)]，将文档解析视为使用大语言解码器进行图像到文本的生成任务。这些模型在OmniDocBench上报告了最先进的结果，而该基准的文档绝大多数是英文和中文。这些优势能否在印度语系文字上延续尚不清楚。

天城文，印地语及其他几种语言的书写系统，带来了拉丁语和中日韩文字中不存在的挑战：堆叠的辅音合字（saṃyuktākṣar）、置于基字上方、下方和旁边的依赖元音符号（matras）、连接顶线（shirorekha）、努克塔变音符号、频繁的印地语/英语混合书写以及两套数字系统。一个在拉丁文字上表现出色的模型仍可能在这些方面处理不当。

我们提出三个问题。(Q1) 现代OCR-VLM在真实图像退化条件下对天城文的准确性和鲁棒性如何？(Q2) 它们系统性地在哪些方面出错？(Q3) 一个轻量级后校正器能否恢复廉价引擎的错误？我们的贡献如下：

- • 一个受控的、多字体、多条件的天城文OCR基准，附带脚本感知的评估协议（Unicode NFC规范化；CER/WER/chrF++）。
- • 一项鲁棒性分析，表明语料均值误差被罕见的灾难性重复失败所主导，因此中位数与灾难率一起才是忠实的总结。
- • 一个天城文错误分类，对比了传统OCR和VLM的失败模式。
- • 一个分布匹配的字节级后校正器，在匹配噪声上取得了积极结果，而在跨引擎迁移上取得了负面结果。

## 2 相关工作

**端到端OCR-VLM。** GOT-OCR2[4 (https://arxiv.org/html/2606.29213#bib.bib4)]、Nougat和DeepSeek-OCR系列将OCR视为长序列生成任务，使用高压缩视觉编码器和LLM解码器。Unlimited-OCR[2 (https://arxiv.org/html/2606.29213#bib.bib2)]用参考滑动窗口注意力取代了解码器的注意力机制，以限制长文档解析的KV缓存，在OmniDocBench上报告了相对于DeepSeek-OCR总体+6的提升。**通用VLM**，如Qwen2.5-VL[3 (https://arxiv.org/html/2606.29213#bib.bib3)]，也在文档OCR任务上表现出竞争力。**文档OCR基准**，如OmniDocBench[5 (https://arxiv.org/html/2606.29213#bib.bib5)]和olmOCR-Bench[olmocr]，通过真实PDF上的单元测试式检查推动了进展，但其文档绝大多数是英语/拉丁语和中文，印度语系文字基本缺失。**印地语OCR**历史上依赖于流水线系统；据我们所知，对新型OCR-VLM和前沿LLM在天城文上的大规模评估尚属空白，这正是本文填补的缺口。**OCR后校正**作为序列到序列的去噪任务，在拉丁语和历史文本中已确立；我们使用字节级模型研究其在印地语上的应用。

## 3 基准构建

**源文本。** 我们使用FLORES测试集的印地语一侧（997个句子），为主评估采样前N=100个天城文句子。FLORES在训练中被保留。

**渲染。** 每个句子被渲染为白底图像，使用五种天城文字体之一（Droid Sans Devanagari; Lohit Devanagari; Noto Sans Devanagari Regular/Medium/Condensed），在句子间循环，行宽设置为1400像素，字号40像素。

**退化条件。** 从每张清晰图像我们生成三个退化变体：*模糊*（高斯模糊，σ∈[1.0,1.8]）；*噪声*（对6%的像素添加像素噪声）；以及*低DPI*（0.45倍下采样后双线性上采样）。这提供了4种条件×100张图像。

**指标。** 所有参考文本和假设文本在评分前均经过Unicode NFC规范化。我们报告字符错误率（CER）、词错误率（WER）和chrF++（带词顺序2的字符n-gram F值）。因为一个视觉字符（akṣara）对应多个码位，码位级CER低估了结构性错误；我们将其视为已知局限（§6 (https://arxiv.org/html/2606.29213#S6)）。

**真实印刷数据集。** 为衡量合成图像与真实图像之间的差距，我们额外在300张带有转录的真实印刷天城文图像上进行了评估，这些图像来自Sanskrit-OCR-Typed语料库（历史排字扫描）。这些是单词和短短语级别，因此我们将其用作真实图像鲁棒性探针，而非文档解析基准。

**模型。** 我们评估了来自四个系列的十个系统。*传统*：EasyOCR（印地语和英语）。*开放VLM*：Qwen2.5-VL-3B和新版Qwen3-VL-8B（通用，提示词要求逐字转录）以及olmOCR-7B（olmOCR-Bench背后的模型）。*专用OCR-VLM*：DeepSeek-OCR（3B，0.5B激活；“免费OCR”）和Unlimited-OCR（3B，0.5B激活；“文档解析”，Gundam模式）。*前沿闭源（API）*：Google Gemini 2.5 Flash、Anthropic Claude Opus 4.7、OpenAI GPT-5.5和Mistral OCR，在清晰和真实集上评估（受成本限制），而本地开放和专用模型额外运行所有四种退化条件。VLM输出在评分前剥离了布局和定位特殊令牌以及边界框坐标。本地推理在单个NVIDIA A10G（23GB）上以bfloat16运行，一次常驻一个模型。我们还尝试了PaddleOCR、GOT-OCR2和LlamaParse：前两者在我们的环境中无法稳定运行（PaddlePaddle在Amazon Linux 2023上出现段错误和处理器实例化错误），LlamaParse则在每张图像上返回非天城文（拉丁文）输出，因此我们将三者从量化表格中省略。

## 4 结果

### 4.1 清晰准确性：所有模型表现良好

在清晰渲染文本上，所有十个系统的chrF++得分都集中在91到98的狭窄区间内（表1 (https://arxiv.org/html/2606.29213#S4.T1)）。前沿闭源模型略胜一筹（Claude 98.0，Mistral 97.6），但传统EasyOCR、开放VLM和专用OCR-VLM的差距都在几个百分点以内。清晰的合成文本无法区分各系统，而这正是退化条件和真实数据至关重要的原因。

表1：清晰渲染天城文，N=100。CER↓ / chrF++↑。

### 4.2 退化条件下的鲁棒性

表2 (https://arxiv.org/html/2606.29213#S4.T2) 报告了我们在所有四种条件下本地运行的六个系统在各个条件下的语料CER。EasyOCR和Qwen模型几乎保持平坦，olmOCR稳定，Unlimited-OCR适度退化，而DeepSeek-OCR的语料CER在模糊条件下爆炸至111.8，在低DPI条件下达到51.9。

表2：各条件下的语料CER（%，↓），N=100。每列最佳值以**粗体**显示。
参考图说明
图1：按图像条件划分的语料CER（对数刻度）。EasyOCR和Qwen几乎平坦，而DeepSeek-OCR在模糊和低DPI条件下崩溃。

**均值掩盖了真相。** 表3 (https://arxiv.org/html/2606.29213#S4.T3) 分解了每个样本的CER。DeepSeek-OCR在所有系统中具有最佳的中位数CER（1.2至1.5），但其均值被2%至3%进入退化重复循环的样本所拖累，这些样本的输出长度可达参考长度的71.6倍。Unlimited-OCR的解码器使用了显式的无重复n-gram防护，将其最坏情况限制在3.8倍。因此，我们建议在报告均值的同时，报告中位数CER和灾难率（CER高于50%的样本比例）。

表3：模糊和低DPI条件下每个样本的CER分布。“cat”是CER高于50%的比例；“max×”是最大输出与参考长度之比。
参考图说明
图2：在模糊条件下，DeepSeek-OCR具有最佳中位数CER（1.5），但灾难性均值（73.7），因为2%的样本进入重复循环。中位数与灾难率一起才是忠实的总结。

**报告的排序不能迁移。** 据报道，Unlimited-OCR在拉丁语和中文的OmniDocBench上以总体+6的优势超越了DeepSeek-OCR。在清晰天城文上，排序相反：DeepSeek-OCR获得了更高的chrF++（93.84对91.04）和更低的WER。这两个专用的OCR-VLM在鲁棒性方面也均被通用VLM（Qwen）和传统EasyOCR所超越。

### 4.3 错误分类

我们将每个假设与参考在字符级别对齐，并将每次编辑分类到天城文特定的类别中（表4 (https://arxiv.org/html/2606.29213#S4.T4)）。灾难性重复样本被排除，因此分类反映了真实的识别错误。

表4：按类别划分的错误计数，清晰条件，N=100。
参考图说明
图3：按类别划分的错误组成（清晰）。EasyOCR的错误主要由数字和标点主导，而VLM在结构性元素（合字、元音符号、努克塔符号）上失败。

出现了两种特征。传统引擎在表面元素上失败：天城文数字（将其转录为拉丁数字或误读）和标点（例如，danda规范化）。VLM在结构性元素上失败：合字、元音符号和努克塔符号。Unlimited-OCR制造了最多的结构性错误，与其较低的chrF++一致。反复出现的形似混淆在视觉和语音上具有动机，并且在系统中一致：ba↔va，gha↔dha，ma↔bha，da↔dha，以及ta↔Ta。我们还注意到，相当一部分形似编辑实际上是标点规范化（danda与句号，智能引号）；此类差异会夸大原始错误计数，应予以规范化——这是一个供印地语OCR评估参考的方法论注意事项。

### 4.4 合成与真实印刷天城文对比

清晰条件下的持平结果在300张真实印刷天城文扫描图像上消失了（表5 (https://arxiv.org/html/2606.29213#S4.T5)，图4 (https://arxiv.org/html/2606.29213#S4.F4)），这些图像使十个系统的chrF++得分分布在一个76分的范围内。四项发现值得关注。

(1) **合成渲染严重高估了质量。** 十个系统中有九个从合成图像下降到真实图像；EasyOCR从chrF++ 93.6降至58.3，其中位数CER从约2%上升至17%。仅基于渲染文本构建的基准对于天城文具有误导性。

(2) **专用OCR-VLM崩溃。** DeepSeek-OCR的中位数CER为100%（89%的样本为灾难性），Unlimited-OCR通过幻觉平均输出4倍于参考长度的文本；两者均垫底（chrF++ 10到25）。

(3) **前沿闭源模型大多保持稳定。** Gemini、Claude和Mistral的中位数CER均达到0.0，chrF++介于77和86之间。但这并非简单的“闭源优于开源”的故事，如发现(4)所示。

(4) **英文排序不能迁移。** 两个结果打破了olmOCR-Bench和英文的排序。首先，GPT-5.5——英文文档OCR中的顶级模型——在真实天城文上chrF++降至58.5，与传统EasyOCR持平，且远低于Gemini和Claude。其次，开放的Qwen3-VL-8B达到了chrF++ 75.2（中位数CER 0.0），超越了GPT-5.5并接近Mistral，尽管它可以在单个24GB GPU上免费运行。最值得注意的是，olmOCR-Bench排行榜背后的模型olmOCR-7B在真实天城文上崩溃至chrF++ 40.5。因此，强大的英文OCR性能是印地语性能的一个糟糕预测指标。

我们承认一个混淆因素：这些图像是单词和短短语级别，这对面向页面的模型不利。即便考虑到这一点，Gemini与GPT-5.5之间，或Qwen3-VL与olmOCR之间的差距，都发生在同一尺度内，无法仅用粒度来解释。

表5：真实印刷天城文扫描（N=300，单词级别），按chrF++排序。“cat”是CER高于50%的比例；“len×”是平均输出与参考长度之比。F表示前沿闭源，O表示开放，C表示传统，S表示专用OCR-VLM。
参考图说明
图4：合成清晰渲染图像与真实印刷扫描上的chrF++，十个系统按真实数据chrF++排序（真实数据条形按类别着色）。几乎所有系统在真实图像上崩溃。Gemini、Claude、Mistral和开放的Qwen3-VL保持强劲，而GPT-5.5和olmOCR-7B尽管英文表现强劲，却急剧下降。

## 5 分布匹配的后校正

我们测试是否可以通过一个后校正器来挽救廉价引擎，该校正器将噪声OCR文本映射到清晰文本。我们基于6,000个真实的（OCR输出，清晰）对微调了**ByT5-small**（字节级，适合字符级OCR噪声）。将保留的印地语句子（来自IITB和一个通用语料库，与FLORES不重叠）在相同的四种条件下渲染，并使用EasyOCR进行转录。在推理时，我们将输入截断为最多90个字符（因为校正器在短跨度上训练，长输入否则会诱发重复），然后重新拼接片段。

表6：后校正（ByT5-small在EasyOCR噪声上训练）。CER↓ / chrF++↑，前→后。
参考图说明
图5：一个在EasyOCR自身错误分布上训练的ByT5后校正器在所有条件下均改善了EasyOCR的chrF++。

该校正器持续改善了其所训练的引擎（在所有条件下，EasyOCR的chrF++提升了1.2到1.5，并且在清晰和噪声条件下CER有所改善）。但它不能迁移：应用于Qwen、Unlimited或DeepSeek的输出时（其错误分布不同），效果中性或有害。实际结论是，OCR后校正是有效的，但训练数据必须严格匹配目标引擎的错误分布。