Ventana de contexto y buenas prácticas

Prerequisito: Para seguir este post solo necesitas saber qué es un prompt (el texto que le envías al modelo para pedirle algo). No necesitas saber programar todavía.

Cuando empecé a trabajar con modelos de lenguaje, cometí un error muy concreto: creía que cuanto más contexto le daba al modelo, mejor respondía. Le pegaba correos completos, documentos enteros, páginas de especificaciones. Los resultados eran mediocres. El modelo a veces ignoraba las instrucciones importantes, mezclaba información de sitios distintos, o respondía como si no hubiera leído la mitad de lo que le mandé.

El problema no era la cantidad. Era que no entendía cómo funciona la memoria del modelo.

Qué es un token (hay que entender esto primero)

Antes de hablar de ventana de contexto necesito explicar qué es un token, porque todo lo demás depende de este concepto.

Un token no es una palabra completa. Es un fragmento de texto, algo parecido a una sílaba pero sin seguir las reglas silábicas del idioma. La palabra “programador” puede ser un token o puede partirse en dos (“program” + “ador”), dependiendo del modelo y del contexto. Las palabras cortas suelen ser un token. Las más largas se parten.

¿Por qué existe esto? Porque los modelos no leen texto como lo hacemos nosotros. Trabajan con números, y los tokens son la unidad mínima con la que convierten texto en números. No tiene que preocuparte el mecanismo exacto: lo que importa es que los límites del modelo se miden en tokens, no en palabras ni en caracteres.

Como referencia práctica: un párrafo normal de unas 80-100 palabras equivale aproximadamente a 130-160 tokens en español, según los tokenizadores de OpenAI y Anthropic, que puedes probar directamente en sus playgrounds. No intentes memorizar ningún número, porque varía bastante según el texto.

La memoria a corto plazo del modelo

La ventana de contexto es el límite de cuánto texto puede leer, procesar y tener “en mente” el modelo en una sola interacción.

Una analogía: imagina que le das a alguien una pila de tarjetas para que las lea y luego te conteste preguntas. Solo puede sostener un número fijo de tarjetas a la vez. Si la pila supera ese límite, tendrá que soltar las primeras para leer las últimas. Lo que soltó, lo olvidó.

Eso es lo que pasa cuando superas la ventana de contexto. El modelo no lee todo: llega hasta donde puede, y el resto no existe para él.

Los modelos modernos tienen ventanas de contexto grandes, algunos con cientos de miles de tokens. Pero “grande” no significa “ilimitado”. Y aquí viene algo que sorprende a mucha gente cuando empieza: incluso cuando tienes espacio de sobra, cómo organizas la información importa tanto como cuánta información incluyes.

El efecto “Lost in the middle”

Existe un problema conocido en cómo los modelos procesan textos largos: prestan más atención al inicio y al final del contexto, un comportamiento que investigadores documentaron formalmente en 2023. El contenido que queda en el medio tiende a recibir menos atención, aunque esté dentro del límite de la ventana.

Las instrucciones importantes van al principio. La pregunta concreta va al final. El material de referencia (documentos, datos, ejemplos) va en el medio.

Este es el esquema que uso para estructurar prompts largos:

// Estructura de prompt que respeta el efecto "perdido en el medio"
const prompt = `
<instrucciones>
Responde siempre en español.
Usa solo la información del documento de abajo.
Si no sabes la respuesta, di "no lo sé".
</instrucciones>

<documento>
${textoDeReferencia}
</documento>

¿Cuál es el punto principal del documento?
`;
// Instrucciones críticas: al inicio, dentro de <instrucciones>
// Material de referencia: en el medio, dentro de <documento>
// La pregunta real: al final, fuera de cualquier etiqueta

Las etiquetas como <instrucciones> o <documento> no son ningún estándar obligatorio. Son simplemente delimitadores que ayudan al modelo a entender qué parte del texto es qué, igual que los subtítulos ayudan a un lector humano a orientarse en un documento.

Calidad sobre cantidad: el contexto no es un cajón de sastre

Este fue mi error principal al empezar. Meter mucha información no hace al modelo más listo. Lo que hace es añadir ruido.

Cada token que incluyes en el contexto compite con todos los demás por la atención del modelo. Un documento irrelevante no es neutral: puede hacer que el modelo le dé menos peso al documento que sí importa. La respuesta se vuelve más vaga, mezcla cosas que no debería mezclar, o directamente ignora las instrucciones que enterraste entre páginas de texto que no venían al caso.

La pregunta que hay que hacerse antes de incluir algo es simple: ¿el modelo necesita esto para responder bien? Si la respuesta es “puede que ayude”, probablemente no lo necesita.

Esto es especialmente importante cuando automatizas llamadas al modelo desde código. La tentación natural es pasar todo lo que tienes. Resiste esa tentación.

Few-shot: enseñar con ejemplos dentro del contexto

El prompt engineering (el arte de darle instrucciones precisas al modelo para obtener mejores respuestas) tiene muchas técnicas, pero esta es de las más útiles para quien empieza.

Few-shot, en español “pocos ejemplos”, consiste en incluir dentro del prompt algunos ejemplos de lo que quieres que el modelo haga. En lugar de solo describir el formato que esperas, lo demuestras directamente.

