你在工作中一定遇到过这样的场景：用截图保存了很多对话记录和网页内容，想要找的时候却没办法搜索；或者是签字盖章过的重要合同必须扫描成 PDF 留存原始记录，而你要查询时却没法搜索、想要引用也不能复制，只能不断翻页、不断手敲。
而我们在 Gety 中内置 OCR 的初衷，就是为了帮你解决这些问题。
近期，我们针对 Gety 内置的 OCR 引擎以及市面主流的端侧 OCR 方案进行了一次能力测试。这次测试利用了两套公开数据集（MDPBench 和 OmniDocBench）中的文档图片，测试对象还包括：开源领域公认最强的 PaddleOCR(PP-OCRv6)、装机量最大的老牌引擎 Tesseract，以及 macOS 和 Windows 自带的系统方案。
- 本次测试不包括在线 OCR 服务和云端大模型（如 Gemini），它们需要联网、上传文件、按调用付费，与本地离线运行的端侧引擎属于不同品类。
结合测试成绩，Gety 内置的 OCR 引擎能力占据明显优势：
- 在可本地运行的端侧引擎中，多语言识别准确率排名第一，在 17 种语言上综合表现领先。
- 内存占用仅为同类端侧模型的五分之一左右，具备长期后台运行和实时计算的可行性。
下面是具体的测试方法、测试过程和各项成绩。
一、多语言：大幅领先第二名
许多 OCR 引擎在英语、法语等「拉丁语系」上表现尚可，但一旦切换到韩语、俄语、泰语或印地语等「非拉丁语系」，准确率会从 0.9 以上急剧下滑至 0.2 甚至 0.1，基本失去可用性。下表的测试素材取自 MDPBench 的 17 种语言文档图片：
| 语言 / 指标 | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| 多语言总分 (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| 拉丁语系（平均） | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| 英语 | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| 德语 | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| 法语 | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| 西班牙语 | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| 意大利语 | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| 葡萄牙语 | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| 荷兰语 | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| 印尼语 | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| 越南语 | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| 非拉丁语系（平均） | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| 简体中文 | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| 繁体中文 | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| 日语 | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| 韩语 | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| 俄语 | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| 泰语 | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| 印地语 | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| 阿拉伯语 | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
在「非拉丁语系（平均）」的得分中，其他引擎已经从拉丁语系的 0.9 左右跌落到 0.4、0.3 甚至 0.1 时，Gety 内置 OCR 依然维持在 0.832 的较高水准，这种差距直接决定了用户对产品可用性的感知。因此在实际使用中，Gety 可以更准确识别包含中文、日文、韩文或俄文在内的图像文字，在这些语种上不需要担心因语言类型不同而识别失败。
关于拍摄退化场景（模糊、歪斜、带光斑的翻拍照片），我们利用同一批素材分别测试了「数字原生」与「拍摄退化」两种输入条件的差异：
| 模型 | 数字原生 (F1) | 拍摄退化 (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
可以看到，拍摄退化下的识别是全行业共同面对的技术难题，所有模型的准确率都从 0.9 级别大幅下降至 0.2~0.4 区间。Apple Vision 在这一项上较为领先（0.421），Gety 内置 OCR 模型以微弱优势领先于其他开源产品、位列第二。
结合日常使用场景来看，我们所留存的图片内容大多是清晰的屏幕截图或经过数字化扫描的图像文件，而现今用于拍摄照片的设备也具有较高的拍摄稳定性，退化的情况较少，因此数字原生场景下的表现对实际体验的影响更高。
二、复杂版式：与最强开源引擎并驾齐驱
除了语言类型覆盖面，另一个重要维度是版式复杂度：遇到分栏文字、表格、页眉页脚等混排的文档时，OCR 能否进一步准确识别而不出现遗漏或错位。结合 OmniDocBench 的文档图片测试，各方案的综合版式识别准确率如下：
| 模型 | 综合版式识别准确度 (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Gety 内置 OCR 模型（0.963）与当前开源领域表现最强的 PP-OCRv6 small（0.968）表现优异，差距仅在千分之五左右，同时明显领先于系统自带方案。在实际使用体验中，两者都同属第一梯队，用户不会感知到差异。
三、资源占用：以更低成本实现同等甚至更高准确率
端侧 OCR 引擎的计算能力完全依赖于设备本机。作为需要常驻后台运行的能力，高准确率不能以高资源占用为代价，否则将严重影响用户的日常使用。我们基于同一台设备分别测试以下三项指标：
| 模型 | 多语言识别准确度 (F1) | 单页耗时（中位） | 单页内存峰值 |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
（仅测试第三方端侧 OCR 模型，Apple Vision 和 Windows OCR 的硬件生态不在同一条件下，故不参与本项测试。）
结果显示，在识别准确度极高的同时，Gety 内置 OCR 模型所消耗的单页内存峰值约 908MB，而 PP-OCRv6 的 tiny 和 small 版本分别达到 4.7GB 和 6.3GB，差距近五到七倍之多。
因此在设备硬件资源优先的条件下，Gety 可以安静地常驻后台持续运行，新文件存储至设备时，也能够丝滑完成自动识别和索引。而高内存占用的模型常驻后台可能会影响设备运行，难以做到对文件的持续检测和实时响应，更适合采用具有针对性的「按需启动」模式。
四、测试方法与对比对象
测评集
我们所使用的这两套数据集素材，分别对应了两个核心问题：
| 数据集 | 考察维度 |
|---|---|
| MDPBench | 17 种语言覆盖，兼顾数字原生与拍摄退化，可衡量「多语言识别是否稳定」 |
| OmniDocBench | 复杂版式文档，衡量「复杂排版时能否准确」 |
两个数据集口径不同，我们分别展示测试结果，避免误导。需要说明的是，我们仅选取数据集中的文档图片作为测试素材，评测方法、指标与对比模型均结合实际使用场景设计，非官方评测方案。
评分方法与考量因素
在准确度测试上，我们采用**与版式无关的字符级 F1（综合识别准确度）**评估 OCR 识别结果。该指标只衡量文字是否被正确识别，不评估排版、换行、段落结构或文字位置的识别。我们之所以采用该方法，是因为 OCR 引擎本身是对文字的识别，在实际的索引、搜索和复制时，用户也更需要应用能够准确识别出每一个字符，而非将图像内容完整还原。
对于每一页内容，我们将 OCR 输出结果与人工标注文本进行比较，并计算：
在计算前，标准答案和 OCR 输出都会经过相同的归一化处理，包括 Unicode 归一化、去除不可见字符、统一空白字符，并移除不相关的版面附属内容。字符匹配采用多重集统计，相同字符出现多次时分别计数，以避免阅读顺序、换行和段落切分差异影响评分，使指标更能表示 OCR 是否正确识别出页面中的文字。
最终结果按页计算 F1，并在不同语言和数据分组上采用宏平均；报告中同时给出 bootstrap 95% 置信区间。
对比对象
对比对象的选择上，我们尽可能覆盖真实场景下会使用的主流方案：
- PaddleOCR(PP-OCRv6)：目前综合实力最强的开源 OCR 方案，代表开源领域的天花板。本次仅测试 tiny 和 small 两个端侧版本；medium 版本参数规模达 34.5M，主要面向高性能服务器 GPU 设计，不适用于常规消费领域。
- Tesseract：老牌开源引擎，装机量大，代表常见的基线水平。
- Apple Vision / Windows OCR：macOS 与 Windows 自带的系统级方案，代表「零安装」状态下的默认体验。
五、准确率是基础，「好用」才是目的
以上数据足以说明 Gety 内置的 OCR 引擎「读得准」。但准确率本身不是终点，它只是「好用」的前提。
传统 OCR 工具的使用链路通常是：
找到要识别的图片 -> 拖入工具或在工具中选择 -> 手动触发开始识别 -> 等待输出 -> 获得可使用的文本这个链路里存在一个天然的断层：绝大多数扫描件和截图，在进入电脑的那一刻起就成为了「盲区」，它们从未被送入过 OCR 流程，用户需要时只能手忙脚乱不断翻找——它们始终是搜索框触达不到的死角。
我们希望解决的正是这个断层问题。Gety 本身以常驻后台的方式运行，而图像文件存入系统时，Gety 会自动调用 OCR 快速完成识别和索引，用户不需要转换格式、不需要手动操作，需要时直接在全局搜索框输入关键词即可。
换句话说：准确率决定识别质量，而资源消耗决定这项能力是否能被充分使用。我们不只是做一个更准确的 OCR 引擎，而是希望让「图片里的文字不能被搜索」这个问题，在我们的用户身上不再是问题。
以上为我们的内部评测结论。我们使用了 MDPBench、OmniDocBench 公开数据集的文档图片作为测试素材，但评测方法与指标为我们自定，与数据集原作者发布的官方评测不同。所引用数据集各有其许可与使用边界（部分声明仅供研究用途），本文仅展示评测结论，不分发任何数据样本。