El LLM como componente de software

Casi toda la ingeniería de software se apoya en una suposición silenciosa: si le das a una función la misma entrada, devuelve el mismo resultado. Los tipos, las pruebas y los contratos de API dependen de eso. Un gran modelo de lenguaje (LLMLLM Large language model: red neuronal entrenada para predecir el siguiente token y ajustada para seguir instrucciones.) rompe esa suposición, y además falla de una forma incómoda: sus respuestas equivocadas parecen correctas.

Esta lección trata al LLM como un componente con un contrato particular. Cubre en qué se diferencia ese contrato, qué son los tokensToken Pedacito de texto, a menudo parte de una palabra, que el modelo lee y escribe y por el que cobran los proveedores. y por qué cuestan, por qué el modelo no recuerda nada entre llamadas, qué hace y qué no hace la "temperatureTemperature Ajuste que controla cuán aleatoria es la elección del siguiente token: bajo da salidas predecibles, alto da salidas más variadas." y cómo convertir el texto del modelo en datos confiables. Los casos de estudio son docket, que llama a modelos, y Adapta, que los sirve.

Un contrato distinto

Un programa llama a un modelo enviándole mensajes, por ejemplo una instrucción ("extrae los datos de contacto") y el texto del usuario, y recibe texto de vuelta. La solicitud web en sí es exacta; el contenido no. Una respuesta exitosa significa "el modelo respondió", no "la respuesta es correcta".

Tokens: lo que el modelo lee y lo que pagas

Los modelos no leen letras ni palabras. Leen tokens: fragmentos de texto, a menudo una palabra corta o parte de una más larga. En inglés un token equivale en promedio a unos cuatro caracteres; el español y muchos otros idiomas necesitan más tokens para el mismo contenido. Los tokens importan porque:

• se cobran, normalmente con precios distintos para la entrada y la salida;
• tienen límite: cada modelo tiene una ventana de contextoVentana de contexto Máximo de tokens que un modelo puede leer en una llamada; el modelo no conserva nada entre llamadas. máxima, el total de texto, entrada más salida, que puede manejar en una llamada;
• toman tiempo: el modelo escribe un token a la vez.

Sin memoria entre llamadas

El modelo no recuerda nada de una llamada a la siguiente. Una app de chat que parece recordar está reenviando todo el historial cada vez. Por eso cada turno cuesta más que el anterior, alguien tiene que decidir qué descartar cuando el historial ya no cabe, y lo que queda fuera no existe para el modelo.

El historial se envía como mensajes con rol: system para las instrucciones del desarrollador, user, assistant para las respuestas anteriores del modelo y, donde hay herramientas, tool. Pero antes de que el modelo los vea, todos los mensajes se unen en un solo texto, con marcas donde empieza y termina cada rol (Adapta lo hace en adapta/core/chat_templates.py).

Eso importa para la seguridad: no hay una pared entre instrucciones y datos. El rol system pesa más solo porque el modelo fue entrenado para obedecerlo, así que un texto escondido en un documento puede competir con tus instrucciones (ver Sandboxing y seguridad de agentes).

Temperature no es determinismo

Para cada token siguiente, el modelo elige entre opciones probables. La temperature fija qué tan arriesgada es esa elección. Cerca de 0, casi siempre toma el token más probable; con valores más altos, explora alternativas.

Quién fija el valor por defecto también es una decisión de diseño. docket se lo deja al proveedor salvo que quien llama elija uno, así que nunca adivina los valores por defecto de un modelo. Adapta, como es el servidor, aplica su propio valor configurado y limita el largo de la respuesta.

Convertir texto en datos confiables

Para una persona, Nombre: Ana. Email: ana@example.com es perfecto. Para un programa que debe guardar ese email, es texto libre cuya forma puede cambiar entre respuestas. Hay tres niveles de defensa:

1. Pedirlo en las instrucciones ("responde solo con JSON"). Funciona casi siempre.
2. Usar structured output (salida estructuradaSalida estructurada Hacer que el modelo responda en un formato de datos fijo definido por un esquema, normalmente JSON Schema, para que los programas lo lean de forma confiable.): el proveedor obliga a que la respuesta sea JSON válido o siga un esquema que tú defines.
3. Validar siempre en tu propio código. Un esquema puede comprobar que el email es texto; no puede distinguir una dirección real de una inventada.

Después, decide qué pasa cuando la validación falla: reintentar, pedirle al modelo que corrija, pasárselo a una persona o rechazarlo. Esa decisión es AI engineering en miniatura.

Fallas que parecen correctas

• Respuestas cortadas. Si el modelo llega a su límite de largo, el JSON o una solicitud de herramienta pueden quedar a medias. docket lo detecta y termina el turno como inválido sin ejecutar ninguna herramienta.
• Forma válida, contenido inventado. Pasa cualquier validación de tipos.
• Instrucciones ignoradas en silencio, como responder en otro idioma.
• Salida vacía que no cuenta como error. En la generación de datos de Adapta, una respuesta que no se puede parsear no produce nada, pero solo los errores de ejecución cuentan para la tasa de fallas, así que ese fragmento no aporta datos sin que nadie lo note.

En la práctica

• Valida en el código, no solo en las instrucciones.
• Define una respuesta para cada falla esperable: reintentar, pedir corrección, escalar a una persona o rechazar.
• Mide utilidad, no solo respuestas: "el modelo respondió" y "la respuesta fue útil" son números distintos. Ver Evaluar modelos.

Si el modelo va a pedir acciones y no solo producir texto, el siguiente paso es De la aplicación con LLM al agente.

Para profundizar

La documentación de Adapta y de docket muestra estas ideas desde los dos lados, el servidor y quien llama (en inglés):

• Learning the system explica qué calcula un modelo de lenguaje, qué son los tokens y por qué determinan costos y límites.
• Architecture sigue una solicitud de chat a través de Adapta, incluido el paso que comprueba que el promptPrompt Todo lo que se envía al modelo en una llamada: instrucciones, mensajes de la conversación y las definiciones de herramientas, si las hay. quepa en la ventana de contexto.
• Consuming the API muestra cómo un programa llama a Adapta y qué recibe: la respuesta, el uso de tokens y un formato de error consistente.
• Models, gateways, and coding harnesses explica cómo docket se conecta con los proveedores de modelos, y qué garantiza y qué no la palabra "compatible".

Para llevar

• Una llamada exitosa solo significa que el modelo respondió; la corrección hay que verificarla aparte.
• Los tokens cuestan dinero, espacio y tiempo; separa los conteos reales de las estimaciones.
• El modelo no tiene memoria: el historial se reenvía cada vez, y todos los roles terminan en un solo texto.
• Una temperature de 0 no garantiza respuestas repetibles, y repetible no significa correcto.
• Valida siempre la salida en tu propio código y decide de antemano qué pasa cuando la validación falla.

Comprueba lo aprendido