¿Qué modelo de IA convierte documentos en datos estructurados?

Por qué la extracción es el workload donde los modelos fallan más en silencio

La extracción es el workload donde los errores se esconden más tiempo. La salida parece datos — campos, tipos, valores limpios — y los sistemas downstream la consumen como si la hubiera generado un parser determinista. Cuando el modelo rellena un campo faltante con una estimación plausible, ningún log lo señala. El número aparece en un informe trimestral y alguien toma una decisión sobre él.

Eso cambia los criterios de selección. La adherencia al esquema y negarse a inventar pesan más que la inteligencia bruta. Un modelo que devuelve un campo vacío con un marcador null es más útil que uno que devuelve una estimación de aspecto convincente. Un modelo que respeta literalmente la estructura JSON que describiste vale más que uno que añade un preámbulo amable. Algunos de los modelos frontier más capaces puntúan mal en estos ejes: fueron entrenados para ser útiles, y inventar un valor para un campo faltante se interpreta como ayuda a menos que lo midas explícitamente.

El trabajo también es inusualmente sensible al precio. Un pipeline que procesa un millón de facturas al mes tiene un modelo que lee mucho y escribe poco. Cada token innecesario en el prompt del sistema o en las cadenas de razonamiento cuesta dinero real. Los modelos que producen salidas estructuradas concisas y limpias recuperan su posición solo por precio.

Cinco restricciones definen el trabajo: adherencia estricta al esquema, economía de throughput masivo, contexto de documentos largos, robustez con entrada ruidosa y cobertura multilingüe. El modelo adecuado para procesar en lotes recibos en veinte monedas raramente es el adecuado para analizar un contrato de cincuenta páginas con cinco tablas superpuestas. El stack normalmente necesita los dos.

Una restricción más descansa bajo las otras cinco y es fácil olvidar en la fase de diseño: la observabilidad. Un pipeline de extracción que no puedes auditar es un pipeline en el que no puedes confiar. Cada salida debe ser trazable hasta el fragmento de entrada del que proviene, cada puntuación de confianza debe registrarse, y cada negativa a extraer debe quedar anotada para que la siguiente iteración pueda decidir si el modelo tenía razón al callarse o se equivocó al rendirse. Esa telemetría vale más que cualquier actualización de modelo.

Las cinco dimensiones que deciden qué modelo gana

Estos son los ejes con los que nuestra scorecard evalúa cualquier modelo que se despliega cerca de un pipeline de extracción. La ponderación relativa varía según proceses pocos documentos de alto valor o millones de bajo valor — pero el mínimo en los cinco no es negociable.

1. 01 — Adherencia al esquema

   ¿La salida coincide con la estructura que especificaste?

   El mejor predictor de idoneidad para la extracción es la frecuencia con la que el modelo devuelve JSON válido y conforme al esquema sin prosa circundante, campos extra o claves renombradas. Los modos de salida estructurada estrictos de los proveedores que los soportan resuelven este problema; los modelos sin esos modos necesitan un bucle de reintento y un validador.

2. 02 — Negarse a inventar

   ¿Deja un campo vacío cuando la fuente calla?

   Una fecha de factura faltante que recibe un valor inventado es un bug silencioso que sale a la superficie en la siguiente auditoría. Prueba a los candidatos explícitamente en documentos donde faltan campos obligatorios: el modelo correcto devuelve null, el incorrecto devuelve su mejor estimación y nunca te lo dice.

3. 03 — Contexto de documento largo

   ¿Puede extraer datos de la página cuarenta sin perder la página dos?

   Los contratos, prospectos, historiales médicos y documentos legales superan habitualmente las cien páginas con referencias cruzadas que abarcan todo el documento. El modelo necesita tanto el tamaño de ventana como atención profunda a lo largo de ella; lo primero sin lo segundo es marketing.

4. 04 — Robustez con entrada ruidosa

   ¿Se recupera bien de errores OCR y layouts rotos?

   La extracción en el mundo real nunca ve texto limpio. La entrada es salida OCR de un recibo escaneado con una mancha en la fecha, o HTML de un sitio con tres layouts de tabla distintos en la misma página. El modelo tiene que tolerar ese ruido y aún así producir salida limpia sin sobrecorregir.

5. 05 — Cobertura multilingüe

   ¿Extrae de facturas japonesas igual de bien que de las inglesas?

   Un modelo de extracción desplegado a escala acabará viendo cada escritura y convención que usan sus clientes. Los modelos frontier anuncian amplia cobertura; la calidad fuera de los seis idiomas principales varía mucho. Los formatos de fecha, separadores decimales y convenciones de dirección requieren pruebas empíricas.

Top 5 de Tokonomix para extracción de datos hoy

Esto es lo que dirigiríamos a tráfico real de producción mañana por la mañana. La extracción a cualquier escala significativa casi siempre implica un pipeline de dos niveles: un modelo de masa que hace el noventa por ciento bien formado a coste casi cero, y un modelo más pesado al que el modelo de masa deriva documentos cuando su propia confianza cae. Elegir los dos de la lista es más útil que elegir uno perfectamente.

Precio de entrada por millón de tokens

La extracción es el workload raro donde los costes de entrada dominan, no los de salida: todo el documento se lee, la respuesta es JSON compacto. El gráfico muestra el precio de lista actual en entrada para cada uno de los cinco modelos.

Guía de campo: qué modelo para qué trabajo de extracción

La correspondencia que sigue es la que usaríamos para aconsejar a un equipo de operaciones que empieza de cero. Trátala como punto de partida, no como veredicto: un benchmark en cien de tus propios documentos superará cualquier recomendación general.

Haz benchmark en tus propios documentos antes de comprometerte

Toma cincuenta documentos reales de tu backlog y etiquétalos a mano. Es un trabajo poco glamuroso; se paga solo la primera vez que el pipeline de producción se despliega y quieres saber si el modelo es mejor que la regex que reemplazó. Pasa a todos los candidatos por los mismos cincuenta y mide precisión y recall contra tu verdad de referencia.

Luego mira los fallos, no los promedios. ¿Dónde inventó cada modelo un campo? ¿Dónde dejó uno en blanco que debería estar rellenado? ¿Cómo gestionó cada uno la página escaneada, el documento en otro idioma, la tabla girada? El modelo que sobrevive a tu análisis de fallos es el que sobrevive a producción. Despliega ese, independientemente de lo que recomiende esta guía.