Techinfo
En abril, se lanzó DharmaOCR-LITE, un modelo especializado en el reconocimiento óptico de caracteres (OCR) que abarca una amplia variedad de documentos, desde contratos y presentaciones judiciales hasta facturas, identificaciones y formularios. El estudio que respalda este modelo argumenta de manera precisa y medida la importancia de la especialización en dominios: un modelo más pequeño, entrenado específicamente para su tarea, puede superar a las API de propósito general en esa misma función.
El OCR permite obtener el texto de una página, respetando el formato original. Esto es fundamental cuando se necesita trabajar con un documento completo, como un contrato que se leerá en su totalidad o un manuscrito que se está digitalizando. Sin embargo, existe otro caso de uso: no se desea el documento completo, sino campos específicos en un formato que un sistema posterior pueda procesar. Por ejemplo, cada ítem de una factura debe presentarse como una lista, o el nombre del paciente, tipo de examen y fecha de una requisición médica deben estar listos para ser programados. Además, los campos de una identificación deben estar mapeados a las columnas de un registro de empleados.
Al procesar un documento a través de OCR, se obtiene todo lo impreso en él, línea por línea, sin indicar cuál es el tipo de examen, cuál es la fecha o cuál es el total. Aún se requiere que alguien escriba el código que asigne cada valor al campo correcto antes de que llegue a la base de datos. Un modelo de lenguaje de propósito general puede realizar esta tarea hoy en día, con un prompting cuidadoso. Sin embargo, a precios y latencias de API de frontera, en una tarea que muchas empresas necesitan ejecutar a gran volumen, esto se convierte rápidamente en una solución costosa para un problema bien definido.
Por ello, se desarrolló un modelo específico para esta necesidad. El Field Extractor toma una imagen de un documento y puede recibir una solicitud para extraer todo lo que encuentre o un esquema exacto a completar, devolviendo un JSON estructurado: tipificado, campo por campo, anidado donde el documento lo esté. Por ejemplo, una factura regresa con cada ítem como una lista ordenada, cada uno con su cantidad y valor, junto a los totales. Una identificación se devuelve con los campos que se almacenarán, bajo los nombres que su sistema ya utiliza. Este mismo modelo maneja todo sin necesidad de ajustes específicos por tipo.
Imaginemos que cada mañana recibes un lote de facturas de proveedores y necesitas extraer cuatro datos de cada una para integrarlos en tu sistema: el proveedor, el número de factura, la fecha de vencimiento y el total. La misma situación se presenta con requisiciones médicas que se ingresan en un programador, o contratos que alimentan un sistema de cumplimiento, donde lo que importa son las partes involucradas, el plazo, las penalizaciones y los montos de las multas. No necesitas la página completa, sino ciertos campos específicos. Con el Extractor de Campos, hay dos formas de solicitarlos:
Abierto: no se proporciona un esquema. El modelo lee la página y determina cuáles partes son campos estructurados (una etiqueta seguida de un valor, una tabla con una fila de encabezado sobre sus columnas) a partir del contexto y el diseño, no de una lista fija de nombres de campo, y devuelve todo lo que encuentra como pares clave-valor.
Dirigido por esquema: especificas la forma exacta que deseas, campo por campo, con un tipo para cada uno (cadena, número o booleano), bajo los nombres de clave que ya utiliza tu sistema. Si pides "proveedor_de_servicio" y "empresa_cliente", esos son los nombres exactos que recibirás. Si solicitas una tabla, la completará fila por fila, columna por columna, emparejando cada celda con la clave correspondiente. Si pides un campo que no está en el documento, devuelve nulo en lugar de inventar un valor.
La elección depende de lo que ya conoces. Envía una solicitud abierta cuando no sepas qué contiene el documento. Envía un esquema cuando la salida debe coincidir con una forma que ya existe en otro lugar.
En cualquier caso, lo que regresa es JSON: los campos como claves, los valores tipificados según lo solicitado, y nulo donde el documento no tenía lo que pediste. Cuando envías un esquema, la salida lo sigue exactamente, con las mismas claves y sin campos adicionales, por lo que puede integrarse directamente en el siguiente sistema.
Cómo fue entrenado. El modelo base es DharmaOCR-LITE v1.1, una nueva versión de 2 mil millones de parámetros optimizada a partir de la presentada en el artículo y ya especializada en OCR mediante ajuste fino supervisado y DPO. Sobre ese punto de control, se entrenó un adaptador LoRA con 43,384 ejemplos de entrenamiento que cubren ambos modos de solicitud.
Los datos están organizados en tres flujos: datos en inglés de múltiples dominios: documentos diversos recopilados de la web pública, abarcando muchos tipos de documentos. Datos del dominio brasileño: documentos brasileños reales obtenidos internamente, en portugués.
La base de datos multilingüe incluye una menor proporción de otros idiomas europeos y asiáticos, lo que permite una generalización más amplia más allá del inglés y el portugués. Todos los conjuntos de datos están anotados a nivel de campo. La mezcla es intencionalmente multidominio: se incluyen recibos, facturas comerciales, formularios, estados de cuenta bancarios, documentos de identidad y documentos sintéticos, en lugar de limitarse a un solo tipo de archivo.
El benchmark completo abarca 546 documentos en tres escenarios de solicitud, sumando un total de 1,638 casos: la extracción de cada campo sin esquema, un esquema parcial que nombra solo los campos reales, y un esquema que también incluye campos deliberadamente inexistentes. La puntuación se calcula a partir del F1 a nivel de campo (coincidencias por ruta, incluyendo la posición dentro de una tabla), multiplicado por la similitud de Levenshtein en los valores que coincidieron y por la proporción de salidas que regresan como JSON válido.
Se realizó el mismo benchmark contra cuatro configuraciones de modelos de lenguaje general. En comparación con los LLM de propósito general, la diferencia de calidad varía entre 1.8 puntos (Claude Opus 5, el más cercano) y 9.3 puntos (GPT-5.6 Luna, el más amplio). En cuanto a costos, se observa que varían desde aproximadamente seis veces menos (GPT-5.6 Luna) hasta aproximadamente 147 veces menos (GPT-5.6 Sol). Ambos lados tienen precios diferentes. Las cifras de frontera provienen de la medición del promedio de tokens de entrada y salida por página, incluyendo tokens de razonamiento, en comparación con la lista de precios publicada por cada proveedor. Cada modelo de frontera se ejecutó con el razonamiento configurado en bajo; Claude Opus 5 utilizó un esfuerzo adaptativo, que puede omitir el razonamiento en páginas más simples mientras se mantiene en un nivel bajo. En nuestro caso, no se cobra por token: el modelo se ejecuta de forma autohospedada, por lo que la cifra se refiere al tiempo de GPU en un solo L40S a $2.24 por hora.
Este no es un precio de venta. El costo autohospedado depende del hardware, el volumen y la latencia que cada implementación necesita. La comparación se presenta para mostrar que un SSLM soberano, desplegado en su propia infraestructura, es una alternativa real a las APIs de frontera.
SROIE y FUNSD son dos conjuntos de datos públicos incluidos en nuestro benchmark, que no se utilizaron en el entrenamiento. A continuación, se presenta un ejemplo de cada uno. En un recibo de SROIE, solicitamos todos los 18 campos impresos en él, sin campos fantasma en esta ocasión, y cada uno de ellos se devuelve correctamente: la dirección de facturación, que ocupa varias líneas y no está etiquetada, se captura como un solo campo, los dos campos en blanco (vendedor y referencia) se devuelven correctamente como nulos, y cada número en el recibo coincide hasta el centavo.
En un formulario de variación de fotocopiado FUNSD, un modelo evaluó con precisión una lista de doce campos booleanos, que incluía un grupo anidado de cinco subopciones. El modelo marcó exactamente la única casilla que estaba seleccionada (un original de baja calidad, con una nota manuscrita que decía "desvanecido" al lado) como verdadera, mientras que las otras once las clasificó como falsas, coincidiendo exactamente con el formulario. Además, logró leer correctamente el ID Bates manuscrito en la página y devolvió un valor nulo para los dos campos que quedaron en blanco, lo que demuestra su capacidad para manejar tanto datos estructurados como no estructurados.
Un modelo de 2 mil millones de parámetros obtuvo una puntuación de 0.834, superando todas las configuraciones de frontera que probamos, desde Claude Opus 5 con 0.816 hasta GPT-5.6 Luna con 0.741, mientras se ejecutaba en un único L40S a un costo por extracción inferior al de cada API en la comparación. Esto demuestra una calidad superior y un costo más bajo, medidos en el mismo estándar y en la misma ejecución. Este rendimiento resalta la eficiencia del modelo, que no solo logra resultados precisos, sino que también lo hace de manera más económica.
No es la primera vez que realizamos esta medición. Nuestro trabajo sobre OCR posicionó al primer DharmaOCR-LITE, un modelo de 3 mil millones de parámetros, por encima de todas las API comerciales de frontera probadas en portugués brasileño; tres meses después, llegaron modelos más nuevos y mejor equipados, y la diferencia se mantuvo. Ahora, un modelo de 2 mil millones de parámetros logra lo mismo en la extracción de campos. Cada resultado refuerza la tesis con la que iniciamos Dharma-AI: en una tarea delimitada, un modelo pequeño entrenado específicamente para esa tarea supera a un modelo de frontera que se le pide hacer lo mismo de manera general. En esta evaluación, también costó entre 6 y 147 veces menos ejecutarlo, lo que resalta la viabilidad económica de utilizar modelos más pequeños y especializados.
La cantidad de parámetros establece un límite superior; el entrenamiento determina cuánto de ese límite alcanza un modelo en tu tarea. Tu negocio no necesita el modelo más grande disponible. Necesita uno entrenado para tu problema específico, lo que implica que la personalización y el enfoque en la tarea son cruciales para obtener resultados óptimos. La capacidad de un modelo para adaptarse a las necesidades particulares de un negocio puede ser más valiosa que simplemente contar con el modelo más avanzado en términos de parámetros.
En el ámbito de la extracción de datos, se destacan varios conjuntos de datos que han sido utilizados para evaluar el rendimiento de modelos como Dharma Field Extractor. Uno de ellos es FUNSD, que fue reservado para la evaluación y no se utilizó durante el entrenamiento. Este conjunto de datos está disponible en huggingface.co/datasets/nielsr/funsd y también se puede consultar en el sitio web de Guillaume Jaume.
Otro recurso importante son las facturas de Zenodo, recopiladas por Cruz y Castelli de NOVA IMS en 2022, que se pueden encontrar en zenodo.org/records/6371710. También se menciona el conjunto de datos de líneas de productos, disponible en huggingface.co/datasets/Sagarjha456/line_items, que ofrece información valiosa para la extracción de datos estructurados.
Además, se encuentra el conjunto de datos de facturas de Katanaml, conocido como Donut, elaborado por Kozłowski y Weichbroth en 2021, accesible a través de Mendeley Data con el DOI: 10.17632/tnj49gpmtz.2. Este recurso también está disponible en huggingface.co/datasets/katanaml-org/invoices-donut-data-v1.
HumynLabs ha desarrollado un conjunto de datos que incluye facturas y cuentas brasileñas, el cual se puede consultar en huggingface.co/datasets/HumynLabs/Brazilian_Bills_and_Invoices_Dataset. Por otro lado, Tech4Humans ofrece el conjunto de datos BR-Doc Extraction, que se puede encontrar en huggingface.co/datasets/tech4humans/br-doc-extraction.
En un estudio realizado por Gabriel Pimenta de Freitas Cardoso y otros, titulado "DharmaOCR: Modelos de Lenguaje Pequeños Especializados para OCR Estructurado que superan las Líneas Base de Código Abierto y Comerciales", se analiza el rendimiento de estos modelos. Este trabajo está disponible como preprint en arXiv bajo el código arXiv:2604.14314 (2026).
Para aquellos interesados en profundizar en el tema, se sugiere leer sobre cómo la especialización del vocabulario de los Modelos de Lenguaje Pequeños (SLMs) puede reducir los costos de inferencia en aplicaciones reales, así como otros estudios que abordan la gestión de GPU y la optimización de preferencias directas más allá de los chatbots.
Los modelos mencionados en este artículo, junto con los conjuntos de datos y espacios referenciados, ofrecen una visión amplia de las capacidades de extracción de datos y el potencial de los sistemas de inteligencia artificial especializados en comparación con los modelos de propósito general.
Fuente original: Hugging Face Blog.
