Bienvenido al Curso de RAG a fondo. Si ya pasaste por Fundamentos de embeddings y RAG, ahí viste la idea general en una tarde. Este curso hace lo contrario: baja a cada pieza del pipeline y la desarma, porque en RAG el resultado se juega en los detalles — cómo cortaste el documento, qué modelo de embeddings usaste, si combinaste búsqueda vectorial con búsqueda por palabras, si reordenaste los resultados antes del prompt. Este primer módulo establece el mapa: qué problema resuelve RAG, por qué no lo resuelven las alternativas obvias, y cómo se ve el sistema completo antes de meternos en cada pieza.

La tesis del módulo

Un LLM es un motor de razonamiento con una memoria congelada en el pasado y sin fuentes. RAG no lo hace más inteligente: le pone delante el texto correcto en el momento correcto. Por eso la mayor parte de la calidad de un sistema RAG se juega en el retrieval, no en el modelo: si el fragmento que contiene la respuesta no llega al prompt, ningún LLM del mundo lo arregla.

El problema: qué NO puede hacer un LLM solo

Un LLM (Large Language Model, modelo de lenguaje grande) aprendió a predecir texto leyendo una cantidad enorme de documentos hasta una fecha determinada. Ese aprendizaje quedó comprimido en sus pesos (los millones de números que definen el modelo). Y ahí empiezan cuatro problemas que ninguna cantidad de prompt engineering arregla.

1. Knowledge cutoff. El cutoff es la fecha límite de los datos de entrenamiento. Todo lo que pasó después no existe para el modelo. Tampoco existe nada que nunca fue público: el manual interno de tu empresa, los tickets de soporte del año pasado, la política de reembolsos que cambió el martes.

2. Alucinación. Un LLM no tiene un mecanismo para decir “no sé”. Está entrenado para producir la continuación más plausible del texto, y una respuesta inventada con seguridad es estadísticamente más plausible que un “no tengo esa información”. Cuando le preguntas por algo que no sabe, el modelo alucina: genera algo que suena correcto y no lo es.

3. No puede citar. Aunque acierte, el conocimiento está difuso en los pesos. No hay un puntero al documento del que salió esa afirmación. Y sin cita no hay auditoría: nadie en un banco, una clínica o un estudio jurídico va a firmar una respuesta que no se puede rastrear.

4. No respeta permisos. Si metieras los documentos de toda la empresa en el entrenamiento, el modelo sabría todo para todos. No hay forma de que un modelo entrenado “olvide” el documento de RRHH cuando le pregunta un practicante. Los permisos necesitan ser una capa fuera del modelo.

Qué es RAG

RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) es una arquitectura de tres movimientos:

Recuperar (retrieval): dada la pregunta del usuario, buscar en tu corpus los fragmentos de texto más relevantes.
Aumentar: pegar esos fragmentos dentro del prompt como contexto, con instrucciones de responder solo con esa información.
Generar: el LLM escribe la respuesta leyendo ese contexto.

El término clave que aparece a partir de aquí es grounding (anclaje): la generación queda anclada a un texto verificable. El modelo deja de recitar de memoria y pasa a leer un documento que le pusiste delante. Es la diferencia entre un examen a libro cerrado y uno a libro abierto — y el modelo, igual que un estudiante, rinde muchísimo mejor con el libro abierto.

De paso, los cuatro problemas se caen solos: el conocimiento se actualiza reindexando (no reentrenando), la alucinación baja porque hay texto real que copiar, la cita es trivial porque sabes de qué chunk salió cada dato, y los permisos se aplican en el filtro de búsqueda antes de que el modelo vea nada.

Ojo: RAG reduce la alucinación, no la elimina. El modelo puede recibir el fragmento correcto y aun así deformarlo, mezclar dos fuentes o completar con lo que “sabía”. Por eso existen el módulo de generación y prompting y el de evaluación: el grounding se diseña y se mide, no se asume.

RAG vs fine-tuning vs contexto largo vs prompt estático

Esta es la tabla que ordena la decisión. Las cuatro son formas de meterle información a un LLM, y se confunden todo el tiempo.

Prompt estático: pegar la información fija en el system prompt. Sirve para poco texto que casi nunca cambia.
Contexto largo: meter el corpus entero en cada consulta, aprovechando ventanas de 200K o 1M tokens.
Fine-tuning: seguir entrenando el modelo con tus datos para que ajuste sus pesos.
RAG: buscar y pegar solo lo relevante.

