The Trinity mejoró la capa de control de un agente de IA y sumó 9,8 puntos en tareas nuevas

El agente entra por segunda vez en una habitación que ya ha revisado, olvida una restricción y gasta el presupuesto restante en llamadas inútiles. La tentación inmediata es pagar por un modelo más potente. Pero antes conviene revisar el código que lo rodea: qué se guarda en la memoria, qué observaciones se incluyen en el prompt y qué decide cuándo detenerse. The Trinity investiga cómo mejorar automáticamente esa capa.

Según los resultados recogidos en el material, los módulos de la primera iteración elevaron la puntuación media en tareas nuevas de 37,45 a 47,26: unos 9,8 puntos. Es un resultado útil sin modificar los pesos del modelo. La mejora más espectacular de 26,2 puntos también aparece en las tablas, pero incluye condiciones adicionales que cambian sustancialmente el sentido de la comparación.

El agente escribe sus propias instrucciones de trabajo

La capa de control es el código que convierte un modelo en un agente capaz de actuar. Prepara las observaciones, guarda el historial, organiza las llamadas a herramientas, comprueba las restricciones y gestiona los reintentos. Incluso un buen modelo tendrá dificultades si ese código pierde una parte importante del estado una y otra vez.

Imaginemos un laberinto con puertas: se puede avanzar, pero ya no es posible volver por el mismo camino. Al agente no le basta con encontrar una ruta corta. Necesita recordar dónde están las puertas y comprobar de antemano el camino de vuelta. En The Trinity, un error de este tipo sirve de motivo para añadir el módulo correspondiente a la capa de control.

El sistema reparte el trabajo entre tres roles que desempeña un mismo modelo congelado. Evolver analiza los errores y propone cambios. Creator genera entornos de entrenamiento simplificados. Explorer los recorre y recopila trayectorias: secuencias de observaciones, decisiones y resultados. Un programa anfitrión independiente valida los entornos y los cambios propuestos.

Las tareas se agrupan según las capacidades que requieren. Un laberinto y un rompecabezas visual pueden acabar en el mismo grupo si ambos exigen interpretar con precisión las observaciones y recordar el estado. Para esos grupos, el sistema crea pequeños mundos en los que resulta más fácil reproducir y analizar el error pertinente que en un juego completo y largo.

Por qué la mejora de 26 puntos necesita una explicación

Tras cuatro iteraciones, la puntuación media en 18 benchmarks nuevos pasó de 37,45 a 63,61 puntos. Sin embargo, la estimación más alta utiliza una selección ideal de la capa de control: cada tarea recibe la mejor variante. El enrutador real, que debe elegir de antemano a partir de la descripción disponible, obtuvo 60,96 puntos.

También hay una preparación previa a la evaluación. Cada variante de la capa de control dispone de cinco intentos en el benchmark correspondiente; después, esa experiencia se condensa en habilidades almacenadas. Los episodios preparatorios no cuentan para la puntuación final. Por tanto, el resultado no puede interpretarse como la resolución de tareas completamente desconocidas al primer intento.

La comparación de la primera iteración ayuda a separar los efectos. Los módulos aprendidos, por sí solos, aportan unos 9,8 puntos sobre la base; las habilidades preparadas, por sí solas, unos 11,2. Juntos aportan unos 16,1. El autor del análisis no encontró una comparación equivalente sin preparación para la cuarta iteración.

Los dos robots físicos de la nueva sección también requieren una salvedad: los módulos se entrenaron en versiones simuladas de esas mismas tareas. Lo que se comprueba aquí es la transferencia del simulador al hardware. Y el resultado del 60% equivale a seis episodios satisfactorios de diez: la escala del experimento sigue siendo pequeña.

Qué aplicar en tu propio producto

La comparación más interesante tiene que ver con los entornos de entrenamiento. Al entrenar directamente en los benchmarks, el árbol de capacidades apenas mejoró el rendimiento frente a una única capa de control compartida, pero necesitó aproximadamente tres veces menos tokens. El paso a simulaciones creadas por el propio sistema sumó casi cinco puntos en tareas nuevas, aunque aumentó el coste de entrenamiento.

Para un equipo, esto invita a empezar por un registro de fallos recurrentes. Si el agente olvida habitualmente las condiciones para regresar, crea un entorno pequeño con esas condiciones. Si incumple las restricciones de una herramienta, diseña tareas breves y verificables centradas en ese fallo. Después, compara la capa de control modificada con la original en escenarios reservados para evaluación y con el mismo presupuesto.

The Trinity plantea una hipótesis práctica: algunas limitaciones de los agentes pueden corregirse mediante memoria, comprobaciones y tareas de entrenamiento. Pero conviene desglosar la mejora anunciada: cuánto aportaron los propios módulos, cuánto los intentos previos y con qué acierto selecciona el sistema la capa de control adecuada en una ejecución real.