PaddleOCR：理解内容的OCR page

#先进行检测：这会带来什么变化

PaddleOCR 是一款采用 Apache 2.0 许可证的开源 OCR 工具包，它并非逐行读取页面：而是先定位文本位置，再读取每个区域，随后可以重建页面及其表格结构。这使其在处理发票、表单、倾斜扫描和多语言文档时具有强大的鲁棒性，而像 Tesseract 这样的引擎在这些场景下往往会自信地产生荒谬的结果。该项目分为两个系列：一个模块化流水线（PP-OCRv6 用于识别，PP-StructureV3 用于结构分析）以及 PaddleOCR-VL，这是一个拥有约 9 亿参数的视觉模型，能够一次性将页面转换为 Markdown，并且根据发布方的说法，在 OmniDocBench v1.6 上达到了 96.33% 的成绩。代价是安装过程更繁重，需要 PaddlePaddle 和模型权重，并且 VL 变体有文档记录的 GPU 前置要求。对于大量清晰文本，轻量级引擎仍然更简单。

传统引擎假设页面由一行行文本组成，排列方式就像书籍一样。实际文档并非如此：发票有框线，表单有字段，演示文稿中的文本叠加在图像上，扫描件可能歪斜，技术图纸上则有倾斜的标签。

PaddleOCR 将问题拆分处理。检测模型找出文本区域，无论它们位于何处，并返回其位置；识别模型则读取每个区域。倾斜的文字、页边的图注和单元格中的数字，分别成为众多区域中的三个。这使它能够应对那些逐行读取系统会悄然出错的文档。

#处理流程的步骤

并非所有步骤都是必需的。读取几个标签只需要检测和识别；为文档检索导入财务报告，则有理由使用完整的处理流程。PP-OCRv6 是 2026 年发布的一代识别模型，仅凭一个统一模型就能覆盖 50 种语言（中文、英文、日文及 46 种使用拉丁字母的语言），无需在不同语言之间切换模型。

#PaddleOCR-VL：从 OCR 演变为视觉模型

自 2025 年 10 月起，该项目在同一名称下发布了第二个系列：PaddleOCR-VL。这是一款紧凑的视觉语言模型，用单次处理取代整个五步流水线。2026 年 5 月底发布的 1.6 版本拥有约 9 亿个参数，将动态分辨率视觉编码器与小型语言模型相结合。在将文档转换为 Markdown 或 JSON 的权威基准测试 OmniDocBench v1.6 中，它的得分达到 96.33%，项目方将这一水平称为新的业界最佳水平。

令人印象深刻的不仅是分数，更是获得该分数的模型规模。InsiderLLM 发布的一篇指南用一句话总结了现状：一个拥有 9 亿参数的模型在文档 OCR 上超越了 720 亿参数的模型和 GPT-4o。同一篇文章指出，通用竞争对手的内存成本——Qwen2.5-VL-72B 在 Q4 量化下需要 48 GB 或更多的 VRAM——而 PaddleOCR-VL 转换为 GGUF 格式并量化为 Q4_K_M 后，占用空间大约在一到一点五 GB 之间，包括语言模型权重和视觉投影器。这条 GGUF 路径很新：对 PaddleOCR-VL 的支持已于 2026 年 2 月（版本 b8110）集成到 llama.cpp 中，且可用的 GGUF 文件来自社区，而非 PaddleOCR 团队。

取得 OmniDocBench 评分的组件并不是项目中的唯一组件：除了 PaddleOCR-VL，该项目还维护 PP-StructureV3，这是一条专门将复杂 PDF 转换为 Markdown 或 JSON 的处理流程，并保留每个表格单元格和每个文本块的精确坐标。两个组件的目标相同——将真实文档妥善转换——但采用不同的路径：PaddleOCR-VL 使用单一模型，PP-StructureV3 则使用一系列专用组件。无论使用哪种引擎，都原生支持多 GPU 和多进程推理；当需要在合理时间内处理包含数万页文档的语料库时，这一点就很重要。

#PaddleOCR 或 Tesseract

设计合理的处理流程会同时使用两种引擎：简单页面交给轻量引擎，复杂页面交给成本较高的引擎。这种分流不增加成本，在处理大型语料库时能节省数小时。表中关于倾斜的那一项并非无关紧要：发票信息提取软件厂商 Koncile 在自己的测试中测得，Tesseract 对摆正的发票的识别率为 100%，而扫描图像仅倾斜 3 至 5 度，识别率就降至 31%——这恰好是 PaddleOCR 的方向分类步骤旨在应对的情况。

