PaddleOCR，把图片和 PDF 变成 AI 能用的数据

哈喽，大家好，我是阿亮。

这篇聊一个把图片、扫描件、PDF 变成结构化数据的 GitHub 项目，叫 PaddleOCR。

它不是单纯把图片里的字抠出来。

真正值得看的地方，是它正在把 OCR 这件老技术，往 AI 工作流的入口层推：图片、票据、合同、论文、表格、手写笔记、公式、印章、图表，最后都尽量变成 Markdown、JSON，交给 RAG、Agent、知识库、自动化流程继续处理。

项目地址：https://github.com/PaddlePaddle/PaddleOCR

截至 2026 年 6 月 17 日，这个仓库已经有 82.7K Star、10.8K Fork，最新版本 v3.7.0 在 2026 年 6 月 11 日发布。这个热度已经很能说明问题：很多团队并不是缺一个聊天框，而是缺一条把现实世界资料送进 AI 系统的路。

先说真正的痛点。

大模型很擅长总结、问答、检索、生成，但它天然不认识你手里那一摞“脏数据”：扫描 PDF、拍歪的表格、带水印的合同、图片里的公式、章印、手写批注、多栏论文。

你把这些东西直接扔给模型，轻则漏字段，重则顺序错乱、表格崩掉、公式变形。更麻烦的是，很多企业文档不能随便上传到外部平台，成本、隐私、稳定性都要算账。

PaddleOCR 解决的就是这层入口问题。

它把“看图识字”拆成更工程化的流程：先做版面分析，找出标题、正文、表格、图片、公式、印章、页眉页脚；再做文字识别、表格还原、公式识别、文档结构恢复；最后输出更适合机器继续处理的结果。

它真正重要的一句话是：

很多 AI 应用卡住的不是模型不够聪明，而是现实资料进不了系统。

好，那它到底能干什么？

第一类是通用文字识别。

PaddleOCR 的 PP-OCR 系列面向的是身份证、街景、书籍、工业字符、屏幕、票据这类真实场景。v3.7.0 里发布的 PP-OCRv6，把中文、英文、日文和 46 种拉丁语系语言放到同一个模型里处理，不用为不同语种来回切模型。

这对跨境电商、海外客服、资料站、全球化产品很实用。不是所有 OCR 场景都需要一个巨大的视觉语言模型，有些场景更需要速度、成本、部署灵活度和稳定识别。

第二类是复杂文档解析。

PP-StructureV3 更像是“文档拆解器”。它处理的不是一行字，而是一整页文档：多栏阅读顺序、表格、图片、公式、印章、图表、Markdown 输出，都在这条线上。

比如一份行业报告，普通 OCR 只能告诉你“这一页有哪些字”。但产品经理、研究员、运营同学真正需要的是：标题层级是什么，表格还原成什么，哪些内容可以进知识库，哪些图片和图表要单独保留。

第三类是 PaddleOCR-VL。

这是更贴近 AI 时代的一块。PaddleOCR-VL 是面向文档解析的视觉语言模型系列，最新 1.6 版本主打文本、公式、表格、古籍、罕见字符、印章、图表理解。它的核心思路不是只拿一个 VLM 硬看整页，而是用完整 pipeline：先做版面分析和区域裁切，再让 VLM 去识别元素，最后按阅读顺序合并成完整结果。

这个区别很关键。

很多人一提文档 AI，就会本能地想“把 PDF 截图丢给多模态大模型”。这能做 demo，但很难做稳定工程。PaddleOCR-VL 的思路更像是把“看懂文档”拆成可控步骤，让每一步都能优化、替换、部署和排查。

这也是它值得 AI 从业者学习的地方。

不是所有问题都要用一个更大的模型解决。文档处理这种场景，输入复杂、格式复杂、下游任务复杂，工程 pipeline 反而比单点模型更重要。

如果你是工程师，它给你的启发是：AI 应用不是只接一个模型 API。你要处理输入、结构、坐标、格式、部署、服务化、隐私和成本。

如果你做产品，它给你的启发是：用户要的不是“OCR 准不准”这个孤立指标，而是“我的合同、票据、论文、表格能不能进入下一步工作流”。这两个问题不是一回事。

如果你做运营、内容或知识管理，最小可用场景很简单：把图片笔记、PDF 报告、课程截图、表格资料先转成 Markdown，再进入 Obsidian、Notion、RAG 知识库或自动化脚本。

这里还有一个很有现实感的变化：PaddleOCR 已经不只是 Python 包，还在往 AI 工具链里接。

它提供 MCP Server，可以把 OCR、PP-StructureV3、PaddleOCR-VL 作为工具接入 Claude Desktop 这类 MCP Host；也有 LangChain 相关封装，能把 PaddleOCR-VL 的文档解析能力接到已有的 RAG 流程里。

这意味着它的位置变了。

过去 OCR 更像后台算法模块；现在它可以成为 Agent 的工具。用户给 Agent 一张手写笔记、一份 PDF、一张表格截图，Agent 不应该只会“看图说话”，还应该能把内容拆出来、转成文件、写入知识库、生成可编辑表格、继续执行后续任务。

小白怎么开始？

如果只是想先体验，官方有在线体验中心和 API。想在本地跑，先装推理引擎，再装 PaddleOCR。全功能安装命令是：

python -m pip install "paddleocr[all]"

如果只想尝试文档解析，可以从 PP-StructureV3 或 PaddleOCR-VL 的命令行开始：

paddleocr pp_structurev3 -i ./demo.png

paddleocr doc_parser -i ./demo.png --save_path ./output

工程集成时，再切到 Python API，把结果保存成 JSON 或 Markdown。这个路径比一上来研究所有模型配置更顺手。

但别把它神化。

第一，安装和部署不是“复制一行命令就永远没事”。PaddleOCR 3.x 要考虑 PaddlePaddle、Transformers、CPU/GPU、Docker、不同硬件后端，文档解析能力越强，环境和算力要求越要提前评估。

第二，文档解析不是零误差任务。表格、公式、扫描质量、倾斜、遮挡、复杂版式都会影响结果。生产环境要拿自己的真实文档做小流量验证，别只看 demo。

第三，云 API、AI Studio、千帆、自托管服务、本地推理各有取舍。数据敏感就优先本地或自托管；想快速验证就用官方 API；要高并发就要认真看服务化部署和成本。

第四，PaddleOCR-VL 要用完整 pipeline 才能发挥价值。只把其中的 VLM 组件当成普通多模态模型来调用，容易得到不稳定甚至幻觉更多的结果。

所以我更愿意把 PaddleOCR 理解成一个“文档入口工程”。

它不是替代大模型，而是把大模型最难吃下去的那部分现实资料，先洗干净、拆明白、排好队，再送进去。

AI 应用越往真实业务走，越会遇到这种朴素问题：资料不是一段干净文本，而是一堆 PDF、图片、截图、合同、票据、表格、手写稿。

PaddleOCR 的价值就在这里。

如果你正在做知识库、Agent、企业搜索、合同审查、票据自动化、研究报告分析，别只盯着最后那个问答模型。先看看你的资料入口是不是可靠。

入口不稳，后面再聪明也会歪。

如果你已经用 PaddleOCR 做过真实项目，评论区告诉我：它在哪类文档上最稳，哪类文档最容易翻车。