开篇
就在昨日——2026.3.30，百度的 PaddleOCR Github Stars 数突破 73.3 K，正式超越谷歌旗下开源 OCR 标杆产品 Tesseract OCR（73.2K），成为全球 Stars 数最高的 OCR 项目！
对 OCR 这个领域来说，这不是一个普通的数字节点。
说起OCR，国内用户可能更熟知 PaddleOCR。但 Tesseract 多年来一直是开源 OCR 世界里的经典坐标系。它最初诞生于 HP，后来又曾长期由 Google 推动发展。
也正因为如此，当 PaddleOCR 完成本次反超时，我更愿意把它理解成一个行业信号：
全球开发者正在把注意力，从“一个能识别文字的 OCR 引擎”，转向“一套更完整、更开放、更适合文档 AI 工作流的基础设施”。
如果你去看 PaddleOCR 官方仓库现在的生态描述，也会发现这次反超不是靠一波短期热度堆出来的。
当前，PaddleOCR 已经支持 100+ 语言，被 6k+ GitHub 仓库所依赖，并且和 MinerU、RAGFlow、Pathway、Cherry Studio 等热门项目形成了深度集成。再叠加持续活跃的社区贡献和频繁的版本更新，这背后其实是一条很清晰的主线：开源 OCR 的重心，正在向“文档理解 + 工程落地 + 生态接入”这套组合迁移。
借着这波热潮，今天我们一起解读下百度最新的开源 OCR 旗舰模型 —— PaddleOCR-VL-1.5，并附上一个应用实战案例分享给大家。
PaddleOCR-VL-1.5
尽管是“多模态大模型”架构，PaddleOCR-VL-1.5 依旧保持 PaddleOCR 家族一贯的轻量高效特色，硬是把模型规模压在了 0.9B。
然而，就是这么个体积大小，却在 OmniDocBench v1.5 上把整体精度做到了 94.5%，在官方新构建的 Real5-OmniDocBench 上做到了 92.05%。
更重要的是，它并不是像市面上其它 OCR 模型只会做“干净文档”的模型，而是把扫描、倾斜、卷曲、屏摄、复杂光照这些现实世界问题，正面拉进了评测体系里。
如果只用一句话总结 PaddleOCR-VL-1.5，我认为：它开始把“文档理解”这件事，做成一个真正统一的多任务系统了。
这次 1.5 版本最让我在意的有三点。
它不再把复杂文档理解拆成一堆彼此割裂的小能力，而是把 OCR、表格识别、公式识别、图表理解、文本 spotting、公章识别这 6 类任务收进同一套统一框架里。对于做知识库、票据流、档案数字化、论文解析的人来说，这件事非常重要，因为你的真实输入，从来都不是“只有纯文本”。
它这次把 PP-DocLayoutV3 放到了一个非常关键的位置。传统矩形框在真实文档里经常不够用，尤其是卷曲页面、倾斜拍摄、多栏排版、异形区域。PP-DocLayoutV3 做的是多点框定位和阅读顺序联合建模，意思很简单：不仅要看见哪里有内容，还要知道应该先读谁、后读谁。
它终于把“抗畸变能力”当成主问题来做了。很多 OCR 演示一遇到手机拍照、阴影、纸张变形就开始崩，这也是为什么我对 Real5-OmniDocBench 这个基准印象很深。模型并不是只在榜单自嗨，而是要真正落地解决用户痛点。
反超背后的直觉
我一直觉得，OCR 这个方向最容易掉进一个误区：
大家都在比“能不能再刷高 1 个点”，却很少有人认真讨论“这些点到底是在哪些样本上丢掉的”，这本质是对 PB 的一种过拟合。
PaddleOCR-VL-1.5 并没有回避这些难题。譬如文档拍歪了怎么办，页面卷起来怎么办，屏摄有摩尔纹怎么办，复杂表格里混着公式和小字怎么办，它给出的答案不是一句“后处理再调调”，而是从布局分析、多任务训练、数据构建到评测基准一起做。
这背后其实是一个很朴素的工程逻辑：
真正好用的 OCR，不是把一张图片里的字认出来，而是把这张文档重新变回“可计算、可检索、可复用”的信息。
从这点看，PaddleOCR-VL-1.5 的意义已经不只是 OCR 了，它是在给 RAG、知识库构建、文档自动化、金融票据处理、教育内容解析这些场景补基础设施。
此外，我也顺手看了一些公开社区讨论，感觉挺有意思。
一边是明显的认可。Reddit 上有人直接把它概括成“一个专门为复杂文档 OCR 做的小而强模型”，看重的是 0.9B 的体量、Apache-2.0 的开源许可，以及它对表格、公式、阅读顺序、印章、多语言文档的兼顾。还有人提到，如果你在做本地 OCR 流水线、票据自动化、旧档案数字化，这个模型很值得认真试一遍。
另一边也有很成熟的工程视角。也有开发者拿它和其他 PDF to Markdown 工具做横向测试，结论并不是一边倒的“它什么都赢”。真实部署里，速度、环境依赖、输出格式、不同类型文档的偏好，仍然会影响最终选择。
这也从侧面说明 PaddleOCR-VL-1.5 已经不只是论文里的“新模型”了，它开始进入工程师真正会拿来比较、拿来接入、拿来落地的那张候选名单。
而 PaddleOCR 在 GitHub Star 上超越 Tesseract，某种意义上只是这个过程的必然外部结果。
更核心的变化是，社区不再只把它当成一个孤立的 OCR demo，而是在把它当成下一代开源文档 AI 基座来评估。
从 Star 里程碑，到真正可落地
也正因为 PaddleOCR 已经走到“超越 Tesseract”这个节点，一个更现实的问题就来了：
再强的模型，如果没有一个顺手的工作流入口，最后也很容易停在演示阶段。
环境复杂，团队里不是每个人都愿意折腾部署。
结果再好，如果不能快速复核、修正、导出，也很难真正进入生产流程。
尤其是文档理解这种事情，本来就不是“模型跑一下”这么简单，它后面连着人工校验、批量处理、数据沉淀、再训练和服务化调用。
今天我们就以 X-AnyLabeling 为例，演示下 PaddleOCR 是如何赋能现有工具去提供基座能力。
X-AnyLabeling OCR 实战
X-AnyLabeling 是一款面向多模态视觉数据标注与 AI 辅助理解的开源平台，把模型调用、人工修订、批量处理、格式转换和远程服务这些原子化能力，尽量接到同一条工作链里。
从产品定位上看，X-AnyLabeling 一直在做两件事。
一件事，是把前沿模型真正融入到本地工作流里。
另一件事，是把这些能力重新整理成工程上可复用的动作，比如标注、复查、半自动修正、批量处理、格式转换、远程服务调用等。
在 OCR 这条线上，X-AnyLabeling 也不是从 PaddleOCR-VL-1.5 才开始发力的。客户端早已经支持 PPOCR 系列相关的数据标注、识别回查与格式导出；而在服务端模式下，又可以把更重的多模态多任务模型以统一接口接进来，让桌面端直接调用。
下面我们将为简要介绍下关于 PaddleOCR 模型在 X-AnyLabeling 上的一些典型应用案例。
项目地址：https://github.com/CVHub520/X-AnyLabeling
任务一：关键信息抽取
如果你的目标不是单纯识别文字，而是抽取字段关系，比如发票、快递面单、合同页、证件页里的“问题-答案”“键-值”“实体-关系”，那最直接的方式，就是在客户端里走关键信息抽取这条流程。
在这套流程里，X-AnyLabeling 把 KIE 拆成了两层：
一层是 SER，也就是语义实体识别。你先把文本区域框出来，可以用矩形、旋转框、多边形三种方式，然后在标注框里填 label 和 description。前者是实体类别，后者是真实文本内容。
另一层是 RE，也就是关系抽取。这里你会额外用到 group_id 和 linking，把问题和答案、字段和字段值真正连起来。
这套设计很简洁，因为它不是把 KIE 说成一个抽象概念，而是把训练数据该怎么长出来这件事讲清楚了。你标完之后，可以直接在客户端导出成 PP-OCR KIE 所需格式，后续继续训练或者做数据清洗都很顺。
任务二：文字识别与纠错
如果你的需求更偏基础 OCR，比如文本检测、文本识别、识别结果修订、训练集制作，那么客户端里的文字识别与复核流程会更直接。
这里有一个我觉得很实用的细节：它不只是支持“自动跑一次 OCR”，还支持你在检测框不满意的时候，手动画框，然后只重跑识别部分。也就是说，你可以把检测和识别拆开调。
这对真实标注非常有用。
很多时候不是模型完全不行，而是某几块区域框歪了、漏了、切得不好。以前你只能整页重跑，现在可以把已有框保留下来，开启 Skip Det，只对选中的区域重新识别，效率会高很多。
还有一个很贴心的点是，PPOCR 标注里真正该重点维护的是 description 字段，也就是识别文本本身，而不是 label。X-AnyLabeling 在这个交互上做得很顺，你可以快速逐框巡检、逐框改字，最后再导出成 PP-OCR 训练格式。尤其从 v3.2.4+ 开始，Loop Select Shapes 这种顺序巡检能力也补上了，做大批量文字纠错会省下很多机械操作。
任务三：服务端多任务调用
如果你要的不是“单一 OCR 能力”，而是整页文档里的文字、表格、公式、图表、公章、spotting 一次打通，那就应该走服务端多任务调用这条路。
这条路的核心思路很简单：
把更重、更完整的多任务模型放在 X-AnyLabeling-Server 上跑，客户端只负责选择任务、发起请求、查看结果、做人机协同修正。
在客户端里，操作并不复杂。按下 Ctrl+A 打开 AI 面板后，先选择 Remote-Server，再切到 PaddleOCR-VL-1.5
，然后根据任务类型选择 OCR、表格识别、公式识别、图表理解、文本 spotting 或公章识别即可。对于批量数据，还可以直接按 Ctrl+M 走批处理模式。
需要注意的是，这些能力并不是固定的。X-AnyLabeling 里的 Remote-Server 插件会先从服务端拉取可用模型列表，再把当前图片和任务参数发到远程预测接口里。这意味着你完全可以把客户端界面当作统一入口，把服务端模型当作可替换能力层。
这就是我前面一直在说的那件事：
一个好模型真正有价值，不是因为它只会在论文图里赢，而是因为它能被顺滑地接进真实工作流。
如果你后续准备做完整文档解析，我会非常建议把 PaddleOCR-VL-1.5 和 PP-DocLayoutV3 放在一起看。前者负责多任务识别，后者负责布局和阅读顺序，两者组合起来，才更接近真实文档理解的完整闭环。
结语
今天，很高兴看到 PaddleOCR 取得这样的成绩。
这不仅是一个开源项目的里程碑，也让我们看到了国产开源 OCR 技术生态真正走向全球的可能。正如官方所说：
这一里程碑的背后，是无数社区贡献者的一行行代码、一个个平台的深度集成、一位位用户的真实场景打磨。全球开发者用 Star 投票，选择了一个更开放、更强大、更易用的 OCR 技术底座。
但比起 Star 这些数字本身，更让我在意的是，它背后已经形成了一条更完整、更健康的开源链路：
模型层面，有论文、有权重、有开源许可；
生态层面，有多项目集成、有持续贡献者，也有不断演进的版本更新；
工作流层面，则有像 X-AnyLabeling 这样的平台，把能力真正落地到用户手中。
