Mantener los agentes de IA en tierra: Estrategias de ingeniería del contexto que evitan que éste se pudra utilizando Milvus

Si has trabajado con conversaciones de LLM de larga duración, probablemente hayas pasado por este frustrante momento: a mitad de un largo hilo, el modelo empieza a ir a la deriva. Las respuestas se vuelven vagas, el razonamiento se debilita y los detalles clave desaparecen misteriosamente. Pero si se le pide exactamente lo mismo en una nueva conversación, de repente el modelo se comporta de forma centrada, precisa y fundamentada.

No es que el modelo se esté "cansando", es que el contexto se está pudriendo. A medida que crece la conversación, el modelo tiene que hacer malabarismos con más información y su capacidad para establecer prioridades disminuye lentamente. Los estudios de Antropic demuestran que cuando las ventanas de contexto pasan de unos 8.000 tokens a 128.000, la precisión de la recuperación puede caer entre un 15 y un 30%. El modelo aún tiene espacio, pero pierde de vista lo que importa. Las ventanas de contexto más grandes ayudan a retrasar el problema, pero no lo eliminan.

Aquí es donde entra en juego la ingeniería del contexto. En lugar de dárselo todo al modelo de una vez, le damos forma a lo que ve: recuperando sólo las partes que importan, comprimiendo lo que ya no necesita ser verboso y manteniendo los avisos y herramientas lo suficientemente limpios para que el modelo pueda razonar sobre ellos. El objetivo es sencillo: hacer que la información importante esté disponible en el momento adecuado e ignorar el resto.

La recuperación desempeña aquí un papel fundamental, sobre todo en el caso de los agentes de larga duración. Las bases de datos vectoriales como Milvus proporcionan los cimientos para recuperar de forma eficiente los conocimientos relevantes en su contexto, lo que permite al sistema mantener los pies en la tierra incluso cuando las tareas crecen en profundidad y complejidad.

En este blog, veremos cómo se produce la rotación del contexto, las estrategias que utilizan los equipos para gestionarla y los patrones arquitectónicos -desde la recuperación hasta el diseño de avisos- que mantienen a los agentes de IA alerta a lo largo de flujos de trabajo largos y de varios pasos.

Por qué se pierde el contexto

A menudo se asume que dar más contexto a un modelo de IA conduce de forma natural a mejores respuestas. Pero eso no es cierto. Los humanos también tenemos problemas con las entradas largas: la ciencia cognitiva sugiere que nuestra memoria de trabajo contiene aproximadamente 7±2 trozos de información. Si vamos más allá, empezamos a olvidar, desdibujar o malinterpretar los detalles.

Los LLM muestran un comportamiento similar, pero a una escala mucho mayor y con modos de fallo más dramáticos.

El problema radica en la propia arquitectura de Transformer. Cada testigo debe compararse con todos los demás, formando pares de atención en toda la secuencia. Esto significa que el cálculo crece O(n²) con la longitud del contexto. Ampliar la solicitud de 1.000 fichas a 100.000 no hace que el modelo "trabaje más", sino que multiplica por 10.000 el número de interacciones entre fichas.

Luego está el problema de los datos de entrenamiento. Los modelos ven muchas más secuencias cortas que largas. Cuando se pide a un LLM que trabaje en contextos muy amplios, se le empuja a un régimen para el que no ha sido entrenado. En la práctica, el razonamiento en contextos muy largos suele estar fuera de distribución para la mayoría de los modelos.

A pesar de estos límites, el contexto largo es ahora inevitable. Las primeras aplicaciones LLM consistían principalmente en tareas de un solo turno: clasificación, resumen o generación simple. Hoy en día, más del 70% de los sistemas empresariales de IA se basan en agentes que permanecen activos durante muchas rondas de interacción, a menudo durante horas, gestionando flujos de trabajo ramificados y de múltiples pasos. Las sesiones de larga duración han pasado de ser una excepción a convertirse en algo predeterminado.

Entonces, la siguiente pregunta es: ¿cómo mantenemos la atención del modelo sin abrumarlo?

Enfoques de recuperación del contexto para resolver la putrefacción del contexto

