OCR评测：10个AI，20 种语言
我选择了 20 种语言的 20 份文档，并在每份文档上测试了 10 个AI系统。每一条响应都被保存下来，这样我就能检查实际输出，而不只是依赖最终得分。
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
几个月前，我在六个真实世界的 OCR 类别中对比了 Tesseract、EasyOCR、PaddleOCR、TrOCR 和 DocTR。那篇文章完全聚焦于开源 OCR 库。
想了解那次开源对比的读者可以点击这里阅读。
这一次，我想测试另一组工具。当前的视觉模型无需标准的 OCR 管线，就能读取文档、标牌、截图或手写纸上的文字。与此同时，还有一些专为文档提取而构建的现代 API，例如 Mistral OCR 和 Sarvam Doc Intelligence。
我选择了 20 种语言的 20 份文档，并在每份文档上测试了 10 个系统。每一条响应都被保存下来，这样我就能检查实际输出，而不只是依赖最终得分。
最后这一步比我预期的更重要。
在普通页面上，模型之间的对比相对直接。但在表格、报纸和多栏文档上，同一个指标可能因为模型以不同的顺序读取各栏而对其产生惩罚。有一个响应把报纸总结了一遍，而不是转写它。另一个响应提取出了正确的段落，然后继续输出了图像中并不存在的文本。
所以，这变成的不只是一张简单的准确率排行榜。
1、我测试的模型
其中有八个系统是通用视觉模型：
| Provider | Model |
|--------------|--------------------------------|
| Anthropic | Claude Sonnet 4.6 |
| Anthropic | Claude Haiku 4.5 |
| OpenAI | GPT-5.4 |
| OpenAI | GPT-5.4 mini |
| Google | Gemini 3.1 Pro Preview |
| Google | Gemini 3 Flash |
| Google | Gemini 3.1 Flash Lite Preview |
| Moonshot AI | Kimi K2.5 |
剩下两个是专用文档 API：
| Provider | Endpoint |
|-------------|--------------------------|
| Mistral AI | Mistral OCR |
| Sarvam AI | Sarvam Doc Intelligence |
这个区别很重要，因为八个视觉模型除了图像之外还接受普通的文本指令。我给这八个模型发送了相同的提示词：
提取这张图片中可见的每一个文字，一字不差地按原样输出。只输出原始文本——不要评论、不要格式、不要 Markdown。在自然换行处保留换行。
没有系统提示词，也没有示例响应。
Mistral OCR 和 Sarvam Doc Intelligence 使用各自的 API 结构。它们的 API 接收文档并返回提取的或结构化的数据，所以上面的提示词并不适用于它们。此外，Sarvam 接受目标语言代码，这起到的是语言选择器的作用，而不是 OCR 指令。
我在提供给它的所有文档上都测试了 Sarvam，以观察它的表现，但文档数字化功能的官方支持范围仅限于 22 种计划内的印度语言和英语。因此，本次实验中外语输出应被视为观察结果，而不是 Sarvam 官方支持这些语言的证据。
在其文档覆盖范围之外，无法提供任何性能保证；Sarvam 主要面向印度文档和语言。在这次测试中，它仍然为外语文档提供了输出；不过，我会把这些视为范围之外的观察结果。
2、测试文档
我不希望这次对比被英语页面主导。20 份文档按多种文字和版式进行了分组。
2.1 印度语言文档
印度语组包含古吉拉特语、泰米尔语、泰卢固语、印地语和乌尔都语。其中包括书页、广告、报纸摘录和干净的段落式文档。
泰米尔语来自 Appen Limited 在 Kaggle 上的泰米尔语 OCR 数据集。泰卢固语来自 Divs0910/telugu-ocr-dataset，古吉拉特语来自 Yourgotoguy/Gujarati_ocr_data，乌尔都语来自 Qaari 乌尔都语新闻数据集。印地语页面来自 MDPBench。
2.2 东亚语言文档
这一组包含日语、韩语、简体中文和繁体中文。
它们是测试中最难的页面。日语图像包含手写的空间笔记和图表。韩语样本采用了多栏加照片的报纸版式。简体中文样本是一页极其密集的报纸页面，而繁体中文样本则遵循干净得多的学术版式。
2.3 拉丁文字文档
其余 MDPBench 样本涵盖英语、德语、西班牙语、法语、印度尼西亚语、意大利语、荷兰语、葡萄牙语和越南语。
语言本身并不总是难点。版式带来了更多麻烦。西班牙语页面用了三栏，印度尼西亚语和意大利语页面包含表格，荷兰语页面则混合了正文、侧边栏、图片和脚注。
2.4 阿拉伯语和俄语
阿拉伯语样本是一页从右到左阅读顺序的干净学术页面。俄语样本是从数字原生 PDF 中提取的三栏教案表格。
俄语的真实文本来自 PDF 文本层，而不是单独的人工转写。这适合检查可见文本是否被恢复，但该表格仍然没有单一自然的扁平化阅读顺序。
3、数据集来源
大多数多语言文档来自 MDPBench，这是一个以 Apache 2.0 许可发布的多语言文档解析基准。参考文本是利用提供的边界框从其公开标注中重建的。
其余数据集包括：
- 多语言页面：Hugging Face 上的 MDPBench
- 泰米尔语：泰米尔语文件类型 OCR 图像数据
- 泰卢固语：Divs0910/telugu-ocr-dataset
- 古吉拉特语：Yourgotoguy/Gujarati_ocr_data
- 乌尔都语：oddadmix/qaari-0.1-ocr-urdu-news-dataset-small
- 俄语：HumynLabs/Russian_Documents_Dataset_PDF
主要对比中每种语言只使用一份文档。因此，把它描述为一次多语言压力测试，比描述为对任何单一语言的权威基准更恰当。
4、为什么我没有对每个页面使用统一的准确率得分
OCR 通常用字符错误率（CER）和词错误率（WER）来评估。
字符错误率（CER）衡量的是把预测结果转换为参考文本所需的字符插入、删除和替换次数。越低越好。
我还使用了派生的字符准确率：
Character accuracy = 1 - CER
当文档有清晰的阅读顺序、且参考文本包含图像中可见的文本时，这种方法效果很好。
当页面存在多种有效阅读路径时，它就变得不可靠了。
想象一份三栏排版的报纸。一种方法可能从上到下处理第一栏，然后进入第二栏。另一种策略可能从页面标题开始，再回头处理正文。在这两种情况下，对于熟知的词语，结果可能相似，但随后简单的 CER 分析可能显示，第二种方法因词语顺序不同而被判为错误。
有些参考文本也不完整，因为它们遗漏了可见内容。古吉拉特语参考文本没有包含广告中可见的电话号码。印度尼西亚语和意大利语参考文本没有包含可见表格内的文本。所以，一个模型即使正确提取了这些信息，也可能因为参考文本中缺少这些额外文本而得到更差的 CER。
因此，我把文档分为两条轨道。
4.1 线性转写
有十个页面具有稳定的阅读顺序和足够完整的参考文本。它们是泰米尔语、泰卢固语、乌尔都语、阿拉伯语、德语、英语、法语、印地语、葡萄牙语和繁体中文。
对于这些页面，我在 Unicode 规范化、方向标记清理、提供方包装清理和空白规范化之后，计算了归一化 CER。
4.2 复杂文档
其余十个页面包含多栏、表格、图表、空间笔记或不完整的参考文本。它们是古吉拉特语、西班牙语、印度尼西亚语、意大利语、日语、韩语、荷兰语、俄语、越南语和简体中文。
这些页面采用了与顺序无关的参考覆盖率指标。这个指标衡量参考文本中有多少出现在预测结果中，而不要求所有栏目都按精确的扁平化顺序返回。
参考覆盖率不等于整页准确率；它不能说明版式是否正确重建，也不为从真实文本中遗漏的文字打分。在这种情况下，它只是比假设一个复杂页面只有一种完美文本序列更安全。
我还人工审查了全部 200 条响应。数值指标无法告诉我输出究竟是转写、总结、倒序文本，还是嵌入了图像的结构化输出。
5、线性文档的结果
CER 越低越好。
| Rank | Model | Mean CER | Median CER |
|------|--------------------------------|----------|------------|
| 1 | Gemini 3 Flash | 2.44% | 1.07% |
| 2 | Gemini 3.1 Pro Preview | 2.59% | 1.04% |
| 3 | Gemini 3.1 Flash Lite Preview | 2.67% | 1.69% |
| 4 | Claude Sonnet 4.6 | 6.95% | 1.18% |
| 5 | Sarvam Doc Intelligence | 7.59% | 2.32% |
| 6 | Mistral OCR | 7.97% | 1.41% |
| 7 | GPT-5.4 | 10.22% | 5.50% |
| 8 | Kimi K2.5 | 15.84% | 7.01% |
| 9 | GPT-5.4 mini | 18.18% | 8.25% |
| 10 | Claude Haiku 4.5 | 20.10% | 12.21% |
Gemini 3 Flash 名列第一，但我不确定把三个 Gemini 版本之间的差异解读为显著差异是否合理。第一和第三之间的差距只有 0.23 个百分点。由于每种语言只有一份文档，我会认为三个 Gemini 变体在线性文档上的表现相近。
Claude Sonnet 的平均值高于其他模型，尽管其中位数与领先模型相差不远。一些转写非常准确，但少数错误拉高了平均值。
Mistral OCR 的表现类似。它的 CER 中位数非常出色，但泰卢固语的一条响应拉低了它的平均值。那条输出对段落的转写是正确的，但多了一段从 10 到 100 的不必要数字序列。
Sarvam 在测试中产出了最好的泰卢固语转写。这个结果值得注意，但一个泰卢固语页面不足以宣布它是所有印度语言的最佳 OCR 系统。它在其余文档上的表现差异很大。
6、复杂文档的结果
参考覆盖率越高越好。
| Rank | Model | Mean reference coverage |
|------|--------------------------------|-------------------------|
| 1 | Gemini 3.1 Pro Preview | 96.37% |
| 2 | Gemini 3 Flash | 96.31% |
| 3 | Gemini 3.1 Flash Lite Preview | 95.45% |
| 4 | Mistral OCR | 94.70% |
| 5 | Kimi K2.5 | 93.60% |
| 6 | GPT-5.4 | 93.20% |
| 7 | Claude Sonnet 4.6* | 88.62% |
| 8 | GPT-5.4 mini | 86.81% |
| 9 | Sarvam Doc Intelligence | 80.01% |
| 10 | Claude Haiku 4.5 | 71.07% |
Gemini 3.1 Pro 和 Gemini 3 Flash 只相差 0.06 个百分点。Flash Lite 和 Mistral OCR 的结果也相近。
Mistral 作为专用 OCR 端点表现良好，能够跨不同文档类型提取大部分所需文本，尽管有些输出仍需要处理。六条输出中还包含 Markdown 图像占位符。
Sarvam 的输出文件需要更仔细的处理。有些包含 Base64 编码的图像、生成的图片描述或 HTML 格式的表格。虽然它为外语页面返回了输出，但质量普遍弱于印度语言页面。因此，我不能说它能提供的多语言支持范围超出了 Sarvam 官方声明覆盖的语言。
7、Claude 总结而非转写的那一页
Claude Sonnet 旁边的星号来自那页密集的简体中文报纸。
在相同的基线提示词下，Claude 没有尝试完整转写。相反，它描述了页面，挑出几个标题，并生成了摘要。
最初的结果得分很糟糕，但得分并不能解释问题所在。只依赖 CER 会让人觉得 Claude 尝试了 OCR 但犯了大量错误。实际上，它改变了任务。
针对这张图片，我加强了提示词，明确说明这是 OCR 任务而非总结任务，需要完整的转写。
随后 Claude 做出了更全面的转写尝试。这把它在这页的参考覆盖率从 2.27% 提高到 16.86%，但页面仍然极其复杂，最终输出依然很差。
修订后的输出已计入 Claude 的复杂文档得分。但最初的行为仍然值得讨论，因为它凸显了检查原始输出的重要性。
这也是关于提示工程的重要提醒。尽管"提取所有文本"在我们看来已经足够明确，但更通用的助手可能会选择对材料进行泛泛的描述。对于长文档，我会让指令刻意机械化：
转写每一个可见字符。不要总结、解释、翻译、重组或省略重复文本。只返回转写内容。
即使提示词更强，人工检查仍然必不可少。更好的指令可以让模型尝试正确的任务，但不能保证页面会被准确读取。
8、另一个 CER 无法解释的失败
Kimi K2.5 生成了一些可读的阿拉伯语文本，但它是按相反顺序返回的。我用相同的提示词再次尝试同一张图片，得到了类似的结果。
这个问题可以通过字符指标识别出来；然而，这并不能解释失败源于从右到左的阅读顺序。
同样的道理也适用于摘要、拒绝、Markdown 标签、嵌入图像和幻觉产生的额外文本。所有这些都以某种文本的形式进入了评分流程。如果问题没有在原始输出中定位出来，所有不同的缺陷就可能累积成一个低分。
这就是为什么我必须保存并分析每一条回答，而不是只依赖从 API 输出生成的分数。
9、即使是前沿模型也在劣质文档上栽跟头
主要对比使用的是足够清晰的文档，以保证公平。我还测试了来自 Real5-OmniDocBench 的三张额外图片，以评估糟糕的拍摄质量对 OCR 性能的影响。
三种场景分别是：光照不均、严重倾斜和页面弯曲。
在我针对这些图片测试的模型中，没有一个产出了我能信任的转写。
我不会用这三个案例来给其他模型排名。把它们放在这里是为了说明，真实的 OCR 输入几乎永远不会像基准截图那样干净。手机照片可能有阴影，页面可能在书脊附近弯曲，文档可能以糟糕的角度被拍摄。
在这些情况下，仅仅更换模型不太可能解决问题。去斜、透视校正、对比度调整、阴影去除和文档展平可能同样重要。
这三个劣质样本来自 Real5-OmniDocBench，真实文本继承自 OmniDocBench。
10、处理时间
下面的计时是每张图片单次端到端的观测结果，不是受控的吞吐量基准。这些计时有助于理解本次运行，但不应视为提供方保证的延迟。
| Model | Median time | p90 time |
|--------------------------------|-------------|----------|
| Mistral OCR | 4.90s | 18.76s |
| Gemini 3.1 Flash Lite Preview | 7.65s | 25.05s |
| Gemini 3 Flash | 8.65s | 20.42s |
| Gemini 3.1 Pro Preview | 10.10s | 46.10s |
| Kimi K2.5 | 11.05s | 23.31s |
| GPT-5.4 | 11.10s | 19.71s |
| Sarvam Doc Intelligence | 12.50s | 17.84s |
| GPT-5.4 mini | 13.15s | 17.67s |
| Claude Haiku 4.5 | 15.10s | 20.65s |
| Claude Sonnet 4.6 | 28.15s | 41.66s |
在这次运行中，Mistral OCR 的中位响应时间最低。在通用视觉模型中，Gemini Flash Lite 和 Gemini 3 Flash 的中位速度最快。
更大的教训是，速度并没有完全遵循模型规模。网络延迟、输出长度、提供方负载和文档密度都会影响响应时间。
11、这些 API 的费用
选择 OCR API 不只是看准确率。一个在某个表格上表现略好的模型，当面对成千上万甚至数百万页面时，可能仍然难以证明其价值。
下面的数字基于 2026 年 8 月各提供方官方页面发布的信息核实。价格可能变化，尤其是预览版本。请注意，本节对比的是读者目前可以购买的 API 方案。
| Model | Official standard price |
|-----------------------------|-------------------------|
| Claude Sonnet 4.6 | $3 / 1M input tokens, $15 / 1M output tokens |
| Claude Haiku 4.5 | $1 / 1M input tokens, $5 / 1M output tokens |
| GPT-5.4 | $2.50 / 1M input tokens, $15 / 1M output tokens |
| GPT-5.4 mini | $0.75 / 1M input tokens, $4.50 / 1M output tokens |
| Gemini 3.1 Pro Preview | $2 / 1M input tokens and $12 / 1M output tokens below 200K tokens |
| Gemini 3 Flash | $0.50 / 1M input tokens, $3 / 1M output tokens |
| Gemini 3.1 Flash Lite | $0.25 / 1M input tokens, $1.50 / 1M output tokens |
| Kimi K2.5 | ¥4 / 1M cache-miss input tokens, ¥21 / 1M output tokens on the official Kimi platform |
| Mistral OCR | Current OCR 4: $4 / 1,000 pages; OCR 3 remains $2 / 1,000 pages |
| Sarvam Document Digitization| ₹0.50 per page |
一般来说，视觉模型按使用的 token 数量向客户收费，而不是按处理的页数。图像的分词方式也因模型所属的公司而异。因此，一个通用的每页估价并不准确。
不过，粗略估算仍然有用。下表基于以下假设：
- 较简单的页面：1,500 个计费输入 token 和 500 个输出 token
- 密集页面：3,000 个计费输入 token 和 2,000 个输出 token
- 总共 1,000 页
这些信息仅作为示例，并不是本次基准测试的实际账单。实际数字将取决于图像质量、公司使用的视觉分词方法、推理 token 和输出长度等因素。
| Model | Rough cost for 1,000 lighter pages | Rough cost for 1,000 dense pages |
|-------------------------------|------------------------------------|----------------------------------|
| Gemini 3.1 Flash Lite | $1.13 | $3.75 |
| Gemini 3 Flash | $2.25 | $7.50 |
| GPT-5.4 mini | $3.38 | $11.25 |
| Claude Haiku 4.5 | $4.00 | $13.00 |
| Gemini 3.1 Pro Preview | $9.00 | $30.00 |
| GPT-5.4 | $11.25 | $37.50 |
| Claude Sonnet 4.6 | $12.00 | $39.00 |
| Kimi K2.5 | ¥16.50 | ¥54.00 |
| Mistral OCR 4 | $4.00 per 1,000 pages | $4.00 per 1,000 pages |
| Sarvam Document Digitization | ₹500 per 1,000 pages | ₹500 per 1,000 pages |
从预算角度考虑，使用专用端点是有道理的，因为它们按页计费。而按 token 消耗计费的模型，随着输入和输出量的增加，支出可能显著上升，这意味着在处理复杂文档时，输出中的 token 可能成为成本的重要组成部分。
在分析准确率表格时，把定价因素考虑进去也很重要。Gemini 3.1 Pro 能处理最困难的文档，而 Gemini 3 Flash 紧随其后，且比 Gemini 3.1 Pro 便宜得多。尽管 Flash Lite 是这些模型中最便宜的，它仍然能交出与其他两者非常接近的结果。
便宜并不总是好事。当前的使用场景可能对输出有特定格式要求，对可运营地域有地理限制，或者在隐私或集成软件方面有其它需求。毫无疑问，模型的价格不应该压过 OCR 系统的功能特性。
官方定价来源：
- Anthropic Claude pricing
- OpenAI GPT-5.4 pricing
- OpenAI GPT-5.4 mini pricing
- Google Gemini API pricing
- Kimi API pricing
- Mistral API pricing
- Sarvam pricing changelog
12、我会先从哪个 API 开始？
对于经济高效的多语言管线，我会首先测试 Gemini 3.1 Flash Lite 和 Mistral OCR。
Flash Lite 虽然更便宜，但表现与其他 Gemini 模型相近。Mistral 则拥有最低的中位响应时间，并采用按页计费，尽管它的输出仍需要仔细解析。
如果你想要一个折中的选择，与其它模型相比，我仍然推荐先从 Gemini 3 Flash 开始。它在线性页面上取得了最好的平均 CER，同时在复杂页面内容的高覆盖率方面不输给更昂贵的模型。
当优先考虑提取质量而非价格时，Gemini 3.1 Pro 可以作为处理复杂文档的最佳工具。这个模型的主要优势是其高复杂文档覆盖率，但结果非常接近，顶级模型之间的差距很小。
尽管成本更高，在 OCR 只是某个流程中的一个步骤、并且我们已经在使用这些供应商的情况下，Claude Sonnet 和 GPT-5.4 API 也可以纳入实施。在这次 OCR 测试中，它们额外的成本并没有带来显著的 OCR 优势。
Sarvam 也应该单独评估。尽管泰卢固语的结果很高，但该工具在其它语言上的表现不稳定，而且数据处理阶段相当繁琐。因此，评估任何 OCR 系统效率的最好方法，是针对特定文字和文档类型进行测试，而不是只依赖这里 Sarvam 的平均结果。
14、结束语
最有趣的失败并没有出现在干净页面上。
多个模型都能以几乎零字符级错误转写这些页面。
只有在 API 响应之后，更复杂的问题才变得可见。
文字是否被正确保留？模型是转写了页面上的每一个词，还是只总结了大部分内容？输出是纯文本，还是包含 Markdown、HTML 表格或图像？响应是否包含足够的数据？最后，当 API 价格乘以大量页面时，一个错误是否就变得重要了？
这些细节很容易被淹没在一个平均分里。
最好的模型不一定是得分最高的那个，而是能处理你需要的页面、产出你可处理的输出、并且价格足够便宜以支持规模化使用的那个。
在选择 OCR API 之前，收集一小批你自己的文档，包括你最糟糕的扫描件。然后检查原始输出，计算相关指标。
指标只能说明两个文本样本有多相似或不同。然而，它并不能告诉你模型到底对文档做了什么。
原文链接：I Tested 10 AI Models for OCR Across 20 Languages
汇智网翻译整理，转载请标明出处
