Resumen Técnico: Bayesian-Agent: Evolución de Habilidades Guiada por la Posterior para Agentes LLM

1. Planteamiento del Problema

Los agentes de Modelos de Lenguaje Grande (LLM) dependen cada vez más de entornos de inferencia externos —que comprenden prompts, herramientas, memoria, Procedimientos Operativos Estándar (SOPs) y retroalimentación del harness— en lugar de depender únicamente de los pesos del modelo. Si bien estos activos reutilizables pueden mejorar la ejecución sin necesidad de reentrenamiento, los métodos actuales para actualizarlos suelen depender de la reflexión heurística o de simples recuentos de frecuencia de éxito y fracaso.

El artículo identifica dos limitaciones primarias en los enfoques existentes:

1. Actualizaciones No Calibradas: Tratar las trayectorias dispersas de los agentes como observaciones independientes e idénticamente distribuidas (i.i.d.) conduce a ediciones ruidosas. Una habilidad puede ser confiable en un contexto pero perjudicial en otro; el simple recuento falla al capturar este matiz.
2. Fallo Externalizado: Cuando las capacidades se externalizan en habilidades y SOPs, los fallos también se externalizan. Si un agente actualiza sus activos basándose únicamente en la autocrítica en lenguaje natural, puede reparar un fallo actual pero introducir ediciones que degradan el rendimiento en tareas futuras. Por el contrario, si el harness nunca revisa las habilidades, los fallos repetidos permanecen fuera del bucle de aprendizaje del modelo.

El desafío central es cómo mantener el entorno de decisión externo (el "harness") de modo que las habilidades y los SOPs reutilizables evolucionen basados en evidencia verificada en lugar de un ensayo y error no calibrado.

2. Metodología: Bayesian-Agent

Los autores presentan Bayesian-Agent, un marco que trata las habilidades reutilizables y los SOPs como hipótesis portadoras de evidencia. En lugar de preguntar a un LLM si una habilidad es "buena", el marco plantea una pregunta bayesiana: Dado un modelo congelado y un entorno de inferencia específico, ¿qué deberíamos creer sobre esta habilidad tras combinar supuestos previos con evidencia verificada?

2.1 Formulación del Problema

El marco fija los pesos del modelo ($M_\theta$) y trata la evolución del harness como una optimización sobre las condiciones de inferencia ($C_t$). La fiabilidad de una habilidad $h_k$ se define como la probabilidad de éxito dado el modelo, el contexto y las características observadas:
$$p_{k,t} = P(y_t = 1 \mid M_\theta, C_t, h_k, z_t)$$
donde $z_t$ es un vector de características discretas extraído de una trayectoria verificada (por ejemplo, conteo de tokens, conteo de turnos, modos de fallo).

2.2 Evidencia de Trayectoria

Bayesian-Agent actualiza las creencias únicamente a partir de trayectorias verificadas ($e_t$) generadas por un harness de ejecución. Estas trayectorias incluyen:

• Contexto de la tarea y resultado ($y_t \in \{0, 1\}$) determinado por un verificador externo o un evaluador de benchmark, no por la autoevaluación del modelo.
• Señales de tiempo de ejecución (costo de tokens, latencia, conteo de turnos) discretizadas en cubetas fijas para manejar conjuntos de datos en línea dispersos.
• Modos de fallo derivados del verificador.

2.3 Modelo de Evidencia Bayesiana

El sistema mantiene un modelo de evidencia categórico condicionado por características para cada habilidad:

• Priors (Distribuciones Previas): Utiliza suavizado de Laplace para proporcionar estimaciones conservadoras cuando las observaciones son escasas.
• Likelihood (Verosimilitud): Calcula la probabilidad de éxito/fallo condicionada a valores de características específicos (por ejemplo, "el modo de fallo X ocurre en el contexto Y").
• Posterior: Computa una probabilidad de éxito ($s_{k,t}$) utilizada para el ranking y la toma de decisiones.
• Resumen: Mantiene un resumen Beta-Bernoulli conjugado ($\alpha, \beta$) para auditoría y comprobaciones de dominancia de fallos.

2.4 Acciones de Habilidad Guiadas por la Posterior

La posterior impulsa una política de reescritura conservadora que mapea los estados de creencia a cinco acciones inspeccionables:

1. Explorar (Explore): Se activa cuando no existen observaciones o la posterior es incierta.
2. Parchear (Patch): Se activa cuando el mismo modo de fallo aparece al menos dos veces (convirtiendo fallos repetidos en salvaguardas).
3. Dividir (Split): Se activa cuando una habilidad amplia cubre casos heterogéneos (3+ contextos, 4+ observaciones).
4. Comprimir (Compress): Se activa cuando una habilidad es fiable (éxito $\ge$ 0.72) para mantener el contexto conciso.
5. Retirar (Retire): Se activa cuando la evidencia de fallo domina (baja probabilidad de éxito, $\beta$ alto).