La recuperación es una de las palancas más eficaces que tenemos para combatir la putrefacción del contexto, y en la práctica tiende a aparecer en modelos complementarios que abordan la putrefacción del contexto desde distintos ángulos.

1. Recuperación "justo a tiempo": Reducción del contexto innecesario

Una de las principales causas de la descomposición del contexto es sobrecargar el modelo con información que aún no necesita. Claude Code -el asistente de codificación de Anthropic- resuelve este problema con la recuperación Just-in-Time (JIT), una estrategia en la que el modelo obtiene información sólo cuando es relevante.

En lugar de almacenar bases de código o conjuntos de datos enteros en su contexto (lo que aumenta enormemente la probabilidad de deriva y olvido), Claude Code mantiene un pequeño índice: rutas de archivos, comandos y enlaces a documentación. Cuando el modelo necesita un elemento de información, lo recupera y lo inserta en el contexto en elmomento en que importa, noantes.

Por ejemplo, si le pide a Claude Code que analice una base de datos de 10 GB, nunca intenta cargarla entera. Trabaja más como un ingeniero:

1. Ejecuta una consulta SQL para obtener resúmenes de alto nivel del conjunto de datos.

2. Utiliza comandos como head y tail para ver datos de muestra y comprender su estructura.

3. Conserva sólo la información más importante -como estadísticas clave o filas de muestra- dentro del contexto.

Al minimizar lo que se guarda en el contexto, la recuperación JIT evita la acumulación de tokens irrelevantes que provocan la putrefacción. El modelo se mantiene centrado porque sólo ve la información necesaria para el paso de razonamiento actual.

2. Pre-recuperación (búsqueda vectorial): Evitar la deriva del contexto antes de que empiece

A veces, el modelo no puede "pedir" información de forma dinámica: los sistemas de atención al cliente, de preguntas y respuestas y los flujos de trabajo de los agentes a menudo necesitan disponer de los conocimientos adecuados antes de que comience la generación. Aquí es donde la recuperación previa es fundamental.

La pérdida de contexto suele deberse a que el modelo recibe una gran pila de texto sin procesar y se espera que clasifique lo que importa. La recuperación previa invierte esta situación: una base de datos vectorial (como Milvus y Zilliz Cloud) identifica las piezas más relevantes antes de la inferencia, garantizando que sólo el contexto de alto valor llega al modelo.

En una configuración RAG típica

• Los documentos se incrustan y almacenan en una base de datos vectorial, como Milvus.

• En el momento de la consulta, el sistema recupera un pequeño conjunto de fragmentos muy relevantes mediante búsquedas de similitud.

• Sólo esos fragmentos entran en el contexto del modelo.

De este modo se evita la putrefacción de dos maneras:

• Reducción del ruido: el texto irrelevante o poco relacionado nunca entra en el contexto.

• Eficacia: los modelos procesan muchos menos tokens, lo que reduce la posibilidad de perder de vista detalles esenciales.

Milvus puede buscar millones de documentos en milisegundos, lo que hace que este enfoque sea ideal para sistemas en vivo en los que la latencia importa.

3. Recuperación vectorial y JIT híbrida

La recuperación previa basada en la búsqueda vectorial aborda una parte importante de la pérdida de contexto al garantizar que el modelo comience con información de alta señal en lugar de con texto sin procesar y sobredimensionado. Pero Anthropic pone de relieve dos retos reales que los equipos suelen pasar por alto:

• La puntualidad: Si la base de conocimientos se actualiza más rápido de lo que se reconstruye el índice vectorial, el modelo puede basarse en información obsoleta.

• Precisión: antes de que comience una tarea, es difícil predecir con exactitud lo que necesitará el modelo, especialmente en el caso de flujos de trabajo exploratorios o de varios pasos.

Por ello, en las cargas de trabajo del mundo real, la solución óptima es un appaorch híbrido.

• Búsqueda vectorial de conocimientos estables y de alta confianza

• Exploración JIT dirigida por agentes para información que evoluciona o que sólo se vuelve relevante a mitad de la tarea

