Chandra OCR 2:PDF 识别后少返工

一份混着双栏、公式和表格的 PDF，识别出文字以后，工作往往才刚开始。段落顺序乱了，表格只剩一串文本，公式还得重新录入。OCR 明明跑完了，人却继续在后面收拾版面。

Chandra OCR 2 处理的是这段返工。它可以把文档转成 Markdown、HTML 或 JSON，尽量把页面结构一起带出来。这样得到的内容才方便继续进入知识库、检索系统、内容清洗或程序化处理，而不是停在一份只能复制粘贴的纯文本里。

偶尔识别几张截图，用系统自带 OCR 会轻松得多。Chandra 更适合另一类材料：页数不少，版面不规整，识别结果还要交给下一道流程。表格、图表、数学公式和手写文本都在项目列出的处理范围内，多语言覆盖写的是 90 多种。这个范围很宽，但不代表每种语言、每种扫描质量都能得到同样的结果。

复杂文档碎片被整理成统一结构化流程的正文配图

三个输出格式解决的事情并不一样。Markdown 适合接写作和知识库，HTML 更容易保留页面层次，JSON 则方便程序继续拆字段。若最终只需要一段可搜索的文字，这些结构化输出未必派得上用场；若 PDF 后面还连着 RAG、归档或内容生产，它们会直接影响整条链路要不要人工补救。

单一复杂文档分流到多种结构化输出形态的正文配图

部署也分成两种心态。本地 transformers 推理适合拿几份真实文档试水，先看输出能不能被现有工具接住。确定样本合适，再用 vLLM 和 FastAPI 做远端服务，才需要考虑并发、资源和调用接口。直接从服务化开始，容易花时间解决部署问题，却还不知道模型是否适合自己的文件。

比较稳妥的试法，是挑三份平时最难处理的材料：一份复杂表格，一份带公式的双栏文档，再加一份扫描质量不太理想的文件。分别输出 Markdown、HTML 和 JSON，检查丢失的是文字、结构还是阅读顺序。只有这些结果过关，后面的服务化工作才有意义。

Datalab 在 2026 年 3 月 18 日发布的 olmOCR 对比表里，给 Chandra 2 报出的总分是 85.9，位置靠前。这是项目方公布的 benchmark，可以用来决定要不要试，不能替代自己的样本测试。OCR 最麻烦的地方恰恰是数据分布不同：别人测的是整套基准，你最后处理的可能全是某种财务表格或老旧扫描件。

本地试跑与远端服务化两条部署路径的正文配图

Chandra 2 是一款 3B 级视觉语言模型，项目把它定位为可以自托管的 OCR 路线。文档不方便交给外部 API，或者内部已经有模型服务基础设施时，自托管会带来更多控制权。代价也很直接：模型运行、服务维护和升级都要自己负责。

还有一项不能等到上线前再看。官方许可把商业使用单独列出，需要 Chandra OCR 2 commercial license；研究、个人使用和年收入低于 200 万美元的创业团队有另一套说明。具体项目准备投入生产前，应按自己的主体和用途核对授权，不能把“模型权重可下载”理解成可以直接免费商用。

适合继续试用与应当克制采用的 OCR 场景边界图

这套工具是否省事，答案藏在识别后的十分钟里。输出文件能直接继续处理，它就有可能替掉一段长期的人工整理；如果表格和阅读顺序仍然频繁出错，再漂亮的 benchmark 也帮不上忙。先用最难的几份 PDF 做本地测试，再决定要不要部署服务，成本会低很多。

Chandra OCR 2 的代码、文档和许可说明可以在项目仓库查看：<https://github.com/datalab-to/chandra>。