PaddleOCR 3.5 brings Transformers-backed OCR to document AI workflows

PaddleOCR 3.5 adds a Transformers inference backend for supported OCR and document parsing models, so teams already using PyTorch, Transformers, or Hugging Face tooling can test PaddleOCR without rebuilding their whole document stack. The release keeps PaddleOCR in charge of the OCR and parsing pipeline while letting developers select engine="transformers" for compatible models. For LinkLoot readers, the useful angle is not “another OCR model,” but a cleaner ingestion layer for RAG, document agents, and searchable knowledge bases.

Key takeaways

• PaddleOCR 3.5 supports flexible inference backends, including Paddle static graph, Paddle dynamic graph, and Transformers for supported models.
• The GitHub release says 20 major models now support Transformers as an inference backend, while the Hugging Face post shows the engine="transformers" setup path.
• The release also adds Office-document-to-Markdown conversion, DOCX export for parsed results, and an official browser inference SDK called PaddleOCR.js.
• Use the Transformers backend when your stack already depends on Hugging Face model loading, PyTorch services, or Hub-based experimentation.
• Keep throughput expectations realistic: the Hugging Face post says PaddleOCR’s default paddle_static backend is usually the better choice when maximum OCR speed is the priority.

Practical LinkLoot angle

Document AI workflows fail quietly when the first ingestion step is weak. If scanned PDFs, screenshots, tables, or office documents enter a RAG pipeline as messy text, the downstream LLM can retrieve the wrong context or miss the numbers that matter. PaddleOCR 3.5 is useful because it gives builders another way to fit OCR and document parsing into the infrastructure they already operate.

A practical test workflow looks like this:

1. Pick a small document set: one scanned PDF, one table-heavy report, one screenshot, and one Office document.
2. Run the same documents through your current parser and through PaddleOCR 3.5 with the Transformers backend.
3. Compare Markdown structure, table preservation, recognition errors, latency, and GPU memory use.
4. Feed both outputs into the same retrieval or agent workflow and check whether answers cite the correct page, row, or section.
5. Only move to production if the parser improves retrieval quality without adding unacceptable latency or deployment complexity.

What to verify before you act

Start by confirming model compatibility for your exact PaddleOCR task, because the Transformers backend applies to supported models rather than every possible pipeline. Then test hardware behavior: the Hugging Face example uses backend options such as dtype, device placement, and attention implementation, and those settings can change both quality and cost. Finally, verify output quality with downstream retrieval, not just OCR accuracy, because a document agent cares whether the extracted Markdown or JSON preserves the structure needed for citations and decisions.

Source check

The Hugging Face post confirms the engine="transformers" usage, the target use cases around RAG and document agents, and the recommendation to keep Paddle’s default backend in mind for throughput-sensitive work. The GitHub release independently confirms PaddleOCR v3.5.0, the 20-model Transformers backend claim, Office-to-Markdown conversion, DOCX export, and PaddleOCR.js. PyPI provides an additional package-level corroboration for the 3.5.0 release and recent feature summary.

If you are building document workflows around agents, pair this with LinkLoot’s guide to AI workflow automation and treat OCR quality as a measurable part of the workflow, not a hidden preprocessing detail.