¿Qué es la ingeniería de contexto?

El mensaje de sistema establece el contexto fundamental del agente: su identidad, capacidades, restricciones y pautas de comportamiento. A diferencia de las indicaciones del usuario que cambian con cada interacción, la indicación del sistema se mantiene relativamente estable y actúa como una "personalidad" persistente y un libro de reglas. Los prompts de sistema efectivos equilibran tres demandas en competencia: especificidad (lo suficientemente clara para prevenir comportamientos ambiguos), flexibilidad (lo suficientemente general para manejar situaciones diversas) y concisión (lo suficientemente breve para preservar el espacio contextual de la ventana). Estas son algunas de las prácticas recomendadas:

• Definir el rol del agente explícitamente ("Eres un asistente de analista financiero...")
• Proporcionar ejemplos concretos de comportamiento deseado en lugar de reglas abstractas
• Usar delimitadores estructurados (etiquetas XML, secciones de markdown) para organizar instrucciones que faciliten la comprensión del modelo
• Colocar restricciones críticas (reglas de seguridad, requisitos de formato de salida) en posiciones prominentes, ya que los modelos presentan sesgo posicional

Las técnicas avanzadas incluyen instrucciones condicionales que se activan en función del contexto de ejecución (por ejemplo, "Si el usuario pregunta por información personal, redirígete a la política de privacidad") y metainstrucciones que guían el proceso de razonamiento del agente (por ejemplo, "Piensa paso a paso antes de proporcionar análisis"). El prompt del sistema es particularmente vulnerable a la competencia en ventanas de contexto; a medida que se acumulan el historial de conversaciones, las salidas de herramientas y los datos recuperados, los prompts de sistema mal diseñados se desplazan fuera de la capacidad de atención efectiva del modelo, causando una deriva conductual en la que el agente gradualmente "olvida" sus instrucciones principales.

La memoria a largo plazo permite a una IA retener información a través de múltiples sesiones o conversaciones. A diferencia de la memoria a corto plazo, que es efímera y se pierde al final de una sesión, la memoria a largo plazo permite a una IA recordar las preferencias del usuario, las interacciones pasadas y los datos aprendidos para referencia futura.

El estado y el historial constituyen la memoria de trabajo del agente de la sesión actual: el registro de lo que se ha dicho, hecho y aprendido dentro de una interacción en curso. Esta memoria a corto plazo permite la continuidad conversacional; el agente puede hacer referencia a intercambios anteriores sin obligar a los usuarios a repetir el contexto. Sin embargo, el historial de conversación crece linealmente con la longitud de la interacción, consumiendo rápidamente la ventana de contexto.

Una ingeniería de contexto efectiva requiere estrategias de gestión de memoria activas. El resumen comprime los intercambios más antiguos en representaciones concisas y al mismo tiempo preserva hechos y decisiones clave. Windowing mantiene solo los N mensajes más recientes, descartando el historial anterior bajo el supuesto de que el contexto reciente es el que más importa. Retención selectiva aplica heurísticas para identificar y preservar información crítica (preferencias del usuario, hechos establecidos, preguntas abiertas) mientras poda el relleno conversacional rutinario.

Los enfoques más sofisticados utilizan estructuras de memoria episódica donde el agente escribe un estado importante en almacenamiento externo y lo recupera a demanda, imitando cómo los humanos no retienen conversaciones completas en memoria de trabajo activa, sino que pueden recordar detalles específicos cuando lo requieren. El desafío es mantener la coherencia; una poda demasiado agresiva hace que el agente "olvide" contexto clave y repita errores, mientras una compresión insuficiente provoca desbordamiento de contexto y degradación del rendimiento.

Retrieval-Augmented Generation (RAG) implica que la IA recupere datos externos "justo a tiempo" de una base de conocimientos, como documentos internos de la empresa o sitios web públicos. RAG permite a la IA responder preguntas utilizando información con la que no se había entrenado originalmente, lo que garantiza que sus respuestas sean actuales y precisas.

La fragmentación semántica mejora la recuperación al estructurar la información de forma lógica. En lugar de dividir el texto en fragmentos arbitrarios de tamaño fijo, la fragmentación semántica agrupa conceptos relacionados (por ejemplo, por párrafos, funciones o secciones lógicas). Cuando se recupera un fragmento relevante, también se incluyen sus alrededores inmediatos. Esto proporciona al LLM un contexto más coherente y completo, lo que lo ayuda a razonar de forma más efectiva y a mitigar los problemas derivados de la información fragmentada.

