Comprender tokens, contexto e instrucciones

Un modelo no recibe «todo lo que sabe la aplicación». Recibe una secuencia de contenido preparada para esa invocación. Esa secuencia se representa y contabiliza en tokens, y debe caber dentro de los límites de contexto de la configuración utilizada.

La ingeniería útil no consiste en memorizar cuántos tokens admite un modelo concreto. Esa cifra es volátil. Consiste en aprender a seleccionar qué información merece ocupar contexto y qué información debe mantenerse fuera hasta que sea necesaria.

Qué es un token

Los modelos trabajan con unidades de representación llamadas tokens. Un token no equivale necesariamente a una palabra: puede corresponder a una palabra, parte de una palabra, signos u otros fragmentos según el tokenizador.

La documentación actual de OpenAI, por ejemplo, dispone de mecanismos específicos para contar tokens de entrada antes de ejecutar determinadas solicitudes. Anthropic documenta igualmente la ventana de contexto como el conjunto de tokens disponibles para que el modelo procese información y produzca la respuesta.

No conviertas estas implementaciones de proveedor en una definición rígida para todos los sistemas. Lo estable es el concepto: existe un presupuesto finito de representación para la interacción.

Qué compite por el contexto

Según la API y el producto, dentro de ese presupuesto pueden aparecer:

• instrucciones del sistema o del desarrollador;
• petición del usuario;
• historial seleccionado;
• ejemplos;
• contenido recuperado;
• definiciones de herramientas;
• resultados de herramientas;
• archivos, imágenes u otras entradas compatibles;
• tokens reservados o utilizados para producir la salida.

Esto explica por qué añadir información no siempre mejora la respuesta. Cada bloque irrelevante desplaza atención y presupuesto que podría utilizarse para reglas, evidencia o salida.

Contexto no es memoria

El contexto es la información disponible para la inferencia actual. La memoria persistente es información almacenada fuera de esa invocación y recuperada posteriormente por una aplicación o producto.

Una conversación larga puede dar sensación de memoria porque el sistema conserva mensajes o resúmenes y los vuelve a introducir. Sin ese mecanismo de persistencia, el modelo no debe tratarse como si recordara automáticamente sesiones anteriores.

Distingue también estado estructurado de historial textual. Para un proceso empresarial suele ser más robusto guardar cliente_id, fase, decisión, pendientes o documentos como datos explícitos que depender de que toda la conversación siga presente.

Diseña un presupuesto de contexto

Empieza por la tarea. Pregunta qué información necesita el modelo para resolverla y qué puede mantenerse fuera.

Una distribución conceptual podría contener:

1. reglas críticas;
2. instrucción de la tarea;
3. datos del caso;
4. evidencia recuperada;
5. definiciones de herramientas;
6. historial estrictamente relevante;
7. margen suficiente para la salida.

No existe una proporción universal. Mide con el modelo y la tarea reales.

Long context no significa relevant context

Una ventana más grande permite incluir más contenido, pero no garantiza que toda la información sea útil ni que el sistema seleccione siempre la evidencia correcta.

Un error frecuente es reenviar documentos completos «porque caben». Si una política contiene 200 páginas y la pregunta depende de dos apartados, recuperar esos apartados puede ser más controlable, barato y evaluable que enviar todo el documento.

La decisión entre contexto directo y recuperación depende de volumen, repetición, frecuencia de actualización y necesidad de citas, no solo del tamaño máximo soportado.

Ordena instrucciones por responsabilidad

Separa claramente:

• reglas estables de la aplicación;
• tarea actual;
• datos del usuario;
• contexto externo;
• ejemplos;
• formato de salida.

La documentación de prompting de OpenAI distingue instrucciones de alto nivel y entradas de usuario y recomienda estructurar claramente el contexto. Los detalles exactos de jerarquía dependen de la API, por lo que debes consultar la documentación vigente del proveedor.

