Tu llamada a la API se completa. Claude o GPT-4o devuelve una respuesta. Pero en algún lugar a mitad de tu documento de 8.000 palabras, dejó de prestar atención. No porque el modelo se rompiera, sino porque te quedaste sin ventana de contexto.
La ventana de contexto es el número máximo de tokens que un LLM puede procesar en una sola solicitud. Claude 3.5 Sonnet maneja 200.000 tokens. GPT-4o maneja 128.000. Llama 3 70B maneja 8.000. Si excedes ese límite, tu solicitud falla. Si te mantienes por debajo pero metes demasiado, la atención del modelo se degrada en el material enterrado en el medio, un fenómeno llamado el problema de «perdido en el medio».
Esta no es una limitación teórica. Rompe sistemas de producción reales: chatbots de atención al cliente que no pueden recordar los primeros turnos de conversación, pipelines de análisis de documentos que se pierden secciones críticas y flujos de trabajo de investigación que se ahogan con los PDFs.
Cómo Funciona Realmente la Ventana de Contexto
Cada palabra, número, signo de puntuación y espacio en blanco se convierte en tokens antes de que el modelo lo procese. Un token ≈ 4 caracteres en inglés, pero varía según el idioma y la estructura.
Una ventana de 200.000 tokens de Claude Sonnet se desglosa así:
- Prompt del sistema: 500 tokens
- Entrada del usuario (tu documento): 150.000 tokens
- Historial de conversación: 30.000 tokens
- Reservado para salida: 19.500 tokens
Te quedan 19.500 tokens para la respuesta del modelo. Si necesitas un análisis detallado, es suficiente. Si necesitas múltiples pasos de razonamiento, estás al límite.
Las matemáticas son rígidas: tokens de entrada + tokens de salida ≤ ventana de contexto. Si lo excedes, la mayoría de los proveedores de API rechazan la solicitud con un error 400. Algunos servicios la ponen en cola. Ninguno de ellos la trunca silenciosamente.
El Problema de «Perdido en el Medio» es Real
En septiembre de 2023, investigadores del MIT probaron si los LLM realmente usan todo el contexto que afirman soportar. Insertaron un dato clave en diferentes posiciones de un documento largo y pidieron al modelo que lo recuperara.
El hallazgo: los modelos rinden mejor con la información al principio y al final del contexto. La información en el medio —posiciones del 40 al 60% del documento— se procesa con una precisión un 25-35% menor que la misma información al principio.
Esto no es un problema específico de Claude o GPT-4o. Afecta a todos los modelos basados en transformadores. La razón: los patrones de atención en los modelos de lenguaje dan más peso a los tokens anteriores por defecto, y el modelo «guarda» capacidad para el resumen y la respuesta final.
Impacto práctico: si tu bot de atención al cliente procesa una conversación de 5 mensajes, los mensajes iniciales reciben un tratamiento degradado. Si tu analizador de documentos procesa un PDF de 50 páginas, las páginas 20-30 se vuelven invisibles.
Técnica 1: Resumir Antes de Procesar
En lugar de enviar el documento completo, comprímelo primero.
# Enfoque incorrecto: enviar el documento completo
Usuario: "Analiza este contrato de 30 páginas. ¿Cuáles son las obligaciones clave?"
[enviar contrato completo de 30 páginas como entrada]El modelo utiliza valiosa ventana de contexto en secciones repetitivas que no importan.
# Enfoque mejorado: proceso en dos etapas
Paso 1: Resumir el documento
Prompt: "Resume este contrato en 500 tokens. Conserva las obligaciones, el plazo y los términos de pago. Elimina el texto repetitivo."
[enviar contrato completo]
Salida: Resumen de 500 tokens
Paso 2: Analizar el resumen
Prompt: "Basándote en este resumen, enumera todas las obligaciones de la contraparte y qué parte asume cada riesgo."
[enviar el resumen de 500 tokens]
Salida: Análisis estructuradoPor qué funciona: utilizas la ventana de contexto en la primera llamada para extraer la señal, luego procesas solo la señal en la segunda llamada. La segunda llamada es más rápida, más barata y más precisa porque el modelo trabaja con información destilada.
Ahorro real de tokens: un contrato de 50 páginas (≈25.000 tokens) se convierte en un resumen de 500 tokens. Tu segunda llamada de análisis pasa de 25.500 tokens a 1.000.
Técnica 2: Dividir y Reordenar para el Historial de Conversación
Las conversaciones largas son el problema de contexto más difícil porque cada nuevo mensaje se añade al historial. Después de 15 intercambios, has consumido entre 8.000 y 15.000 tokens solo en memoria de conversación.
# Problema: el historial de conversación se hincha
Giro de conversación 20:
Sistema: [prompt del sistema original]
Usuario: [giro 1]
Asistente: [respuesta]
Usuario: [giro 2]
Asistente: [respuesta]
... [giros 3-19] ...
Usuario: [giro 20] <- mensaje nuevo
Asistente: [el modelo responde]Para el giro 20, el modelo ha visto 15+ intercambios irrelevantes antes de llegar a la pregunta actual. Para el giro 50, el contexto es principalmente peso muerto.
Solución: utiliza un enfoque de reordenación.
Después de cada 8-10 giros, puntúa cada mensaje histórico por relevancia para el hilo de conversación actual utilizando embeddings o un modelo de lenguaje ligero. Conserva solo los 5-7 giros pasados más relevantes, más los 2 giros más recientes. Descarta el resto.
import openai
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np
def prune_conversation_history(history, current_message, max_turns=7):
# Obtener embeddings de todos los mensajes de usuario pasados
past_messages = [h[
