背景

在检索增强生成（RAG）和文档AI应用中，一个被普遍忽视的瓶颈是文档预处理。企业数据大量以PDF、扫描件、截图、表格、图表等形式存在，LLM本身无法直接理解这些非结构化内容。可靠的结构化提取（OCR、版面分析、表格识别等）是整个流程的“最后一公里”，也是最容易出错的一环。如果文档解析质量低，后续的检索和生成将错误百出，再强大的LLM也无法弥补。

PaddleOCR作为百度PaddlePaddle生态下最成熟的OCR工具包，长期以来为开发者提供端到端的文字检测、识别、表格解析能力。然而，其原生依赖于PaddlePaddle推理后端，使得习惯使用HuggingFace Transformers生态的开发者需要额外适配，增加了技术栈的复杂性。

核心内容：Transformers后端支持

2026年5月发布的PaddleOCR 3.5版本带来了一个关键变化：支持HuggingFace Transformers作为推理后端。开发者只需在API中设置 engine="transformers"，即可用Transformers前端直接运行PaddleOCR的模型（如PP-OCRv5、PaddleOCR-VL 1.5）。

具体实现上，PaddleOCR 3.5引入了灵活的推理引擎接口，通过engine参数选择后端，engine_config传递后端特有选项（如dtype、设备分配、注意力实现方式）。这意味着：

• 开发者无需手动组装内部组件，PaddleOCR自动管理从图像输入到结构化输出的完整流程。
• 支持的模型仍然由PaddleOCR训练和发布，但推理时可以选择Transformer运行时，无缝融入HuggingFace生态。
• 可以轻松与其他Transformers模型（如Embedding模型、LLM）组合，构建端到端的文档AI流水线。

行业影响与专业点评

PaddleOCR 3.5的这一更新虽然看似只是工程层面的整合，但其影响深远：

1. 降低集成成本：对于已经使用HuggingFace Transformers栈的团队，现在可以直接使用pipeline API加载PaddleOCR模型，不再需要维护两套推理框架。这减少了学习曲线和部署复杂性，尤其是在Kubernetes等容器化环境中。

2. 推动文档AI标准化：文档AI领域长期缺乏统一的模型接口标准。PaddleOCR的加入使得Transformers生态同时覆盖文本、图像、音频、文档等多个模态，有望成为多模态AI的统一接口层。

3. 加速RAG应用落地：高质量的文档解析是RAG系统可靠性的基础。PaddleOCR的强项在于中文、表格、复杂版面等场景，搭配Transformers生态中的Embedding模型（如BGE、E5）和LLM，可以快速搭建高效的文档问答系统。

当然，这次更新目前仅支持部分PaddleOCR模型，且Transformers后端可能在特定场景下性能略低于原生PaddlePaddle引擎。但对于大多数应用场景，开发便利性的提升远大于性能损耗。正如团队所说：“文档AI的困难部分往往在LLM之前”，PaddleOCR 3.5正是在最困难的阶段提供了更顺手的工具。

---

来源