mejores modelos, ventanas de contexto más grandes y agentes más capaces. Pero la mayoría de las fallas del mundo real no provienen de la capacidad del modelo: provienen de cómo se construye, transmite y mantiene el contexto.
Este es un problema difícil. El espacio avanza rápidamente y las técnicas aún están evolucionando. Gran parte sigue siendo una ciencia experimental y depende del contexto (juego de palabras), las limitaciones y el entorno en el que se opera.
En mi trabajo en la construcción de sistemas multiagente, ha surgido un patrón recurrente: el rendimiento se trata mucho menos de cuánto contexto se le da a un modelo, y mucho más de con qué precisión se le da forma.
Esta pieza es un intento de resumir mis aprendizajes en algo que puedas usar.
Se centra en los principios para gestionar el contexto como un recurso limitado: decidir qué incluir, qué excluir y cómo estructurar la información para que los agentes sigan siendo coherentes, eficientes y confiables a lo largo del tiempo.
Porque al fin y al cabo los agentes más fuertes no son los que más ven. Ellos son los que ven las cosas correctas, en la forma correcta y en el momento correcto.
Terminología
Ingeniería de contexto
La ingeniería de contexto es el arte de proporcionar la información, las herramientas y el formato adecuados a un LLM para que complete una tarea. Una buena ingeniería de contexto significa encontrar el conjunto más pequeño posible de tokens de alta señal que le den al LLM la mayor probabilidad de producir un buen resultado.
En la práctica, una buena ingeniería de contexto suele reducirse a cuatro movimientos. Usted descarga información a sistemas externos (descarga de contexto), por lo que el modelo no necesita llevar todo dentro de banda. Recupera información dinámicamente en lugar de cargarla toda por adelantado (recuperación de contexto). Aíslas el contexto para que una subtarea no contamine a otra (aislamiento de contexto). Y se reduce el historial cuando es necesario, pero sólo de manera que se preserve lo que el agente seguirá necesitando más adelante (reducción de contexto).
Un modo de falla común por otro lado es la contaminación del contexto: la presencia de demasiada información innecesaria, contradictoria o redundante que distrae al LLM.
Pudrición del contexto
La descomposición del contexto es una situación en la que el rendimiento de un LLM se degrada a medida que se llena la ventana de contexto, incluso si está dentro del límite establecido. El LLM todavía tiene espacio para leer más, pero su razonamiento comienza a desdibujarse.
Habrá notado que la ventana de contexto efectiva, donde el modelo funciona con alta calidad, a menudo es mucho más pequeña de lo que el modelo es técnicamente capaz de hacer.
Hay dos partes en esto. Primero, un modelo no mantiene una recuperación perfecta en toda su ventana de contexto. La información al principio y al final se recuerda de manera más confiable que las cosas en el medio.
En segundo lugar, las ventanas de contexto más grandes no resuelven los problemas de los sistemas empresariales. Los datos empresariales son efectivamente ilimitados y se actualizan con frecuencia, por lo que incluso si el modelo pudiera asimilarlo todo, eso no significaría que pudiera mantener una comprensión coherente sobre ellos.
Así como los humanos tienen una capacidad de memoria de trabajo limitada, cada nuevo token introducido en el LLM agota en cierta medida este presupuesto de atención que tiene. La escasez de atención surge de restricciones arquitectónicas en el transformador, donde cada token atiende a todos los demás. Esto conduce a un patrón de interacción n² para n tokens. A medida que el contexto crece, el modelo se ve obligado a distribuir su atención entre más relaciones.
Compactación de contexto
La compactación del contexto es la respuesta general a la descomposición del contexto.
Cuando el modelo se acerca al límite de su ventana de contexto, resume su contenido y reinicia una nueva ventana de contexto con el resumen anterior. Esto es especialmente útil para tareas de ejecución prolongada para permitir que el modelo continúe funcionando sin demasiada degradación del rendimiento.
Un trabajo reciente sobre plegado de contexto ofrece un enfoque diferente: los agentes gestionan activamente su contexto de trabajo. Un agente puede dividirse para manejar una subtarea y luego plegarla al finalizar, colapsando los pasos intermedios y manteniendo un resumen conciso del resultado.
La dificultad, sin embargo, no está en resumir, sino en decidir qué sobrevive. Algunas cosas deberían permanecer estables y casi inmutables, como el objetivo de la tarea y las limitaciones estrictas. Otros pueden descartarse con seguridad. El desafío es que la importancia de la información a menudo sólo se revela más tarde.
Por lo tanto, una buena compactación debe preservar hechos que continúan limitando acciones futuras: qué enfoques ya fallaron, qué archivos se crearon, qué suposiciones fueron invalidadas, qué manejos pueden revisarse y qué incertidumbres permanecen sin resolver. De lo contrario, obtendrá un resumen claro y conciso que lee bien a un humano y es inútil para un agente.
Arnés de agente
Un modelo no es un agente. El arnés es lo que convierte a un modelo en uno.
Por aprovechamiento me refiero a todo lo relacionado con el modelo que decide cómo se ensambla y mantiene el contexto: serialización rápida, enrutamiento de herramientas, políticas de reintento, las reglas que rigen lo que se conserva entre pasos, etc.
Una vez que se observan los sistemas de agentes reales de esta manera, muchos de los supuestos “fallos del modelo” ahora se ven diferentes. Me he encontrado con muchos de estos en el trabajo. En realidad, se trata de fallos de arnés: el agente olvidó porque nada persistía en el estado correcto; repitió el trabajo porque en el arnés no apareció ningún artefacto duradero de falla anterior; eligió la herramienta equivocada porque el arnés sobrecargaba el espacio de acción; etcétera.
Un buen arnés es, en cierto sentido, un caparazón determinista envuelto alrededor de un núcleo estocástico. Hace que el contexto sea lo suficientemente legible, estable y recuperable como para que el modelo pueda gastar su limitado presupuesto de razonamiento en la tarea en lugar de reconstruir su propio estado a partir de un rastro desordenado.
Comunicación entre agentes
A medida que las tareas se vuelven más complejas, los equipos han optado por sistemas multiagente.
El error es suponer que más agentes significa más contexto compartido. En la práctica, descargar una transcripción compartida gigante en cada subagente a menudo crea exactamente lo contrario de la especialización. Ahora cada agente lee todo, hereda los errores de los demás y paga la misma factura contextual una y otra vez.
Si solo se comparte algo de contexto, aparece un nuevo problema. ¿Qué se considera autoritativo cuando los agentes no están de acuerdo? ¿Qué sigue siendo local y cómo se reconcilian los conflictos?
La salida es tratar la comunicación no como memoria compartida, sino como transferencia de estado a través de interfaces bien definidas.
Para tareas discretas con entradas y salidas claras, los agentes normalmente deberían comunicarse a través de artefactos en lugar de rastros en bruto. Un agente de búsqueda web, por ejemplo, no necesita transmitir todo su historial de navegación. Sólo necesita sacar a la superficie el material que los agentes posteriores realmente pueden utilizar.
Esto significa que el razonamiento intermedio, los intentos fallidos y los rastros de exploración permanecen privados a menos que sean explícitamente necesarios. Lo que se transmite son resultados destilados: hechos extraídos, hallazgos validados o decisiones que limitan el siguiente paso.
Para tareas más estrechamente acopladas, como un agente de depuración en el que el razonamiento posterior realmente depende de intentos anteriores, se puede introducir una forma limitada de intercambio de seguimiento. Pero esto debería ser deliberado y con un alcance determinado, no algo predeterminado.
Penalización de caché KV
Cuando los modelos de IA generan texto, suelen repetir muchos de los mismos cálculos. El almacenamiento en caché de KV es una técnica de optimización del tiempo de inferencia que acelera este proceso al recordar información importante de los pasos anteriores en lugar de volver a calcular todo nuevamente.
Sin embargo, en sistemas multiagente, si cada agente comparte el mismo contexto, se confunde el modelo con un montón de detalles irrelevantes y se paga una enorme penalización de caché KV. Varios agentes que trabajan en la misma tarea necesitan comunicarse entre sí, pero esto no debe hacerse compartiendo memoria.
Es por eso que los agentes deben comunicarse a través de resultados mínimos y estructurados de manera controlada.
Mantenga el conjunto de herramientas del agente pequeño y relevante
La elección de herramientas es un problema de contexto disfrazado de problema de capacidad.
A medida que un agente acumula más herramientas, el espacio de acción se vuelve más difícil de navegar. Ahora existe una mayor probabilidad de que el modelo tome la acción equivocada y tome una ruta ineficiente.
Esto tiene consecuencias. Los esquemas de herramientas deben ser mucho más distintos de lo que la mayoría de la gente cree. Las herramientas deben entenderse bien y tener una superposición mínima en su funcionalidad. Debe quedar muy claro cuál es su uso previsto y tener parámetros de entrada claros que sean inequívocos.
Un modo de falla común que noté incluso en mi equipo es que tendemos a tener conjuntos de herramientas muy inflados que se agregan con el tiempo. Esto lleva a una toma de decisiones poco clara sobre qué herramientas utilizar.
Memoria agente
Esta es una técnica en la que el agente escribe regularmente notas que se guardan en la memoria fuera de la ventana de contexto. Estas notas vuelven a la ventana contextual más adelante.
La parte más difícil es decidir qué merece ser promovido a la memoria. Mi regla general es que la memoria duradera debe contener elementos que sigan limitando el razonamiento futuro: preferencias persistentes. Todo lo demás debería tener el listón muy alto. Almacenar demasiado es sólo otra ruta de regreso a la contaminación contextual, sólo que ahora la has hecho persistente.
Pero la memoria sin revisión es una trampa. Una vez que los agentes persisten en las notas a lo largo de los pasos o sesiones, también necesitan mecanismos para la resolución, eliminación y degradación de conflictos. De lo contrario, la memoria a largo plazo se convierte en un vertedero de creencias obsoletas.
para resumir
La ingeniería de contexto todavía está evolucionando y no existe una única forma correcta de hacerlo. Gran parte de esto sigue siendo empírico, moldeado por los sistemas que construimos y las limitaciones bajo las que operamos.
Si no se controla, el contexto crece, se desvía y, finalmente, colapsa por su propio peso.
Si se gestiona bien, el contexto se convierte en la diferencia entre un agente que simplemente responde y uno que puede razonar, adaptarse y mantenerse coherente en tareas largas y complejas.