El mensaje de error «La longitud de contexto máxima de este modelo es X tokens. Sin embargo, tus mensajes suponen Y tokens» es engañosamente simple. Parece un muro infranqueable, pero en la práctica es un síntoma de un problema de diseño —normalmente uno que es fácil de corregir una vez que entiendes dónde se consumen realmente los tokens.
Diagnostica antes de corregir: ¿a dónde van tus tokens?
El primer paso cuando alcanzas un error de límite de tokens no es empezar a fragmentar de inmediato —es contar a dónde van tus tokens realmente. Los equipos se sorprenden con frecuencia al ver qué parte de su prompt consume más espacio.
Una estructura típica de prompt y dónde se acumulan los tokens:
- Prompt de sistema: A menudo el mayor coste fijo. Instrucciones, ejemplos, definiciones de herramientas, texto de persona. Puede alcanzar fácilmente entre 2.000 y 5.000 tokens en una aplicación compleja.
- Historial de conversación: Crece linealmente con cada turno en una sesión de múltiples turnos. En el turno 8–10, el historial supera con frecuencia el tamaño del mensaje actual entre 5 y 10 veces.
- Documentos o contexto recuperados: Los pipelines de RAG que traen 5–10 fragmentos de 500 tokens cada uno añaden entre 2.500 y 5.000 tokens antes de que el usuario haga siquiera una pregunta.
- Mensaje del usuario: Normalmente la parte más pequeña. Incluso un mensaje largo del usuario rara vez supera los 500–800 tokens.
- Espacio reservado para la salida: Muchas APIs requieren que reserves tokens explícitamente para la respuesta. Si no lo haces, el modelo puede no tener espacio para responder aunque la entrada quepa.
Pega tu prompt actual —todas las partes— en el contador gratuito de tokens de IA para ver un desglose exacto. Saber si tu prompt de sistema o tu historial de conversación es el principal culpable cambia cuál corrección aplicar.
Estrategia 1: Fragmentación de tamaño fijo para procesamiento de documentos
Cuando el problema es un documento o conjunto de datos demasiado largo para procesarse en una sola llamada, la fragmentación —dividirlo en trozos más pequeños— es el enfoque fundamental.
La fragmentación de tamaño fijo divide el contenido en segmentos uniformes de un recuento de tokens especificado. Un punto de partida habitual es 512–1.024 tokens por fragmento con un solapamiento del 10–20% entre fragmentos adyacentes.
El solapamiento es fundamental. Sin él, una oración o idea dividida en el límite de dos fragmentos queda huérfana —el contexto que empieza al final del fragmento 1 y se completa al principio del fragmento 2 nunca está completamente disponible para el modelo en ninguna pasada. Un solapamiento del 10–20% asegura que la información de los límites aparezca en al menos un fragmento completo.
Consideraciones de implementación:
-
Fragmenta en límites semánticos cuando sea posible. Los saltos de párrafo, los encabezados de sección y los finales de oración son mejores puntos de división que los recuentos arbitrarios de tokens. Una oración dividida por la mitad de una palabra genera una entrada confusa. Divide en espacios en blanco o puntuación en el punto más cercano a tu objetivo de tokens.
-
Elige el tamaño del fragmento según tu tarea. Para recuperación (RAG), los fragmentos más pequeños de 256–512 tokens producen resultados de búsqueda más precisos. Para resumen, los fragmentos más grandes de 1.500–2.500 tokens preservan más contexto local y reducen el número de llamadas a la API necesarias.
-
Ten en cuenta la sobrecarga de tu prompt. Si tu prompt de sistema tiene 1.500 tokens y tu modelo tiene un contexto de 128K, tu espacio utilizable por fragmento es de unos 126.500 tokens menos la salida esperada. No fragmentes basándote en el límite de contexto bruto —fragmenta basándote en el espacio restante después de tu sobrecarga fija de prompt.
Estrategia 2: Resumen del historial de conversación
Para aplicaciones conversacionales —chatbots, asistentes de codificación, herramientas de investigación— la causa más común de errores de límite de tokens no son los documentos sino el historial de conversación acumulado. Cada turno añade a la entrada en la siguiente llamada.
La corrección estándar es el resumen progresivo con una ventana deslizante:
- Mantén los últimos N turnos con fidelidad completa (donde N es algo como 5–8 turnos, dependiendo de la importancia del contexto conversacional en tu app).
- Cuando el contexto total se acerca al 70–80% del límite del modelo, resume los turnos más antiguos en un bloque comprimido de «conversación hasta ahora».
- Sustituye los turnos antiguos por el resumen. Los nuevos turnos continúan acumulándose hasta el siguiente disparador de resumen.
Una implementación práctica: una heurística habitual es disparar el resumen cuando se alcanza el 70% de la capacidad del contexto. Almacena el resumen junto con los mensajes recientes de fidelidad completa, dando al modelo un historial condensado más contexto reciente completo. El resumen debe capturar: decisiones clave tomadas, información que compartió el usuario, tareas completadas y cualquier hilo abierto.
La calidad de tu prompt de resumen importa. Pedir al modelo que «resuma esta conversación» produce resultados vagos. Un prompt más efectivo: «Resume los hechos clave, las decisiones y las preguntas sin resolver de esta conversación en menos de 300 palabras. Conserva cualquier número específico, nombre o detalle técnico que mencionó el usuario.»
Para aplicaciones donde la precisión de los detalles de principios de la conversación es crítica —contextos médicos, legales, financieros— registra la conversación completa externamente en lugar de depender únicamente del resumen en contexto. El resumen es una herramienta de gestión del presupuesto de tokens, no un archivo fiable.
Estrategia 3: Truncado con puntuación de importancia
A veces la corrección más rápida es el truncado inteligente —eliminar contenido del contexto en lugar de resumirlo. Esto funciona mejor cuando tu contexto contiene material con relevancia variable para la solicitud actual.
Un enfoque simple de truncado: elimina primero el contenido más antiguo. Si un usuario hizo una pregunta en el turno 1 que no guarda relación alguna con el turno 15, eliminar el turno 1 rara vez perjudica la calidad.
Un enfoque más sofisticado añade puntuación de importancia antes de decidir qué truncar. Puntúa los bloques de contenido según:
- Recencia: El contenido más reciente obtiene una puntuación más alta.
- Relevancia para la consulta actual: ¿Qué relación tiene este bloque con lo que acaba de preguntar el usuario? La similitud coseno entre embeddings es una señal fiable.
- Presencia de entidades: ¿Este bloque menciona nombres, números o términos técnicos que aparecen en la consulta actual?
- Referencias explícitas: ¿El usuario hizo referencia a este contenido directamente («como mencioné antes…»)?
Calcula una puntuación compuesta y trunca primero los bloques con puntuación más baja. Este enfoque conserva el contenido temprano contextualmente importante mientras elimina los turnos históricos irrelevantes. La guía de Redis de 2026 sobre el desbordamiento de contexto sugiere que este tipo de puntuación de recencia más relevancia supera consistentemente al simple truncado de lo más antiguo primero para aplicaciones complejas.
Estrategia 4: MapReduce para el resumen de documentos largos
Cuando necesitas resumir un documento más largo que cualquier ventana de contexto única, el MapReduce es la arquitectura fiable:
- Fase Map: Divide el documento en fragmentos que quepan dentro del límite de contexto. Envía cada fragmento al modelo con el mismo prompt de resumen. Recoge los resúmenes de cada fragmento.
- Fase Reduce: Concatena los resúmenes de los fragmentos (son mucho más cortos que el original) y envíalos al modelo para un resumen de síntesis final.
Para documentos muy largos, puede que necesites varias fases de reducción —resume los resúmenes si incluso el resumen combinado supera tu límite.
MapReduce añade sobrecarga de llamadas a la API —si tu documento se divide en 10 fragmentos, haces al menos 11 llamadas a la API en lugar de 1. Para documentos procesados una vez (análisis de informes, revisión de contratos), esto es aceptable. Para operaciones de alta frecuencia sobre los mismos documentos, considera si RAG con una base de datos vectorial sería más rentable que pasadas repetidas de MapReduce.
Una nota de rendimiento: el resumen con MapReduce pierde coherencia entre fragmentos. Las referencias que abarcan límites de fragmento —«la cláusula definida en la sección 2 aplica a las situaciones descritas en las secciones 7 y 12»— pueden no capturarse con precisión si las secciones 2 y 7 terminan en fragmentos diferentes. Para documentos legales y financieros donde importan las referencias cruzadas, considera aumentar el solapamiento de fragmentos o usar fragmentación semántica que respete los límites de las secciones.
Conoce tus recuentos de tokens antes de alcanzar el límite
El mejor momento para diseñar una estrategia de fragmentación es antes de encontrar el error, no cuando tu aplicación falla a las 2 de la madrugada. La mayoría de los errores de límite de tokens en producción son predecibles desde la fase de diseño —si mides el tamaño medio de tu prompt y tu tasa de crecimiento, puedes ver el techo aproximarse.
Una auditoría rápida lleva 15 minutos: mide los tamaños de prompt mediano y del percentil 95 en los cuatro componentes (prompt de sistema, historial, contexto recuperado, mensaje del usuario). Compáralos con el límite de tu modelo. Si regularmente superas el 60–70% del límite en condiciones normales, estás a una solicitud inusual de un usuario de un error.
Usa el contador gratuito de tokens de IA para medir cada componente de tu prompt por separado, luego súmalos. La herramienta muestra el recuento de tokens y el coste de cualquier texto que pegues —ejecútalo en tu prompt de sistema, una conversación larga representativa y tus mayores fragmentos de documentos. Esa medición te dice exactamente qué componente necesita más trabajo y qué estrategias priorizar.
Preguntas frecuentes
¿Cuál es la diferencia entre fragmentación y RAG — debería usar ambas? Son complementarias. La fragmentación es el proceso de dividir el contenido en trozos más pequeños. RAG (Generación Aumentada por Recuperación) es una arquitectura donde almacenas fragmentos en una base de datos vectorial y recuperas solo los más relevantes en el momento de la consulta, en lugar de enviar todos los fragmentos. RAG es más sofisticado y requiere más infraestructura, pero resuelve el problema del límite de tokens mientras también reduce costes —envías 3–5 fragmentos relevantes en lugar de los 50 completos. Para el procesamiento puntual de documentos, la fragmentación con MapReduce es más simple. Para consultas recurrentes sobre una base de conocimiento extensa, RAG vale el coste de configuración.
¿Cuánto solapamiento debería usar entre fragmentos? Un punto de partida es el 10–20% del tamaño de tu fragmento —así que para un fragmento de 512 tokens, entre 51 y 102 tokens de solapamiento. Más solapamiento significa más contenido redundante enviado al modelo, lo que aumenta los costes. Menos solapamiento arriesga perder contexto en los límites. Ajusta según tu tasa de error en preguntas que abarcan límites. Muchos equipos se establecen en un 15% de solapamiento como equilibrio práctico.
Mi prompt de sistema es demasiado largo — ¿qué puedo eliminar? Empieza por los ejemplos. Los ejemplos de pocos ejemplos son frecuentemente el mayor consumidor individual de tokens del prompt de sistema, y 3 ejemplos a menudo rinden casi tan bien como 8. A continuación, aprieta la redacción de las instrucciones —las instrucciones verbosas no suelen ser más efectivas que las concisas. Por último, considera si todas las instrucciones aplican a todas las solicitudes, o si algunas pueden añadirse de forma dinámica solo cuando se detecta el tipo de tarea relevante.
¿Puedo aumentar el límite de contexto actualizando mi plan de OpenAI? El límite de contexto es una propiedad del modelo, no del plan. GPT-5 tiene un límite de contexto de 256K independientemente de tu nivel de plan. Lo que cambia con los planes son los límites de velocidad (solicitudes por minuto) y el acceso a ciertas variantes de modelo, no el tamaño de la ventana de contexto de ningún modelo individual.
¿Por qué el error ocurre a veces pero no siempre con la misma entrada? Si el error es intermitente en entradas que están cerca del límite, la causa suele ser el crecimiento del historial de conversación. Una sesión que empieza bien dentro de los límites puede superar la ventana de contexto en el turno 6 o 7 a medida que se acumula el historial. Añade registro del recuento total de tokens por solicitud y verás el patrón de crecimiento de inmediato.