Al combinar estos dos enfoques, se obtiene la velocidad y eficacia de la recuperación vectorial para la información conocida, y la flexibilidad para que el modelo descubra y cargue nuevos datos siempre que sean relevantes.

Veamos cómo funciona esto en un sistema real. Tomemos como ejemplo un asistente de documentación de producción. La mayoría de los equipos se deciden finalmente por un proceso en dos etapas: Búsqueda vectorial impulsada por Milvus + recuperación JIT basada en agentes.

1. Búsqueda vectorial con Milvus (Pre-recuperación)

• Convierta su documentación, referencias API, registros de cambios y problemas conocidos en incrustaciones.

• Almacénelos en la base de datos vectorial de Milvus con metadatos como el área del producto, la versión y la hora de actualización.

• Cuando un usuario formule una pregunta, ejecute una búsqueda semántica para obtener los K segmentos más relevantes.

Esto resuelve aproximadamente el 80% de las consultas rutinarias en menos de 500 ms, lo que proporciona al modelo un punto de partida sólido y resistente al contexto.

2. Exploración basada en agentes

Cuando la recuperación inicial no es suficiente (por ejemplo, cuando el usuario pide algo muy específico o urgente), el agente puede recurrir a herramientas para obtener nueva información:

• Utilice search_code para localizar funciones o archivos específicos en el código base.

• Utilizar run_query para obtener datos en tiempo real de la base de datos.

• Utilice fetch_api para obtener el estado más reciente del sistema

Estas llamadas suelen tardar entre 3 y 5 segundos, pero garantizan que el modelo funcione siempre con datos actualizados, precisos y relevantes, incluso para cuestiones que el sistema no podía prever de antemano.

Esta estructura híbrida garantiza que el contexto siga siendo oportuno, correcto y específico de la tarea, lo que reduce drásticamente el riesgo de que se pierda el contexto en los flujos de trabajo de agentes de larga duración.

Milvus es especialmente eficaz en estos escenarios híbridos porque admite:

• Búsqueda vectorial + filtrado escalar, que combina la relevancia semántica con restricciones estructuradas.

• Actualizaciones incrementales, que permiten refrescar las incrustaciones sin tiempo de inactividad.

Esto convierte a Milvus en una columna vertebral ideal para los sistemas que necesitan tanto comprensión semántica como control preciso sobre lo que se recupera.

Por ejemplo, puede ejecutar una consulta del tipo:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Cómo elegir el enfoque adecuado para tratar la putrefacción del contexto

Con la recuperación previa de búsqueda vectorial, la recuperación "Just-in-Time" y la recuperación híbrida, la pregunta natural es: ¿cuál debería utilizar?

He aquí una forma sencilla pero práctica de elegir en función de la estabilidad de sus conocimientos y de la previsibilidad de las necesidades de información del modelo.

1. Búsqueda vectorial → Mejor para dominios estables

Si el dominio cambia lentamente pero exige precisión-finanzas, trabajo legal, cumplimiento, documentación médica-entonces una base de conocimiento impulsada por Milvus con pre-recuperación suele ser la adecuada.

La información está bien definida, las actualizaciones son poco frecuentes y la mayoría de las preguntas pueden responderse recuperando documentos semánticamente relevantes por adelantado.

Tareas predecibles + conocimiento estable → Pre-recuperación.

2. Mejor para flujos de trabajo dinámicos y exploratorios.

Campos como la ingeniería de software, la depuración, la analítica y la ciencia de datos implican entornos que cambian rápidamente: nuevos archivos, nuevos datos, nuevos estados de despliegue. El modelo no puede predecir lo que necesitará antes de que comience la tarea.

Tareas impredecibles + conocimientos que cambian rápidamente → Recuperación justo a tiempo.

3. Enfoque híbrido → Cuando se cumplen ambas condiciones

Muchos sistemas reales no son puramente estables ni puramente dinámicos. Por ejemplo, la documentación de los desarrolladores cambia lentamente, mientras que el estado de un entorno de producción cambia minuto a minuto. Un enfoque híbrido le permite:

• Cargar conocimientos conocidos y estables mediante la búsqueda vectorial (rápida y de baja latencia).