Eje	Prompt estático	Contexto largo	Fine-tuning	RAG
Qué aporta	Instrucciones fijas	Conocimiento por consulta	Comportamiento y estilo	Conocimiento
Costo inicial	Cero	Cero	Alto (datos + GPU)	Medio (pipeline + índice)
Costo por consulta	Bajo	Muy alto (pagas todo el corpus siempre)	Bajo	Bajo (solo los chunks)
Actualizar conocimiento	Editar el prompt	Inmediato	Reentrenar (horas/días)	Reindexar (minutos)
Citar fuentes	No	Difícil, sin punteros	No	Sí, nativo
Permisos por usuario	No	No	Imposible	Sí, filtro en la búsqueda
Latencia	Mínima	Alta (procesar 1M tokens tarda)	Mínima	Media (+ búsqueda)
Techo de tamaño	~Miles de tokens	La ventana del modelo	Ilimitado en teoría	Millones de documentos
Cuándo usarlo	Reglas fijas cortas	Corpus chico y estable, análisis de un doc	Formato de salida, tono, dominio raro	Conocimiento propio, cambiante o privado

La confusión más cara del mercado es esta: fine-tuning enseña comportamiento, RAG aporta conocimiento. Si tu problema es “el modelo no sabe nuestros productos”, el fine-tuning es la herramienta equivocada: vas a gastar semanas y el modelo va a aprender a sonar como tu empresa mientras sigue inventando los precios. Si tu problema es “quiero que siempre responda en formato JSON con este esquema y en tono formal chileno”, ahí sí el fine-tuning es la herramienta. Y no son excluyentes: los sistemas maduros hacen fine-tuning para el formato y RAG para los datos.

Por qué el contexto largo no mató a RAG

Cada vez que sale un modelo con más ventana de contexto (context window: cuántos tokens caben en una llamada) reaparece el titular de que RAG murió. No pasó, por cuatro razones concretas.

Costo. Pagas por token de entrada. Meter 500.000 tokens de contexto en cada consulta, mil veces al día, es un orden de magnitud más caro que recuperar 4.000 tokens relevantes. El costo escala con cada pregunta, no una sola vez.

Latencia. Procesar una ventana gigante toma tiempo real antes de emitir el primer token. Una búsqueda vectorial sobre millones de chunks responde en decenas de milisegundos. Este punto está desarrollado en contexto largo y KV cache.

Lost in the middle. Es un resultado bien documentado (Liu et al., 2023, el paper que le dio nombre): cuando el contexto es largo, el modelo atiende mucho mejor a lo que está al principio y al final, y se le pierde lo del medio. La atención no es uniforme. Meterle todo no garantiza que lo lea todo; a veces el dato correcto está en el token 300.000 y el modelo lo ignora. Un contexto corto y curado supera a uno largo y sucio.

No cabe igual. Un corpus empresarial real son gigabytes: años de tickets, wikis, contratos, correos. Ni 1M ni 10M de tokens alcanzan. El contexto largo es un complemento de RAG — permite pasarle chunks más grandes y más de ellos — pero no reemplaza la necesidad de elegir cuáles.

Anatomía del pipeline: dos tiempos

Un sistema RAG son en realidad dos sistemas que corren en momentos distintos y que la gente confunde por estar en el mismo repositorio.

El tiempo offline (indexación) ocurre antes de que exista ninguna pregunta. Es un trabajo por lotes que toma tus documentos y los deja listos para ser buscados: ingesta, parsing, chunking, embedding e indexación. Corre cuando agregas documentos o cambian los existentes.

El tiempo online (consulta) ocurre por cada pregunta del usuario, en milisegundos: se embebe la pregunta, se buscan los chunks parecidos, se reordenan, se arma el prompt y se genera la respuesta con citas.

TIEMPO OFFLINE (indexación, por lote)

START ──► ┌───────────────┐     ┌────────────────┐
          │    ingesta    │ ──► │    parsing     │
          │  PDF/HTML/DB  │     │ texto+metadata │
          └───────────────┘     └───────┬────────┘
                                        │
                                        ▼
          ┌───────────────┐     ┌────────────────┐
          │  embeddings   │ ◄── │    chunking    │
          │ texto a vector│     │ cortar en piez.│
          └───────┬───────┘     └────────────────┘
                  │
                  ▼
          ┌───────────────┐
          │    ÍNDICE     │ ──► END
          │   vectorial   │
          └───────────────┘