La búsqueda híbrida es fundamental para la ingeniería de contexto porque confiar en un solo método de recuperación a menudo falla. La búsqueda vectorial destaca por encontrar información conceptualmente similar (por ejemplo, "ropa de verano" encuentra "conjuntos para clima cálido"), pero puede pasar por alto términos específicos y precisos. La búsqueda por palabras clave (como BM25) destaca encontrando coincidencias exactas (por ejemplo, "SKU-123AB") pero falla con los sinónimos. Al combinar ambos en una única consulta unificada, la búsqueda híbrida garantiza que el LLM reciba el contexto más preciso y equilibrado posible, capturando tanto la intención conceptual del usuario como cualquier palabra clave crítica.

Reclasificación resuelve el compromiso de "velocidad vs. precisión" inherente en la recuperación a gran escala. La búsqueda inicial (como la búsqueda híbrida) está optimizada para recuperar rápidamente un gran conjunto de documentos potencialmente relevantes (por ejemplo, los 100 principales). Un modelo de reclasificación (que suele ser más costoso computacionalmente pero mucho más preciso) se utiliza para volver a puntuar solo este subconjunto más pequeño. Para la ingeniería de contexto, esto es vital porque asegura que los fragmentos absolutamente mejores y más relevantes se coloquen en la parte superior de la ventana de contexto, lo cual es esencial para mitigar el problema de "perderse en el medio" y enfocar la atención del LLM en la información de la más alta calidad.

Las herramientas amplían las capacidades de un agente más allá de la generación de texto, ya que permiten la interacción con sistemas externos: ejecutar código, consultar bases de datos, llamar a API o manipular archivos. Desde el punto de vista de la ingeniería de contexto, las herramientas plantean un reto único: cada herramienta requiere una descripción (nombre, finalidad, parámetros, ejemplos de uso) que ocupa espacio en la ventana de contexto. A medida que crecen las bibliotecas de herramientas, esta "sobrecarga del contexto de la herramienta" se vuelve significativa. Un agente de 100 herramientas puede dedicar 30%–40% de su ventana de contexto solo describiendo las capacidades disponibles antes de que comience la tarea real del usuario.

La ingeniería eficaz de herramientas sigue varios principios:

• Mantén las descripciones de las herramientas concisas pero sin ambigüedades: Incluye el propósito de la herramienta, los parámetros requeridos con sus tipos y un ejemplo canónico.
• Herramientas de diseño que sean componibles: las herramientas más pequeñas y enfocadas (por ejemplo, "search_documents", "summarize_text") se combinan de forma más flexible que las herramientas monolíticas que intentan manejar varios escenarios.
• Implementar categorías de herramientas o espacios de nombres para permitir la carga selectiva: un agente que trabaja en análisis financiero no necesita herramientas para procesamiento de imágenes.
• Usar el filtrado de resultados de la herramienta: arroja solo la información esencial al agente, no las respuestas sin procesar de la API. Una herramienta de consulta de base de datos debería arrojar "Se encontraron 3 transacciones relevantes por un total de $4532" en lugar de conjuntos de resultados SQL completos.

Las herramientas bien diseñadas también incluyen la gestión de errores en sus descripciones para enseñarle al agente cómo recuperarse de las fallas en vez de propagar errores en el flujo de trabajo.

Búsqueda agencial

La búsqueda agencial es una herramienta especializada de subagente que realiza exploraciones complejas y de múltiples pasos en su propio contexto aislado. Por ejemplo, puede traducir una solicitud en lenguaje natural a una consulta ESQL precisa, encontrar los datos y arrojar solo un resumen conciso al agente principal, manteniendo limpia tu memoria de trabajo.

Flujos de trabajo específicos del dominio

Los flujos de trabajo específicos de cada dominio son cadenas de herramientas predefinidas y deterministas diseñadas para procesos empresariales predecibles y de alto riesgo, en los que la fiabilidad y la consistencia prevalecen sobre la flexibilidad exploratoria. A diferencia de los agentes de propósito general que razonan dinámicamente cada paso, estos flujos de trabajo siguen una secuencia estricta y validada. Por ejemplo: "Verificar la identidad del cliente → comprobar el historial crediticio → el control regulatorio externo → calcular el puntaje de riesgo → generar un reporte de cumplimiento". Cada paso tiene criterios de éxito explícitos, gestión de errores y procedimientos de reversión.

