El problema
Un equipo construye un agente de soporte que necesita tres tipos de información: la política de reembolsos de la empresa, el historial completo del ticket actual y el estado más reciente del pedido del cliente. Alguien decide simplificar: pega el manual de políticas entero, el historial completo del ticket y todo el registro de eventos del pedido en cada llamada a la API, "para asegurarse de que el modelo tenga todo lo necesario". El contexto crece exponencialmente, el costo por llamada se dispara y la tasa de acierto cae — porque el único párrafo de la política relevante para ese ticket queda sepultado bajo diez páginas de texto genérico.
El error fundamental no fue incluir demasiada información. Fue tratar la ubicación de un dato como una decisión uniforme — arrojar todo al mismo lugar — cuando en realidad existen al menos cuatro destinos diferentes para un hecho, cada uno adecuado para un tipo específico de información.
Cuatro destinos, tres preguntas
Para cada hecho que una aplicación necesita manejar, tres dimensiones arquitectónicas definen dónde debe residir:
- Volatilidad: ¿este dato cambia en cada llamada o permanece estable durante días o semanas?
- Volumen: ¿el conjunto de datos cabe por completo de forma predecible o es tan extenso que solo una fracción es relevante por consulta?
- Alcance: ¿el dato pertenece únicamente a este turno, a toda esta sesión activa o debe persistir entre sesiones independientes a lo largo del tiempo?
A partir de estas respuestas, se definen con claridad cuatro destinos:
- Mensaje/prompt de la llamada actual — para datos de alta volatilidad y alcance estrictamente local: el ticket que se está respondiendo en este instante o el texto que el usuario acaba de enviar.
- Bloque de contexto estable (system prompt o archivos de proyecto) — para datos de baja volatilidad requeridos en cada llamada: un resumen conciso de las políticas, no el manual exhaustivo. Si el contenido cambia constantemente, no pertenece aquí.
- Búsqueda / RAG — para datos de gran volumen donde solo una pequeña porción es relevante por consulta: la base de conocimiento completa o el historial de miles de tickets anteriores. El sistema recupera el fragmento relevante e inyecta únicamente ese extracto.
- Memoria persistente entre sesiones — para datos que deben trascender conversaciones distintas: las preferencias de idioma del cliente o el registro de que ya ha abierto múltiples tickets sobre el mismo incidente.
El error del escenario inicial fue tratar un dato de gran volumen y baja volatilidad (el manual de políticas) como si fuera contexto local — volcando el documento completo en la solicitud en lugar de indexarlo y recuperar solo el párrafo pertinente.
Lost-in-the-middle no se resuelve ampliando el contexto
Los modelos de lenguaje tienden a prestar mayor atención al inicio y al final de bloques extensos de contexto. Un dato crítico ubicado en medio de un texto voluminoso tiene mayor probabilidad de ser pasado por alto — aun estando técnicamente presente en la ventana de contexto. Este fallo suele diagnosticarse erróneamente como "falta de capacidad del modelo", cuando en realidad es un problema de volumen y posicionamiento.
La mitigación correcta no consiste en ampliar la ventana de contexto ni en repetir el dato múltiples veces. La solución pasa por una reducción drástica del contexto — incluyendo únicamente lo indispensable para esa llamada — y posicionando las directivas críticas cerca de los extremos: al inicio de la instrucción o inmediatamente antes de la consulta final. Recuperar un párrafo específico y colocarlo junto a la pregunta ofrece un rendimiento muy superior a volcar un manual entero en el centro del prompt.
Prompt caching requiere estabilidad byte a byte
Almacenar en caché el prefijo estático de un prompt — el system prompt, directrices fijas o ejemplos que no varían — reduce drásticamente el costo y la latencia en llamadas repetitivas que comparten dicho prefijo. Sin embargo, el acierto de caché exige que el contenido sea estrictamente idéntico byte a byte entre llamadas.
Un fallo silencioso muy común ocurre cuando se incluye una marca de tiempo dinámica, un ID de sesión autogenerado o variables que cambian en cada llamada dentro del bloque marcado para caché. El caché se invalida silenciosamente en cada invocación sin emitir ningún error — la aplicación funciona, pero el ahorro esperado nunca se concreta. La solución es separar lo genuinamente estático (en el bloque almacenable en caché) de los valores variables (en la parte no cacheada del mensaje).
Dónde falla la intuición
Tres suposiciones que parecen acertadas pero violan restricciones reales de ingeniería:
- "Poner todo en el prompt garantiza que el modelo no se equivoque por falta de información." Ignora el costo, la latencia y el efecto lost-in-the-middle — mayor contexto no se traduce automáticamente en mayor precisión.
- "RAG resuelve cualquier problema de conocimiento extenso." RAG introduce sus propias fuentes de fallo: si la búsqueda recupera fragmentos erróneos, el modelo recibe contexto aparentemente relevante pero inútil, sin capacidad para detectar que la búsqueda falló.
- "El caché es solo una optimización de costos y no afecta la exactitud." En la práctica, definir mal los límites del bloque cacheado puede provocar que la aplicación sirva información desactualizada de forma inadvertida porque el caché funcionó a nivel técnico — pero con datos obsoletos.
Ponlo en práctica
En el laboratorio de esta lección implementarás un motor de enrutamiento de contexto: a partir de una lista de hechos con metadatos de volatilidad, volumen y alcance, decidirá el destino óptimo entre los cuatro modelos descritos, validado por un conjunto de pruebas automatizadas que verifican el cumplimiento del marco de decisión.