El índice que queda al final del tiempo offline es la entrada del tiempo online:

TIEMPO ONLINE (consulta, por pregunta)

START ──► ┌───────────┐     ┌──────────────┐
          │  pregunta │ ──► │  retrieval   │
          │  usuario  │     │ top-k chunks │
          └───────────┘     └──────┬───────┘
                                   │
                                   ▼
                            ┌──────────────┐
                            │   reranker   │
                            │  reordenar   │
                            └──────┬───────┘
                                   │
                                   ▼
      ┌──────────┐          ┌──────────────┐
      │   LLM    │ ◄─────── │    prompt    │
      │ responde │          │ ctx+pregunta │
      └────┬─────┘          └──────────────┘
           │
           ▼
      respuesta + citas ──► END

Fíjate en la asimetría: el tiempo offline es donde se decide la calidad (si cortaste mal, ya perdiste) y el tiempo online es donde se decide la experiencia (latencia, costo, citas). Los módulos 2 a 4 de este curso viven en el tiempo offline; los módulos 5 a 9, en el online.

La verdad incómoda que ordena el curso

Aquí va la afirmación que conviene tatuarse antes de escribir una línea de código:

La mayor parte de la calidad de un sistema RAG está en el retrieval, no en el LLM.

La razón es aritmética. Si el chunk que contiene la respuesta no está entre los que le pasaste al modelo, la probabilidad de que el modelo acierte es cero — o peor, va a inventar algo con el contexto irrelevante que sí recibió. Cambiar de un modelo bueno a uno excelente sube unos puntos de calidad de redacción; arreglar un retrieval que trae el documento equivocado puede duplicar la tasa de aciertos (de un 40% a un 85%, por poner números ilustrativos).

En la práctica esto significa que cuando tu RAG responde mal, la pregunta correcta casi nunca es “¿cambio de modelo?”. Es: ¿el chunk correcto está en el índice? ¿La búsqueda lo trajo? ¿En qué posición? Ese diagnóstico en tres preguntas es lo que sistematiza el módulo de evaluación.

Un RAG mínimo en 40 líneas

Todo lo anterior cabe en un script corto. Sin frameworks, sin base de datos vectorial: una lista de textos, embeddings y numpy. La idea es que veas que el corazón son cuatro pasos.

import numpy as np
from openai import OpenAI

client = OpenAI()

# 1) EL CORPUS. En la vida real esto sale de PDFs parseados y cortados
#    (módulos 2 y 3). Aquí son chunks a mano para ver el mecanismo.
CHUNKS = [
    "La política de reembolsos permite devoluciones hasta 30 días "
    "después de la compra, con boleta y producto sin uso.",
    "El horario de atención de sucursales es de lunes a viernes "
    "de 9:00 a 18:00, y sábados de 10:00 a 14:00.",
    "Los despachos a regiones tardan entre 3 y 5 días hábiles. "
    "El despacho es gratis sobre $50.000.",
    "La garantía legal en Chile cubre 6 meses por fallas de fábrica, "
    "independiente de la garantía del fabricante.",
]

def embed(textos: list[str]) -> np.ndarray:
    """Convierte textos en vectores. Cada vector es una lista de floats
    que representa el SIGNIFICADO del texto: dos textos que hablan de lo
    mismo quedan cerca en ese espacio (ver módulo 4)."""
    resp = client.embeddings.create(
        model="text-embedding-3-small",
        input=textos,
    )
    return np.array([d.embedding for d in resp.data])

# 2) INDEXACIÓN (offline). Se hace UNA vez y se guarda. Aquí la "base de
#    datos vectorial" es una matriz de numpy en memoria.
INDICE = embed(CHUNKS)

def buscar(pregunta: str, k: int = 2) -> list[str]:
    """3) RETRIEVAL. Embebe la pregunta y busca los k chunks más
    parecidos por similitud coseno: el coseno del ángulo entre dos
    vectores. Vale 1 si apuntan igual, 0 si no tienen relación."""
    q = embed([pregunta])[0]
    # Los embeddings de OpenAI vienen normalizados (norma 1), así que el
    # producto punto YA es el coseno. Si no lo estuvieran, habría que
    # dividir por (norma del vector * norma de q).
    scores = INDICE @ q
    top = np.argsort(scores)[::-1][:k]
    return [CHUNKS[i] for i in top]