Esta rigidez es intencional; previene que la imprevisibilidad inherente al razonamiento basado en LLM afecte las operaciones de misión crítica como aprobaciones financieras, diagnósticos médicos o cumplimiento normativo. Desde el punto de vista de la ingeniería de contextos, los flujos de trabajo de dominio simplifican la tarea del agente reduciendo los grados de libertad. El agente no necesita contexto sobre todas las herramientas y estrategias posibles, solo la información específica requerida para el paso del flujo de trabajo actual. Este contexto específico mejora tanto la precisión como la eficiencia.

La implementación suele implicar máquinas de estados o grafos acíclicos dirigidos (DAGs), donde el LLM gestiona elementos variables (análisis de la entrada del usuario, selección de fuentes de datos, generación de resúmenes en lenguaje natural), mientras que la lógica determinista controla el flujo general del proceso. El compromiso es una reducción de la adaptabilidad; estos flujos de trabajo destacan en escenarios conocidos, pero tienen dificultades cuando los casos límite se salen del camino predefinido.

Descubrimiento dinámico de herramientas

El descubrimiento dinámico de herramientas aborda el problema de la 'proliferación de herramientas' que ocurre cuando los agentes tienen acceso a grandes bibliotecas de herramientas. En lugar de enumerar cientos de descripciones de herramientas en el indicador del sistema (lo que consume un valioso espacio en la ventana de contexto y reduce la precisión en la selección de herramientas), esta estrategia utiliza la búsqueda semántica en el metadato de las herramientas para recuperar solo las capacidades relevantes en tiempo de ejecución.

Cuando un agente recibe una tarea, consulta un registro de herramientas usando la descripción de la tarea como entrada, recuperando de 3 a 5 herramientas semánticamente similares para ese contexto específico. Este enfoque refleja la recuperación de datos justo a tiempo: las herramientas permanecen en almacenamiento externo hasta que se necesitan, y la atención del agente se mantiene centrada en las capacidades aplicables en lugar de diluirse en un catálogo exhaustivo. Algunos protocolos, como MCP (Model Context Protocol), estandarizan este patrón proporcionando registros donde se pueden descubrir, entender e invocar herramientas dinámicamente. Sin embargo, el descubrimiento dinámico introduce latencia (la propia operación de búsqueda) y requiere una ingeniería cuidadosa para prevenir que el agente seleccione herramientas subóptimas o persiga callejones sin salida cuando las descripciones de las herramientas son ambiguas.

La indicación del usuario es la entrada directa que desencadena el comportamiento del agente y define el contexto inmediato de la tarea. A diferencia del prompt del sistema (que permanece relativamente estático), el prompt del usuario varía con cada interacción y tiene el mayor peso de atención en la mayoría de las arquitecturas LLM. Este sesgo posicional significa que los prompts del usuario a menudo anulan la información conflictiva en otras partes del contexto.

La ingeniería de contexto eficaz trata las indicaciones de los usuarios como algo más que simples preguntas; pueden incluir pistas contextuales explícitas (marcas de tiempo, preferencias de los usuarios, estado de la sesión) que guían la recuperación y la selección de herramientas sin sobrecargar las indicaciones del sistema. Para los agentes con estado, el mensaje de usuario se convierte en el punto de entrada donde se inyecta la información específica de la sesión; por ejemplo, "dada nuestra conversación sobre las métricas trimestrales..." indica al agente que priorice los datos financieros recuperados recientemente. Sin embargo, las indicaciones de los usuarios también representan el elemento más impredecible del contexto y pueden ser ambiguas, contradictorias o conflictivas. La ingeniería de contexto debe tener en cuenta esta variabilidad mediante modelos de comprensión de consultas que reformulan las solicitudes poco claras, filtros de seguridad que detectan intentos de inyección de comandos y estrategias alternativas cuando no es posible inferir de forma fiable la intención del usuario a partir de la entrada por sí sola.

Salida estructurada se refiere a la información que una IA necesita formatear de manera específica, como JSON, XML o tabla. Al definir una salida estructurada, las respuestas de IA pueden ser consistentes y fácilmente utilizables por otros programas o sistemas.

Para una exploración más profunda de estos conceptos, lee la publicación de blog completa: Visión general de la ingeniería de contexto.