• Obtener información dinámica con herramientas de agente bajo demanda (precisa, actualizada)

Conocimiento mixto + estructura de tareas mixta → Enfoque de recuperación híbrido.

¿Y si la ventana de contexto no es suficiente?

La ingeniería del contexto ayuda a reducir la sobrecarga, pero a veces el problema es más fundamental: la tarea simplemente no cabe, incluso con un recorte cuidadoso.

Algunos flujos de trabajo, como la migración de una base de código de gran tamaño, la revisión de arquitecturas de múltiples repositorios o la generación de informes de investigación exhaustivos, pueden superar los 200.000 ventanas de contexto antes de que el modelo llegue al final de la tarea. Incluso con la búsqueda vectorial haciendo el trabajo pesado, algunas tareas requieren una memoria más persistente y estructurada.

Recientemente, Anthropic ha ofrecido tres estrategias prácticas.

1. 1. Compresión: Preservar la señal, eliminar el ruido

Cuando la ventana de contexto se acerca a su límite, el modelo puede comprimir las interacciones anteriores en resúmenes concisos. Una buena compresión mantiene

• Decisiones clave

• Restricciones y requisitos

• Cuestiones pendientes

• Muestras o ejemplos relevantes

Y elimina

• Salidas verbosas de la herramienta

• Registros irrelevantes

• Pasos redundantes

El reto es el equilibrio. Si se comprime demasiado, el modelo pierde información crítica; si se comprime demasiado poco, se gana poco espacio. Una compresión eficaz conserva el "por qué" y el "qué", pero descarta el "cómo hemos llegado hasta aquí".

2. Toma de notas estructurada: Mover la información estable fuera del contexto

En lugar de guardarlo todo dentro de la ventana del modelo, el sistema puede almacenar los hechos importantes en una memoria externa:una base de datos independiente o un almacén estructurado que el agente pueda consultar cuando lo necesite.

Por ejemplo, el prototipo de agente Pokémon de Claude almacena datos duraderos como:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

Mientras tanto, los detalles transitorios -registros de batalla, resultados de herramientas largas- permanecen fuera del contexto activo. Esto refleja la forma en que los humanos utilizamos los cuadernos: no guardamos todos los detalles en nuestra memoria de trabajo, sino que almacenamos puntos de referencia externos y los consultamos cuando los necesitamos.

La toma de notas estructurada evita la pérdida de contexto provocada por la repetición de detalles innecesarios, al tiempo que proporciona al modelo una fuente fiable de verdad.

3. Arquitectura de subagentes: Dividir y conquistar grandes tareas

Para tareas complejas, puede diseñarse una arquitectura multiagente en la que un agente principal supervise el trabajo global, mientras varios subagentes especializados se encargan de aspectos específicos de la tarea. Estos subagentes profundizan en grandes cantidades de datos relacionados con sus subtareas, pero sólo devuelven los resultados concisos y esenciales. Este enfoque suele utilizarse en situaciones como informes de investigación o análisis de datos.

En la práctica, lo mejor es empezar utilizando un único agente combinado con compresión para gestionar la tarea. El almacenamiento externo sólo debe introducirse cuando exista la necesidad de conservar la memoria a lo largo de las sesiones. La arquitectura multiagente debe reservarse para tareas que realmente requieran el procesamiento paralelo de subtareas complejas y especializadas.

Cada uno de estos enfoques amplía la "memoria de trabajo" efectiva del sistema sin reventar la ventana de contexto y sin provocar la rotación del contexto.

Mejores prácticas para diseñar un contexto que realmente funcione

Después de gestionar el desbordamiento del contexto, hay otra pieza igualmente importante: cómo se construye el contexto en primer lugar. Incluso con compresión, notas externas y subagentes, el sistema tendrá problemas si las instrucciones y las herramientas no están diseñadas para soportar razonamientos largos y complejos.

Anthropic ofrece una manera útil de pensar en esto, menos como un solo ejercicio de escritura, y más como la construcción de contexto a través de tres capas.

Sistema de estímulos: Encontrar la zona Goldilocks