def responder(pregunta: str) -> str:
    """4) GENERACIÓN. Arma el prompt con el contexto recuperado y le
    prohíbe explícitamente inventar: eso es grounding."""
    contexto = "\n\n".join(
        f"[{i+1}] {c}" for i, c in enumerate(buscar(pregunta))
    )
    prompt = (
        "Responde la pregunta usando SOLO el contexto entregado.\n"
        "Si el contexto no alcanza, di exactamente: 'No tengo esa "
        "información'. Cita la fuente con su número entre corchetes.\n\n"
        f"CONTEXTO:\n{contexto}\n\nPREGUNTA: {pregunta}"
    )
    r = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0,  # determinista: no queremos creatividad aquí
    )
    return r.choices[0].message.content

print(responder("¿Cuánto tiempo tengo para devolver un producto?"))
# → "Tienes hasta 30 días después de la compra, con boleta y el
#    producto sin uso. [1]"

print(responder("¿Aceptan bitcoin?"))
# → "No tengo esa información."

Eso es RAG completo. Los once módulos que siguen son, literalmente, hacer cada una de estas cuatro funciones bien: embed mejor, buscar mejor, y el prompt de responder mejor. La segunda llamada, la del bitcoin, es la más importante del script: un RAG bien construido sabe decir que no sabe, y esa es la propiedad que un LLM solo no tiene.

Mapa del curso

Módulo	Tema	Tiempo	Qué resuelve
2	Ingesta y parsing	Offline	Extraer texto usable de PDFs y compañía
3	Chunking	Offline	Cortar sin romper el significado
4	Embeddings e indexación	Offline	Elegir modelo y construir el índice
5	Búsqueda vectorial y vector DBs	Online	Buscar rápido en millones de vectores
6	BM25 y búsqueda léxica	Online	Lo que el vector no encuentra: códigos, nombres
7	Búsqueda híbrida	Online	Combinar ambas y fusionar rankings
8	Rerankers	Online	Reordenar con precisión antes del prompt
9	Generación y prompting	Online	Grounding, citas y decir “no sé”
10	Evaluación	Ambos	Medir en vez de adivinar
11	RAG avanzado	Ambos	Query rewriting, small-to-big, agentic RAG
12	RAG en producción	Ambos	Permisos, costo, latencia, actualización

Errores comunes

Empezar por el modelo en vez del retrieval. El reflejo de “probemos con un modelo más grande” cuando las respuestas son malas. Si el chunk correcto no llegó al prompt, cambiar de modelo no mueve la aguja. Diagnostica primero el retrieval.
Usar fine-tuning para meter conocimiento. Es lento, caro, no se actualiza, no cita y no respeta permisos. El fine-tuning es para comportamiento y formato; el conocimiento va por RAG.
Creer que RAG elimina la alucinación. La reduce mucho, pero el modelo puede deformar el contexto que recibió. Sin instrucción explícita de “responde solo con esto” y sin evaluación, sigues expuesto.
Meter todo el corpus en el contexto porque “ahora caben 1M tokens”. Pagas el corpus completo en cada consulta, la latencia sube, y por “lost in the middle” el modelo igual ignora la mitad.
Tratar el pipeline como una sola pieza. Indexación y consulta son sistemas distintos, con SLAs distintos y bugs distintos. Confundirlos hace que se depure el lugar equivocado.
No guardar de qué documento salió cada chunk. Sin ese puntero no hay citas, no hay auditoría y no hay forma de depurar una respuesta mala. La metadata se decide en la ingesta, no después.

La frase para llevarse

“RAG no hace más inteligente al modelo: le pone el libro abierto en la página correcta. Y si abriste la página equivocada, da lo mismo lo brillante que sea el lector.”

Qué viene

Módulo 2: ingesta y parsing, el eslabón que todos subestiman y donde se pierde más calidad que en ningún otro. Vamos a ver por qué el PDF es un formato hostil para las máquinas, qué herramientas de extracción existen y cuál usar según el caso, cuándo hace falta OCR, cómo limpiar el texto sin destruirlo, y por qué la metadata que captures en ese momento es el activo que después habilita filtros, citas y permisos. La regla del módulo es dura: tu retrieval nunca va a ser mejor que el texto que indexaste.

RAG — Módulo 1: ¿por qué RAG? El problema y la anatomía del pipeline