La práctica de la ingeniería de contexto se entiende mejor como el diseño de un pipeline sistemático construido para soportar el LLM. En lugar de limitarse a combinar varios componentes de forma ad hoc, este pipeline se adapta a una tarea específica y está diseñado para gestionar todo el flujo de información hacia y desde el modelo en cada etapa del ciclo. Este pipeline se divide típicamente en tres etapas de núcleo:

1. Recuperación y generación de contexto: Esta etapa implica obtener activamente datos sin procesar de una amplia gama de entradas potenciales, como recuperar documentos de una base de datos vectorial, consultar una base de datos SQL estructurada o realizar llamadas API a servicios externos.
2. Procesamiento de contexto: una vez reunida, la información sin procesar se optimiza. Esto implica transformar los datos para maximizar su relación señal-ruido utilizando técnicas como la fragmentación, el resumen, la compresión y la estructuración.
3. Gestión del contexto: esta etapa final rige la forma en que se almacena, actualiza y utiliza la información en múltiples interacciones. Es crucial para la construcción de aplicaciones con estado e implica estrategias tanto para la memoria a corto plazo (sesión) como para la memoria a largo plazo (persistente).

La estrategia más poderosa es mantener la información fuera de la ventana de contexto y recuperarla "justo a tiempo" cuando el agente la necesite. Esto refleja cómo trabajamos los seres humanos: no memorizamos bibliotecas enteras; usamos motores de búsqueda y sistemas de archivo para encontrar lo que necesitamos cuando lo necesitamos.

Para un agente de IA, esto significa consultar una base de conocimientos externa. Sin embargo, encontrar la información adecuada supone un reto importante. A medida que los datos aumentan, la búsqueda semántica simple puede volverse poco confiable. Una selección eficaz suele requerir un enfoque híbrido, que combine varias técnicas de búsqueda, como la recuperación por palabras clave, semántica y basada en grafos, para identificar el contexto exacto que se necesita a partir de sets de datos vastos y complejos.

Esta estrategia le da a un agente un lugar para descargar información escribiendo en una memoria externa, como un archivo "scratchpad" o una base de datos dedicada. Por ejemplo, un agente puede guardar su plan de varios pasos en un archivo y consultarlo, previniendo que el plan sea expulsado de una ventana de contexto saturada. Esto permite al agente mantener el estado y seguir el progreso en tareas de larga duración sin saturar su memoria de trabajo.

Las técnicas de compresión reducen el número de tokens en la ventana de contexto, al tiempo que conservan la información esencial.

• Resumen: emplea un LLM para destilar largas conversaciones o documentos en resúmenes concisos. Por ejemplo, la salida completa y llena de tokens de una herramienta puede ser reemplazada por un breve resumen de sus resultados.
• Recorte: filtra el contexto usando reglas codificadas, como eliminar los mensajes más antiguos en una conversación o borrar las salidas redundantes de herramientas que ya no son necesarias.

Para tareas muy complejas, un solo agente puede sentirse abrumado. El aislamiento implica desglosar el problema y asignar subtareas a "subagentes" especializados, cada uno con su propia ventana de contexto limpia y enfocada. Un agente principal coordina este equipo, recibiendo solo las salidas finales destiladas de cada especialista. Este enfoque mantiene el contexto de cada agente relevante y manejable, mejorando el rendimiento general en tareas complejas de investigación o análisis.

Al seguir estos principios, la ingeniería de contexto tiene como objetivo proporcionar al LLM el conjunto más pequeño posible de tokens de alta señal que maximice la posibilidad de un resultado exitoso: una respuesta relevante.

En su fundamento, la ingeniería de contexto está moldeada por una restricción fundamental: los LLMs tienen presupuestos de atención finitos. La ventana de contexto (medida en tokens) define la cantidad máxima de información que un modelo puede procesar a la vez. Aunque los modelos modernos admiten ventanas de contexto cada vez más grandes (100 000, 1 millón o incluso 2 millones de tokens), el hecho de llenar este espacio no garantiza un mejor rendimiento.

Los LLM operan con arquitectura de transformadores, donde cada token debe atender a todos los demás tokens. A medida que el contexto crece, esto genera sobrecarga computacional y lo que los profesionales llaman "podredumbre del contexto": la capacidad del modelo para mantener el enfoque y recordar detalles específicos se degrada a medida que aumenta la carga de información. Este fenómeno refleja los límites cognitivos humanos; más información no siempre significa mejores decisiones.