La mayoría de las instrucciones sobre sistemas fracasan en los extremos. Demasiados detalles (listas de reglas, condiciones anidadas, excepciones codificadas) hacen que el aviso sea frágil y difícil de mantener. Demasiada poca estructura deja al modelo adivinando qué hacer.

Las mejores instrucciones se sitúan en un término medio: lo suficientemente estructuradas como para guiar el comportamiento y lo suficientemente flexibles como para que el modelo pueda razonar. En la práctica, esto significa dar al modelo un papel claro, un flujo de trabajo general y una ligera guía de herramientas, ni más ni menos.

Por ejemplo:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Este aviso marca la dirección sin abrumar al modelo ni obligarle a hacer malabarismos con información dinámica que no corresponde.

Diseño de herramientas: Menos es más

Una vez que el sistema establece el comportamiento de alto nivel, las herramientas se encargan de la lógica operativa real. Un modo de fallo sorprendentemente común en los sistemas aumentados por herramientas es simplemente tener demasiadas herramientas, o tener herramientas cuyos propósitos se solapan.

Una buena regla general

• Una herramienta, un propósito

• Parámetros explícitos e inequívocos

• Sin solapamiento de responsabilidades

Si un ingeniero humano dudara sobre qué herramienta utilizar, el modelo también lo haría. Un diseño limpio de las herramientas reduce la ambigüedad, disminuye la carga cognitiva y evita que el contexto se sature con intentos innecesarios de utilizar herramientas.

La información dinámica debe recuperarse, no codificarse

La última capa es la más fácil de pasar por alto. La información dinámica o sensible al tiempo, como los valores de estado, las actualizaciones recientes o el estado específico del usuario, no debe aparecer en absoluto en el indicador del sistema. Incluirla en el prompt garantiza que se volverá obsoleta, hinchada o contradictoria en tareas largas.

En su lugar, esta información debe obtenerse sólo cuando sea necesario, ya sea a través de la recuperación o a través de herramientas de agente. Mantener el contenido dinámico fuera del sistema evita que se pierda el contexto y mantiene limpio el espacio de razonamiento del modelo.

Conclusión

A medida que los agentes de IA se introducen en los entornos de producción de distintos sectores, asumen flujos de trabajo más largos y tareas más complejas que nunca. En estos entornos, la gestión del contexto se convierte en una necesidad práctica.

Sin embargo, una ventana de contexto más grande no produce automáticamente mejores resultados; en muchos casos, hace lo contrario. Cuando se sobrecarga un modelo, se le proporciona información obsoleta o se le obliga a responder a preguntas masivas, la precisión disminuye silenciosamente. Ese lento y sutil declive es lo que ahora llamamos "putrefacción del contexto".

Técnicas como la recuperación JIT, la recuperación previa, los conductos híbridos y la búsqueda semántica basada en bases de datos vectoriales persiguen el mismo objetivo: garantizar que el modelo vea la información correcta en el momento adecuado, ni más ni menos, para que pueda mantener los pies en la tierra y producir respuestas fiables.

Como base de datos vectorial de alto rendimiento y código abierto, Milvus se sitúa en el núcleo de este flujo de trabajo. Proporciona la infraestructura necesaria para almacenar los conocimientos de forma eficiente y recuperar las piezas más relevantes con baja latencia. Junto con la recuperación JIT y otras estrategias complementarias, Milvus ayuda a los agentes de IA a mantener la precisión a medida que sus tareas se hacen más profundas y dinámicas.

Pero la recuperación es sólo una pieza del rompecabezas. Un buen diseño de las instrucciones, un conjunto de herramientas limpias y mínimas, y unas estrategias de desbordamiento sensatas -ya sea compresión, notas estructuradas o subagentes- trabajan conjuntamente para mantener el modelo centrado en sesiones de larga duración. Así es la verdadera ingeniería contextual: no se trata de ingeniosos hacks, sino de una arquitectura bien pensada.

Si desea que los agentes de IA sean precisos durante horas, días o flujos de trabajo completos, el contexto merece la misma atención que prestaría a cualquier otra parte fundamental de su pila.

¿Tienes preguntas o quieres que profundicemos en alguna función? Únete a nuestro canal de Discord o presenta incidencias en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.