Hace dos años, uno de los límites más frustrantes de trabajar con IA era la ventana de contexto. Tenías que resumir documentos, fragmentar análisis, perder hilo entre conversaciones. Los modelos simplemente no podían «leer» más de unas pocas páginas a la vez sin empezar a olvidar lo que había al principio.
Ese límite ha cambiado radicalmente. Los modelos actuales como Gemini 1.5 Pro o Claude permiten contextos de cientos de miles de tokens, y en algunos casos superan el millón. En términos prácticos, eso equivale a varios libros completos, repositorios de código enteros, o bases de datos de tamaño considerable, todo procesado en una sola consulta.
Pero aquí está el problema que nadie explica bien: tener una ventana de contexto enorme no significa que el modelo vaya a usar bien toda esa información. Y entender por qué es la diferencia entre aprovechar esta capacidad de verdad o frustrarte con resultados mediocres.
Lo que pasa realmente cuando el contexto es muy largo
Los modelos de lenguaje no leen de forma lineal como un humano. Procesan toda la información a través de mecanismos de atención que deciden qué partes del contexto son relevantes para la respuesta actual. Cuando el contexto es corto, esa atención funciona bien. Cuando el contexto es muy largo, empieza a aparecer un fenómeno que los investigadores llaman «lost in the middle»: el modelo tiende a prestar más atención a lo que está al principio y al final del contexto, y a ignorar sutilmente lo que está en el centro.
Esto tiene consecuencias prácticas importantes. Si metes un contrato de cien páginas y la cláusula crítica está en la página 60, hay una probabilidad real de que el modelo la pase por alto o la pondere menos que información menos importante que está al principio o al final del documento.
No es que el modelo no pueda ver ese dato. Es que la arquitectura lo hace estadísticamente menos probable que lo recupere con precisión si no le ayudas a encontrarlo.
La solución más efectiva: decirle dónde mirar
La forma más simple de combatir este problema no requiere ningún truco técnico. Requiere ser muy específico en la instrucción sobre qué parte del documento debe consultar y qué debe ignorar.
En lugar de «analiza este contrato y dime si hay cláusulas problemáticas», algo como: «en el documento adjunto, busca específicamente en las secciones de penalizaciones, rescisión anticipada y propiedad intelectual. Ignora las secciones de definiciones y antecedentes. Para cada cláusula que identifiques como potencialmente problemática, cita el texto exacto y explica por qué.»
Esta instrucción hace varias cosas a la vez: reduce el espacio de búsqueda, obliga al modelo a citar texto real en lugar de parafrasear de memoria, y define criterios claros de qué cuenta como «problemático». Cada uno de esos elementos reduce la probabilidad de alucinaciones y mejora la precisión.
Por qué obligar al modelo a citar es tan importante
Cuando trabajas con documentos largos, las alucinaciones toman una forma particular y peligrosa: el modelo genera respuestas que suenan completamente coherentes con el tono y el estilo del documento, pero que contienen datos inventados o mezclados de secciones distintas.
La razón es que el modelo tiene dos fuentes de información simultáneas: el documento que le has dado y todo su conocimiento de entrenamiento. Si no le dices explícitamente que use solo el documento, combinará ambas fuentes de forma que resulta difícil de detectar.
La instrucción que más ayuda es exigir citas textuales con ubicación. Algo tan simple como añadir al final del prompt: «para cada afirmación, indica en qué sección del documento se encuentra y cita las palabras exactas que la sustentan. Si la información no está en el documento, dilo explícitamente.» Esta instrucción cambia completamente el comportamiento del modelo porque le hace «buscar» en lugar de «recordar».
Cómo estructurar el documento antes de enviarlo
Hay un ajuste de preparación que marca una diferencia notable en la calidad de los resultados: etiquetar las secciones del documento con marcadores claros antes de introducirlo en el prompt.
Si tienes un informe anual de una empresa y quieres analizarlo, en lugar de pegar el texto en bruto, añade etiquetas descriptivas al inicio de cada sección: algo como [INICIO: Resultados financieros Q1] y [FIN: Resultados financieros Q1]. No hace falta que sean etiquetas XML sofisticadas. Lo importante es que el modelo pueda orientarse en el documento usando esas marcas cuando lo necesite.
Este pequeño esfuerzo de preparación puede parecer manual y tedioso, pero en documentos de más de 50 páginas la mejora en precisión justifica los cinco minutos que lleva hacerlo, especialmente si vas a hacer varias consultas sobre el mismo documento.
El razonamiento en pasos para análisis complejos
Cuando el análisis que necesitas es complejo, pedir todo de golpe en un solo prompt es el enfoque menos eficiente, aunque el modelo tenga capacidad de contexto suficiente para procesar todo el documento.
Un análisis en tres pasos funciona mucho mejor. El primer paso es de extracción pura: «del documento adjunto, extrae todos los párrafos que mencionen fechas límite, importes económicos o responsabilidades de las partes. No analices todavía, solo extrae.»
El segundo paso trabaja sobre lo extraído: «de los fragmentos que acabas de identificar, determina cuáles implican obligaciones para [nombre de la empresa] y ordénalos por fecha.»
El tercero sintetiza: «basándote en esas obligaciones ordenadas cronológicamente, identifica cuáles se solapan temporalmente y podrían generar conflictos de recursos.»
Este encadenamiento obliga al modelo a hacer un trabajo de atención focalizada en cada paso en lugar de intentar hacer todo a la vez, y el resultado final es notablemente más preciso y verificable.
Casos donde esto cambia las reglas de forma real
El análisis de contratos y documentación legal es el caso más obvio. Lo que antes requería horas de un abogado junior repasando cláusula por cláusula puede ahora hacerse como primer filtro en minutos, con el modelo señalando qué secciones merecen atención humana. No reemplaza al abogado, pero cambia completamente cómo distribuye su tiempo.
La revisión de repositorios de código antiguo es otro caso que tiene valor real para equipos de desarrollo. Cargar el código fuente completo y poder preguntar sobre dependencias, detectar patrones de arquitectura, o identificar dónde está la lógica de negocio de un sistema que nadie recuerda bien, son tareas que antes requerían días de lectura y ahora son consultas de minutos.
Y para investigación y análisis de mercado, poder trabajar con transcripciones de entrevistas, informes de analistas y datos de ventas en un mismo contexto, haciendo preguntas que cruzan fuentes, es algo cualitativamente diferente a lo que era posible hace dos años.
Lo que hay que tener claro antes de depender de esto
El coste de procesar contextos muy largos es real. Tanto en tiempo de respuesta como en coste económico si usas la API. Para análisis puntuales de documentos importantes tiene todo el sentido. Para consultas frecuentes sobre documentos que no cambian, una arquitectura RAG donde el documento está indexado y se recuperan solo los fragmentos relevantes es más eficiente a medio plazo.
Y siempre, siempre, hay que verificar los resultados cuando el documento es la base de una decisión importante. El modelo puede citar correctamente el 95% de las veces y alucinaciones sutiles en el 5% restante. En un análisis legal o financiero, ese 5% importa.
