Investigadores de Google proponen RRSI para evitar que los agentes de IA que se automejoran memoricen las pruebas

Investigadores de Google han propuesto un método para mejorar agentes de IA sin permitir que se sobreajusten a las tareas utilizadas para optimizarlos. Denominado Regularized Recursive Self-Improvement of Agent Harnesses, o RRSI, el enfoque aborda un problema que se vuelve más grave a medida que los sistemas reescriben automáticamente sus propios prompts, flujos de trabajo, herramientas y lógica de memoria.

Según un artículo de investigación descrito por The Decoder, RRSI mejoró los resultados en benchmarks no vistos anteriormente hasta en 4,7 puntos y utilizó aproximadamente un 30 % menos de tokens en tiempo de ejecución que un enfoque de optimización no regularizado. Las mejoras comunicadas proceden de cambiar el harness del agente alrededor de un modelo congelado, en lugar de actualizar los pesos del modelo.

Por qué los harnesses de agentes se convierten en el objetivo

Muchos agentes de IA de producción consisten en un modelo de lenguaje fijo rodeado por un harness de agente: los prompts, las llamadas a herramientas, las reglas del flujo de trabajo, los sistemas de memoria, el comportamiento de recuperación y el tratamiento de las salidas determinan cómo opera el modelo. El harness puede decidir si un agente comprueba un archivo antes de editarlo, vuelve a intentarlo después de un error o estructura su respuesta final.

Investigadores de Google Cloud AI Research y colaboradores universitarios estudian formas de automatizar mejoras en esa capa. En un ciclo típico de automejora recursiva, un modelo de lenguaje propone cambios al harness, los evalúa frente a un conjunto de tareas y utiliza los resultados para generar cambios adicionales.

El riesgo es que una optimización repetida sobre una pequeña colección de pruebas haga que un agente sea mejor en esas pruebas exactas sin volverlo más capaz en general. El sistema puede aprender patrones específicos del benchmark, seleccionar cambios que funcionan por casualidad o acumular complejidad innecesaria que eleva la puntuación medida mientras aumenta el coste y la fragilidad.

El problema importa porque los agentes de IA suelen evaluarse con conjuntos de tareas limitados, mientras que sus entornos de despliegue previstos son mucho menos predecibles. Un harness que funciona bien con flujos conocidos puede fallar cuando cambian las estructuras de archivos, las instrucciones, las herramientas o los objetivos del usuario.

Cómo limita RRSI el sobreajuste

RRSI aplica controles en dos puntos del proceso de optimización. Al generar revisiones candidatas, limita cuántas ediciones independientes pueden agruparse en una propuesta. El número permitido de ediciones disminuye con el tiempo, desplazando el proceso desde rediseños amplios hacia modificaciones más específicas.

El sistema también registra intentos anteriores, lo que le ayuda a evitar explorar repetidamente cambios que ya han fallado. Cuando el progreso se detiene, dirige la experimentación hacia partes del harness que aún no han sido examinadas.

Un crítico independiente evalúa los cambios propuestos antes de que se vuelvan permanentes. Rechaza revisiones que parezcan codificar de forma rígida nombres de tareas, soluciones u otro comportamiento específico del benchmark. RRSI también exige un beneficio de rendimiento observable antes de aceptar cambios que aumenten el coste computacional, y elimina componentes que ya no contribuyen.

En conjunto, esas reglas pretenden favorecer mejoras más pequeñas y explicables que se transfieran a nuevas tareas, en lugar de cambios agresivos que maximicen una puntuación de prueba limitada. El método mantiene el harness editable, pero establece límites sobre la velocidad y libertad con que puede reescribirse.

Qué muestran los resultados comunicados

Los investigadores probaron RRSI en ocho benchmarks que abarcan programación, trabajo de agentes orientado a oficinas y diseño de ingeniería. El modelo subyacente, identificado en el informe como Claude Opus 4.8, permaneció congelado. La comparación incluyó un harness de referencia sin modificar y otros cuatro métodos de optimización.

Los resultados comunicados muestran una compensación. RRSI produjo mejoras de hasta 14,1 puntos en las tareas utilizadas durante la optimización, pero el resultado más significativo fue su rendimiento en cinco benchmarks no vistos, donde la mejora máxima alcanzó 4,7 puntos. Según el artículo difundido por The Decoder, el harness de RRSI no quedó por debajo de la referencia en ninguna de esas evaluaciones no vistas.

