Resumen Técnico: ¡Viva el Bibliotecario! Un Sub-Agente de Búsqueda Persistente para Sistemas de Ingeniería de Software Multi-Agente Eficientes Energéticamente

Enunciado del Problema

Aunque los Sistemas Multi-Agente (MAS) han avanzado significativamente la ingeniería de software (SWE) autónoma, sus crecientes demandas de energía de inferencia plantean preocupaciones de sostenibilidad. La literatura existente sobre el consumo energético de los LLM se centra en gran medida en configuraciones por llamada o ejecuciones de un solo agente, sin caracterizar las dinámicas energéticas únicas de los MAS donde una sola tarea abarca numerosas llamadas a LLM a través de sub-agentes especializados.

Los autores identifican una ineficiencia crítica en los diseños actuales de MAS: la generación redundante de tokens de salida. En las arquitecturas existentes, los sub-agentes carecen de memoria persistente del historial de exploración de archivos entre invocaciones. En consecuencia, cuando un orquestador emite diferentes consultas, los sub-agentes atraviesan repetidamente regiones superpuestas del repositorio y regeneran largos fragmentos de archivos. Este ciclo de reexploración amplifica la categoría de tokens más intensiva en energía: los tokens de salida.

El análisis empírico revela una asimetría energética marcada: un token de salida consume de 30 a 1.000 veces más energía que un token de entrada o en caché. A pesar de esto, las cuentas agregadas de tokens y los proxies de precios de API a menudo subestiman el consumo real de energía de la GPU porque no tienen en cuenta el costo desproporcionado de los tokens de salida generados por la exploración redundante.

Metodología

1. Atribución y Diagnóstico de Energía

Los autores realizaron un estudio de atribución de energía a nivel de turno en SWE-Bench Verified utilizando dos sistemas multi-agente (BOAD y HyperAgent) y dos modelos base Qwen3.6 (35B-A3B y 27B) en GPUs NVIDIA A100 y B200.

• Descomposición a Nivel de Token: Descompusieron la energía de la GPU en tres categorías: entrada sin caché ($x_u$), entrada en caché ($x_c$) y salida ($x_o$).
• Análisis de Regresión: Un modelo de regresión lineal ($E_t = \alpha + \beta_u x_u + \beta_c x_c + \beta_o x_o$) confirmó que los tokens de salida dominan el consumo de energía, con coeficientes ($\beta_o$) que oscilan entre 660 y 3.512 mJ/token, en comparación con ~0.5–34 mJ/token para los tokens de entrada.
• Identificación de la Causa Raíz: El estudio rastreó el exceso de salida hacia "reescrituras duplicadas". Los sub-agentes leen frecuentemente de nuevo regiones de archivos que ellos mismos u otros agentes ya habían inspeccionado en el mismo episodio, regenerando el texto completo en sus respuestas al orquestador.

2. El Sub-Agente Bibliotecario

Para abordar esto, los autores proponen Librarian (Bibliotecario), un sub-agente de búsqueda persistente diseñado para eliminar la exploración redundante y minimizar el volumen de salida. Se integra en los MAS existentes reemplazando al sub-agente estándar de navegación de código.

Principios de Diseño Central:

• Sesión Persistente: A diferencia de los sub-agentes estándar que comienzan con un contexto fresco, el Bibliotecario mantiene una única sesión de larga duración a través de todas las invocaciones dentro de un episodio. Retiene la trayectoria completa de búsquedas y respuestas anteriores.
• Frescura del Contexto: Para asegurar que el historial se alinee con el estado actual del repositorio, cada invocación se suministra con un "informe de frescura" que lista los archivos y rangos de líneas modificados desde la llamada anterior. Se instruye al Bibliotecario a reatravesar solo estas regiones modificadas, mientras reutiliza fragmentos en caché para las áreas sin cambios.
• Respuestas Solo con Punteros: En lugar de incluir fragmentos completos de archivos en su respuesta, el Bibliotecario devuelve breves comandos de visualización (punteros a rutas de archivos y rangos de líneas). Los fragmentos de código reales son recuperados por la capa de herramientas del sistema y reenviados al orquestador. Esto reduce drásticamente el volumen de tokens generado por el propio LLM.

