De los informes de laboratorio escaneados a datos estructurados: compromisos en la arquitectura OCR
Cómo una startup de salud con limitaciones presupuestarias puede sopesar las bibliotecas OCR, las APIs de Google Cloud y un LLM de visión autohospedado al convertir escaneos médicos en JSON estructurado.
Fuentes: How We Chose Our OCR Architecture for a Medical Reports Pipeline (Part 1 of 2)
Convertir una foto de una impresión de laboratorio en una fila que diga “Hemoglobina, 13.2, g/dL, referencia 12.0–15.5” parece ser un problema de OCR, pero el reconocimiento de texto simple es solo el primer paso. El verdadero reto consiste en obtener significado de una escaneo desordenado de manera económica, fiable y sin filtrar datos del paciente. Esta guía explica las decisiones arquitectónicas detrás de un pipeline de extracción de este tipo para un MVP de informes médicos, para que pueda reutilizar ese razonamiento cuando se enfrente a un problema similar de comprensión de documentos con un presupuesto limitado.
El requisito que impulsa todo
Imagínese un producto de salud en su fase inicial. Los pacientes suben un informe médico escaneado, ya sea en formato PDF o una foto del papel de laboratorio impreso tomada con el teléfono. El sistema debe convertirlo en registros médicos estructurados que tanto el paciente como su médico puedan consultar, y que posteriormente puedan ser analizados por inteligencia artificial. Cada registro necesita cuatro elementos: el nombre del parámetro, su valor medido, la unidad y el rango de referencia.
Esa última oración es clave. Una herramienta que solo devuelve un bloque de caracteres reconocidos no satisface por sí sola este requisito. Aún es necesario determinar qué número corresponde a qué prueba, qué cadena representa una unidad y qué par de números constituye un rango normal. Toda decisión que se tome tiene que ver con dónde se ubica ese paso de “comprensión” y cuál es su costo.
Las limitaciones eran típicas para un MVP: un equipo pequeño, un presupuesto reducido para la infraestructura y un volumen inicial esperado de unos 500 informes subidos por día, lo que equivale a aproximadamente 30,000 páginas al mes.
Decisión 1: Elegir el lenguaje de desarrollo
La ventaja del ecosistema de Python es real
Si se parte de la pregunta “¿qué lenguaje cuenta con las mejores herramientas de OCR y ML?”, Python gana sin mucho debate. Motores open source maduros como PaddleOCR y EasyOCR están diseñados principalmente para Python; OpenCV también dispone de integraciones de primera clase en este lenguaje, y la mayoría de los ejemplos de visión por computadora asumen su uso. Un pipeline de OCR desde cero naturalmente comenzaría en Python.
También vale la pena ser honesto sobre lo que no constituye un diferenciador. La API Vision de Google era una de las opciones de pago bajo consideración, y Google publica bibliotecas de cliente para Python así como para Go. Por lo tanto, la disponibilidad del SDK no favorecía a ninguno de los dos lenguajes.
Por qué Go ganó de todos modos
Los factores decisivos estuvieron relacionados con el sistema circundante y no con el OCR en sí. El resto del pipeline asíncrono ya estaba planeado como un proceso en Go: consume tareas desde Redis Streams, descarga los archivos subidos del almacenamiento de objetos Cloudflare R2 y escribe los resultados en Postgres. Escribir la fase de extracción en Python habría significado ejecutar dos entornos de trabajo, con despliegue, gestión de dependencias y capacidades de monitoreo separados, para una sola funcionalidad. El ingeniero encargado también era más productivo con Go para este tipo de servicio de estilo infraestructura.
La lección general: el lenguaje con el catálogo de bibliotecas más extenso no es necesariamente el adecuado. Si el paso de extracción puede reducirse a llamar a un modelo mediante HTTP (que es donde termina este diseño), mantener un único entorno de ejecución para toda la capa de trabajadores suele ser más valioso que una profundidad de bibliotecas que apenas se utilizará.
Decisión 2: APIs en la nube versus auto-hospedaje, con precios elevados
El equipo comparó cuatro opciones teniendo en cuenta las 30,000 páginas mensuales esperadas. Las cifras a continuación son las estimaciones utilizadas en el momento de la evaluación; los precios en la nube cambian, por lo que consulte las listas de precios actuales antes de confiar en ellas.
- Google Cloud Vision con
DOCUMENT_TEXT_DETECTION. Devuelve texto en bruto junto con coordenadas y sin campos estructurados. Con un costo de aproximadamente 1,50 dólares por 1,000 páginas, eso equivale a unos 45 dólares al mes.
Interpretar correctamente las cifras
La API Vision parece económica, pero resuelve un problema diferente. Te indica que los caracteres “13.2” aparecen en ciertas coordenadas; no tiene idea de que se trata de una lectura de hemoglobina. Aún así, tendrías que crear tú mismo toda la capa de análisis, por lo que su precio no es comparable con las opciones que devuelven datos estructurados.
Document AI sí devuelve información estructurada, pero un costo mensual de entre 1,000 y 2,000 dólares representa un gasto variable elevado para un producto que aún no ha generado ingresos.
Gemini Flash es el competidor realmente interesante. La tarifación basada en tokens para páginas escaneadas se sitúa en el mismo rango que la opción de auto-hospedaje, y evitas tener que gestionar infraestructura GPU. Entonces, ¿por qué no elegirlo?
Por qué el auto-hospedaje sigue siendo la mejor opción
Tres argumentos influyeron en la decisión:
- Límite de costo. Un nodo dedicado cuesta lo mismo ya sea que procese 5,000 o 50,000 páginas. Una API con medición de uso no tiene límite: un aumento repentino en el tráfico, una serie de intentos fallidos o una importación masiva se reflejan directamente en la factura.
- Aislamiento de datos. Los informes médicos contienen información de salud protegida. Al realizar la extracción dentro de la propia red privada del equipo, los documentos de los pacientes nunca se envían a una API de terceros con cada carga, lo que evita todo tipo de problemas relacionados con el cumplimiento normativo y las revisiones por parte de proveedores, algo para lo cual un equipo MVP carece de capacidad.
- Sin cuotas externas ni latencia. No existen límites de velocidad, niveles de concurrencia ni saltos adicionales en la red en el camino crítico.
Como resultado, se descartaron tanto las opciones de Google Cloud como Vertex AI y se optó por una solución completamente autohospedada.
También es útil considerar el otro lado de la moneda. La facturación por servidores fija solo es predecible hasta el nivel de rendimiento que puede manejar un único equipo; más allá de eso, debes adquirir más hardware y encargarte tú mismo de la planificación de capacidad y del tiempo de actividad. El autoalojamiento tampoco elimina las obligaciones de cumplimiento, ya que sigues siendo responsable del almacenamiento, del control de acceso y de la auditoría de esos datos. Para una carga de trabajo pequeña y constante con datos sensibles, generalmente es más ventajoso el autoalojamiento; en cambio, para volúmenes altos y en crecimiento rápido con un equipo que no cuenta con capacidad operativa, una API gestionada podría ser la mejor opción.
Decisión 3: Omitir las bibliotecas OCR tradicionales
Los motores de código abierto como PaddleOCR y Docling son capaces, pero su salida está diseñada para mostrar el contenido. Por lo general, el contenido se presenta entre etiquetas de formato o en formato Markdown para que se muestre bien en una interfaz de usuario o vista HTML. Esto es ideal cuando alguien leerá el resultado, pero resulta incómodo cuando el código necesita extraer “Hemoglobina: 13.2 g/dL” como un campo limpio.
Cerrar esa brecha constituye un proyecto en sí mismo. Sería necesario extraer valores de la estructura de etiquetas, probar y error repetidamente para adaptarse a diferentes laboratorios y formatos de informes, y probablemente aplicar procesamiento previo o posterior con OpenCV a las tablas y regiones que el motor no segmentó correctamente. Todo ello se suma al trabajo ya existente de integrar e hospedar el motor OCR. Para un MVP, se trata de una gran cantidad de trabajo técnico destinado a la infraestructura y no al producto en sí.
Hay una advertencia importante que merece énfasis: esta evaluación refleja la opinión del equipo, no un veredicto definitivo sobre estas herramientas. Los ingenieros con mayor experiencia en PaddleOCR o Docling podrían conocer una forma más rápida de obtener campos limpios a partir de sus resultados estructurados, y como ambos proyectos evolucionan con rapidez, vale la pena revisar nuevamente sus formatos de salida actuales.
Decisión 4: Un LLM de visión autohospedado, adaptado al presupuesto
Extraer significado en lugar de caracteres
La alternativa a “OCR y luego escribir un analizador para el resultado del OCR” es permitir que un modelo de lenguaje con capacidad visual realice ambas acciones al mismo tiempo. El OCR clásico reconoce caracteres. Un LLM de visión, con una instrucción bien estructurada, puede analizar la página escaneada y devolver directamente los campos de parámetro, valor y unidad, omitiendo el paso intermedio de procesar Markdown con etiquetas.
La capacidad visual es esencial aquí, no una actualización opcional. Un modelo solo de texto no puede ayudar con una imagen escaneada porque aún no existe texto al que recurrir. El modelo debe leer los píxeles por sí mismo.
Este enfoque conlleva sus propios riesgos, y vale la pena planificar cómo hacerles frente desde el primer día. Los modelos de lenguaje pueden interpretar mal los dígitos o generar valores que parecen plausibles pero que no aparecen en la página; además, los modelos más pequeños en particular no siempre devuelven exactamente la estructura JSON que se solicitó. En el caso de los datos de salud, esto exige un análisis defensivo de la respuesta del modelo, la validación de los valores según los tipos y rangos esperados, y una forma en que los usuarios o médicos puedan ver y corregir el documento original.
Elegir un modelo que realmente se pueda ejecutar
La selección del modelo siguió la misma lógica presupuestaria. Los modelos más grandes de Qwen con capacidad de visión son potentes, pero alojar uno de esa categoría de tamaño requiere más VRAM y recursos de procesamiento de lo que era razonable para la infraestructura por la cual el equipo pagaba con el presupuesto del MVP. La elección recayó en MiniCPM-V: un modelo mucho más pequeño que Ollama puede ejecutar en hardware económico sin problemas, aunque aún suficientemente bueno para la extracción estructurada de imágenes de informes de laboratorio.
Si repite este ejercicio, pruebe los modelos candidatos en una muestra representativa de sus documentos reales, incluyendo fotos borrosas tomadas con teléfono y diseños inusuales de laboratorios, en lugar de confiar únicamente en las puntuaciones del ranking. El mejor modelo en teoría es irrelevante si no puede permitirse ejecutarlo.
Qué necesita la implementación a continuación
La arquitectura descrita anteriormente determina qué se ejecuta; el pipeline de producción aún debe gestionar cómo. El trabajo posterior incluye convertir PDF en imágenes que el modelo pueda leer, estructurar la solicitud y el prompt de la API Ollama, analizar JSON de forma defensiva cuando un modelo pequeño se desvía del formato solicitado, y utilizar Redis Streams en el trabajador de Go para que los informes se procesen de manera fiable a medida que aumenta el volumen.
Puntos clave
- Defina la salida que necesita (aquí: nombre, valor, unidad, rango de referencia) antes de comparar herramientas; el texto OCR en bruto y los datos estructurados son productos diferentes con precios distintos.
- Elija el lenguaje del trabajador para todo el sistema, no solo por la biblioteca más completa de un componente en particular.
- Compare las opciones en la nube según una salida equivalente, y luego considere los límites de costo, el aislamiento de datos y las cuotas además del precio principal.
Lecturas relacionadas
- OCR con LLM visual autohospedado en Go: Rastreación, generación de prompts, análisis — Cómo un proceso en Go convierte PDF médicos en JSON estructurado utilizando Ollama, pdftoppm, prompts estrictos, análisis de respaldo y grupos de consumidores de Redis Streams.
- Agente = Modelo + Herramienta: De dónde proviene realmente el comportamiento fiable de la IA — Aprenda qué es una herramienta para agentes de IA, por qué el estado, la autoridad y la verificación deben quedar fuera del modelo, y qué estructuras serán obsoletas a medida que los modelos mejoren.
- Creación de instrucciones para LLM listas para producción: un marco de siete capas — Aprende un marco estructurado, inspirado en API, con siete capas de instrucciones: indicaciones, contexto, restricciones y más, para crear sistemas LLM fiables de nivel profesional.