• Tesseract：轻量级引擎，哪些情况下够用
• Docling：转换结构化文档
• 端到端提取发票数据
• 使用本地视觉模型分析图像

#使用场景：何时切换到 PaddleOCR

计费与账务管理

发票扫描件很少完全端正；表格结构（数量、单价、增值税）必须保持清晰可读，让各项金额仍能表达原本的含义，而不是变成一行互不关联的数字。

多语言行政文件

表单、身份证件、使用不同文字系统书写的信件：PaddleOCR 支持的语言范围广，无需为每个国家或每套字母系统分别部署不同的引擎。

用于 RAG 的长篇报告

数十页的报告包含标题、副标题和表格，建议保留其结构进行转换：符合章节划分的切分方式优于按字符数量切分。

杂乱的扫描档案

一箱箱纸质文档扫描得很粗糙，页面方向杂乱：在读取内容之前，方向分类步骤就能解决大部分由此造成的混乱。

处理量大且文本清晰

相反，对于大量已妥善取景的收银小票或对账单，通常仍是更轻量的引擎更合适——参见上文与 Tesseract 的比较。

#安装并启动首次提取

安装通过 pip 完成，但有一点需要注意：从 3.x 系列开始，仅安装 paddleocr 包还不够。文档要求先安装所选的推理引擎（默认为 PaddlePaddle），然后再安装 paddleocr 包。每条处理流水线首次运行时，都会下载检测、识别模型的权重，以及在需要时下载版面分析模型的权重。

1. 01
   安装库

   首先按照官方安装页面安装PaddlePaddle（根据设备选择CPU或GPU版本），然后运行命令 python -m pip install paddleocr。基础包支持Python 3.8及以上版本；文档解析扩展包（paddleocr[doc-parser]）要求Python 3.9及以上版本。
2. 02
   执行首次提取

   paddleocr ocr 命令接收一张图片作为输入（选项 -i），并将结果写入由 --save_path 指定的文件夹。要使用 PaddleOCR-VL 将页面转换为 Markdown，请使用 paddleocr doc_parser 命令，同样采用 -i 和 --save_path 选项。
3. 03
   启用有用步骤

   use_doc_orientation_classify、use_doc_unwarping 和 use_textline_orientation 选项会启用页面或文本行的倾斜校正。对于清晰的扫描件，将这些选项设为 False 可以加快处理速度；官方文档建议，当推理速度过慢时，应禁用不必要的功能。

python -m pip install paddleocr
paddleocr ocr -i ./facture.jpg --use_doc_orientation_classify True --use_textline_orientation True --save_path ./output

#资源消耗情况

该项目没有公布适用于所有文档的每页处理速度：它取决于文档内容的密集程度、启用的处理步骤和硬件。文档建议关闭不必要的功能，或在推理较慢时选择更轻量的模型。请先用您自己的约二十页文档进行测量，再推算整个语料库的处理情况。对于 PaddleOCR-VL，官方文档列出了 NVIDIA GPU 的要求（PaddlePaddle：计算能力 7.0 或以上，且 CUDA 11.8 或以上；vLLM：计算能力 8.0 或以上，且 CUDA 12.6 或以上），也提供了使用 x64 处理器的运行方式。模型权重只需下载一次，之后全部在本地运行：不使用任何 API，也没有按页计费的成本。

#决定性理由：不编造内容

PaddleOCR 读取像素。它可能误读某个字符，而数字被误读成另一个数字也不一定容易察觉。让通用视觉模型转录文档时，它可能生成一个格式正确、看似合理、却并不存在于页面上的值，而输出中没有任何迹象提示这一点。PaddleOCR-VL 的情况更棘手：它生成文本，而不是逐区域读取，因此即使专门接受过转录训练，也面临与通用视觉模型同一类的风险。任何系统都无法完全避免在识别模糊字符时出错。

对于文档核查、会计工作或任何必须可审计的任务，这一区别应当指导您的选择：对于您将据以开展工作的数字，使用专用 OCR 引擎；当您希望文档得到解释而非转录时，使用通用视觉模型。对于重要文件，同时使用两者并比较结果，仍是合理的第三种选择。

实际操作中，核查并不需要重新通读所有内容。每批抽取几十份文档，手动将其与引擎输出进行对照，就足以发现系统性偏差——例如字段区域框选不准、语言识别错误，或表格反复被错误拆分——从而避免这些偏差影响数千页自动处理的文档。

• 来源：PaddleOCR 在 GitHub 上的官方仓库
• 来源：PaddleOCR-VL-1.6 模型页面
• 来源：本地PaddleOCR-VL独立评测

#FAQ