PaddleOCR 3.5 añade backend Transformers para OCR | Keryc
PaddleOCR 3.5 llega para darte más flexibilidad a la hora de convertir documentos en datos útiles. ¿Qué cambia? Ahora puedes ejecutar modelos de OCR y parsing documental proporcionados por PaddleOCR usando transformers como backend de inferencia, lo que facilita integrarlos en pilas centradas en Hugging Face y PyTorch.
Qué trae PaddleOCR 3.5
La novedad principal es una interfaz de inferencia más flexible: el parámetro engine permite elegir el backend y engine_config acepta opciones específicas del mismo. En la práctica esto significa:
PaddleOCR sigue gestionando las tuberías internas de OCR y parsing documental, así que no tienes que llamar manualmente a cada componente.
transformers pasa a ser un backend soportado para ejecutar modelos PaddleOCR compatibles.
Puedes configurar opciones como dtype, colocación de dispositivos y la implementación de atención a través de .
engine_config
Una forma simple de entender la pila:
Capa
Qué significa
Ejemplos
Capa de aplicación
Aplicaciones que consumen OCR y parsing documental
RAG, agentes, Document AI
Capa de modelo
Capacidades de OCR y parsing
PP-OCRv5, PaddleOCR-VL 1.5
Capa de backend de inferencia
Runtime para ejecutar los modelos
paddle_static, paddle_dynamic, transformers
Esta versión se centra en la capa de backend: PaddleOCR mantiene las capacidades de OCR y parsing, y transformers ofrece una alternativa natural para entornos centrados en Hugging Face.
Ejemplos prácticos (instalación y uso)
Instala PaddleOCR 3.5 junto con PaddleX, Transformers y un build de PyTorch compatible con tu hardware. En CUDA 12.6, por ejemplo:
La configuración óptima depende del modelo, el hardware y el entorno de despliegue.
¿Cuándo usar el backend Transformers y cuándo no?
Usa el backend transformers cuando quieras que las capacidades de OCR y parsing encajen de forma natural en una pila centrada en Hugging Face y PyTorch. Es especialmente útil si ya usas:
Pipelines, herramientas y despliegues basados en transformers.
Descubrimiento y distribución de modelos a través del Hub.
Infraestructura PyTorch para experimentación y gestión de artefactos.
Si tu prioridad es maximizar throughput y latencia en producción, el backend por defecto paddle_static suele ser la opción recomendada. Esta integración no reemplaza backends: te da libertad para elegir según tus necesidades.
Recomendaciones técnicas y buenas prácticas
Prueba varias combinaciones de dtype y attn_implementation para encontrar el mejor balance entre precisión, memoria y velocidad en tu hardware.
Valida el pipeline de ingestión documental (tablas, fórmulas, layouts complejos) antes de integrarlo con LLMs. Un mal preprocesamiento arruina cualquier RAG o agente, por bueno que sea el LLM.
Si ya tienes infraestructura en Hugging Face (Spaces, Hub, Transformers Serving), la integración reduce fricción y facilita el manejo de modelos y artefactos.
Para despliegues en producción, mide throughput, latencia y uso de memoria en ambos backends (transformers vs paddle_static) antes de decidir.
Prueba el demo en Hugging Face Spaces para ver cómo se comporta en escenarios reales:
Si trabajas en RAG, agentes documentales, búsqueda o analítica, PaddleOCR 3.5 facilita el paso crítico de transformar documentos en datos estructurados dentro de un flujo basado en Transformers. No es magia: es un atajo para integrar capacidades maduras de OCR con la infraestructura que ya usan muchos equipos.
Piénsalo así: la mayor complejidad en Document AI suele estar antes del LLM. PaddleOCR agiliza esa primera etapa y te deja concentrarte en la lógica de recuperación, razonamiento y acción.
