Un modelo pequeño mejoró 85% en extracción y Microsoft muestra por qué los modelos frontera aún ganan
Con 17 documentos de entrenamiento, un evaluador en Python y 100 pasos de refuerzo, Microsoft subió la F1 de extracción de gpt-oss-20b de 0.44 a 0.81. Los modelos frontera obtuvieron 0.98.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
La cifra principal del experimento de Microsoft del 16 de octubre es una mejora de 85%. La cifra más útil es la que Microsoft puso justo al lado: después del entrenamiento, el modelo pequeño seguía cometiendo varios veces más errores de extracción que los modelos frontera que debía reemplazar. Una publicación de un proveedor que muestra dónde se queda corto su propio enfoque merece una lectura atenta.
El experimento
La tarea es extracción estructurada de documentos como facturas: encontrar los valores correctos, mapearlos a los campos de un JSON Schema, conservar todos los registros repetidos (una factura de validación tenía 37 líneas de detalle) y devolver JSON válido que el siguiente sistema pueda usar. El evaluador compara pares normalizados de campo y valor con la respuesta esperada, y la F1 combina precisión (cuántos pares extraídos son correctos) con exhaustividad (cuántos pares esperados se encontraron).
En la línea base, los dos modelos de pesos abiertos fallaban de formas distintas. gpt-oss-20b rechazó la tarea o usó fórmulas de disculpa en 25% de las respuestas, devolvió JSON analizable 63.8% de las veces y cubrió 47.1% de los campos esperados. gpt-oss-120b produjo JSON válido 96.3% de las veces, pero seguía omitiendo campos: una salida analizable no es una salida completa.
El equipo usó después Foundry Interactive Training, en versión preliminar pública, con 17 documentos de entrenamiento, sus respuestas esperadas y un evaluador en Python. El modelo generó ocho respuestas candidatas por documento, el evaluador dio crédito parcial por los valores correctos y penalizó el JSON inválido, y 100 pasos de optimización de políticas relativas de grupo (GRPO) reforzaron las mejores respuestas. Las respuestas esperadas se usaron solo para la evaluación y nunca se mostraron al modelo.
| F1 antes | F1 después del entrenamiento | Precio por 1M de tokens (entrada / salida) | |
|---|---|---|---|
| gpt-oss-20b | 0.4379 | 0.8115 | $0.07 / $0.30 (con fine-tuning, regional) |
| gpt-oss-120b | 0.6816 | 0.8573 | $0.15 / $0.60 (tarifa base) |
| GPT-6-sol | 0.9764 | Referencia, sin entrenar | $2.00 / $10.00 |
| GPT-5.6-sol | 0.9766 | Referencia, sin entrenar | $4.00 / $20.00 |
| GPT-5.5 | 0.9760 | Referencia, sin entrenar | $5.00 / $30.00 |
Qué mejoró
El modelo 20B pasó de 0.4379 a 0.8115 de F1, la mejora relativa de 85.3% que aparece en el título. El modelo 120B alcanzó la puntuación más alta, 0.8573. Una segunda ejecución de entrenamiento con una semilla distinta quedó en 0.8101, cerca de la primera. El comportamiento cambió tanto como la puntuación: las fórmulas de rechazo cayeron a cero, el JSON válido subió a 98.8% y la cobertura a 94.9%.
Dos advertencias de la propia publicación. La evaluación usó 20 documentos, suficiente para ver una dirección y no para fijar un presupuesto de error. Y los modelos frontera se midieron con un protocolo distinto, así que la comparación es indicativa.
Cómo leer el trade-off
Con precios de entrada de $0.07 frente a $2.00 por millón de tokens, el modelo 20B con fine-tuning es aproximadamente 29 veces más barato por token que la referencia frontera más económica. Con una F1 de 0.81 frente a 0.98, falla o pierde aproximadamente un par de campo y valor de cada cinco, frente a cerca de uno de cada cuarenta. Que ese trade-off sea bueno depende por completo de lo que cueste un error después del modelo: los minutos de un revisor, un pago rechazado, una carta a un cliente con el importe equivocado.
Por eso, “modelo más barato” es el marco equivocado. Un equipo que considere esta ruta debería comparar el costo por documento correcto, incluidos los controles humanos o automatizados que detectan los errores adicionales, no el precio por token. Microsoft señala lo mismo: su tabla de precios “no es un análisis completo del costo total de propiedad”.
También hay rutas intermedias. La validez de JSON casi perfecta del modelo ajustado lo convierte en una primera pasada predecible. Un pipeline puede aceptar los campos que pasan una validación determinista (totales que cuadran, fechas que se interpretan, IDs que existen en los datos maestros) y enviar solo los documentos que fallan a un modelo frontera o a una persona, la lógica de enrutamiento que describimos en gestionar modelos como un portafolio.
El activo reutilizable es el evaluador
La parte más transferible de la receta no es el modelo. Es el evaluador: un fragmento de código que define qué es una extracción correcta para su esquema y asigna crédito parcial. Impulsa el entrenamiento, mide la línea base y sigue midiendo después del despliegue. El propio consejo de Microsoft es medir primero y probar cambios más simples, como prompting, antes de entrenar; después, reservar un conjunto de prueba intacto con fuentes nuevas y diseños de documento distintos para la comprobación final.
En extracción regulada, como reclamaciones, facturas sujetas a auditoría o registros clínicos, el evaluador también se convierte en evidencia: una definición documentada y versionada de “correcto” que un revisor puede inspeccionar. Un equipo que la escribe tiene algo valioso tanto si acaba ajustando un modelo pequeño como si paga por uno grande.