Imagínese que su equipo de ingeniería acaba de implementar un agente de inteligencia artificial para buscar en documentos internos de la empresa y responder a preguntas de empleados. Aunque funciona a la perfección durante la fase de desarrollo, en producción suele generar errores o incumplir restricciones clave. Resolver estos problemas no es cuestión de aplicar un parche rápido, sino de llevar a cabo un tedioso proceso de ensayo y error, ajustando simultáneamente la segmentación de datos, los métodos de recuperación y las indicaciones del sistema. La gran dificultad radica en que estos ajustes están interrelacionados, por lo que resulta casi imposible identificar cuál modificación resolvió el problema.
Para superar este obstáculo, un equipo conjunto de la Universidad Renmin de China y Microsoft Research ha creado Arbor, un marco de trabajo diseñado para transformar la optimización impulsada por IA desde un conjunto de conjeturas aisladas hacia un proceso de aprendizaje acumulativo. Arbor estructura hipótesis, experimentos y conclusiones en forma de árbol, permitiendo que el sistema aprenda de errores anteriores y avance con mejoras inteligentes y verificadas a lo largo del tiempo.
En pruebas prácticas, Arbor logró superar en más de 2,5 veces la mejora de rendimiento verificable obtenida por agentes estándar como Claude Code y Codex, empleando el mismo presupuesto computacional. Para las empresas, esto supone una herramienta revolucionaria que automatiza y acelera la mejora continua de sistemas de ingeniería complejos del mundo real. 
Limitaciones en la optimización autónoma tradicional
Con el avance de los grandes modelos de lenguaje y sistemas de IA, se espera que realicen operaciones cada vez más complejas, como la optimización autónoma (AO) de infraestructuras de software o algoritmos de entrenamiento de modelos. La AO reproduce el ciclo fundamental de investigación autónoma: un agente comienza con un artefacto inicial —por ejemplo, una base de código o una tubería de datos— y un objetivo específico; su misión es mejorar iterativamente ese artefacto mediante experimentos, sin supervisión humana paso a paso.
Sin embargo, esta tarea presenta una dificultad poco comprendida. Muchos equipos técnicos descubren que simplemente aumentar el tiempo o recursos computacionales de un agente con capacidad de codificación no garantiza mejoras. Según Jiajie Jin, coautor del estudio, “automatizar el proceso puede mantener a una IA trabajando durante mucho tiempo, pero un bucle repetitivo no equivale a progreso real. Si el objetivo es vago o el indicador puede manipularse fácilmente, la automatización sólo genera supuestas mejoras que no interesan a nadie”.
Jin explica que tareas complejas requieren múltiples intentos para ser dominadas, y los agentes actuales carecen de estructuras de datos cruciales para registrar y mantener el estado del proceso. “¿Cómo asegurarse de que las ideas y experiencias de cada intento se acumulen en lugar de perderse en un historial inaccesible?”, señala. La ausencia de este mecanismo provoca que los agentes repitan errores consecutivamente.
Las soluciones actuales permiten ejecutar experimentos durante horas con objetivos claros, modificando código, invocando herramientas o realizando pruebas de forma autónoma. Sin embargo, tratan cada intento de forma aislada, sin poder acumular ni actuar en base a aprendizajes previos. Tampoco pueden gestionar simultáneamente varias líneas de investigación ni interpretar tanto éxitos como fracasos para guiar futuras exploraciones, una capacidad clave que caracteriza a la investigación humana.
A nivel técnico, los agentes suelen almacenar la memoria como transcripciones conversacionales. Como las tareas de AO pueden involucrar cientos de interacciones que exceden los límites habituales de contexto, estos agentes pierden capacidad para conservar y reutilizar pruebas durante largos períodos, lo que los hace vulnerables a atascarse en errores iniciales o a desviarse persiguiendo fluctuaciones irrelevantes en las métricas. Por ello, se requiere una memoria estructurada y durable que registre qué ideas se han probado, qué evidencias se han generado y cómo han influido en la formulación de nuevas hipótesis.
Además, estos marcos son propensos al ‘reward hacking’ o sobreajuste a métricas de desarrollo, dando la falsa impresión de avance sin que las mejoras sean reales en entornos prácticos. Por último, la dependencia de un único entorno compartido para modificar código limita la capacidad de probar hipótesis paralelas sin contaminar la base principal ni dificultar la atribución de resultados a cada idea.
Cómo funciona Arbor
Arbor aborda estos retos estructurando el proceso de optimización autónoma como un ciclo de largo plazo basado en exploración, experimentación y abstracción, similar a la forma en que trabajan los investigadores humanos. Introduce dos componentes clave que separan la investigación estratégica de las tareas concretas de desarrollo:
El coordinador: un agente de IA de larga duración que actúa como investigador principal. No modifica directamente la base de código objetivo, sino que administra el estado general de la investigación de optimización, analiza evidencias acumuladas, genera nuevas hipótesis y decide qué hacer tras recibir los resultados experimentales.
Los ejecutores: agentes de IA de corta duración y enfoque especializado. Cuando el coordinador decide probar una idea, crea un ejecutor en un entorno aislado (un nuevo git worktree limpio). Cada ejecutor recibe una única hipótesis a implementar, evaluando su ejecución, depurando errores y reportando resultados y artefactos al coordinador.
Ambos trabajan mediante un mecanismo denominado “Refinamiento del Árbol de Hipótesis” (HTR). Éste representa toda la investigación como un árbol ramificado persistente donde cada nodo almacena cuatro elementos: la hipótesis, el artefacto ejecutable, la evidencia factual resultante y una conclusión extraída. De esta forma, el coordinador explora simultáneamente direcciones competitivas sin perder el hilo de la investigación.
Las ideas generales se sitúan en las raíces del árbol, mientras que las refinaciones concretas se ramifican como hojas. Esto permite ensayar diferentes hipótesis en paralelo. Cuando una prueba falla, el árbol registra el motivo como una restricción negativa, evitando repetir el error indefinidamente.
Por ejemplo, en un escenario empresarial común de optimización de un pipeline Retrieval-Augmented Generation (RAG) para un asistente interno, los agentes tradicionales como Claude Code o Codex suelen mezclar cambios en segmentación, prompts y métodos de recuperación en una sola pasada, afectando el repositorio principal sin aislamiento ni clara atribución. Arbor descompone cada palanca en ramas separadas, aplicando y evaluando cada una en entornos aislados, lo que permite identificar qué modificaciones aportan mejoras reales y cuáles perjudican.
Cuando un ejecutor finaliza, el coordinador incorpora la evidencia al árbol y propaga las conclusiones a nodos superiores, convirtiendo observaciones locales en restricciones generales que guían futuras ideas.
Para evitar que se optimice a costa de sesgos o errores en los datos de desarrollo, Arbor implementa una “puerta de fusión” estricta: aunque un ejecutor informe de una mejora notable, el coordinador realizará una prueba aislada con datos de test externos. Sólo si la mejora se verifica se integra el cambio en la rama principal, asegurando que los avances sean aplicables y reales.
Resultados y aplicaciones reales
Arbor fue evaluado en una batería de tareas de optimización autónoma basadas en escenarios reales y en el benchmark MLE-Bench Lite, que incluye ámbitos como entrenamiento de modelos, ingeniería de entornos de pruebas y síntesis de datos. Usaron modelos variados para coordinadores y ejecutores, entre ellos Claude Opus 4.6, GPT-5.5 y Gemini-3-Flash, y compararon Arbor frente a Codex, Claude Code, AI-Scientist, ML-Master y AIDE, todos con los mismos recursos.
Arbor superó consistentemente a sus competidores, obteniendo los mejores resultados en pruebas externas en todas las tareas. Alcanzó más de 2,5 veces la mejora media relativa que Codex y Claude Code. En la tarea BrowseComp, que consiste en optimizar un agente de búsqueda, aumentó la precisión del sistema del 45,33% inicial al 67,67%, mientras Codex y Claude Code quedaron estancados en torno al 50-53%. En MLE-Bench Lite, usando GPT-5.5, Arbor logró el resultado más destacado de todos los sistemas evaluados.
Además, mostró gran resistencia al sobreajuste. Por ejemplo, en Terminal-Bench 2.0, Claude Code logró una puntuación alta de 75 en desarrollo, pero bajó a 71 en datos externos. Arbor, con menor puntuación de desarrollo (72,22), alcanzó la máxima puntuación real con 77,36, garantizando aplicabilidad práctica.
En un experimento de transferencia, después de optimizar para BrowseComp, el código mejorado por Arbor fue probado en dos tareas distintas (HLE y DeepSearchQA), donde también mejoró notablemente el rendimiento, demostrando capacidad de generalización.
Implementación y consideraciones
Arbor está diseñado para integrarse sobre flujos de trabajo existentes basados en Git, sin sustituirlos. Su resultado es una rama Git convencional que puede revisarse mediante los procesos habituales de control de calidad y aprobación humana, incorporando sólo los cambios validados. Esto minimiza riesgos al mantener intacta la rama principal hasta que un desarrollador decide promocionar nuevos códigos.
No obstante, su despliegue implica costes específicos, destacando el gasto en tokens ya que el coordinador debe ejecutarse a largo plazo gestionando el árbol y coordinando ejecutores. Además, mantener múltiples entornos de prueba paralelos requiere recursos reales de computación y almacenamiento.
Según Jiajie Jin, Arbor es especialmente adecuado para tareas con métricas claras y fiables, tolerancia a largos horizontes temporales y espacios de búsqueda con varias opciones válidas, como la optimización de pipelines, mejora en síntesis de datos o ajuste de recetas de entrenamiento.
En cambio, no es recomendable para tareas con exigencias de latencia real, arreglos triviales ni métricas poco fiables, ya que la calidad del proceso queda limitada por la del evaluador. Jin asegura: “Si la métrica es débil, Arbor sólo acelerará la optimización hacia un resultado poco sólido”.
Como siguiente paso, los investigadores contemplan extender Arbor para soportar múltiples métricas simultáneas en cada nodo (precisión, latencia, coste), avanzando hacia una búsqueda de Pareto multiobjetivo más sofisticada y acorde con escenarios reales diversos.
