OCR, no el LLM, es el cuello de botella en pipelines de documentos a escala

Cuando los equipos de ingeniería llevan Document AI a producción, la intuición habitual es que el modelo de lenguaje será la parte cara: el componente que consume GPU, que tarda, que escala mal. Un paper publicado esta semana en arXiv desmonta esa intuición con datos de un pipeline real procesando miles de documentos multipágina por hora. La conclusión más llamativa: el OCR, no el LLM, domina la latencia total del sistema.

El trabajo, titulado Operationalizing Document AI: A Microservice Architecture for OCR and LLM Pipelines in Production (arXiv:2605.18818), cubre el hueco que la literatura académica suele ignorar: el tramo entre "tenemos un modelo que funciona" y "el modelo procesa carga real sin caerse".

Qué propone la arquitectura

Los autores describen una arquitectura de microservicios que encadena tres etapas: clasificación de documentos, reconocimiento óptico de caracteres y extracción estructurada de campos mediante LLM. Cada etapa es un servicio independiente, lo que permite escalarlas por separado según su naturaleza computacional.

Las decisiones de diseño que detallan son las que cualquier equipo de ingeniería termina tomando a golpe de incidente en producción:

• Separación de inferencia GPU de la orquestación CPU. Los workers que llaman al modelo viven en procesos distintos a los que coordinan el flujo. Mezclarlos provoca contención de recursos difícil de diagnosticar.
• Procesamiento asíncrono para operaciones I/O. La mayor parte de las esperas en un pipeline de documentos son I/O: lectura de ficheros, llamadas a APIs, escritura de resultados. Bloquear threads en esas esperas es el camino más rápido a una cola infinita.
• Escalado horizontal independiente por etapa. Cada microservicio sube o baja réplicas según su propio perfil de carga, en lugar de escalar el sistema completo como un bloque.
• Clasificación híbrida. Combinar un clasificador ligero (que descarta rápido los documentos que no requieren procesamiento completo) con modelos más pesados reduce el trabajo innecesario antes de que llegue al LLM.

Las dos sorpresas del profiling en batch

Los autores aplicaron batch profiling al pipeline completo y extrajeron dos hallazgos que, según reconocen, no esperaban y que cambian cómo se planifican los despliegues.

El primero: el OCR acapara la mayor parte de la latencia end-to-end. En documentos multipágina con layouts complejos, el tiempo de reconocimiento óptico supera con claridad al de la inferencia LLM posterior. Esto tiene implicaciones directas en dónde invertir en hardware y en qué etapa optimizar primero.

El segundo: el sistema no satura por número de workers, sino por la capacidad compartida de inferencia GPU. Añadir más workers de orquestación sin aumentar la capacidad GPU no mejora el throughput; solo incrementa la cola de espera. El punto de saturación real lo fija la GPU, no el paralelismo de los procesos que la llaman.

Para quién es útil esto

Este paper no va dirigido a investigadores de modelos. Va dirigido a equipos que ya tienen un modelo de extracción de documentos funcionando en staging y necesitan llevarlo a producción sin que explote a las dos semanas.

Es especialmente relevante para quienes construyen integraciones con Claude u otros LLMs sobre flujos de documentos empresariales: facturas, contratos, expedientes médicos, formularios. En esos contextos, los documentos no llegan de uno en uno, llegan en ráfagas, y la arquitectura que funciona en un notebook raramente aguanta mil páginas por hora.

Las empresas que usan Claude vía API para extracción estructurada de campos encontrarán aquí un marco de referencia sólido para el wrapper que rodea esa llamada: cómo gestionar la cola, cómo dimensionar las réplicas de OCR y cómo no confundir saturación de GPU con falta de workers.

Qué no cubre

El paper se centra en la arquitectura de ejecución, no en la calidad de los modelos. No evalúa qué LLM extrae mejor los campos ni qué motor de OCR comete menos errores. Tampoco aborda estrategias de caché de resultados ni el manejo de documentos con layouts muy irregulares que rompen las asunciones del clasificador.

Son limitaciones que los propios autores reconocen, y que dejan espacio para trabajo posterior.

---

La contribución principal del paper es modesta en el mejor sentido: no propone nada nuevo, sino que documenta con rigor lo que funciona. En un campo donde la literatura se acumula en benchmarks de modelos y escasea en guías de operación, eso tiene más valor práctico de lo que parece.