ThinkingBox: Microsoft convierte la base de datos en premio

Qwen3.8-27B pasó de completar 38 tareas de base de datos de forma consistente a completar 107, casi el triple, después de 50 pasos de entrenamiento por refuerzo. La señal que usó para aprender no fue la opinión de un modelo juez: fue el estado final de la base de datos, verificado de forma ejecutable por ThinkingBox, la herramienta que Microsoft y Hugging Face ahora publicaron como stack de entrenamiento en GitHub.

Para un founder que está a punto de conectar un agente a la base de datos de producción, la lectura incómoda es esta: la métrica que casi todos reportan, el éxito promedio, no dice nada sobre si el agente va a repetir el acierto mañana.

¿Qué es ThinkingBox y por qué ahora también entrena agentes?

ThinkingBox nació como un banco de pruebas para detectar agentes que reportan éxito cuando la base de datos dice otra cosa. ThinkingBox-Bench tiene 507 tareas. Cada una levanta un backend real, le entrega al agente un conjunto de herramientas MCP y un usuario simulado con contexto privado, lo deja trabajar y al final corre verificaciones ejecutables contra el estado terminal de la base de datos.

La decisión de diseño clave: las verificaciones se hacen contra el registro que debe quedar correcto, no contra las llamadas a herramientas que hizo el agente. Eso empuja al modelo a descubrir caminos de solución nuevos en lugar de imitar la secuencia que resolvió el caso original.

En el primer post del proyecto, el caso testigo fue un agente que cerró el ticket de un cliente como resuelto mientras la excepción del transportista seguía abierta: nueve llamadas a herramientas que parecían competentes y una fila equivocada en la base de datos.

El insight que desbloqueó el entrenamiento fue simple. Para la mayoría de las tareas, un chequeo ejecutable puede devolver 1 o 0 directamente desde el estado final. Eso no es solo un corrector: es una función de recompensa. Así construyeron un pool de tareas con formato ThinkingBox fuera del benchmark y usaron sus resultados ejecutables como señal de entrenamiento.

La métrica que casi nadie reporta: observed 20/20

El benchmark se evalúa con 20 intentos por tarea, 10.140 intentos en total. Ahí conviven tres métricas que ordenan a los modelos de forma distinta:

• pass@1: éxito promedio sobre todos los intentos.
• pass@20: proporción de tareas resueltas al menos una vez.
• observed 20/20: proporción de tareas que pasan todos los intentos registrados.

El caso de Kimi-K3 muestra la trampa: resolvió el 93,89% de las tareas al menos una vez, pero completó solo 68 de 507 (13,41%) en los veinte intentos. Claude Opus 5.5 invirtió la relación: cobertura más angosta y mucha más consistencia.

Y un modelo mejor no cierra la brecha por sí solo. Claude Opus 5.5 sacó 0,66 puntos porcentuales más que Claude Opus 5 en pass@1, pero pasó exactamente la misma cantidad de tareas, 241, en los veinte intentos. Ese aumento de precisión no compró nada de confiabilidad adicional.

El ranking de observed 20/20 queda así: Claude Opus 5.5 con 241 (47,53%), GPT-6 Astra con 231 (45,56%), GPT-5.4 con 128 (25,25%), el Qwen3.8-27B ajustado con 107 (21,10%), Claude Sonnet 4.6 con 102 (20,12%), GPT-5.6 Sol con 82 (16,17%), Kimi-K3 con 68 (13,41%) y el Qwen3.8-27B base con 38 (7,50%).

¿Cómo se eligen las tareas que enseñan algo?

GRPO tiene un problema aritmético. Si los ocho rollouts de un grupo fallan, el vector de recompensa es [0,0,0,0,0,0,0,0]. Si los ocho aciertan, es [1,1,1,1,1,1,1,1]. En ambos casos, centrar dentro del grupo no produce ventaja: ninguna trayectoria lo hizo mejor que otra. Solo un grupo mixto como [0,0,0,1,1,1,1,1] da contraste para aprender.

Y ese contraste es caro: cada rollout levanta un backend aislado, corre una sesión de herramientas real y llama a otro modelo para hacer de usuario simulado.

Por eso el equipo no eligió solo modelo y optimizador, sino qué tareas entran al pool. La regla, en lenguaje llano: las tareas que el modelo siempre falla probablemente todavía no le enseñan nada; las que siempre acierta ya están aprendidas; las que resuelve a veces son las que aportan contraste.

El método es una dificultad relativa a la política, estimada offline. Cada tarea candidata se corre n veces contra el modelo base y su probabilidad latente de éxito se modela con una posterior de Jeffreys, Beta(k + ½, n − k + ½). El intervalo se parte en cinco bandas con cortes en 0,08, 0,40, 0,60 y 0,90: las que casi nunca se resuelven se descartan, las que casi siempre se resuelven también, y las difíciles, intermedias y frecuentes se conservan.

Un ejemplo del post: una tarea donde la política base acertó 3 de 8 sondeos produjo una posterior Beta(3.5, 5.5), con el 54,0% de su masa en la banda de dificultad alta. Al muestrearla para entrenamiento generó el grupo mixto [0,0,0,0,1,1,1,1].

