Dharma Field Extractor: JSON exacto con 2B parámetros

Un modelo de 2.000 millones de parámetros que supera a la IA frontera

Dharma-AI presentó en su blog de Hugging Face el Dharma Field Extractor, un modelo de 2.000 millones de parámetros que lee un documento y devuelve los campos que le pidas en JSON tipado. En el benchmark que la propia compañía publicó, el modelo obtuvo 0,834 de field-level F1, por encima de Claude Opus 5 (0,816) y de GPT-5.6 Luna (0,741), y lo hizo corriendo sobre una única GPU Nvidia L40S a US$2,24 por hora.

Para un founder que procesa facturas, formularios o expedientes a volumen, el dato relevante no es el puntaje: es que la brecha de costo frente a las APIs frontera va de 6 veces menos (frente a GPT-5.6 Luna) a 147 veces menos (frente a GPT-5.6 Sol).

¿Qué es el Dharma Field Extractor y en qué se diferencia del OCR?

OCR y extracción de campos resuelven problemas distintos, y confundirlos es una de las causas más comunes de proyectos de automatización que se estancan.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El OCR devuelve el texto de la página, fiel al formato original. Eso es lo correcto cuando el trabajo es el documento completo: un contrato que vas a leer de punta a punta, un manuscrito que estás digitalizando. El Field Extractor parte de otra pregunta: no quieres la página, quieres ciertos campos, con la forma que tu sistema ya usa.

La diferencia práctica se ve en el paso siguiente. Si pasas una factura por OCR, obtienes todo lo impreso, línea por línea, sin ninguna indicación de qué string es el tipo de examen, cuál es la fecha o cuál número es el total. Alguien tiene que escribir igual el código que mapea cada valor a su campo antes de que llegue a la base de datos. El Field Extractor se salta ese paso.

El modelo acepta dos modos de petición:

Abierto: no se envía esquema. El modelo deduce del contexto y el layout qué partes del documento son campos estructurados (una etiqueta seguida de un valor, una tabla con fila de encabezado) y devuelve todo lo que encuentra como pares clave-valor.
Dirigido por esquema: se especifica la forma exacta, campo por campo, con un tipo para cada uno (string, number o boolean) y bajo los nombres de clave que tu sistema ya usa. Si pides service_provider y client_company, esos son exactamente los nombres que vuelven. Si pides un campo que no está en el documento, devuelve null en lugar de inventar un valor.

La regla de decisión es simple: usa el modo abierto cuando no sabes qué contiene el documento; usa el esquema cuando la salida tiene que calzar con una estructura que ya existe en otra parte de tu stack.

Los números del benchmark: ¿de verdad compite con los LLM frontera?

El benchmark cubre 546 documentos en tres escenarios —extraer todos los campos sin esquema, un esquema parcial con campos reales y un esquema que incluye campos deliberadamente inexistentes— para 1.638 casos en total. La métrica es exigente: field-level F1 (con match por path, incluida la posición dentro de una tabla), multiplicada por la similitud de Levenshtein sobre los valores que sí coincidieron y por la proporción de salidas que vuelven como JSON válido.

El resultado: contra los LLM de propósito general, medidos en la misma corrida, la brecha de calidad va de 1,8 puntos (Claude Opus 5, la más cercana) a 9,3 puntos (GPT-5.6 Luna, la más ancha).

En SROIE (recibos) y FUNSD (formularios), dos datasets públicos que la compañía dejó fuera del entrenamiento, el detalle muestra por qué la especialización pesa. En un recibo de SROIE el modelo recuperó los 18 campos impresos, capturó como un único campo la dirección de facturación multilínea y sin etiqueta, devolvió null en los dos campos que venían en blanco y todos los números coincidieron al centavo. En un formulario de FUNSD con doce campos booleanos y un grupo anidado de cinco sub-opciones, marcó como true exactamente la casilla tildada, leyó el identificador Bates manuscrito y devolvió null en los dos campos vacíos.

Conviene un punto de honestidad: es un benchmark autoinformado por el propio fabricante. Eso no lo invalida, pero significa que la validación que realmente importa sigue siendo la tuya, sobre tus documentos.

¿Cómo se entrenó un modelo tan chico para extraer campos?

La base es DharmaOCR-LITE v1.1, una versión de 2.000 millones de parámetros optimizada a partir del modelo del paper original y ya especializada en OCR mediante supervised fine-tuning y DPO. Sobre ese checkpoint, Dharma-AI entrenó un adaptador LoRA con 43.384 ejemplos que cubren los dos modos de petición.

Los datos se organizan en tres corrientes:

Multi-dominio en inglés: documentos diversos recolectados de la web pública, que abarcan muchos tipos de documento.
Dominio brasileño: documentos reales de Brasil en portugués, obtenidos internamente.
Multilingüe: una porción menor en otras lenguas europeas y asiáticas, para generalizar más allá del inglés y el portugués.

