Cuando la calificación de bases de datos se convierte en recompensa RL: ThinkingBox para agentes post-entrenamiento

Resumen

ThinkingBox nació para atrapar a agentes que anuncian haber terminado cuando en realidad dejan registros inconsistentes en la base de datos. Lo que empezó como un sistema de evaluación —un conjunto de 507 tareas que arranca backends reales, ofrece herramientas y luego verifica el estado final de la base de datos— se convirtió también en una fuente de recompensas para entrenamiento por refuerzo. Al usar esas verificaciones ejecutables como señal de recompensa, los autores lograron aumentar la confiabilidad repetible de Qwen3.8-27B tras 50 pasos de GRPO.

¿Qué es ThinkingBox y por qué importa?

ThinkingBox-Bench es un benchmark que valida agentes observando directamente los cambios que dejaron en backends reales. Cada tarea arranca un backend, proporciona herramientas MCP y un usuario simulado con contexto privado, y al final ejecuta checks que consultan el estado terminal de la base de datos para decidir si la tarea se resolvió correctamente. Es una evaluación orientada a efectos reales sobre datos —no a si el agente hizo llamadas específicas— lo que favorece soluciones efectivas sobre imitaciones de pasos humanos.

Para organizaciones y proyectos en América Latina, donde muchos sistemas críticos (banca, telecomunicaciones, atención pública) dependen de integridad transaccional, este enfoque es especialmente relevante: no basta que un agente parezca correcto en lenguaje; debe dejar registros consistentes en producción.

De calificador a función de recompensa

Los desarrolladores de ThinkingBox observaron que muchas verificaciones ejecutables son binarias: el estado final de la base de datos cumple o no cumple la condición esperada (1 o 0). Esa salida binaria puede servir no solo como grader sino como una función de recompensa para entrenar agentes. A partir de tareas en formato ThinkingBox pero fuera del benchmark principal, construyeron una piscina de entrenamiento cuyos resultados ejecutables alimentan un bucle de RL.

El desafío clave: seleccionar tareas útiles para el entrenamiento. Muchas tareas resultan triviales para el modelo actual o, por el contrario, imposibles: ambas categorías aportan poco aprendizaje. Por eso introdujeron la noción de dificultad relativa a la política offline: una estimación de la probabilidad de éxito de cada tarea usando la política base antes de entrenar. Con ese puntaje, fijaron una piscina de entrenamiento y la mantuvieron estática durante el afinamiento.

Cómo entrenaron y qué métricas usaron

Afinaron Qwen3.8-27B con GRPO durante 50 pasos sobre la piscina seleccionada. Para evaluar, ejecutaron las 507 tareas del benchmark 20 veces cada una. Las métricas fueron:

• pass@1: proporción de intentos individuales exitosos (sobre 10,140 intentos en total).
• pass@20: porcentaje de tareas resueltas al menos una vez en las 20 repeticiones.
• Observed 20/20: porcentaje de tareas que pasan en las 20 ejecuciones, es decir, éxito consistente en todas las repeticiones.

Resultados para Qwen3.8-27B (antes → después de 50 pasos de GRPO):

• Observed 20/20: 38 (7.50%) → 107 (21.10%) — +69 tareas con éxito repetible.
• pass@1 (intentos exitosos): 5,242 (51.70%) → 6,163 (60.78%) — +9.08 puntos porcentuales.
• pass@20 (tareas resueltas al menos una vez): 453 (89.35%) → 446 (87.97%) — −7 tareas.

En resumen: el entrenamiento aumentó netamente la capacidad del agente para reproducir soluciones correctas en forma consistente, a costa de una pequeña caída en la cobertura “al menos una vez”. Eso refleja un trade-off entre dependabilidad (hacerlo bien siempre) y amplitud de soluciones posibles.

Un ejemplo concreto: la reserva hotelera

En una tarea de reserva corporativa, un viajero pide una baja de categoría, pero la política exige aprobación de un gerente. Antes del RL fine-tuning, el agente modificó la reserva y procesó reembolsos sin la aprobación en 15 de 20 intentos. Tras el afinamiento con recompensas ejecutables, el agente preservó el estado de reserva y pago en las 20 ejecuciones; además, en 19 de esas ejecuciones todos los registros esperados coincidieron exactamente con el resultado correcto. Es un ejemplo claro de cómo la señal binaria desde la base de datos puede enseñar al modelo a respetar reglas de proceso.

Dónde se ubicaron las mejoras y qué implican para producción

Las mejoras más notables fueron en la columna de dependabilidad: el indicador Observed 20/20 casi se triplicó. Para aplicaciones en producción eso es crucial: un modelo que a veces funciona y a veces no puede causar errores en transacciones, incumplimientos de políticas o daños reputacionales.

La ligera reducción en pass@20 sugiere que algunas soluciones poco confiables que antes se resolvían ocasionalmente desaparecieron, mientras que las soluciones robustas aumentaron. Dependiendo del caso de uso, esa compensación puede ser deseable: en sistemas financieros o administrativos, preferimos consistencia incluso si se pierde alguna solución marginal.

El bucle de entrenamiento y la selección de tareas

El flujo fue:

1. Evaluar cada tarea con la política base para estimar la probabilidad de éxito (dificultad offline relativa a la política).
2. Seleccionar una piscina de entrenamiento fija con tareas de dificultad intermedia (ni triviales ni imposibles).
3. Afinar el modelo mediante GRPO usando como recompensa la verificación ejecutable del estado final de la base de datos (1/0).
4. Evaluar en el benchmark de 507 tareas no vistas (fuera de la piscina) para medir generalización.

Este diseño busca enseñar al agente a producir estados de base de datos correctos, no a replicar una secuencia específica de llamadas.

Cómo acceder y ejecutar el stack

Los autores informan que ThinkingBox-Training está disponible en GitHub. La implementación incluye componentes para ejecutar tareas en backends simulados, calcular recompensas ejecutables y el loop de RL. Para equipos latinoamericanos interesados en adoptar o evaluar este enfoque, el repositorio puede servir como punto de partida para pruebas controladas sobre sus propios esquemas de datos y reglas de negocio.

Límites, precauciones y próximos pasos

• La señal usada es binaria y depende de checks bien definidos: requiere que los criterios de éxito estén formalizados como consultas o aserciones de base de datos.
• La piscina de entrenamiento se fijó offline; tareas que cambian su dificultad con el aprendizaje podrían necesitar estrategias dinámicas.
• El estudio muestra ganancia en consistencia tras 50 pasos de GRPO, pero no explora escalas extensas de pasos o variantes de recompensa más ricas.

Los avances apuntan a integrar verificaciones ejecutables directamente en bucles de aprendizaje, una dirección prometedora para mejorar la seguridad y la fiabilidad de agentes que interactúan con sistemas productivos.

Conclusión

ThinkingBox transforma el problema de evaluar agentes sobre efectos reales en una oportunidad de entrenamiento: las comprobaciones ejecutables del estado final de la base de datos se convierten en recompensas que fomentan soluciones repetibles y correctas. Para organizaciones que despliegan agentes en producción —y en particular para sectores críticos en América Latina— esta técnica ofrece un camino pragmático para priorizar la integridad de datos y la consistencia operativa. El código está disponible en GitHub para quienes quieran experimentar y adaptar el enfoque a sus propias bases y políticas.

Agradecimientos (por los autores del trabajo original): entrada conjunta de Microsoft y Hugging Face, con contribuciones y revisiones de Mirco Milletari y Xiang Jiang (Microsoft), Sergio Paniego (Hugging Face) y Zhuochun Li (University of Pittsburgh).