Durante años, el OCR ha sido ese mal necesario: útil para “sacar texto”, pero desesperante cuando el documento real se parece más a la vida… es decir, cuando hay tablas densas, columnas múltiples, formularios con casillas, notas manuscritas o un PDF escaneado con calidad dudosa. En ese terreno es donde Chandra intenta jugar a otra liga.
El proyecto —publicado como open source— se presenta como un modelo OCR orientado a reconstruir documentos con estructura, no solo a transcribir caracteres. La promesa no es menor: convertir imágenes y PDFs en HTML, Markdown o JSON preservando el layout, con soporte sólido para tablas, formularios, matemáticas y escritura a mano, además de extracción de imágenes y diagramas con sus captions.
En otras palabras: no busca “texto plano”, busca documentos reutilizables.
No es solo OCR: es “OCR + estructura + salida lista para pipeline”
La idea clave detrás de Chandra es que el valor no está en leer letras, sino en entregar resultados que puedan alimentar flujos automáticos: documentación, sistemas de búsqueda interna, RAG con permisos, archivado legal, analítica de contratos, migración de PDFs a bases de conocimiento, etc.
Por eso, en lugar de limitarse a un .txt, Chandra está pensado para:
- Reconstruir tablas (sin convertirlas en una sopa de celdas mal alineadas).
- Respetar formularios, incluyendo elementos como checkboxes.
- Mantener layout en documentos complejos (multicolumna, encabezados/pies, textos largos y pequeños).
- Extraer imágenes y diagramas con organización y metadatos.
- Ofrecer salida estructurada en HTML/Markdown/JSON.
Y esto, para equipos técnicos, cambia el juego: un OCR que devuelve “estructura” reduce muchísimo el trabajo posterior de limpieza, normalización y parsing.
Dos modos de inferencia: local o remoto (vLLM)
Chandra plantea dos vías de uso, con un enfoque muy práctico:
- Local (Hugging Face)
Para quien quiere procesar documentos en local, con control total del entorno. - Remoto (servidor vLLM / contenedor)
Pensado para producción o procesamiento por lotes. En este caso, el flujo típico es levantar el servidor y ejecutar el CLI apuntando a esa API.
En ambos casos, el punto de entrada es simple: se instala como paquete y se invoca por CLI, con opciones relevantes para el mundo real (rango de páginas, workers en paralelo, tokens máximos por página, extracción de imágenes, etc.).
Qué genera exactamente cuando procesa un PDF
El diseño de salida es otro detalle que apunta a ingeniería de producto (no a demo):
- Un directorio por documento.
- Un
.mdcon el contenido en Markdown. - Un
.htmlcon la reconstrucción en HTML. - Un
*_metadata.jsoncon datos del procesamiento (páginas, tokens, etc.). - Una carpeta
images/para los elementos visuales extraídos.
Esto es especialmente útil si el destino es un pipeline de indexación (por ejemplo, buscar por secciones y anclas en HTML, o versionar Markdown como “fuente viva”).
Benchmarks: donde intenta diferenciarse
El repositorio incluye una tabla comparativa en el olmocr bench, con puntuaciones por categoría (arXiv, tablas, documentos antiguos, multicolumna, texto pequeño, etc.). Más allá de la cifra global, lo relevante aquí es el enfoque: medir por “tipos de documento”. En OCR, las medias globales engañan.
En la tabla publicada, Chandra destaca especialmente en áreas que suelen romper a los OCR generalistas, como tablas y layout difícil, además de mantener resultados competitivos en documentos variados.
El detalle que los equipos legales van a mirar primero: la licencia de los pesos
Aquí hay una distinción importante:
- El código se distribuye bajo licencia permisiva (Apache 2.0).
- Los pesos del modelo se rigen por una licencia tipo OpenRAIL modificada, con condiciones: se permite investigación/uso personal y ciertos escenarios de startups por debajo de umbrales (por ejemplo, financiación/ingresos), pero hay restricciones para usos competitivos con su API y para explotación comercial más amplia sin licencia adicional.
Traducido a lenguaje de empresa: no basta con que sea “open source”. Antes de integrarlo en producto, conviene revisar con lupa qué permite exactamente el esquema de licencias, especialmente si se monetiza el OCR como parte del servicio.
Por qué esto importa en 2026: OCR como pieza base de la “IA útil”
La ola de IA aplicada a empresa está moviéndose (otra vez) hacia lo práctico: menos fuegos artificiales y más automatización real. Y hay una realidad incómoda que se repite en todos los departamentos: la mitad del conocimiento útil sigue viviendo en PDFs.
Sin un OCR capaz de entender estructura:
- La búsqueda interna falla.
- Los sistemas RAG se “inventan” contexto porque el documento se convirtió en texto plano sin jerarquía.
- Los formularios pierden semántica.
- Las tablas se degradan y se vuelven inutilizables.
En ese sentido, modelos como Chandra apuntan a un nicho muy concreto: convertir el caos documental en datos y conocimiento explotables sin que el equipo tenga que rehacerlo a mano.
Preguntas frecuentes
¿Chandra sirve para extraer tablas complejas de un PDF escaneado sin perder columnas?
Esa es una de sus metas principales: reconstrucción con layout y soporte fuerte para tablas, precisamente donde el OCR clásico suele fallar.
¿Qué formato conviene más para integrarlo en un pipeline: HTML, Markdown o JSON?
Depende del destino: HTML suele ser ideal para preservar estructura visual y anclas; Markdown es cómodo para versionado y lectura; JSON encaja bien si se necesita parseo determinista y enriquecimiento posterior.
¿Se puede desplegar en producción para procesar lotes de documentos?
El enfoque con servidor vLLM y CLI apunta justo a eso: procesamiento repetible, paralelizable y más cercano a un servicio interno.
¿Es “libre para uso comercial” sin matices?
No necesariamente: el código es permisivo, pero los pesos tienen condiciones específicas. Para empresas, esto requiere revisión legal si se va a integrar en un producto o servicio.
Fuentes: Repositorio de GitHub datalab-to/chandra (README y tabla de benchmarks), documentación del paquete chandra-ocr y notas de licencia del modelo/pesos.