Todo está anotado a nivel de campo y la mezcla es deliberadamente heterogénea: recibos, facturas comerciales, formularios, extractos bancarios, identificaciones y documentos sintéticos, en lugar de un único tipo de expediente.

No es la primera vez que la compañía mide esta tesis. Su paper de OCR puso al primer DharmaOCR-LITE, de 3.000 millones de parámetros, por encima de toda API comercial frontera probada en portugués brasileño; tres meses después llegaron modelos más nuevos y mejor financiados, y la ventaja se mantuvo. El paper que documenta el enfoque es DharmaOCR: Specialized Small Language Models for Structured OCR that outperform Open-Source and Commercial Baselines (arXiv:2604.14314, 2026).

¿Cuánto cuesta de verdad extraer campos con un modelo self-hosted?

Acá conviene leer con cuidado, porque la comparación no es precio de lista contra precio de lista. Las cifras de los modelos frontera salen de medir tokens promedio de entrada y salida por página —incluidos los tokens de razonamiento— contra el pricing publicado de cada proveedor, y todas corrieron con el razonamiento en nivel bajo. Del lado de Dharma-AI no hay cobro por token: el modelo corre self-hosted, así que la cifra es tiempo de GPU en una L40S a US$2,24 por hora.

La propia compañía aclara que no es un precio de venta: el costo real depende del hardware, del volumen y de la latencia que necesite cada despliegue.

El contexto de industria respalda la dirección. Según MarketsandMarkets, citado por Yahoo Finance, el mercado de Document AI pasaría de US$14.660 millones en 2025 a US$27.620 millones en 2030, con un CAGR de 13,5%. Y un análisis publicado en Forbes Technology Council cita a Nvidia estimando que servir un SLM de 7.000 millones de parámetros cuesta entre 10 y 30 veces menos que operar un modelo en el rango de 70.000 a 175.000 millones. En la misma línea, InfoWorld recoge una proyección de Gartner: para 2027, el uso empresarial de modelos chicos y especializados por tarea será alrededor de tres veces mayor que el de los LLM.

Qué significa esto para tu startup

1. Calcula tu costo por documento antes de firmar otra API frontera. El error típico es mirar el precio por millón de tokens y no el consumo real por página. Los tokens de razonamiento pueden pesar tanto como los de salida, y en documentos densos —un extracto bancario, una factura con veinte ítems— el conteo se dispara. Antes de escalar, mide cuántos tokens por página consume tu caso y multiplícalo por tu volumen mensual.

2. Separa tu volumen repetitivo del resto. InfoWorld recoge la regla de tres criterios que plantea Thomas Randall, de Info-Tech Research Group: los modelos chicos rinden cuando la tarea es acotada en alcance, repetitiva y de alto volumen, y la latencia tolerada es baja. Si tu backlog son facturas de proveedores que llegan cada mañana y solo necesitas cuatro campos de cada una, ese es exactamente el perfil.

3. Define tu esquema antes de elegir herramienta. El modo dirigido por esquema funciona como un contrato de datos: los nombres de clave que pidas son los que vuelven, sin campos extra, y un campo ausente llega como null en lugar de un valor inventado. Diseñar ese contrato primero —con los nombres que ya usa tu base de datos— te ahorra la capa de mapeo que hoy escribes a mano.

4. Diseña una arquitectura híbrida, no una sustitución. Randall lo describe como una arquitectura de ruteo: las consultas simples o bien delimitadas van a un modelo chico especializado y las complejas a un modelo grande. Hay evidencia de que el cambio puede ser quirúrgico: AdExchanger reportó que la empresa Dappier redujo sus gastos generales un 50% tras adoptar SLM de ZeroGPU, y que la migración tomó unos cinco minutos porque los modelos exponían endpoints compatibles con OpenAI.

5. Conoce los límites antes de delegar. InfoWorld advierte que los SLM se degradan en tareas que exigen conciencia de contexto o razonamiento de varios pasos en dominios desconocidos, y que pueden fallar en casos borde. La consecuencia práctica es clara: no pongas al modelo chico a interpretar un contrato, ponlo a extraer los campos del contrato.

Conclusión

El mensaje de fondo de Dharma-AI no es que los modelos grandes estén de más, sino que la cuenta de parámetros fija el techo y el entrenamiento decide cuánto de ese techo alcanza el modelo en tu tarea. Su apuesta es explícita: un modelo chico entrenado cerca del problema le gana a un modelo frontera al que le pides lo mismo en general.

Para un equipo hispanohablante con presupuesto acotado, la lectura útil es doble. Primero, el caso económico de mover los flujos de documentos repetitivos a un modelo especializado —y potencialmente self-hosted— es cada vez más difícil de ignorar. Segundo, y más importante, el activo que necesitas construir no es el modelo: es la anotación a nivel de campo de tus documentos. Eso es lo que nadie más tiene y lo que convierte a un modelo genérico en una herramienta que sirve para tu operación.