Inteligencia Artificial a nivel técnico: de los tokens al RAG, pasando por los LLM

Cuando se habla de “IA” por ahí, el 90% de lo que lees es humo de marketing: “ChatGPT revoluciona”, “la IA te va a quitar el trabajo”… Nada de eso te sirve si lo que quieres es entender qué hay dentro. Esta guía es la que me habría gustado tener cuando empecé: empieza desde el componente más pequeño (el token, una palabra que vas a escuchar hasta la saciedad) y va subiendo de nivel hasta llegar a sistemas completos como los RAG y los agentes, pasando por cómo se entrena, cómo se ajusta y qué herramientas usa todo el mundo en el día a día.

La premisa es simple: no hace falta entender las matemáticas para entender el funcionamiento. Donde el concepto sea denso (atención, cuantización, indexación), te dejo el enlace para ir más profundo cuando lo necesites.

1. Antes de nada: de qué hablamos cuando hablamos de IA

Hoy “IA” casi siempre significa modelos de lenguaje, pero es útil tener el mapa completo para no liarte:

Una forma rápida de situarlo: ChatGPT no es “la IA”. ChatGPT es una aplicación construida sobre un LLM (GPT), al que se le ha añadido una interfaz, un sistema de conversación y un montón de ingeniería alrededor.

2. La pieza fundamental: las redes neuronales

Antes de los LLMs tuvimos, durante décadas, las redes neuronales. Si nunca has visto la intro más clara que existe, párate 30 minutos y mira el primer vídeo de la serie de 3Blue1Brown sobre redes neuronales: Neural networks — 3Blue1Brown. No exagero: tras ese vídeo, el resto de esta guía te resulta mucho más fácil.

La idea en tres líneas:

• Una red es un montón de neuronas organizadas en capas. Cada neurona recibe números, los multiplica por unos pesos, los suma y les aplica una función no lineal.
• Durante el entrenamiento, la red produce un resultado, se compara con el esperado mediante una función de pérdida y se ajustan los pesos en la dirección que reduce el error (backpropagation).
• Por mucha matemática que leas, esto es el núcleo: ajustar millones de parámetros para minimizar el error sobre muchos ejemplos.

Los LLMs no son otra cosa: redes neuronales muchísimo más grandes (miles de millones de parámetros) entrenadas con una tarea casi absurda de simple: predecir la siguiente palabra.

3. El modelo de lenguaje: de tokens a texto

3.1 Tokens: la moneda de cambio

Un LLM no entiende texto: entiende números. Y para convertir texto en números usa tokens. El token es la unidad de procesamiento y de facturación del modelo: un chat cuenta su coste en tokens, la ventana de contexto se mide en tokens, y hasta la velocidad de generación depende de ellos. La frase “me gusta Python” no entra entera: se parte en piezas como ["me", " gusta", " Python"], cada una con su ID de un vocabulario fijo.

Fíjate en un detalle: los tokens no son palabras ni caracteres, son fragmentos de subpalabra. Y un mismo texto produce tokens diferentes según la frecuencia con la que apareció durante el entrenamiento del tokenizador. Eso tiene consecuencias enormes (coste, idiomas, calidad), así que vamos a por el proceso completo.

¿Por qué no un token por palabra (y por qué no por carácter)?

• Por palabra: el vocabulario explotaría. “hablar”, “hablas”, “hablé”, “HABLO”, “Hablaré”… son formas distintas que además dependen de conjugación, género, mayúsculas y errata. No solo no caben todas: el modelo no podría tener memoria (embedding) para palabras que nunca ha visto (insultos inventados, tecnoargot, nombres de marca). Habría un problema de out-of-vocabulary continuo.
• Por carácter: el modelo tendría que dar muchísimos pasos (uno por carácter) y perdería las regularidades de las palabras: “in-”, “pre-”, “-ción” se comportan igual en muchas palabras, y a nivel de carácter no hay cómo compartirlo.

La tokenización subpalabra es el punto medio: un vocabulario fijo y manejable (~32k–200k tokens) con el que casi cualquier texto se puede cubrir con pocos pasos. Las piezas se reutilizan: una palabra inventada se descompone en trozos conocidos (“chatgptano” → chat + gpt + ano).