Crucialmente, el marco separa la información de auditoría de la posterior (almacenada para depuración) de las instrucciones orientadas al modelo. El LLM recibe salvaguardas ejecutables y parches de modos de fallo, no números de probabilidad brutos.

2.5 Modos de Ejecución

• Modo Completo (Full Mode): El registro evoluciona en línea desde cero durante una ejecución de benchmark.
• Modo Incremental (Incremental Mode): El sistema ingiere trazas verificadas de una ejecución base completada, actualiza el registro y vuelve a ejecutar solo las tareas fallidas con parches guiados por la posterior.

3. Contribuciones Clave

1. Formulación de Habilidades como Hipótesis: Cambia la autoevolución de la acumulación empírica de prompts a la optimización de la posterior guiada por evidencia bajo incertidumbre.
2. Marco Unificado: Proporciona una visión bayesiana unificada para la ingeniería de prompts, contexto y harness, instanciada con un modelo de evidencia categórica eficiente y una política de reescritura guiada por la posterior.
3. Soporte Nativo y Cross-Harness: Introduce un backend nativo mínimo mientras define un límite de adaptador que permite a otros harnesses externos (GenericAgent, mini-swe-agent, Claude Code) utilizar el mismo bucle de evidencia de trayectoria.
4. Validación Empírica: Realiza estudios extensos en SOP-Bench, Lifelong AgentBench y RealFin-Bench utilizando modelos DeepSeek, comparando variantes de línea base, Bayesian completo e incremento de reparación.

4. Resultados Experimentales

El artículo evalúa Bayesian-Agent a través de tres benchmarks y múltiples backends (Native, GenericAgent, mini-swe-agent, Claude Code) usando DeepSeek-v4-flash y DeepSeek-v4-pro.

4.1 Ganancias de Rendimiento

• Reparación Incremental: El modo incremental (reparando solo tareas fallidas) mostró mejoras significativas:
  • SOP-Bench: Mejoró del 80% (GA) al 95%.
  • Lifelong AgentBench: Mejoró del 90% (GA) al 100%.
  • RealFin-Bench: Mejoró del 45% (GA) al 65%.
• Eficiencia de Tokens: El enfoque incremental fue altamente eficiente en tokens, utilizando solo 153k tokens para reparar los fallos de SOP-Bench en comparación con la ejecución base completa.
• Agnosticismo de Backend: El marco mejoró con éxito el rendimiento en diferentes backends (Native, GenericAgent, mini-swe-agent, Claude Code), confirmando que el beneficio proviene del bucle de evidencia y no de un runtime específico.

4.2 Limitaciones Observadas

• Inestabilidad del Modo Completo: En el entorno Lifelong AgentBench con DeepSeek-v4-flash, el modo Bayesian Completo (85%) tuvo un rendimiento inferior a la línea base GA (90%). Esto sugiere que la evolución de habilidades en línea puede introducir efectos de ordenamiento negativos o costos cuando la evidencia aún es escasa.
• Saturación: En configuraciones donde el modelo base ya lograba un 100% de precisión (por ejemplo, SOP-Bench con DeepSeek-v4-pro), la capa bayesiana no tenía fallos que reparar, dejando el modo incremental inactivo.

5. Significación y Reivindicaciones

El artículo sostiene que la evolución de las habilidades del agente se visualiza mejor como una optimización del harness guiada por la posterior en lugar de una acumulación de prompts no calibrada.

• Auditabilidad: Al tratar las habilidades como hipótesis con estados posteriores explícitos, el marco hace que el proceso de evolución sea inspeccionable. Los usuarios pueden ver por qué una habilidad fue parcheada, dividida o retirada basándose en modos de fallo específicos.
• Calibración de la Incertidumbre: El enfoque maneja explícitamente la escasez y la dependencia del contexto de las trayectorias de los agentes, evitando las trampas de tratar datos dispersos como recuentos de frecuencia fiables.
• Reparación Práctica: El entorno de reparación incremental demuestra que un harness puede dedicar recursos de inferencia adicionales específicamente a los casos fallidos para convertir los modos de fallo observados en contexto reutilizable, aumentando significativamente la precisión final sin volver a ejecutar todo el benchmark.

Los autores concluyen que, si bien el enfoque no es una panacea para tareas de una sola vez o entornos no estacionarios, proporciona un mecanismo robusto y calibrado por evidencia para mejorar las habilidades reutilizables de los agentes en entornos con verificadores y modos de fallo recurrentes.