No incrustes datos no confiables como si fueran instrucciones. Un documento recuperado, un email o un texto del usuario debe tratarse como contenido, no como autoridad para cambiar permisos o reglas del sistema.

Gestiona conversaciones largas

Cuando el historial crece tienes varias opciones:

• conservar solo mensajes relevantes;
• resumir tramos anteriores;
• extraer estado estructurado;
• recuperar hechos bajo demanda;
• usar mecanismos de compaction disponibles en el proveedor;
• iniciar una nueva sesión conservando únicamente el estado necesario.

Los resúmenes generados pueden introducir pérdidas o errores. Si van a condicionar decisiones posteriores, valida la información que preservan.

Diseña el truncado deliberadamente

El peor truncado es el accidental. Si al superar el límite desaparece una excepción, una instrucción de seguridad o una fuente crítica, el comportamiento puede cambiar sin señal visible.

Define prioridad por bloques. Por ejemplo:

• instrucciones críticas: nunca truncar;
• permisos y condiciones: nunca truncar;
• historial antiguo: resumible;
• ejemplos redundantes: eliminables;
• resultados intermedios: sustituibles por estado estructurado.

Prueba explícitamente qué ocurre cuando la entrada se acerca al límite.

Ejemplo: asistente sobre expedientes

Una aplicación analiza un expediente con cientos de páginas. El error sería enviar siempre todo el expediente más la conversación completa.

Una arquitectura más controlable conserva identidad y estado del expediente, recupera únicamente documentos o fragmentos pertinentes, incluye las reglas de análisis y reserva espacio para una salida estructurada. Si el usuario cambia de pregunta, cambia la evidencia recuperada, no necesariamente todo el historial.

El coste semántico de tokenizar

La tokenización también afecta a coste y capacidad. Idiomas, código, números, tablas y cadenas con formatos particulares pueden consumir cantidades distintas de tokens. Por eso una estimación basada únicamente en número de palabras es imprecisa.

Cuando el volumen importa, cuenta con el tokenizador o mecanismo oficial del proveedor y mide sobre entradas reales. Si una tarea trabaja con grandes tablas o documentos repetitivos, quizá convenga transformar los datos antes de enviarlos en lugar de pagar por contexto que el modelo no necesita.

Ejemplos dentro del contexto

Los ejemplos pueden enseñar formato, criterio y fronteras. Pero cada ejemplo consume contexto y puede introducir sesgos si representa solo casos sencillos.

Selecciona ejemplos que cubran decisiones difíciles: caso válido, excepción, ausencia de dato y resultado que debe rechazarse. Si necesitas decenas de ejemplos permanentes para sostener el comportamiento, valora si parte de ese conocimiento debería convertirse en reglas, recuperación o una estrategia de optimización distinta.

Contexto sensible y minimización

El presupuesto de contexto no es solo técnico. También define exposición de datos. Si una tarea necesita tres campos de un expediente, no envíes el expediente completo por comodidad.

Documenta qué campos entran, qué se redacta o elimina y qué fuente autorizó el acceso. Esta disciplina reduce coste y superficie de riesgo a la vez.

Ejercicio: presupuesto de contexto

Para una tarea concreta crea una tabla con:

• bloque de información;
• origen;
• tamaño aproximado;
• prioridad;
• condición para incluirlo;
• si puede resumirse;
• si puede recuperarse bajo demanda;
• riesgo si se pierde;
• responsable de validarlo.

Añade una prueba de saturación: construye un caso que exceda el presupuesto y documenta exactamente qué se elimina, resume o recupera de otra forma.

Criterio de salida

Al finalizar, debes contar con una política explícita de contexto. Sabes qué entra, qué no entra, qué se conserva fuera, qué puede resumirse y qué nunca debería desaparecer. La siguiente lección tratará la otra mitad del contrato: cómo convertir una salida flexible del modelo en un dato que una aplicación pueda utilizar sin confundir formato correcto con contenido correcto.