El proceso completo: así se construye un tokenizador

Los LLMs modernos usan BPE (Byte Pair Encoding), popularizado por el paper Neural Machine Translation of Rare Words with Subword Units (enlace). Se construye sobre un corpus (documentos en bruto) en cuatro fases:

1. Normalización: se deja el texto “limpio” con reglas que elige cada tokenizador: a veces pasar a minúsculas, unificar Unicode (NFKC: aplicar ṣ→“s”, acentos combinables a su forma NFD…), colapsar espacios raros. Esta fase ya destruye información a propósito: por eso el modelo pierde las mayúsculas si el tokenizador las normaliza, y por qué “café” escrito con caracteres raros puede no producir los mismos tokens.
2. Pre-tokenización: se corta el texto en “palabras ± espacios/puntuación” con reglas por idioma. Cada tokenizador trae su regex: la inglesa separa bien don't en don + 't, la francesa respeta l'aube, la japonesa no asume espacios porque no los hay. Esta es ya una de las razones por las que la tokenización difiere entre idiomas.
3. Base de bytes UTF-8: como “átomo irrompible” se usan los 256 bytes de UTF-8 en vez de palabras. Con eso cualquier texto del mundo —incluidos emojis y caracteres chinos— tiene una representación garantizada, sin importar lo raro que sea. Un emoji como 👋 son 4 bytes, así que se convierte en 1-3 tokens.
4. El bucle de fusión (el corazón del BPE): iterativamente se busca el par de símbolos adyacentes más frecuente del corpus y se fusiona en un token nuevo. Se repite hasta alcanzar el tamaño de vocabulario objetivo. Ejemplo ilustrativo con un corpus minúsculo {low, low, low, lower, lowest, newest, newest, newest, widest}:

Iteración 1: el par "lo" aparece en low+lower = 5 veces → fusionar: lo|w, lo|w, lo|w, lo|w+er, lo|w+est
Iteración 2: el par "low" aparece 5 veces → fusionar: low, low, low, low+er, low+est  (así se forma "low")
Iteración 3: "est" aparece en lowest+newest+widest → fusionar: low+est, new+est, w+d+est...
...sigue hasta alcanzar el tamaño de vocabulario pedido

Resultado: las secuencias muy frecuentes acaban siendo 1 token (low, los, the) y las raras quedan en pedazos (wides+t, id). El vocabulario aprendido es un reflejo de la lengua del corpus, con todo lo que eso implica.

De texto a IDs: así “lee” el modelo

Cuando le das un texto al modelo:

1. Pasa por la misma normalización y pre-tokenización de antes.
2. Se le aplican los merges BPE aprendidos, eligiendo la pieza más larga del vocabulario que coincida en cada punto (búsqueda greedy, no mágica). Por eso el mismo texto siempre produce los mismos tokens.
3. Cada pieza se traduce a su ID con una tabla del vocabulario: {token: id}. Lo que entra a la red neuronal es esa lista de IDs (más los tokens especiales como <|endoftext|> o [CLS], reservados y que jamás deberías escribir literalmente).
4. Al generar, la red emite un ID del mismo vocabulario (sección 3.3) y se descodifica con la tabla inversa. Encodear y decodear es solo mirar una tabla — el “cerebro” empieza una vez que ya tienes los IDs. Por eso tokenizer es una librería aparte de model.

Si quieres verlo en vivo: el tokenizador de GPT-4 en The Tokenizer Playground o implementado a mano en Let’s build the GPT Tokenizer — Karpathy (te recomiendo este vídeo si quieres la verdad completa).

¿Por qué la tokenización es distinta en cada idioma?

El tokenizador no aprende “lenguaje universal”: aprende las frecuencias de un corpus concreto, que en la práctica es abrumadoramente inglés. Las consecuencias:

• En inglés, las palabras comunes son 1 token (the, streets, understanding), porque aparecieron miles de veces como unidad.
• En idiomas menos representados (español, francés, alemán y mucho peor tailandés, árabe, japonés, hindi…), la misma palabra suele partirse en 2-5 tokens, a veces piezas byte a byte. “こんにちは” (japonés) → 3-4 tokens; “Haushaltskasse” (alemán) → varios; el tailandés, que no usa espacios, se parte prácticamente a tientas.
• Morfología flexiva: “hablar”/“hablo”/“hablaremos” no comparten token (salvo el lexema “habl”), y el modelo depende de las piezas comunes para generalizar. Por eso los tokens son subpalabras: la semejanza se ve en los fragmentos, no en la palabra entera.

Este desequilibrio es un impuesto invisible sobre los idiomas no-inglés:

• Coste: las APIs cobran por token. El mismo contenido (en tokens) vale 2-3x más en un idioma minoritario.
• Contexto: llenas la ventana de contexto antes (sección 3.4) — el “espacio” disponible del modelo se fagocita con 4 tokens donde con 1 bastaba.
• Rendimiento percibido: más tokens por frase = más pasos de generación = más lento y más superficie para errores.
• Calidad de los embeddings: una palabra partida en trozos ambiguos puede “sonar” a otra cosa en la capa de atención.

Implicaciones prácticas para tu día a día

1. Números y espacios: los BPE clásicos tokenizan los dígitos fatal (a veces 1 token por dígito si están mezclados con letras), por eso los modelos modernos dedican trucos específicos a los números.
2. Estimación: como regla grosera, ~1.000 tokens ≈ 750 palabras en inglés; en español parecido; en CJK bastantes más tokens por carácter.
3. Herramientas: tiktoken (OpenAI), tokenizers (casi todo el mundo), y cualquiera de los playgrounds online para experimentar con el texto antes de mandarlo.
4. Detalle fino: si algún día optimizas coste o latencia de verdad, el tokenizer es el primer sitio donde mirar (p. ej. eligiendo el idioma del contenido, recortando listados que inflan tokens, o usando encodes sin juegos con espacios).

Y un apunte sobre los embeddings

Cada token del vocabulario tiene un ID para la red y un embedding: un vector de números (p. ej. 768-4096 dimensiones) que lo representa en un espacio geométrico donde cosas parecidas quedan cerca. La cercanía se mide con similitud coseno (ángulo entre vectores) y sobre esa idea se construye todo lo demás que verás: bases vectoriales, RAG, búsqueda semántica (secciones 5, 6 y 8). Si quieres verlo despacio: The Illustrated Word2vec — Jay Alammar.

3.2 El Transformer y la atención

Desde 2017, prácticamente todos los LLMs son transformers, la arquitectura del paper Attention is all you need (enlace al paper). La pieza clave es el mecanismo de atención: le permite al modelo saber, en cada posición de la frase, a qué otras palabras prestar atención. En la frase “el banco abrió la cuenta”, el modelo aprende a relacionar “banco” con “cuenta” a pesar de que no estén juntas.

La mejor explicación visual de la atención la tienes en The Illustrated Transformer — Jay Alammar. Es un clásico, léelo cuando quieras bajar una muesca abajo en abstracción.

3.3 Generar texto: logits, temperatura y sampling

Un LLM no “piensa” la respuesta: genera texto token a token, de forma autoregresiva (cada token nuevo depende de todos los anteriores). Para cada posición, la red devuelve una puntuación por cada posible token del vocabulario (logits), que se pasa por una softmax para convertirlas en una distribución de probabilidad.

Entonces hay que elegir un token:

• Greedy: coge el más probable siempre. Resulta aburrido y repetitivo.
• Temperatura: escala los logits antes de la softmax. temperature=0 es determinista; valores altos hacen la salida más creativa (pero más dispersa).
• Top-k / top-p (nucleus sampling): recorta el abanico de tokens candidatos para que las respuestas no salten entre temas.
• Beam search: mantiene en paralelo las K secuencias más probables hasta el final y escoge la mejor. Típico de traducción y ASR; en chat moderno se usa poco porque favorece respuestas genéricas y cortas.

Este es el motivo por el que un mismo prompt devuelve respuestas distintas: hay ruido deliberado en el muestreo, no es magia. Karpathy lo resume genial en Transformers from scratch si quieres verlo implementado en 500 líneas de código de verdad.