El pool final para Qwen3.8-27B quedó en 187 tareas. El entrenamiento corrió con GRPO de media de tokens, 18 grupos de 8 rollouts (144 episodios) sobre 24 H100, AdamW con learning rate 1e-6 y sin weight decay, durante 50 pasos. Los grupos de varianza cero se reemplazaron al estilo DAPO.

El resultado en una tarea concreta

Un viajero pide bajar de categoría su habitación, pero la política de la empresa exige aprobación del manager primero. Antes del entrenamiento, el agente cambiaba la reserva y emitía reembolsos sin aprobación en 15 de 20 intentos. Después del ajuste, preservó el estado de la reserva y del pago en los 20; todos los registros esperados coincidieron en 19.

El tradeoff también está documentado: pass@20 bajó de 453 (89,35%) a 446 (87,97%), siete tareas menos. La lectura del equipo es agudización: la distribución se movió hacia trayectorias que funcionan de forma repetible y algunos caminos de baja probabilidad desaparecieron. El modelo no se volvió más amplio, se volvió más repetible.

Pass@1 y observed 20/20 subieron en los cinco dominios evaluados (retail, seguros de auto, viajes, neobank y consultoría), mientras pass@20 fue mixto: subió en neobank y consultoría y cayó en retail, viajes y seguros de auto. Seguros de auto tuvo la mayor pérdida de amplitud (−7,0 puntos) y retail la mayor ganancia en observed 20/20 (+24,5 puntos).

¿Cuánto cuesta un agente en el que puedes confiar?

El post traduce la fiabilidad a dinero con una fórmula simple: costo por tarea confiable = costo estimado de la campaña de 507 × 20 intentos ÷ tareas que pasan 20/20.

Con el checkpoint ajustado, el costo de la campaña bajó de US$925,80 a US$855,58 (−7,6%), el costo por intento exitoso cayó de US$0,177 a US$0,139 (−21,4%) y el costo por tarea confiable se derrumbó de US$24,36 a US$8,00 (−67,2%), con 2,8 veces más tareas confiables.

A US$8,00 por tarea confiable, el modelo ajustado quedó cerca de GPT-5.4 (US$6,80), GPT-6 Astra (US$7,45) y Claude Opus 5.5 (US$7,80). El propio equipo aclara que esos dólares son un índice comparativo de serving, no facturas: incluyen el costo de inferencia y excluyen el del entrenamiento y el del sondeo de política.

¿Qué significa esto para tu startup?

Si estás construyendo agentes que tocan registros reales —facturación, tickets, reservas, conciliación—, el trabajo deja tres prácticas que puedes copiar esta semana:

• Sondea antes de entrenar. Toma tu propio set de tareas, corre la política base n veces y mira el histograma por bandas. El equipo señala que los equipos casi nunca inspeccionan esa distribución y que suele estar más desbalanceada de lo esperado.
• Verifica la paridad entre entrenamiento y evaluación. Reproduce la misma salida grabada del modelo por los parsers de entrenamiento y de evaluación, y confirma que ambos extraen los mismos nombres y argumentos de herramientas. Si no coinciden, el entrenamiento premia un comportamiento que la evaluación interpreta distinto.
• Reporta cobertura y repetibilidad juntas. Di cuántas tareas pasan al menos una vez en k intentos y cuántas pasan las k. Un modelo que encuentra la solución ocasionalmente no es lo mismo que uno que la repite.

A eso se suma una advertencia que publicó Forbes Technology Council: hasta el 95% de los programas de IA empresariales no entregan valor medible, y la causa raíz, según ese análisis, está en cómo se construyen los sistemas, no en las alucinaciones. Su recomendación es construir el sistema de evaluación antes que el agente, con 500 a 1.000 ejemplos reales y una rúbrica revisada por expertos. ThinkingBox es, en el fondo, esa misma idea llevada al extremo: la verificación no solo mide, también entrena.

Conclusión

Lo valioso de este trabajo no es un checkpoint de Qwen3.8-27B. Es el bucle completo: convertir resultados ejecutables en recompensas y curar el dataset para que cada rollout enseñe algo. El código es MIT, los datos del benchmark son CDLA-Permissive-2.0 y los tres repositorios (microsoft/thinkingbox, microsoft/thinkingbox-data y microsoft/thinkingbox-training) están abiertos, con una configuración de referencia de 3 nodos × 8 H100 y un paper en arXiv:2608.19741.

Para un equipo pequeño, la parte accionable no requiere 24 H100. Requiere decidir qué significa terminado en tu base de datos y medirlo 20 veces, no una.

Fuentes

• Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox (fuente original)
• Evals, And How They Help Build Good AI Agents For Enterprises

Artículos relacionados:

OpenAI vs Hugging Face: el incidente de RLVR que revela riesgos en IA Castform + Neon: modelo 4B iguala GPT-5.6 Sol 100x más barato ThinkingBox: 67% de fallos de agentes pasan desapercibidos ServiceNow genera datos sintéticos para entrenar agentes IA ThinkingBox-Bench: 80% de los fallos en agentes son de tools