一提到开源 OCR，很多人第一反应还是 Tesseract，国内这几年 PaddleOCR 也抢了不少话题。但你要是关注 GitHub 趋势，会发现一个叫 Surya 的开源 OCR 项目已经悄悄涨到了 11.8K Star，主打的卖点就是 90+ 语言识别。它和我们熟悉的“从图片里抠文字”思路不太一样：Surya 把检测、识别、版面分析、阅读顺序、表格结构都做进了一条流水线，装完之后一条命令能直接吃 PDF，输出的不是一行行散乱文字，而是带坐标、带顺序、带结构的 JSON。这篇文章我就从实际使用的角度，聊聊为什么它值得在文档类项目里被认真考虑。
1. OCR 项目那么多，Surya 凭什么攒到 11.8K Star
1.1 老牌工具解决不了的新场景
很多人一说开源 OCR，第一反应还是 Tesseract。Tesseract 确实历史悠久，中文识别在调好参数之后也堪用，但它的问题很典型：当文档版式复杂，比如有表格、有标题、有双栏混排、有图片夹带文字的时候，Tesseract 的输出基本就是“按行吐字”，版面里的从属关系、阅读顺序这些信息全都丢了。你要把一份合同扫描件转成可检索 PDF，或者把一篇论文截图送进 RAG 管道，这种“裸文字”其实很难直接用。
PaddleOCR 在国内社区很火，中文识别效果确实好，安装时配套的模型也做得相当完善。但它的部署体系比较重，PP-Structure、版面分析这些高阶能力要单独装，不同模块之间的配合也讲究版本兼容。如果你只是一个业务团队，想快速验证“多语言文档识别”这个需求，PaddleOCR 给人的感觉是“能干，但要伺候的东西不少”。
商业 OCR API 当然方便，效果好、响应快，可是数据要出本地这一条就让很多项目直接劝退了。合同、病历、票据、内部档案，这些场景对数据边界非常敏感。本地跑一个开源模型，哪怕精度比商业 API 差一两个点，很多团队也愿意接受。
Surya 恰好站在这个空档上：本地部署、开源、安装链路短、多语言覆盖广，而且它从一开始就是按“文档”来设计的，不是按“单行文字图片”来设计的。它拿到一份扫描 PDF 或一张版面复杂的图片，会先检测出页面里的文本行和区域，再逐块识别文字，最后把版面结构、阅读顺序、表格结构整理好再吐给你。这个“文档级”的定位，才是它 11.8K Star 的真正基本盘。
1.2 11.8K Star 背后代表什么
Star 数当然不能等同于生产环境可靠性，但一个 OCR 项目能做到 11.8K Star，至少说明三件事。
第一，它解决的是高频刚需。文档数字化、合同信息抽取、多语言档案整理、知识库预处理，这些需求在电商、金融、法律、教育、政府信息化里比比皆是。凡是跟“纸质材料电子化”沾边的场景，都会被 OCR 卡一下脖子，所以好工具一出来，口碑传播非常快。
第二，它把门槛压得足够低。Surya 的安装方式接近普通 Python 库，pip 装上之后就有命令行工具，不用自己训练模型，不用手写检测框后处理，默认模型在第一次运行时会自动下载。这种体验对工程师很友好，对非算法背景的业务开发更是救命的。你不是必须搞懂目标检测和序列模型才能用 OCR，装一个库、写几行代码，结果就出来了。
第三，它踩中了多语言需求。90+ 语言识别，这个数字对国内团队来说可能没有特别强的感知，但对做海外市场、跨国业务、多语言知识库的团队来说，价值是实打实的。你不需要为法语、德语、俄语、阿拉伯语分别找一套 OCR 方案，Surya 一个项目就能覆盖，这让架构和运维都简化了很多。
我自己的观察是，一个工具能在开发者圈子里自然涨到 11.8K Star，通常不是靠某个技术指标多惊艳，而是“刚好补上了一个大家都不愿意自己造轮子的位置”。Surya 做文档级多语言 OCR，就是这个位置。
2. 90+ 语言的底气从哪来：Surya 的技术骨架
2.1 检测与识别拆开看
Surya 的核心流程不是“一个模型干所有事”，而是把 OCR 拆成了两个比较经典的部分：文本检测和文字识别。
文本检测负责回答“文字在图像的哪个位置”。它把页面拆成文本行级别的框，不管框里是什么文字，是拉丁字母还是汉字还是天城文，在检测层看来都是“这里有文字”。检测模型对语言不敏感，它可以处理混排文档，同一页上既有中文又有英文，先把所有文本行都找出来再说。
文字识别负责回答“这个框里的字具体是什么”。它拿到检测模型裁出来的文本行图像，再转成字符串序列。这一步对语言是敏感的，所以 Surya 在做识别的时候会要求你传入文档的语言列表，比如["en", "zh"]，模型内部会在这些语言对应的能力范围内做解码。
这种检测和识别解耦的设计，带来的直接好处是工程上很灵活。检测精度不行，可以只替换检测模型；识别某个小语种不准，可以单独补那条语言的识别能力。对使用者来说，两个阶段分开也意味着可以分别观察瓶颈：如果文本行框漏了，问题在检测；如果框画得准但字认错了，问题在识别。
很多人第一次用 Surya 会忽略这个“两阶段”的设定，把它当成一个黑盒。但我建议你至少理解到这一层，因为后面调优和排查问题时，你会频繁用到“到底是检测错了还是识别错了”这个判断。
2.2 除了认字，Surya 还管版面结构
Surya 和传统 OCR 工具拉开差距的关键，是它不只是做“检测 + 识别”，还顺带做了版面分析、阅读顺序和表格结构。
版面分析要回答“这个页面分成了哪几个区域”。比如一份杂志扫描件，有标题区、正文区、图片区、页眉页脚，Surya 会先把这些区域切出来，再在每个区域内做文本行检测。这样识别出来的文字不再是“从左上角一路读到右下角”的杂货铺，而是有明确的区块归属。
阅读顺序解决的是“这些区域按什么顺序读”。这听起来好像很简单，但实际做文档处理的人都知道，双栏论文、复杂海报、嵌套表格里，文字区域的空间位置和真实阅读顺序经常不一致。一个靠纯坐标排序的简单方案，遇到双栏排版会直接把左边栏读完再读右边栏，而正确顺序应该是左栏第一行、右栏第一行、左栏第二行、右栏第二行。Surya 的模型会输出一个页面级的阅读顺序编号，这比“按 y 坐标上下排、再按 x 坐标左右排”的土办法靠谱很多。
表格识别更是实用。票据、报告、合同附件里表格密度极高，而传统 OCR 遇到表格基本是灾难现场：表格线被识别成噪点，单元格里的文字被拆得七零八落。Surya 的表格识别会输出单元格级别的结构，虽然不能保证每个复杂合并单元格都完美还原，但大部分规范表格都能给你一份可以继续喂给结构化解析工具的中间结果。
这套“检测 + 识别 + 版面 + 顺序 + 表格”的组合，很符合现代文档智能流水线的口味。你拿到的已经不是一张图片里的文字，而是一份带结构的文档数据，后面接信息抽取、知识库入库、全文检索，都顺滑得多。
2.3 多语言不是“塞字典”那么简单
90+ 语言识别，听起来像是一个“多准备几份字典”的事情，实际上远没有那么简单。
语言识别的一大难点是脚本系统的多样性。拉丁字母系的语言相互之间至少字形结构接近，但中文字符是方块字，阿拉伯文是连写并依赖上下文变形的文字，印地语等南亚语言有很多组合字符和变音符。OCR 模型要同时支持这些完全不同的文字系统，对特征提取、解码策略、训练数据配比都是很大的工程挑战。
另一个难点是同一页面上的语言混排。一个跨国公司的年报，很可能一页里同时出现英文、中文、日文，甚至表格里混着德文和法文。如果 OCR 工具要求你“每次只识别一种语言”，那处理这种文档就非常痛苦。Surya 的做法是在识别阶段接收一个语言列表，让模型在候选语言集内做推理，这样混排页面也可以一次跑完。
还有零样本和小样本语种的现实问题。90+ 语言里，有些语种公开的标注数据很少，模型训练时能见到的样本可能只有几万张甚至几千张，效果自然不会像中英文这样扎实。这一点我需要提前说清楚：Surya 支持 90+ 语言，不代表这 90+ 语言都能达到商业级精度。主流语言的日常文档效果相当能打，但冷门小语种仍然要自己先做一轮质量验证。
3. 安装到第一次出结果：实测一张中英混排文档
3.1 安装和模型下载
Surya 的安装链路不算长。它是 Python 生态的工具，底层依赖 PyTorch，所以你的机器上需要有 Python 3.9 以上的环境，GPU 不是必须，但有 GPU 会让推理快非常多。
安装命令就是普通 pip：
pip install surya-ocr如果你打算用 GPU 加速，建议提前装好对应版本的 PyTorch，再装 surya-ocr，避免它连带拉一个 CPU 版 PyTorch 或者和你现有环境冲突。
第一次真正跑推理时，Surya 会从模型仓库自动下载检测模型和识别模型。这些模型文件加起来有几百 MB 到一两个 GB，具体大小取决于版本和识别模型规格。下载完成之后会缓存在本地目录，后续再跑相同任务不会重复下载。
提示：第一次下载需要保证网络能访问模型仓库，而且下载过程有时候看起来像卡住了。模型文件较大，耐心等一下是正常的，如果反复失败，建议手动下载后放到缓存目录，具体路径可以通过环境变量指定。
3.2 命令行跑通
Surya 安装好之后会提供命令行入口。我测试时用的是它提供的 OCR 命令，大体长这样：
surya_ocr input.pdf --results_dir ./results不同版本的参数名可能有变化，安装之后先跑一下surya_ocr --help是最稳妥的。它支持直接传图片，也支持传 PDF。后者对文档场景特别有意义，因为很多扫描件本身就是 PDF，省掉了先转图片的预处理步骤。
跑完之后，results目录里会生成 JSON 格式的结果文件和可视化标注图。可视化图会把你检测到的文本行框、区域框画在原始页面上，方便你快速判断检测有没有漏、版面划分对不对。
我第一次跑的时候，用的是一张手机拍的合同照片，中英文混排，上面还有手写签名。Surya 输出里中英文部分都识别出来了，手写签名部分它很诚实地给了很低的置信度，没有强行把签名臆造成某个词。这一点给我的印象不错：它知道哪里有把握，哪里没有把握。
3.3 Python 接口调用
命令行工具适合验证效果和批量跑一次性任务，但真正接进业务系统，还是要用它的 Python 接口。以当前版本的常见用法为例，核心入口大概是这样的：
from surya.ocr import run_ocr image_paths = ["page1.png", "page2.png"] langs = ["en", "zh"] results = run_ocr(image_paths, langs)run_ocr会把一张或多张图片一次性送进去，返回的结果里包含页面级的文本行列表、文本框坐标、置信度以及版面信息。如果你需要更精细的控制，也可以分别调用检测和识别模块，先拿文本行框，再对指定区域做识别。这样灵活度更高，比如你只想识别页面上某个表格区域，就完全不用跑完整页。
我在项目里更常用的方式是把 Surya 的输出转成一个轻量结构，只保留需要字段，文本内容、页码、文本行坐标、置信度，再落成 JSON 或者 JSONL，后续喂给抽取逻辑或全文检索引擎。
3.4 输出结果里有哪些关键信息
Surya 的返回结果不是简单的“识别出一段字符串”，而是结构化的页面对象。我整理几个最常用的字段，你可以把它们当成使用时的观察重点。
- 文本行内容：模型识别出的字符串。
- 文本行坐标：通常是一个多边形框，四个角点坐标。
- 置信度：该行识别的把握程度，用来做结果过滤非常有用。
- 版面区域：当前文本行属于哪个版面区域，比如正文还是表格。
- 阅读顺序：页面内文本行的逻辑顺序，不是单纯按坐标排。
我测试一份中英混排说明书时，文本行坐标基本贴合原文位置，跨栏顺序也没有出现“先读完整左栏再读右栏”的老问题。这说明它的版面分析和阅读顺序模型确实在起作用，不是摆设。
4. 踩坑记录：从“能跑通”到“能上生产”
4.1 模型下载和离线部署
Surya 第一次运行时会自动下载模型，这个机制在个人电脑上很方便，到了生产环境就变成一个问题。我一开始在服务器上部署时，发现第一次跑 OCR 竟然卡了几分钟，日志一看是在下模型。团队里其他人接手时，如果环境没配好，还会出现“代码一样，结果不同”的情况。
生产环境里最好提前把模型文件准备好，放到一个共享目录或者打进镜像。这样做有几个好处：避免运行时下载的不确定性，也方便锁定模型版本。模型仓库那边如果更新了权重，而你的代码还是旧的，可能出现解析输出结构的兼容问题。
注意：OCR 结果会直接受到模型版本影响。建议在项目文档里明确记录你用的 Surya 版本和模型版本，并锁住 Python 依赖。不要用“最新版”这种不可控的表述，不然今天能跑通的代码，过两个月可能完全换了一套输出格式。
4.2 显存、内存和性能调优
Surya 的默认参数照顾的是通用场景，到了大批量处理时就容易碰到资源问题。我自己遇到最大的是显存和内存压力。
一份 300 页 PDF，如果一次性交给 Surya 处理，模型会把批量的页面图像载入显存，识别完之后再统一写结果。页面越大、批量越大、显存越紧张，图片分辨率高的扫描件尤其明显，一张 A4 扫描件动辄 3000 到 4000 像素宽，四个角点坐标和特征图在显存里占的空间不小。
我的做法是分批处理。先把 PDF 转成页面图像流，每次只送几页进去，处理完落盘，再继续下一批。虽然整体耗时变长了一些，但内存峰值稳定可控。批大小可以从 1 开始调，如果显存有余量就往上加，直到速度不再提升为止。
CPU 上跑 Surya 也可以，但速度差距很大。测试一份十页左右的文档，GPU 几秒到十几秒能完成，CPU 可能要分钟级别。如果只是临时验证识别效果，CPU 够用；如果是日常批量任务，建议至少准备一块入门级 GPU，或者想清楚是否能接受数倍等待时间。
4.3 “90+ 语言”不等于所有语言零失误
这是我在做多语言项目时体会最深的一点。
Surya 标注支持 90+ 语言，并不代表每一种语言的精度都跟中英文一样好。像英文、中文、法文、德文、西班牙文这些数据充足的语种，日常印刷体文档的识别效果已经很能打。但一些样本稀少的语言，遇到特殊字体、低分辨率扫描、带噪点的复印页，输出里会出现比较明显的错误。
所以我给出的建议是：如果你的业务只涉及少数几种主流语言，先拿自己真实样本做一轮验证，用置信度过滤掉低质量结果。如果你的业务要覆盖大量冷门语言，更要多留一些抽检样本，甚至准备一条人工复核链路。多语言能力是省事的，但“省事”不等于“免检”。
还有一类内容是 Surya 不太能处理的，比如复杂手写笔记、自然场景下的招牌文字、艺术字体海报。Surya 的定位是文档 OCR，它的训练数据和服务目标都偏向印刷体文档。拿它做自然场景文字识别，属于用错工具。
4.4 不同版本之间的接口变化
开源项目迭代快，Surya 的接口也一直在演进。我刚开始接触时和后来再看文档，发现同样的功能，调用方式已经不一样了。老版本里一些参数在新版本里被合并或改名，命令行入口也调整过。
对个人试用影响不大，但对团队项目来说，依赖锁定非常关键。建议在你的环境文件里固定主版本和次版本，比如显式指定某个版本号，不要把包名裸着写进去。这样至少能保证新同事拉下代码跑出的结果，和你之前验证过的一致。
提示：每次升级 Surya 大版本前，先跑一遍自己的测试样本集，对比前后的输出格式和识别质量。不要因为模型指标“看着提升了”就直接上生产，你的业务样本才是最终标准。
5. 选型：Surya vs Tesseract vs PaddleOCR，如何放对位置
5.1 横向对比
很多人在做事前技术选型时，总希望找到一个“全都能干”的工具。实际上 OCR 工具各有各的设计重心，选型的关键不是比谁强，而是比谁更匹配你的场景。我把几个常见维度拉了一张对比表：
| 维度 | Surya | Tesseract | PaddleOCR |
|---|---|---|---|
| 安装复杂度 | 低，pip 即可 | 低，但系统依赖较多 | 中高，模块多，依赖较复杂 |
| 文档结构输出 | 强，内置版面、顺序、表格 | 弱，基本是行级文本 | 中，PP-Structure 需要额外配置 |
| 多语言覆盖 | 90+，开箱即用 | 支持语言多，但配置繁琐 | 多，但核心优势在中文场景 |
| 中英文精度 | 日常文档够用 | 调优后可用 | 中文场景很强 |
| 标准表格识别 | 内置 | 基本不具备 | 有单独模块 |
| 资源占用 | 较高，依赖 PyTorch | 较低 | 较高 |
| 二次开发灵活性 | Python API，结构清晰 | 老牌，但接口较传统 | 能力全，但模块间耦合较重 |
这张表不是我跑 benchmark 得出的全场最优，但基本反映了我实际使用的体感。Tesseract 适合快速跑一些轻量任务，资源受限，或者环境里不想引入 PyTorch 这种大依赖。PaddleOCR 适合中文为核心、且团队愿意投入时间做集成与维护的场景。Surya 的优势则在“文档级”和“多语言”这两点上。
5.2 我的选择建议
如果你的需求是“把一张图片里的几行字抠出来”，这三个工具都能胜任，选哪个都不会错。但如果需求变成“把一个目录下几百份多语言合同处理成结构化文本”，我的选择会明确倒向 Surya，或者说以 Surya 为核心、其他工具做补充。
具体组合思路可以这样：多语言文档批量 OCR 走 Surya，它输出的版面区域和阅读顺序能直接帮后续信息抽取减少很多工作量。中文占绝对主体、版式又特别复杂的表单票据，我会单独考虑 PaddleOCR 的版面分析做对比，哪边效果好就切哪边。纯轻量、边缘设备、单机一次性小任务，Tesseract 依然是最省事的保底方案。
这里没有“谁淘汰谁”的结论。一个工程团队如果能维护好两套 OCR 工具链，把它们分别放在最合适的场景里，往往比强行用一个工具覆盖所有情况更稳。OCR 看起来是个通用能力，实际上每换一种文档风格、一种语言、一种扫描质量，工具的表现可能天差地别。
6. 最后分享几个我自己常用的组合技巧
我在实际项目里已经跑了不少文档流水线，最后几个经验算是一点私货，希望对你有用。
第一个技巧是 Surya 和大型语言模型配合使用。Surya 负责把 PDF 变成带结构的文字，接下来要抽字段、做摘要、回答文档问题，就交给语言模型处理。Surya 输出的阅读顺序和版面信息不是给你看的，是给后续模型“读”的，保留这些结构信息能让最终提取效果上一个台阶。
第二个技巧是置信度过滤一定要做。Surya 的每个文本行结果都带置信度。我习惯把低于阈值的结果单独拎出来，存成“疑似有误”清单，后续人工复核只处理这部分，而不是从头到尾都靠人看。扫描质量参差不齐时，这条策略能把人工成本压得很低。
第三个技巧是不要一上来就跑整本 PDF。先把样本文档裁前几页，单页单页验证，确认输出结构符合预期，再放大到整个目录。一旦中间某一步出问题，小批次更容易定位是检测的锅、识别的锅，还是文档本身质量问题。
第四个技巧是中文航线测试优先看竖排和复杂版面。竖排古籍、带标号的条款列表、嵌套表格，这些是很多 OCR 工具容易翻车的点。Surya 在这些场景下不一定样样完美，但它的版面模型至少会告诉你“这里它不敢打包票”，剩下的人工处理压力就小多了。
OCR 工具没有银弹，Surya 也不是万能钥匙。但如果你想在本地搭一条覆盖多语言、面向文档、能接进知识库的 OCR 链路，它现在是我愿意优先拆开试的第一选项。装一个包，喂一张图，看一页结构化 JSON，比听任何人下结论都更诚实。
