El Modelo de Interfaz de LLM
Los tokens, las ventanas de contexto, los prompts y los esquemas de salida estructurada o de herramientas pueden parecer un conjunto de detalles de API de LLM no relacionados.
//
Busca en todas las páginas de la documentación
Los tokens, las ventanas de contexto, los prompts y los esquemas de salida estructurada o de herramientas pueden parecer un conjunto de detalles de API de LLM no relacionados.
En realidad, son una sola idea: un modelo de lenguaje grande es una función de texto de entrada, texto de salida con una ventana de atención de tamaño fijo, y cada convención en esta sección existe para gestionar lo que entra en esa ventana y lo que sale de ella como algo que un programa puede usar realmente.
Esta página conecta Conceptos Básicos de LLM, Tokens, Costo y Límites de Tasa, Ingeniería de Prompts y Salida Estructurada en un solo modelo, en lugar de cuatro temas de API separados.
Un token es la unidad que un LLM realmente lee y escribe, no exactamente una palabra y no exactamente un carácter, sino un fragmento de subpalabra producido por el tokenizador del modelo.
Las palabras comunes suelen ser un solo token y las palabras más raras se dividen en varias.
Cada prompt que envías y cada respuesta que obtienes se cuentan, se les asigna un precio y se limitan en tokens, no en caracteres o palabras, por lo que contar tokens es el primer ajuste mental que vale la pena hacer.
La ventana de contexto es el número máximo de tokens, prompt más respuesta combinados en la mayoría de las APIs, a los que un modelo puede atender en una sola llamada, y es un límite estricto.
Los tokens más allá de él son rechazados directamente o truncados silenciosamente, y nada de lo que hagas con el prompt cambia ese límite para un modelo dado.
Una analogía útil es una pizarra de tamaño fijo: puedes escribir lo que quieras en ella, pero una vez que está llena, añadir una nueva línea significa borrar una antigua.
El modelo no tiene memoria más allá de lo que cabe actualmente en esa pizarra, que se invoca desde cero en cada llamada a la API.
Esto lleva a la reestructuración central de esta sección: el prompt es la interfaz.
Donde una API tradicional tiene una firma de función fija, la "firma" de un LLM es cualquier texto que elijas colocar dentro de la ventana de contexto en una llamada dada (instrucciones, ejemplos, conversación previa, documentos recuperados), y el modelo no tiene acceso a nada fuera de ella.
La estructura de roles de sistema/usuario/asistente es la forma estándar de esa interfaz.
El rol del sistema establece instrucciones permanentes y la persona, el rol del usuario lleva la tarea o pregunta real, y el rol del asistente contiene las respuestas previas del modelo al reproducir una conversación.
Dado que el modelo es sin estado entre llamadas, una conversación de varios turnos no significa que el modelo "recuerde" nada.
Es tu código el que reenvía toda la conversación previa, como tokens, dentro de la ventana de contexto cada vez, por lo que el historial de conversación tiene un costo real y creciente en tokens a medida que se alarga.
llamada 1: [system] [user: "hola"] -> [assistant: "hola"]
llamada 2: [system] [user: "hola"] [assistant: "hola"]
[user: "¿cuánto es 2+2?"] -> [assistant: "4"]
Cada llamada reenvía todo lo anterior: el modelo no tiene estado propio entre llamadas.
Esta es también la razón por la que el diseño de prompts y la gestión del contexto son la misma habilidad subyacente: decidir qué incluir es decidir qué cabe en una pizarra de tamaño fijo, y cada token gastado en una cosa es un token no disponible para otra.
La salida estructurada y los esquemas de herramientas/funciones existen para resolver un problema completamente diferente.
La salida nativa de un LLM es texto libre, pero la mayoría de los programas necesitan una forma específica y analizable (un objeto JSON con campos conocidos, o una llamada a una función específica con argumentos tipados) para actuar sobre la respuesta.
En lugar de analizar texto libre con expresiones regulares y esperar que la formulación del modelo se mantenga consistente, las APIs de salida estructurada te permiten proporcionar un esquema que restringe la respuesta del modelo para que coincida con esa forma, convirtiendo las palabras del modelo en un valor que tu programa puede usar directamente.
La llamada a herramientas extiende esta misma idea un paso más allá: en lugar de pedirle al modelo que responda directamente, describes las funciones disponibles en el esquema del prompt, y el trabajo del modelo se convierte en elegir qué función llamar y con qué argumentos.
Tu código, no el modelo, es el que la ejecuta.
A escala, el tamaño fijo de la ventana de contexto se convierte en una restricción arquitectónica real en lugar de una inconveniencia.
Una aplicación que quiere que un modelo razone sobre más información de la que cabe en una ventana, como un documento grande, una conversación larga o una gran base de conocimientos, no puede simplemente usar un prompt más grande más allá de ese límite.
La generación aumentada por recuperación existe específicamente para sortear esto: en lugar de poner una base de conocimientos completa en cada prompt, una búsqueda basada en embeddings recupera solo los pocos pasajes relevantes para la consulta actual, y solo esos se consumen del presupuesto de tokens.
Las conversaciones largas golpean el mismo muro desde una dirección diferente, por lo que las aplicaciones reales resumen o truncan los giros anteriores en lugar de reproducir una transcripción en constante crecimiento literalmente en cada llamada.
El crecimiento ilimitado del historial eventualmente excede la ventana, e incluso antes de hacerlo, hace que cada llamada sea más lenta y costosa.
Las garantías de la salida estructurada también difieren significativamente según el mecanismo, lo que importa al elegir cuán estrictamente necesitas que se aplique la forma.
| Estrategia de Salida | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Texto libre + análisis manual | Sin esquema que diseñar; máxima expresividad del modelo | Frágil: un cambio de formulación rompe silenciosamente tu analizador | Prototipado, salida legible por humanos, uso de bajo riesgo |
| JSON con prompt (pedir amablemente, analizar el resultado) | Funciona con cualquier modelo; no se necesita una característica de API especial | El modelo aún puede emitir JSON inválido o desviarse del esquema en respuestas largas | Necesidades estructuradas simples donde las reintentos ocasionales son aceptables |
| Salida estructurada nativa / generación con esquema restringido | La respuesta está garantizada o fuertemente restringida para coincidir con tu esquema | Requiere soporte del proveedor para la característica; restringe la libertad de formulación del modelo | Sistemas de producción que analizan la respuesta programáticamente |
Los esquemas de herramientas complican esto aún más en sistemas agenticos.
Que el modelo elija la herramienta incorrecta, o proporcione argumentos que no coincidan con los tipos descritos, es un modo de fallo funcionalmente idéntico al JSON mal formado en la salida estructurada simple, solo que un nivel más allá: el esquema es tan bueno como la precisión con la que describe lo que la función realmente necesita.
Un token es un fragmento de subpalabra producido por el tokenizador del modelo: las palabras comunes suelen ser un token, las palabras más raras se dividen en varias. Los modelos se entrenan y se les asigna un precio en tokens porque esa es la unidad en la que opera su vocabulario interno, no los caracteres brutos.
El número máximo de tokens, prompt y respuesta combinados en la mayoría de las APIs, a los que un modelo puede atender en una sola llamada. Es un límite estricto: el contenido más allá de él se trunca o se rechaza, no es simplemente más difícil de manejar para el modelo.
No, el modelo es sin estado entre llamadas. Una conversación de varios turnos funciona porque tu código reenvía todo el historial relevante como parte del prompt en cada nueva llamada, que es también por lo que las conversaciones largas cuestan más tokens por llamada a medida que crecen.
Significa que el texto que colocas en la ventana de contexto (instrucciones, ejemplos, historial, documentos recuperados) funciona como una firma de función. Es toda la superficie de entrada sobre la que el modelo puede actuar, y nada fuera de ella es visible para el modelo en absoluto.
Dan al modelo una forma consistente de distinguir las instrucciones permanentes de la tarea real en cuestión, y de los propios turnos previos del modelo al reproducir una conversación. Sin esa estructura, sería más difícil para el modelo ponderar correctamente las instrucciones y el contenido conversacional.
Los LLM producen nativamente texto libre, pero la mayoría de los programas necesitan una forma específica y analizable para actuar. La salida estructurada te permite proporcionar un esquema que restringe la respuesta para que coincida con esa forma, en lugar de analizar texto con formato flexible con expresiones regulares.
La salida estructurada da forma a una respuesta directa en un esquema; la llamada a herramientas hace que el modelo elija entre funciones descritas y produzca argumentos para una, pero tu propio código es el que realmente ejecuta esa función: el modelo nunca ejecuta nada por sí mismo.
Si los tokens del documento más tus instrucciones y la respuesta esperada exceden la ventana de contexto, será truncado o rechazado directamente. Incluso por debajo del límite, un documento muy grande cuesta proporcionalmente más por llamada y puede diluir la atención del modelo en la parte que realmente importa.
Resuelve el problema del límite de la ventana de contexto para grandes bases de conocimiento. En lugar de intentar meter todo en cada prompt, una búsqueda basada en embeddings recupera solo los pasajes relevantes para la consulta actual, por lo que solo esos tokens se consumen del presupuesto.
No. El JSON con prompt aún puede desviarse del esquema previsto o producir JSON inválido, especialmente en respuestas más largas, mientras que las características de salida estructurada nativas restringen o validan la respuesta directamente contra tu esquema, a costa de requerir soporte del proveedor.
Toda la conversación previa se reenvía como tokens en cada llamada. A medida que el historial crece, cada llamada subsiguiente lleva un prompt más grande, lo que cuesta más tokens y tarda más tiempo en procesar el modelo, independientemente de lo simple que sea la pregunta actual.
No automáticamente. El contexto irrelevante, redundante o mal organizado puede diluir la atención del modelo de la parte que realmente importa, por lo que la construcción deliberada de prompts y la recuperación tienden a superar la simple inclusión de todo lo disponible.
Versiones de Stack: Esta página es conceptual y describe el comportamiento de la forma de la API común en los SDK de proveedores de LLM actuales; no cita números de versión de modelos específicos ya que cambian más rápido que este modelo mental.
Revisado por Chris St. John·Última actualización: 19 jul 2026