3.4 La ventana de contexto y el KV-cache

El contexto es todo lo que el modelo “ve”: tu prompt, los mensajes anteriores, y la respuesta que está generando. Los LLMs modernos admiten ventanas enormes (128k, 200k tokens e incluso millones en los más nuevos), pero no es gratis: toda esa atención se recalcula, y aquí entra el KV-cache (Key-Value cache), que guarda las representaciones de los tokens pasados para no repetir el cálculo en cada paso. Cuanto más largo el contexto, más memoria de GPU consume, y por eso “meter el PDF entero” en el prompt es carísimo frente a extraer solo lo relevante (que es, sorpresa, lo que motiva los RAG de la sección 5). Teoría y medidas en KV cache explained y Prompt caching en Anthropic.

3.5 Anatomía del Transformer: queries, keys, values y posiciones

El mecanismo de atención no es un “focus” abstracto: se monta sobre tres proyecciones lineales por token — Query (Q: qué busco yo), Key (K: qué ofrezco yo) y Value (V: qué aporto). La atención entre dos tokens es un producto escalar Q·K (más softmax) que decide cuánto peso dar al Value de uno frente al otro. Por eso el KV-cache de la sección 3.4 guarda justo esas proyecciones.

Además, la atención por sí sola no sabe en qué orden van los tokens (es un conjunto, no una secuencia). Por eso los transformers inyectan posiciones: las clásicas sinusoidales del paper original, o las modernas RoPE (Rotary Positional Embeddings), que codifican la posición rotando Q y K según la distancia. RoPE es clave para las ventanas largas (puede escalar hacia arriba a contextos que no vio en entrenamiento). Más en Understanding QKV (3Blue1Brown, vídeo) y Rotary Positional Embedding — Elephant Robotics.

3.6 Encoder vs decoder: no todas las arquitecturas sirven para lo mismo

Attention is all you need proponía un transformer completo con dos mitades, y aún hoy “transformer” es un paraguas:

• Encoder-only (ej. BERT, que aprendía con masked language modeling: ocultar palabras al azar y predecir cuáles son): lee toda la secuencia de golpe (bidireccional) y produce embeddings ricos. Ideal para clasificar, extraer o crear vectores de búsqueda (¡los de la sección 5!).
• Decoder-only (todo el GPT: autoregresivo, A B C → predice D). Genera texto. Es la familia dominante de LLMs de chat.
• Encoder-decoder (ej. T5, BART): añade un paso de compresión intermedio; excelente para resumir o traducir.

Que un modelo “lea” antes de escribir (encoder) o directamente prediga (decoder) no es un detalle cosmético: decides cuál usar según si quieres entender o generar. Detalle de la arquitectura en The Transformer — Papers with Code.

3.7 Eficiencia: GQA, Flash Attention y MoE

La atención es el cuello de botella, y sobre ella hay toda una industria de atajos:

• GQA (Grouped-Query Attention): reduce el número de cabezas de Key/Value compartiendo V entre cabezas de Query. Menos memoria de KV-cache sin perder casi calidad (lo usa Llama 2 70B y Llama 3). Idea y números en GQA paper.
• Flash Attention: reimplementa la atención hardware-consciente para no escribir QKᵀ entero en memoria. Resultado: decenas de veces más barata y hasta 2-4x más rápida en entrenamiento, y es la razón por la que hoy se pueden entrenar modelos con millones de tokens por lote. Paper y charla de Tri Dao: Flash Attention.
• MoE (Mixture of Experts): cada token solo despierta a un subconjunto de “expertos” (lo decide una pequeña red llamada router). Con eso se multiplica el número de parámetros totales sin multiplicar el coste por token (sparsity activa). Es la arquitectura detrás de Mixtral, DeepSeek-V3 o Qwen-MoE. Miniguía en Mixture of Experts explained (Hugging Face).

3.8 El modelo aprende del contexto: in-context learning, CoT y salidas estructuradas

El LLM puede “aprender” sin tocar sus pesos: in-context learning. Le das ejemplos en el propio prompt y ya sabe seguir el patrón:

• Zero-shot: “traduce esto a español” sin ejemplos.
• Few-shot: le muestras 3 ejemplos antes de pedirle el 4º.
• Chain-of-thought (CoT): pedirle que razone paso a paso en voz alta mejora resultados en matemáticas y lógica (paper de Wei et al., 2022). Los modelos o1 y R1 llevan esto al extremo: esconden el razonamiento en tokens de “pensamiento” y cobran un coste de cómputo extra en tiempo de inferencia (test-time compute), ver sección 4.2.
• Salidas estructuradas: para que no te responda con texto libre cuando necesitas un JSON, se fuerza a la generación con gramáticas o constrained decoding (el token emitido debe cumplir la gramática del JSON). En local lo hace llama.cpp o Outlines, en la nube es el famoso JSON mode.

4. Entrenar un LLM: las tres fases

Puedes separar la vida de un modelo en tres etapas distintas, cada una con su coste y su propósito:

1. Pre-training — El modelo aprende lenguaje general prediciendo el siguiente token sobre cientos de miles de millones de tokens de internet. Salen los llamados base models (ej. Llama-3-8B, Qwen-2.5-14B). Aquí está el 99% del coste eléctrico y de dinero.
2. Fine-tuning supervisado (SFT) — Se entrena un modelo base con miles de pares pregunta→respuesta para que adopte el estilo de asistente. Esto ya es factible en una GPU de consumo.
3. Alineación (RLHF / DPO) — Se refina el comportamiento para que responda “bien” (rechazar peticiones peligrosas, no alucinar tanto, seguir tono). Técnicas como DPO simplifican mucho ese paso frente al RLHF clásico (PPO). Explicación clara en RLHF en 4 pasos (eng) y DPO, el arma secreta (eng).

4.1 Fine-tuning eficiente: LoRA y cuantización

Ajustar todos los parámetros de un modelo de 7B es inasumible en una máquina normal. La solución estándar es LoRA (Low-Rank Adaptation): en lugar de tocar los pesos originales, entrena unos parchecitos de bajo rango que se añaden a las capas. El modelo original queda congelado y el ajuste ocupa megas en vez de gigas. Variantes como QLoRA van un paso más allá y cuantizan el modelo base a 4 bits antes de entrenar, lo que permite fine-tunear modelos grandes en una sola GPU. Por qué funciona y cómo: LoRA: Low-Rank Adaptation of LLMs (paper) y Understanding LoRA — Hugging Face.

Y ya que hemos mencionado la cuantización: consiste en guardar los pesos con menos precisión (32→4-8 bits) para que el modelo quepa en menos memoria y vaya más rápido a costa de un poco de fidelidad. Es la razón por la que puedes correr un Llama de 8B en un ordenador de sobremesa. Teoría bien explicada en Quantization for LLMs y en Una intro visual a la cuantización.

4.2 Modelos de razonamiento: cuando pensar cuesta más cómputo

Desde 2024-2025 hay una nueva familia de modelos (OpenAI o1/o3, DeepSeek-R1, Qwen-Reasoning) que no responden a la primera: generan una “línea de razonamiento” larga y oculta (decenas o cientos de tokens de CoT) antes de dar el resultado. Eso se llama test-time compute (gastar más cómputo en inferencia, no en entrenamiento): responden mejor cuanto más tiempo de pensamiento se les da.

Se entrenan igual que el resto, pero con una fase extra: RL sobre recompensas verificables (RLVR) — la señal es objetiva (¿el resultado matemático es correcto?, ¿el formato se cumple?), no un humano. El paper de DeepSeek-R1 abrió la vía para que cualquiera pueda destilar este comportamiento en modelos abiertos más pequeños. Consecuencia práctica: estos modelos suelen exigir más VRAM/tokens que un chat normal, y hay que configurarlos adecuadamente en el backend (tiempo y “tokens de pensamiento”).

5. RAG: el modelo que usa tu base de conocimiento

Aquí llegamos al concepto que más nombre tiene últimamente y que menos bien se explica: RAG (Retrieval-Augmented Generation).

Piensa en el problema: tu LLM fue entrenado con internet hasta cierta fecha. No sabe nada de tu empresa, tu documentación interna o tu último proyecto. Tienes tres opciones:

1. Fine-tunear el modelo con tus datos → caro, lento, y el modelo puede “aprender de memoria” cosas equivocadas.
2. Pegarle todo en el prompt → la ventana de contexto se come la memoria y el precio se dispara.
3. RAG → el modelo sale a buscar solo los trozos relevantes de tu base de conocimiento, los mete en el prompt solo con lo que necesita, y responde citando la fuente real.

RAG no es una técnica exótica: es un pipeline con 4 piezas:

1. Ingestión: tu documentación se parte en chunks (trozos de N tokens con solape).
2. Embeddings: cada chunk se convierte en un vector con un modelo de embeddings (ej. text-embedding-3-small, bge-m3, nomic-embed-text).
3. Búsqueda: ante una pregunta, se convierte la pregunta al mismo tipo de vector y se buscan los N vecinos más cercanos en una base vectorial (similitud coseno). Para millones de vectores se usan índices ANN (búsqueda aproximada), de los que el de facto es HNSW. Cómo funciona HNSW en 5 minutos: HNSW explained y Pinecone — Algoritmos de búsqueda vectorial.
4. Generación: los chunks recuperados se meten en el prompt con instrucciones de “responde usando solo este contexto” y el modelo genera.

El flujo, en un diagrama de texto:

Documento  ──chunking──►  chunks  ──embeddings──►  vectores  ──►  Vector DB
                                                                    ▲
Pregunta ───────────► embedding ────────────────────────────────────┘
                                                                    │ top-k
                                               Prompt = contexto + pregunta
                                                                    │
                                                              LLM genera

5.1 Ejemplo mínimo en código (FAISS + sentence-transformers)

from sentence_transformers import SentenceTransformer
import faiss

# 1. Modelo de embeddings
model = SentenceTransformer("sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")

# 2. "Base de conocimiento" → vectores
chunks = [
    "El RAG recupera los trozos relevantes antes de que el modelo genere.",
    "Los embeddings ponen textos similares cerca en un espacio vectorial.",
    "La temperatura controla la creatividad del muestreo de tokens.",
]
vectors = model.encode(chunks, normalize_embeddings=True)  # normalizado → coseno real
index = faiss.IndexFlatIP(vectors.shape[1])   # IndexFlatIP = producto escalar = coseno si está normalizado
index.add(vectors)

# 3. Búsqueda
query_vec = model.encode(["¿Qué recupera el RAG?"], normalize_embeddings=True)
_, idx = index.search(query_vec, k=1)
print(chunks[idx[0][0]])   # "El RAG recupera los trozos relevantes..."

Con FAISS local y unas pocas líneas ya tienes el 80% del RAG más sencillo. Cuando la base crezca, cambiarás IndexFlatIP por un índice HNSW y montarás un servicio (Qdrant, Milvus, Chroma, pgvector) que gestione la indexación.

5.2 Dónde suele fallar el RAG

Solo porque lleves semanas viendo “RAG” en tu feed, no pienses que es plug-and-play. Los problemas típicos:

• Chunking malo: tropiezas con listas, tablas o fragmentos sin contexto. Se soluciona con recursive character splitting, partidos por headings, etc.
• Recuperación imperfecta: el top-k trae basura. Se añade un reranker (un modelo pequeño que reordena por relevancia real) con técnicas como hybrid search (mezclar búsqueda semántica con texto literal).
• Evaluación: ¿cómo sabes que el pipeline funciona? Herramientas tipo RAGAS miden fidelidad, relevancia y cobertura del contexto. Más en RAGAS (eng).

Guía de referencia con todo el detalle de chunking y las opciones: Advanced RAG — Pinecone.

6. Agentes: el LLM que decide usar herramientas

Un LLM solo conversa. Un agente es un LLM metido en un bucle donde puede llamar herramientas. Las piezas son:

• Function calling: el LLM, en vez de responder textualmente, emite una estructura del tipo “quiero llamar a search_web(query=...)”. El sistema ejecuta esa función y le devuelve el resultado; el modelo continúa.
• Loop ReAct (Reason + Act): el modelo alterna razonamiento (“necesito la temperatura actual”) y acción (“llamo a la API del tiempo”), en bucle, hasta que puede dar la respuesta final. La idea original: ReAct paper.
• Memoria: conversación corta, resúmenes largos, y memoria semántica (de nuevo: embeddings + búsqueda).
• Planning: modelos que se descomponen el objetivo en subtareas. Los sistemas tipo tree-of-thoughts o los “agent orchestration” van por ahí. Un buen desglose del hype: How to build good agents — Anthropic y Build a ReAct agent a mano (eng).

Un agente en 10 líneas conceptuales:

while not finished:
    thought = llm(f"Tienes estado: {state}. Razonamiento:")
    action = parse_tool_call(thought)      # p.ej. tool="search", args=...
    result = execute_tool(action)
    state += f"\nResultado: {result}"

Todo el hype de “agentes autónomos” es casi siempre esto: un bucle, herramientas, y una buena definición del estado. Nada mágico, y aún menos fiable de lo que parece cuando encadenas 20 pasos.

7. Modelos multimodales

Un modelo multimodal acepta (o emite) varios tipos de datos: texto + imagen + audio + vídeo. Internamente, cada modalidad tiene su encoder (una red que convierte píxeles o audio en vectores) y los vectores se proyectan al mismo espacio que los tokens de texto, así el transformer los procesa juntos.

• El clásico para entender vision+texto es CLIP (paper), que aprende a alinear imágenes y frases en el mismo espacio vectorial.
• Los LLMs actuales (GPT-4o, Gemini, Llama 3.2 Vision, Qwen2-VL) integran el encoder directamente en el generador.

Un uso práctico que te interesa si vienes de este blog: búsqueda multimodal. Puedes indexar capturas de pantalla o memes con embeddings de imagen y buscar por descripción textual. Lo mismo que RAG, pero con imágenes.

8. IA local y el ecosistema real de herramientas

La parte que más te va a servir en el día a día: qué modelo usar, dónde descargarlo y cómo ejecutarlo. Todo esto es gratis y corre en tu máquina.

8.1 El ecosistema Hugging Face

HF es el GitHub de la IA. Si vas a tocar modelos, te vas a vivir allí:

• transformers: la librería canónica para cargar y usar modelos (PyTorch/TensorFlow). Ejemplo mínimo:

from transformers import pipeline

generator = pipeline("text-generation", model="HuggingFaceTB/SmolLM2-135M-Instruct")
print(generator("La capital de España es", max_new_tokens=30)[0]["generated_text"])

• tokenizers: la librería de tokenización, rápida y en Rust.
• datasets: miles de datasets listos para fine-tuning.
• Formatos de pesos: safetensors (seguro y rápido), y GGUF para correr en CPU.
• Model Hub: todos los modelos con su ficha de licencia. Muchos LLMs buenos y abiertos: Llama, Mistral, Qwen, Gemma, DeepSeek… Los rangos “pequeños” (1B-8B) se ejecutan en una GPU normal.

Si quieres aprender haciendo, el Hugging Face NLP Course es gratis y está muy bien.

8.2 Ejecutar modelos localmente

Ejemplo con Ollama (tras ollama pull llama3.2:3b):

ollama run llama3.2:3b "Explica qué es un RAG en dos frases"
# si quieres OpenAI-compatible para usarlo desde código:
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Qué es un RAG"}]}'

8.3 Orquestadores y librerías

• LangChain / LlamaIndex: frameworks para montar RAG y agentes. Traen mucho hecho (splitters, retrievers, toolkits). Crítica justa: a veces abstraen demasiado y ocultan el detalle. El LlamaIndex RAG handbook está bien para ver patrones, pero el RAG de la sección 5 te enseña el fondo real.
• Bases vectoriales: FAISS (local, librería), Chroma (simple, embebible), Qdrant (servicio en Rust, muy usado), Milvus (escala), pgvector (si ya usas Postgres, suele ser la opción más pragmática: uso de pgvector, y hablamos de bases en este blog para otros proyectos). Para embeddings de frases en español: sentence-transformers con modelos paraphrase-multilingual-* o bge-m3.

