Fundamentos de LLMs

Tokenización

La tokenización es el proceso de trocear el texto en tokens, las unidades con las que trabaja el modelo: fragmentos de palabra, palabras enteras o signos de puntuación. En inglés, un token equivale de media a unas tres cuartas partes de una palabra; en español o en catalán, cada palabra suele ocupar más tokens.

Importa por tres motivos: los proveedores cobran por token (de entrada y de salida, a menudo a precios distintos), los límites del modelo se miden en tokens y el modelo «ve» tokens, no letras. Por eso le cuesta contar caracteres o tratar palabras raras letra a letra.

Embeddings

Un embedding es un vector de números (a menudo de cientos o miles de dimensiones) que representa el significado de un texto. Textos con un significado parecido tienen vectores cercanos, aunque no compartan ninguna palabra: «quiero devolver el producto» y «¿cómo hago una devolución?» quedan cerca.

Son la base de la búsqueda semántica, de la clasificación y del RAG (Módulo 3). Se generan con modelos específicos de embeddings, más pequeños y baratos que los de chat. Una regla importante: para comparar vectores, todos deben haberse generado con el mismo modelo y las mismas dimensiones.

Ventana de contexto

La ventana de contexto es la cantidad máxima de tokens que el modelo puede tener en cuenta en una sola llamada, sumando las instrucciones, el historial de la conversación, los documentos que le pasas y la respuesta que genera.

Una ventana grande no significa que haya que llenarla. Cuanto más contexto, más coste y más latencia, y los modelos tienden a prestar menos atención a la información enterrada en medio de un contexto largo. Decidir qué entra y qué no es justamente el context engineering (Módulo 2).

Temperature, top-p y top-k

Son parámetros que controlan cómo elige el modelo el siguiente token entre los candidatos posibles. La temperature ajusta la aleatoriedad: baja (cerca de 0) hace las respuestas más previsibles y repetibles; alta, más variadas y creativas. Top-k limita los candidatos a los k más probables, y top-p a los que suman una probabilidad acumulada p.

En la práctica, basta con tocar la temperature: baja para extraer datos, clasificar o seguir un formato, y más alta para redactar o generar ideas. Algunos modelos, sobre todo los de razonamiento, ignoran o restringen estos parámetros.

System prompt y user prompt

El system prompt define el papel y las reglas del modelo para toda la conversación («eres el asistente de soporte de una tienda; responde siempre con un tono amable y no prometas nunca un reembolso»). El user prompt es la petición concreta de cada turno: el ticket que hay que resumir o la pregunta del cliente.

Separarlos tiene consecuencias prácticas: el system prompt es estable y se puede versionar y probar, mientras que el user prompt lleva datos variables, a menudo escritos por terceros. Esta separación es también la primera línea de defensa contra el prompt injection (Módulo 5).

Zero-shot, few-shot y chain-of-thought

Son tres formas de pedir una tarea. Zero-shot: solo las instrucciones, sin ejemplos. Few-shot: las instrucciones y algunos ejemplos de entrada y de salida esperada, para que el modelo imite el patrón. Chain-of-thought: pedir al modelo que razone paso a paso antes de dar la respuesta final.

El few-shot funciona muy bien para fijar un formato o un tono, pero los ejemplos también «contaminan»: el modelo tiende a copiar detalles que no querías. El chain-of-thought mejora los problemas de varios pasos a cambio de más tokens y más tiempo; los modelos de razonamiento actuales ya lo hacen internamente (Módulo 11).

Grounding

El grounding es anclar la respuesta del modelo en información concreta que le proporcionas (documentos, datos de la base de datos, el texto de un ticket) en lugar de dejar que responda solo con lo que aprendió durante el entrenamiento.

Es la forma principal de conseguir respuestas correctas y actualizadas sobre tu dominio: el modelo no sabe cuál es tu política de devoluciones hasta que se la das. El RAG (Módulo 3) es, de hecho, una técnica para hacer grounding de forma automática.

Alucinaciones

Una alucinación es una respuesta que suena convincente pero que es falsa: un dato inventado, una referencia que no existe o una política de la empresa que nadie ha escrito nunca. No es un error puntual, sino una consecuencia de cómo funcionan los modelos: generan el texto más plausible, que no siempre es el cierto.

No se pueden eliminar del todo, pero sí reducir y contener: grounding con fuentes fiables, instrucciones explícitas para que diga «no lo sé», salida estructurada que se puede validar con código y revisión humana antes de que la respuesta tenga efectos. El diseño debe dar por hecho que el modelo se equivocará alguna vez.