Estrategia de Integración:
La integración implica un "cambio de herramientas" donde la herramienta de delegación del orquestador para la navegación de código se reemplaza con una herramienta de delegación al Bibliotecario. El plan de resolución se reescribe para formular los pasos de navegación como consultas de búsqueda en lenguaje natural (por ejemplo, "¿Dónde se define el símbolo X?") en lugar de exploraciones abiertas. El Bibliotecario se limita estrictamente a la búsqueda de archivos y código; el razonamiento analítico y la edición permanecen bajo la responsabilidad del orquestador u otros agentes especializados.

Resultados Clave

Los autores evaluaron a Librarian en SWE-Bench Verified (500 tareas) a través de BOAD y HyperAgent con los modelos base Qwen3.6-35B-A3B y Qwen3.6-27B.

• Reducción de Energía: Librarian redujo el consumo de energía por episodio en la GPU en hasta un 25% (por ejemplo, de 25.64 kJ a 22.73 kJ para HyperAgent con 35B-A3B).
• Eficiencia de Tokens: La reducción fue impulsada principalmente por una disminución en los tokens de salida. Por ejemplo, HyperAgent con Librarian redujo los tokens de salida de 48.5K a 42.2K por episodio.
• Preservación del Rendimiento: Crucialmente, Librarian preservó o mejoró la tasa de éxito de las tareas. En la mayoría de las configuraciones, la tasa de éxito se mantuvo comparable o ligeramente superior a la de los MAS de referencia, demostrando que los ahorros de energía no se lograron a costa de la resolución de tareas.
• Comparación con Líneas Base:
  • Métodos de Eficiencia de Tokens: Técnicas como "LastN Observation" (truncar el historial) y "Caveman prompting" (comprimir texto) a menudo degradaron las tasas de éxito o no lograron reducir la energía tan efectivamente, ya que forzaron a los agentes a reexplorar el contexto perdido, inflando los tokens de salida.
  • Variantes Basadas en Recuperación: Reemplazar el historial persistente con contexto basado en recuperación (BM25 o incrustaciones densas) resultó en un mayor consumo de energía y tasas de éxito más bajas, lo que sugiere que las consultas del orquestador requieren una gestión activa del contexto y un razonamiento que una recuperación simple no puede proporcionar.
• Escalabilidad: La reducción de energía persistió a través de diferentes dificultades de tareas. Aunque la frecuencia de invocación de Librarian aumentó con la complejidad de la tarea, los ahorros de energía por episodio se mantuvieron consistentes, y la tasa de éxito se mantuvo incluso en tareas más difíciles.

Significado y Afirmaciones

El artículo afirma identificar y eliminar una fuente importante, previamente pasada por alto, de desperdicio de energía en sistemas de SWE multi-agente. Su significado radica en tres contribuciones principales:

1. Descubrimiento Empírico: Confirma que en entornos de agentes, los tokens de salida dominan el uso de recursos, y que las cuentas agregadas de tokens son malos proxies para el consumo real de energía debido al alto costo marginal de la generación de salida.
2. Diagnóstico de Redundancia: Diagnostica la sobrecarga energética de los diseños actuales de MAS como una consecuencia de las búsquedas de archivos duplicadas a lo largo del ciclo de depuración, una redundancia que ningún sub-agente existente reconoce.
3. Solución Arquitectónica: Propone Librarian, un sub-agente de búsqueda persistente que se integra en los diseños existentes de MAS para suplir un rol faltante (navegación de repositorios con estado). Al devolver punteros en lugar de contenido y reutilizar el historial, minimiza el consumo de energía del hardware mientras iguala el rendimiento de las tareas.

Los autores concluyen que minimizar los tokens de salida mediante una búsqueda persistente y con estado es una estrategia más efectiva para la eficiencia energética en agentes de SWE que la compresión simple de prompts o el truncamiento del contexto, que a menudo degradan el rendimiento. Reconocen limitaciones, señalando que la solución es actualmente específica para roles de navegación de código y se evaluó en modelos de hasta 27 mil millones de parámetros activos, dejando la escalabilidad a modelos más grandes y roles orientados a la ejecución como preguntas abiertas.