8.4 ¿Cuánta memoria necesito para correr un modelo?

La regla que se usa a diario en producción:

VRAM ≈ pesos + KV-cache + overhead del runtime

• Pesos: parámetros × bytes por parámetro. En FP16 son ~2 bytes: un modelo de 8B ocupa ~16 GB en FP16, ~8 GB en INT8 y ~4-5 GB en 4 bits (GGUF Q4).
• KV-cache: depende del contexto. Estimación rápida: ~0.5-1 GB por cada 10k tokens (más en modelos grandes) solo para las claves y valores de la conversación.
• Overhead: activaciones y buffers del backend (del 5 al 20% adicional).

Con esa cuenta, un Llama 3 8B en Q4_K_M (~4.9 GB) + contexto de 32k (~3 GB) sobre una GPU de 8 GB va justo pero funciona; un 70B FP16 (~140 GB) no cabe ni en una tarjeta de 48 GB ni en un portátil: ahí aparecen la cuantización, vLLM (offloading parcial), o directamente un servicio en la nube con GPU. Calculadoras: llamafile VRAM y how to choose a model.

9. Evaluación y alucinaciones: el gran dolor de cabeza

Un LLM puede responder con total seguridad una mentira completa. Eso es una alucinación, y no es un bug: es consecuencia de que el modelo predice texto, no consulta una base de datos.

¿Cómo se mide la calidad de verdad de estos sistemas?

• Perplexity: lo bien que un modelo predice un texto. Mide “fluidez”, no verdad. Cuanto más bajo, mejor predice el modelo ese texto concreto.
• Benchmarks: MMLU, HumanEval, GSM8K… miden conocimiento o razonamiento en condiciones controladas. Ojo: se saturan rápido y pueden estar “contaminados” (ya vistos en el entrenamiento).
• LLM-as-judge: otro LLM puntúa las respuestas. Barato y habitual, pero con sus sesgos (reflexión sobre límites).
• RAGAS / DeepEval: evaluación orientada a sistemas RAG (fidelidad, relevancia).
• Human eval: el oro, caro y lento.

Mitigaciones prácticas de alucinación en un sistema tuyo:

1. Dar contexto (RAG) y pedir que cite.
2. Bajar la temperatura.
3. Pedir “no lo sé” explícitamente y modelar la incertidumbre en el prompt.
4. Validar estructuradamente (si el modelo devuelve JSON, valídalo con schema) y verificar de nuevo (generar → verificar).
5. Escape-hatches: si el sistema no está seguro por debajo de un umbral, no responder.

Nada elimina las alucinaciones al 100%. Quien te diga que su sistema no alucina, te está intentando vender algo.

10. Mini glosario de supervivencia

11. Para seguir aprendiendo (en orden)

Si quieres de verdad dominar esto, esta es la ruta que yo seguiría, y cada eslabón dura lo suyo:

1. 3Blue1Brown — Redes neuronales: la base visual e intuitiva de todo.
2. Karpathy — Neural Networks: Zero to Hero: del zero a entrenar un mini-GPT realmente. Lo más denso pero lo más formativo de la lista.
3. The Illustrated Transformer — Jay Alammar y su guía de embeddings: el puente entre intuición y arquitectura.
4. HF NLP Course: haces fine-tuning de verdad con transformers.
5. Advanced RAG — Pinecone: cuando tu primer RAG no recupere bien.
6. Building effective agents — Anthropic: cuando quieras montar agentes sin que se conviertan en un infierno.

12. Cierre

La IA actual es menos “cerebro mágico” y más ingeniería de un predictor de tokens muy grande al que se le añaden capas cada vez más inteligentes (prompting, RAG, herramientas, evaluación). Una vez que entiendes las piezas —tokens, embeddings, atención, sampling, fine-tuning, recuperación— el “hype” se convierte en vocabulario y puedes ir a por lo divertido: montar sistemas tuyos.

Empieza por lo mínimo: cárgate un modelo pequeño con transformers o ollama, castea un par de frases a embeddings y compáralas con coseno. Con eso ya tienes más “IA aplicada” que el 90% de los artículos que hablan de ella.