Según los informes, otros enfoques rindieron bien en sus tareas de entrenamiento, pero se transfirieron con menor eficacia. Dos métodos quedaron por debajo de la referencia en tareas nuevas. RRSI ofreció la menor mejora en el conjunto de entrenamiento entre las variantes probadas, algo que los investigadores interpretan como evidencia de que sacrificaba la especialización en benchmarks para lograr una generalización más amplia.

El resultado relativo a los tokens también es relevante para los equipos que operan agentes a escala. El sistema RRSI optimizado utilizó aproximadamente un 30 % menos de tokens que la versión no regularizada y requirió menos pasos entre los harnesses optimizados. Sin embargo, la referencia original siguió siendo más económica, por lo que la regularización no hizo que todo el sistema fuera más barato que todas las alternativas.

Se trata de resultados de investigación, no de benchmarks de producción independientes. Las cifras de rendimiento son afirmaciones de la evaluación de los investigadores, y las pruebas disponibles no establecen cómo se comportaría el método con distribuciones de tareas mayores, modelos diferentes o cargas de trabajo empresariales reales.

Implicaciones para desarrolladores y compradores de IA

Para los desarrolladores, el trabajo sugiere que mejorar un agente debe implicar algo más que maximizar un benchmark de desarrollo. Los conjuntos de evaluación deben incluir tareas que el proceso de optimización nunca vea; de lo contrario, un sistema que se automejora puede recompensarse por aprender la prueba en lugar de mejorar su flujo de trabajo subyacente.

El diseño de RRSI también apunta a controles operativos para la automejora recursiva. Los equipos podrían limitar el número de cambios simultáneos, mantener un historial de experimentos fallidos, exigir una justificación de costes para los flujos más caros y bloquear ediciones aparentemente vinculadas a casos de prueba concretos. Estos controles podrían facilitar la auditoría y la reversión de la optimización automatizada del harness.

El enfoque puede ser especialmente relevante para la IA empresarial, donde los costes de los tokens, el comportamiento predecible y la fiabilidad en distintos procesos internos importan tanto como las puntuaciones máximas de los benchmarks. Un harness que generalice a documentos o procedimientos desconocidos puede ser más útil que uno que obtenga una puntuación superior en una colección fija de demostraciones.

El trabajo no resuelve las cuestiones más amplias de seguridad y gobernanza relacionadas con agentes que alteran su propia lógica operativa. RRSI limita los cambios del harness, pero las pruebas disponibles no muestran si sus críticos pueden detectar de manera fiable todas las formas de comportamiento oculto específico de un benchmark. Tampoco aborda sistemas en los que los pesos del modelo cambian durante la optimización.

No obstante, la transferencia comunicada entre modelos resulta destacable. Según se informa, un harness de programación descubierto con Gemini 3.5 Flash elevó la precisión del modelo más débil Gemini 3.1 Flash Lite de 11,2 a 14,6 puntos sin modificar este último. El hallazgo sugiere que algunas mejoras de flujo de trabajo podrían ser portables entre modelos con distintas capacidades, aunque procede del mismo informe de investigación y requiere una validación más amplia.

Qué observar a continuación

La primera señal será la replicación independiente de RRSI con modelos y familias de tareas adicionales. Los resultados deben compararse en tareas reservadas que permanezcan ocultas tanto para el optimizador del harness como para su crítico.

Los investigadores y los equipos de producto también deberían probar si el método sigue siendo eficaz cuando las herramientas, los prompts, los almacenes de memoria y las distribuciones de datos cambian después del despliegue. Las mediciones de costes también serán importantes: la reducción de tokens del 30 % se refiere a un sistema optimizado no regularizado, no necesariamente a una referencia diseñada cuidadosamente.

Otra cuestión abierta es si controles similares pueden gobernar agentes que actualizan los pesos del modelo, en lugar de limitarse al harness circundante. El estudio actual cubre modelos congelados, por lo que deja fuera de su alcance esa forma más trascendental de automejora.

Perspectiva de Creati.ai

RRSI aborda una debilidad práctica de la actual carrera por los agentes: los equipos pueden automatizar la búsqueda de mejores flujos de trabajo más rápido de lo que pueden determinar si esos flujos generalizan. Su principal aportación es, por tanto, metodológica. Trata el rendimiento en tareas no vistas y el coste computacional como restricciones fundamentales, en lugar de depender de una única puntuación de optimización.

La investigación no demuestra que la automejora recursiva esté preparada para un despliegue sin supervisión. Pero ofrece a los desarrolladores un principio de diseño más claro: un agente debe ganarse el derecho a volverse más complejo demostrando mejoras fiables más allá de las pruebas que produjeron el cambio.