// Few-shot: el modelo aprende el patrón viendo los ejemplos
const prompt = `
Clasifica el tono de estos mensajes.
Responde solo con una palabra: formal, informal o técnico.

Mensaje: "Estimado señor García, le escribo para informarle del estado del proyecto."
Tono: formal

Mensaje: "oye tío qué tal todo por tu lado, ¿quedamos?"
Tono: informal

Mensaje: "${mensajeNuevo}"
Tono:
`;
// Con 2 ejemplos ya tiene suficiente para entender el patrón.
// La respuesta llegará solo con la palabra, sin explicaciones.

Dos ejemplos suelen ser suficientes para tareas simples. Lo que importa es que los ejemplos cubran los casos representativos, no que sean muchos.

Si el modelo no entiende el patrón con tres ejemplos, probablemente el problema está en cómo describes la tarea, no en cuántos ejemplos le das. Añadir más ejemplos raramente resuelve ese tipo de problema.

Cuándo el contexto no es suficiente: RAG

¿Qué pasa cuando tienes una base de conocimiento enorme, cientos de documentos, o un repositorio de código completo? Todo eso no cabe en la ventana de contexto de ningún modelo.

Aquí entra RAG (del inglés Retrieval-Augmented Generation, aunque casi nadie lo llama así en español). El post sobre RAG empresarial entra en el detalle técnico completo, pero la idea es esta: en lugar de intentar meter toda la información en el contexto, RAG usa un buscador previo. Cuando haces una pregunta, el sistema primero encuentra qué fragmentos de tu documentación son relevantes para esa pregunta concreta, y solo esos fragmentos pasan al contexto del modelo.

Es como si en lugar de darle a alguien toda la biblioteca para que la leyera, le dieras solo los 4 libros que responden tu pregunta.

Para entender cómo funciona ese buscador por dentro (los embeddings que le permiten encontrar fragmentos por significado, no por palabras exactas), el post sobre búsqueda semántica y embeddings tiene la explicación visual que necesitas.

Errores comunes

Poner las instrucciones en el medio del prompt

Si describes las reglas importantes después del documento de referencia y antes de la pregunta, el modelo las procesa con menos atención. Las instrucciones al principio, siempre.

Asumir que más contexto siempre ayuda

Un error muy común es incluir el hilo completo de una conversación, todos los mensajes previos, cuando lo que importa son los últimos dos o tres. El contexto histórico que no aporta nada activo ocupa espacio y añade ruido. Quédate con lo que el modelo necesita saber para responder ahora.

Describir el formato en lugar de mostrarlo

“Responde en formato tabla con columnas Nombre, Fecha y Estado” parece claro. Pero si incluyes un ejemplo de cómo quieres esa tabla, el resultado es casi siempre mejor. Describir y mostrar a la vez es más efectivo que solo describir.

No usar delimitadores cuando el prompt tiene partes distintas

Si metes instrucciones, datos y la pregunta todo seguido sin separar, el modelo tiene que adivinar dónde termina una cosa y empieza otra. A veces lo hace bien. A veces no. Los delimitadores (<instrucciones>, ---, o simplemente saltos de línea con etiquetas) eliminan esa ambigüedad.

Checklist de implementación

• Las instrucciones críticas están al inicio del prompt

• El material de referencia va entre las instrucciones y la pregunta final

• He eliminado información que el modelo no necesita para responder

• Uso delimitadores claros para separar las partes del prompt (<instrucciones>, <documento>, ---)

• Si quiero un formato específico, incluyo al menos 2 ejemplos few-shot en lugar de solo describirlo

• Si la información supera la ventana de contexto, evalúo RAG antes de intentar meterlo todo a la fuerza

Un concepto nuevo cada semana

Suscribirme

Preguntas Frecuentes

¿Qué pasa exactamente cuando supero la ventana de contexto?

Depende del modelo y de cómo esté configurado. Algunos rechazan la llamada con un error. Otros truncan el texto en silencio: se quedan con el inicio o con el final, y el resto desaparece sin avisarte. En cualquier caso, el modelo no procesa lo que no cabe.

¿La ventana de contexto es lo mismo que la “memoria” del modelo?

No. La ventana de contexto es específica de cada llamada: cuando haces una nueva llamada, el modelo empieza desde cero. No recuerda lo que hablasteis antes a menos que tú mismo incluyas esa conversación en el contexto de la nueva llamada. Por eso los chatbots con “memoria” funcionan guardando el historial e incluyéndolo en cada prompt nuevo.

¿Cuántos tokens tiene mi prompt?

La mayoría de APIs de modelos te devuelven el número de tokens usado después de cada llamada. Si quieres estimarlo antes, existen librerías específicas para eso (cada proveedor suele tener la suya). Como punto de partida: una página de texto normal en español suele estar en el rango de los pocos cientos de tokens, pero varía bastante según la densidad del texto.

¿Los ejemplos few-shot funcionan para cualquier tipo de tarea?

Para clasificación, formateo de salidas y tareas con patrones claros funcionan muy bien. Para razonamiento complejo o preguntas abiertas, ayudan menos. Si la tarea es ambigua de por sí, los ejemplos no resuelven la ambigüedad: hay que reformular las instrucciones primero.