El simple hecho de ampliar la ventana presenta desafíos importantes:

• Aumento de costos y latencia: la complejidad computacional del mecanismo de atención de la arquitectura Transformer crece cuadráticamente ($O(n^2)$) con la longitud de la secuencia, haciendo que los contextos más grandes sean exponencialmente más costosos y lentos.
• Degradación del rendimiento ("perderse en el medio"): los LLM muestran una fuerte capacidad de recuperación de la información al principio o al final de una ventana de contexto larga, pero sufren una caída significativa en el rendimiento para la información ubicada en el medio.
• Ruido y distracción: una ventana de contexto más grande aumenta la probabilidad de incluir información irrelevante "ruidosa", lo que puede distraer al modelo y degradar la calidad de la salida. Esto a menudo se llama el problema de la "aguja en el pajar".

Esta paradoja refuerza la necesidad de una curaduría inteligente, no solo de fuerza bruta, haciendo que la ingeniería de contexto sea en cierta medida un arte refinado.

El principal impulsor de la ingeniería de contexto es garantizar que un agente pueda completar su tarea de manera exitosa y confiable. Sin un contexto preciso y relevante y las herramientas correctas, un agente fallará al alucinar, seleccionar la herramienta incorrecta o no poder ejecutar un plan de varios pasos. Este es el problema fundamental que resuelve la ingeniería de contexto.

La calidad de salida en sistemas diseñados según el contexto se refiere a qué tan bien se alinean las respuestas del agente con la intención del usuario, la precisión fáctica y los requisitos de la tarea, a diferencia de la mera fluidez o coherencia, que los LLM logran de manera natural. Una salida de alta calidad depende fundamentalmente de un contexto de entrada de alta calidad; el principio "basura que entra, basura que sale" se aplica directamente.

La ingeniería de contexto mejora la calidad de salida mediante varios mecanismos:

• La calidad de la recuperación garantiza que el agente acceda a material fuente preciso y relevante en lugar de alucinar o depender de datos de entrenamiento obsoletos.
• La estructura del contexto afecta la eficacia con la que el modelo puede extraer y sintetizar información.
• Un contexto bien estructurado y semánticamente coherente produce un razonamiento más preciso que los fragmentos desconectados.
• La relación señal-ruido es importante: incluir cinco documentos altamente relevantes supera el rendimiento, incluso al incluir esos mismos cinco más veinte documentos marginalmente relacionados, ya que la información irrelevante distrae la atención del modelo.

La calidad de salida también depende de la claridad de instrucciones en la indicación del sistema y de los requisitos explícitos de formato (salidas estructuradas como JSON reducen errores de análisis sintáctico). Medir la calidad requiere evaluación específica de la tarea: precisión fáctica para sistemas RAG, tasas de finalización de tareas para agentes, puntajes de satisfacción del usuario para sistemas conversacionales. La ingeniería de contexto permite una mejora sistemática de la calidad haciendo que la relación entrada-salida sea observable y ajustable; puedes medir qué combinaciones de contexto producen mejores resultados y optimizar la recuperación, el ranking y el filtrado en consecuencia.

Cada token en la ventana de contexto conlleva costos: recursos computacionales, cargos de API y latencia. La ingeniería de contexto impacta directamente en estos tres factores:

• Optimización de costos: reducir tokens innecesarios en indicaciones puede disminuir los costos de API por órdenes de magnitud en aplicaciones de alto volumen.
• Reducción de latencia: los contextos más pequeños y enfocados significan tiempos de inferencia más rápidos y aplicaciones más receptivas.
• Mejora de la calidad: un contexto de alta señal y específico supera de manera consistente a volcados de información grandes y desenfocados.

Los sistemas de IA de producción deben ser resilientes. Una mala ingeniería de contexto conduce a varios modos de fallo:

• Envenenamiento por contexto: cuando las alucinaciones o los errores se incrustan en el contexto y se agravan a través de interacciones posteriores
• Desviación de objetivos: cuando la acumulación de información irrelevante hace que los agentes pierdan de vista sus objetivos originales
• Desbordamiento de capacidad: cuando la información crítica se trunca a medida que la ventana de contexto se llena con datos de menor prioridad

Una buena ingeniería de contexto previene estos problemas mediante validación, poda y gestión estructurada de la memoria. Tratar el contexto como un recurso cuidadosamente seleccionado en lugar de un acumulador pasivo de información.