Chandra: el OCR que quiere convertir PDFs “imposibles” en Markdown y JSON sin romper el diseño

En 2025, el OCR ya no se mide solo por “si acierta el texto”, sino por si es capaz de entender documentos reales: formularios con casillas, tablas con celdas raras, escaneos viejos, notas manuscritas o PDFs que parecen maquetados para derrotar a cualquier extractor automático. En ese contexto está ganando atención Chandra, un modelo de OCR que promete algo muy concreto: convertir imágenes y PDFs en HTML/Markdown/JSON estructurado, preservando la maquetación y la información de layout (no solo el texto plano).

La propuesta es directa: si el documento tiene columnas, encabezados, pies de página, tablas complejas o incluso matemáticas, Chandra intenta reconstruirlo en un formato utilizable para flujos modernos de documentación, IA y automatización. Y ahí está el punto clave: no es “OCR para leer”, es OCR para reutilizar.

Qué trae Chandra y por qué importa

Según la documentación pública del proyecto, Chandra se presenta como un modelo orientado a escenarios donde otros OCR suelen fallar:

  • Tablas y formularios con estructuras irregulares (incluyendo checkboxes).
  • Soporte de escritura a mano y documentos con “ruido” visual.
  • Extracción de imágenes y diagramas, con sus captions y datos estructurados.
  • Más de 40 idiomas.
  • Salidas listas para pipeline: Markdown, HTML o JSON con detalles de layout.

En la práctica, esto encaja con una necesidad creciente en empresas: pasar de “tengo un PDF” a “tengo conocimiento consultable”, sin que el resultado sea un bloque de texto sin contexto.

Dos modos de inferencia: local y servidor

Chandra se puede ejecutar de dos formas, pensadas para perfiles distintos:

  1. Modo local (Hugging Face), útil para equipos que quieren procesar documentos sin sacar datos fuera, o integrarlo en entornos controlados.
  2. Modo remoto (vLLM server), pensado para lotes grandes y despliegues de producción, con paralelización y una experiencia más “servicio”.
ocr test handwritten form

Además, incluye utilidades para empezar rápido: un CLI para procesar archivos o directorios y una app interactiva con Streamlit para pruebas rápidas.

El detalle práctico que lo hace “usable”: estructura de salida

Uno de los problemas habituales de muchos OCR “buenos” es que su salida es difícil de integrar. Aquí el enfoque es más pragmático: por cada documento procesado, el sistema genera un directorio con el Markdown/HTML, un JSON de metadatos (páginas, tokens, etc.) y una carpeta de imágenes extraídas. Esto facilita meterlo en flujos de:

  • indexación (RAG),
  • archivado documental,
  • QA interno,
  • analítica,
  • o migraciones de documentación.

Benchmarks: la guerra real del OCR ya no es solo “accuracy”, es “layout”

Donde Chandra intenta diferenciarse es en benchmarks centrados en documentos reales. En la tabla de referencia que publica el proyecto (basada en “olmocr bench”), aparece comparado con alternativas como Marker, Mistral OCR API, DeepSeek OCR o modelos generalistas “anchored” como GPT-4o y Gemini Flash.

bench ocr llm

Más allá del número global, hay una pista importante: el rendimiento se desglosa por tipos de documento (tablas, multi-columna, encabezados/pies, texto diminuto, escaneos antiguos, matemáticas). Y eso es lo que suele doler en producción: un OCR puede ir bien con PDFs “limpios” y hundirse con un 10-K, un contrato escaneado o una tabla con líneas finas.

Licencia: ojo con el “sí, pero…”

En proyectos de este tipo, la letra pequeña importa. Chandra indica un esquema mixto: código bajo Apache 2.0, pero pesos del modelo bajo una licencia modificada tipo OpenRAIL-M, con uso gratuito para investigación/personal y startups por debajo de ciertos umbrales, y restricciones si compites con su API (según describe el propio proyecto). En entornos empresariales, esto suele traducirse en una tarea clara: revisar legal antes de integrarlo como pieza central.

Por qué aparece ahora: la presión por “document AI” es brutal

El auge de RAG, agentes y automatización documental ha cambiado el listón. Ya no basta con “extraer texto”: hay que preservar estructura, citar fuentes, reconstruir tablas y evitar que los modelos inventen cuando el OCR se equivoca. El OCR se ha convertido en la primera pieza de la cadena… y cuando falla, falla todo lo demás.

Por eso herramientas como Chandra se leen como una respuesta a una realidad muy concreta: las empresas están llenas de PDFs y la IA solo aporta valor cuando esos PDFs se convierten en información navegable y verificable.


Preguntas frecuentes (FAQ)

¿Chandra sirve para extraer tablas complejas de PDFs a Markdown o JSON sin perder celdas?
Ese es uno de sus focos: reconstrucción de tablas y salida estructurada (Markdown/HTML/JSON), con información de layout para mantener coherencia.

¿Se puede usar Chandra en local para OCR de documentos sensibles sin subirlos a terceros?
Sí: el proyecto contempla ejecución local mediante el método basado en Hugging Face, además de la opción servidor con vLLM.

¿Qué diferencia a Chandra de un OCR clásico cuando hay formularios con checkboxes o plantillas escaneadas?
El objetivo no es solo leer texto, sino reconstruir formularios (incluyendo casillas) y mantener la estructura del documento.

¿Qué hay que revisar antes de usar Chandra en un producto comercial?
Además del rendimiento, conviene revisar el esquema de licencias: el código y los pesos del modelo pueden tener condiciones distintas, especialmente si el uso es comercial o compite con servicios relacionados.

Fuentes:

  • Chandra OCR – Layout-Preserving OCR Model – Software
  • Chandra OCR: Complete Setup & AI Pipeline Integration
Scroll al inicio