PaddleOCR 3.5：基于 Transformers 后端的 OCR 与文档解析新范式

背景

在构建 RAG（检索增强生成）、Document AI（文档智能）以及文档 Agent 应用时，真正的挑战往往始于大语言模型（LLM）之前。开发者首先需要将 PDF、扫描文档、截图、表格、图表、公式以及复杂的页面布局转化为可靠的结构化数据。如果这一“数据摄入”（ingestion）环节薄弱，下游的 LLM 工作流可能会遗漏关键信息、检索到错误的上下文，从而产生不可靠的答案。

PaddleOCR 长期以来通过提供 PP-OCRv5 等 OCR 模型系列以及 PaddleOCR-VL 1.5 等文档解析模型系列，致力于解决这一文档摄入难题。然而，随着 Hugging Face 生态系统的普及，许多开发者已经深度依赖 PyTorch 和 Transformers 基础设施进行模型加载、实验、部署及模型工件管理。

为了弥合这一差距，PaddleOCR 3.5 的发布旨在将 OCR 和文档解析任务更紧密地融入 Hugging Face 生态系统。此次更新的核心在于引入了灵活的推理引擎接口，使得受支持的 PaddleOCR 模型可以直接使用 Hugging Face Transformers 作为推理后端，从而降低集成摩擦，为基于 Hugging Face 中心化的工作流提供更自然的路径。

核心内容

PaddleOCR 3.5 引入了更灵活的推理引擎接口，允许开发者通过 engine 参数选择后端，并通过 engine_config 传递特定后端的配置选项。这一架构设计确保了 PaddleOCR 继续管理任务背后的 Pipeline（如 OCR 或文档解析流程），开发者无需手动调用各个内部组件，同时获得了后端选择的自由度。

1. 架构与工作原理

此次更新主要涉及推理后端层。PaddleOCR 依然提供核心的 OCR 和文档解析能力，而 Transformers 成为运行这些模型的另一个受支持的后端选项。

• Pipeline 管理：任务背后的 Pipeline 由 PaddleOCR 统一管理，开发者无需关心内部组件的调用细节。
• 后端解耦：Transformers 成为受支持的推理后端之一。
• 配置灵活：开发者可以通过 engine_config 配置后端相关选项，如数据类型（dtype）、设备放置（device placement）以及注意力机制实现（attention implementation）。

2. 安装与环境配置

要使用此功能，需要安装 PaddleOCR 3.5、PaddleX、Transformers 以及与你硬件兼容的 PyTorch 版本。

CUDA 12.6 环境示例：

python -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126
python -m pip install "paddleocr==3.5.0" "paddlex==3.5.2" "transformers>=5.4.0"

对于 CPU、ROCm 或其他环境，请安装匹配目标硬件的 PyTorch 版本。

3. 代码使用示例

命令行运行：

paddleocr ocr \
-i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png \
--device gpu:0 \
--engine transformers

Python API 调用：

from paddleocr import PaddleOCR

pipeline = PaddleOCR(
    device="gpu:0",
    engine="transformers",
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
    engine_config={
        "dtype": "float32",  # Hugging Face Space 使用 float32 以确保广泛兼容性
    },
)

results = pipeline.predict(
    "https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png"
)

for result in results:
    print(result)

4. 高级配置选项

开发者可以根据自身的模型、硬件和部署环境，通过 engine_config 调整后端特定选项以优化性能：

engine_config = {
    "dtype": "bfloat16",       # 根据硬件支持选择数据类型
    "device_type": "gpu",      # 指定设备类型
    "device_id": 0,            # 指定设备 ID
    "attn_implementation": "sdpa", # 指定注意力机制实现方式
}

5. 适用场景与选型建议

• 推荐使用 Transformers 后端的情况：

  • 希望 PaddleOCR 的能力更自然地融入 Hugging Face 中心化栈。
  • 构建 RAG、Document AI、搜索、分析或 Agent 应用，且已依赖 PyTorch/Transformers 基础设施。
  • 团队已熟悉 Transformers 开发体验，希望获得更熟悉的开发流程。
  • 需要利用 Hub 进行受支持 PaddleOCR 模型的发现和分发。
  • 希望更容易地集成现有的 PyTorch/Transformers 服务。

• 推荐使用默认 paddle_static 后端的情况：

  • 当最大化 OCR 或文档解析吞吐量为首要目标时，PaddleOCR 默认的 paddle_static 后端通常是推荐选择。

此次发布并非旨在用一种后端完全替代另一种，而是赋予开发者更多灵活性：使用 PaddleOCR 获取 OCR 和文档解析能力，并选择最适合自身技术栈的推理后端。

关键要点

• 生态融合：PaddleOCR 3.5 通过支持 engine="transformers"，使受支持的模型可以直接在 Hugging Face Transformers 生态中运行，降低了集成门槛。
• 配置灵活：通过 engine_config 参数，开发者可以精细控制数据类型（如 float32/bfloat16）、设备分配及注意力机制实现。
• 职责分离：PaddleOCR 负责管理 OCR/文档解析的 Pipeline，Transformers 仅作为推理后端，两者各司其职。
• 性能权衡：Transformers 后端适合集成便利性和生态一致性；若追求极致吞吐量，默认的 paddle_static 后端仍是首选。
• 应用导向：该更新特别有利于构建 RAG、Document AI 和 Agent 应用，解决了从非结构化文档到结构化数据摄入的关键痛点。
• 开源协作：此次集成得到了 Hugging Face 工程师团队（包括 Anton Vlasjuk, Raushan Turganbay, Yoni Gozlan 等）的大力支持，提升了集成质量与开发者体验。

意义与影响

PaddleOCR 3.5 的发布标志着 OCR 和文档解析能力向 Hugging Face 中心化工作流的进一步靠拢。对于开发者而言，这意味着在构建 Document AI 应用时，不再需要在不同的工具链之间进行复杂的适配。

1. 降低集成摩擦：对于已经使用 PyTorch 和 Transformers 的团队，可以直接利用现有的基础设施加载和运行 PaddleOCR 模型，无需维护额外的 PaddlePaddle 推理环境，简化了部署流程。
2. 提升数据摄入可靠性：通过更顺畅地连接 OCR 能力与下游 LLM 工作流，有助于确保从 PDF、扫描件等复杂文档中提取的结构化数据更加可靠，从而提升 RAG 和 Agent 应用的答案质量。
3. 增强生态兼容性：支持通过 Hugging Face Hub 发现和分发模型，使得 PaddleOCR 的模型能够更容易地融入现有的模型资产管理、实验追踪和部署服务中。
4. 赋予开发者选择权：PaddleOCR 并未放弃原有的高性能后端，而是提供了“双后端”策略。开发者可以根据具体场景（是追求极致性能还是追求生态集成）灵活选择，这种设计体现了对多样化开发需求的尊重。

总之，PaddleOCR 3.5 通过引入 Transformers 后端，不仅丰富了自身的技术栈，也为整个 AI 开发者社区提供了一种更灵活、更自然的文档处理解决方案，推动了 Document AI 工作流的标准化和易用性发展。

相关链接：

• PaddleOCR 文档: https://www.paddleocr.ai/
• PaddleOCR GitHub: https://