RAG de 0 a Avanzado: La Guía que Nadie te Dio

Si alguna vez te preguntaste cómo los modelos de lenguaje "saben" cosas que no estaban en su entrenamiento — esta es tu respuesta. Y va mucho más allá de "buscar en Google".

Empecemos por el problema real

Imagina que contratas al empleado más inteligente del mundo. Leer todos los libros, todos los artículos, toda la internet hasta 2024. Memoria fotográfica. Razonamiento impecable.

Pero hay un detalle: no sabe nada de lo que pasó después de que lo contrataste.

No sabe el contrato que firmaste ayer. No sabe el reglamento interno que actualizaste el mes pasado. No sabe los precios de tu catálogo de esta semana. No tiene acceso a ningún documento tuyo. Y si le preguntas sobre cualquiera de esas cosas, lo más probable es que invente una respuesta que suena convincente pero está completamente equivocada.

Eso es un LLM sin RAG.

RAG — Retrieval-Augmented Generation — es la solución. Y en este artículo vamos de lo más básico hasta las matemáticas que hacen que funcione de verdad.

Parte 1: ¿Qué es RAG? La explicación de las peras y manzanas

Volvamos a nuestro empleado brillante pero desconectado.

¿Qué harías si quisieras que respondiera preguntas sobre tus documentos internos? Lo más natural del mundo: le pasas el documento relevante antes de que responda.

Eso, en esencia, es RAG:

1. El usuario hace una pregunta.
2. El sistema busca los fragmentos de tus documentos más relevantes para esa pregunta.
3. Esos fragmentos se le meten al LLM junto con la pregunta.
4. El LLM responde basándose en esa información, no en suposiciones.

Es como si en lugar de esperar que tu empleado adivine, le pusieras el expediente correcto en el escritorio justo antes de que conteste la llamada.

Sencillo. Elegante. Y brutalmente poderoso cuando se implementa bien.

Parte 2: Los componentes — qué mueve las piezas

Un sistema RAG tiene tres componentes principales. No dos, no cinco. Tres.

1. El índice (donde vive tu conocimiento)

Tus documentos no se guardan como texto plano en RAG. Se convierten en vectores — representaciones matemáticas del significado de cada fragmento. Hablaremos de esto en detalle más adelante.

Lo importante por ahora: tienes una base de datos especial (llamada vector store o base de datos vectorial) que puede buscar por similitud semántica, no por palabras exactas.

Ejemplo: si buscas "¿cómo cancelo mi póliza?", va a encontrar el fragmento que dice "proceso de rescisión de contrato", aunque la palabra "cancelar" no aparezca ahí.

2. El retriever (el que busca)

Cuando el usuario hace una pregunta, el retriever la convierte en un vector y busca los fragmentos más similares en tu índice. Devuelve los top-K fragmentos más relevantes.

K es un número que tú decides. Generalmente entre 3 y 10.

3. El generador (el LLM)

Recibe la pregunta original + los fragmentos recuperados, y genera la respuesta. Su trabajo es sintetizar, no memorizar.

---

Parte 3: El flujo completo — de la pregunta a la respuesta

Usuario pregunta
      ↓
Pregunta → Embedding (vector)
      ↓
Búsqueda en vector store → Top-K fragmentos
      ↓
Prompt = Pregunta + Fragmentos + Instrucciones
      ↓
LLM genera respuesta
      ↓
Respuesta al usuario

Así de simple en concepto. Ahora vamos a ver dónde se complica — y por qué importa.

Parte 4: Los embeddings — aquí empieza la matemática

Esta es la parte que la mayoría de los tutoriales pasan demasiado rápido.

Un embedding es un vector de números reales que representa el significado de un texto en un espacio de alta dimensionalidad.

¿Qué significa eso en humano?

Imagina que tienes un mapa. En ese mapa, los textos con significados similares están cerca entre sí, y los que hablan de cosas distintas están lejos.

• "Cómo cancelar una póliza" está cerca de "proceso de rescisión de contrato".
• "Receta de pasta carbonara" está lejos de ambos.

Un modelo de embeddings convierte cualquier texto en un vector de, digamos, 1536 números (en el caso de text-embedding-ada-002 de OpenAI). Esos 1536 números definen una posición en un espacio de 1536 dimensiones. Textos similares tienen posiciones cercanas.

La fórmula que importa: similitud coseno

Para medir qué tan "cercanos" están dos vectores, la métrica más común es la similitud coseno:

Donde:

• A · B es el producto punto entre los dos vectores
• |A| y |B| son las magnitudes (normas) de cada vector
• El resultado va de -1 (opuestos) a 1 (idénticos)

En términos más concretos, si tienes dos vectores:

A = [0.2, 0.8, 0.1, ...]
B = [0.3, 0.7, 0.2, ...]

El producto punto A · B = (0.2×0.3) + (0.8×0.7) + (0.1×0.2) + ...

Una similitud coseno de 0.92 indica que los textos son muy similares semánticamente. Por debajo de 0.75, la relevancia ya empieza a ser cuestionable.

¿Por qué coseno y no distancia euclidiana? Porque la distancia euclidiana es sensible a la magnitud del vector, no solo a su dirección. Dos textos sobre el mismo tema pero de distinta longitud pueden tener vectores de magnitudes muy distintas pero ángulos muy similares. El coseno captura la dirección, que es lo que nos interesa.

Parte 5: Chunking — el arte de cortar bien

Antes de crear embeddings, tienes que dividir tus documentos en fragmentos (chunks). Este paso parece trivial. No lo es.

El problema del chunk mal hecho

Un chunk muy grande: el embedding promedia demasiado significado y pierde precisión. Si metes un documento de 10 páginas como un solo chunk, el vector va a ser un promedio difuso de todos los temas que toca.

Un chunk muy pequeño: puede que el fragmento no tenga suficiente contexto para ser útil. "Ver tabla 3." no le dice nada al LLM.

Las estrategias de chunking

Fixed-size chunking: divides cada X tokens (ej: 512), con un overlap de Y tokens entre chunks consecutivos (ej: 50). Simple y funciona razonablemente bien.

Texto: [----512 tokens----][overlap][----512 tokens----][overlap]...

El overlap existe para que no pierdas información en los bordes de corte.

Semantic chunking: en lugar de cortar por número fijo de tokens, detectas cambios semánticos — puntos donde el tema cambia — y cortas ahí. Requiere más procesamiento pero produce chunks más coherentes.

Recursive chunking: intentas hacer chunks del tamaño deseado usando separadores naturales (párrafos, oraciones, palabras), cayendo al siguiente nivel solo si el anterior produce chunks demasiado grandes. Es el approach de LangChain por defecto y funciona bien en la mayoría de casos.

Document-aware chunking: respetas la estructura del documento. En un PDF con secciones, cada sección es un chunk. En una tabla, la tabla completa es un chunk. Mantiene la coherencia estructural.

El tamaño importa — y depende del caso

Regla práctica: el chunk debe ser suficientemente largo para tener contexto propio, pero suficientemente corto para hablar de una sola cosa.

Parte 6: Vector stores — dónde vive todo esto

Una vez que tienes tus embeddings, necesitas almacenarlos y poder buscar en ellos rápido. Eso es un vector store.

El problema de escala

Con 1000 documentos de 10 páginas cada uno, con chunks de 512 tokens, puedes tener fácilmente 50,000 vectores de 1536 dimensiones cada uno. Comparar la pregunta contra cada uno de esos 50,000 vectores en tiempo real haría que tu sistema fuera inutilizablemente lento.

La solución: índices aproximados.

HNSW: el algoritmo que mueve la industria

Hierarchical Navigable Small World (HNSW) es el algoritmo de indexación más usado en vector stores modernos (Pinecone, Weaviate, pgvector, Qdrant, Chroma).

La intuición detrás de HNSW:

Imagina que buscas a alguien en una ciudad. En lugar de tocar puerta por puerta, primero navegas a nivel de barrio (vista gruesa), luego a nivel de calle (vista media), luego a la casa exacta (vista fina). Cada nivel te acerca más a la respuesta correcta sin revisar todo.

HNSW construye grafos jerárquicos donde:

• Las capas superiores tienen pocos nodos muy conectados (los "nodos hub" del grafo)
• Las capas inferiores tienen todos los nodos con conexiones locales
• La búsqueda empieza arriba, navega hacia abajo

Complejidad de búsqueda: O(log n) en lugar de O(n). Para 1 millón de vectores, eso es la diferencia entre buscar en ~20 pasos vs 1,000,000 pasos.

El trade-off: no siempre encuentra el vecino más cercano, sino uno muy cercano. Por eso se llama Approximate Nearest Neighbor (ANN). En la práctica, el accuracy es suficientemente alto (>95% recall) para producción.

Parte 7: RAG avanzado — donde se separan los buenos de los mediocres

El RAG básico funciona. Pero tiene problemas reales que emergen en producción:

1. El retriever trae fragmentos relevantes pero no necesariamente los más relevantes para la respuesta final.
2. Las preguntas ambiguas o mal formuladas generan malos embeddings.
3. Los documentos tienen información desactualizada o contradictoria.

Aquí es donde entran las técnicas avanzadas.

Re-ranking

Después de recuperar los top-K chunks, no los mandas todos al LLM directamente. Los pasas por un modelo de re-ranking que evalúa cada chunk en el contexto específico de la pregunta y los reordena.

Los modelos de cross-encoder (como los de la familia Cohere Rerank o ms-marco) calculan la relevancia con mucha más precisión que la similitud coseno, porque ven la pregunta y el chunk juntos, no por separado.

Pipeline con re-ranking:

Pregunta → Embedding → Top-50 chunks por coseno
       → Re-ranker → Top-5 chunks más relevantes
       → LLM → Respuesta

Recuperas amplio (para no perderte nada), re-rankeas preciso (para no meter ruido al LLM).

HyDE: Hypothetical Document Embeddings

Técnica contraintuitiva y brillante.

El problema: los embeddings de preguntas y de documentos viven en espacios ligeramente distintos. Una pregunta ("¿cómo cancelo mi póliza?") tiene una distribución muy diferente a un párrafo de manual ("El proceso de rescisión puede iniciarse mediante...").

La solución de HyDE: antes de buscar, le pides al LLM que genere un documento hipotético que respondería la pregunta. Luego usas el embedding de ese documento hipotético para buscar en el índice.

Pregunta → LLM genera respuesta hipotética → Embedding de la hipótesis
       → Búsqueda en vector store → Chunks reales similares a la hipótesis
       → LLM responde con los chunks reales

¿Por qué funciona? Porque el embedding de "un documento que explica cómo cancelar una póliza" es mucho más similar al embedding del manual real que el embedding de la pregunta corta.

Query decomposition

Para preguntas complejas con múltiples sub-preguntas, descompones la pregunta en partes más simples, haces RAG para cada parte, y sintetizas al final.

Ejemplo:

Pregunta original: "¿Cuál fue la tendencia de siniestros en automóviles vs hogar durante 2023 y cómo afectó la rentabilidad?"

Preguntas descompuestas:

• ¿Cuál fue la tendencia de siniestros en automóviles en 2023?
• ¿Cuál fue la tendencia de siniestros en hogar en 2023?
• ¿Cómo se relaciona la frecuencia de siniestros con la rentabilidad?

Cada sub-pregunta va al retriever, trae sus chunks, y el LLM sintetiza todo al final.

Contextual compression

Recuperas chunks completos pero antes de mandárselos al LLM, los comprimes: le pides a otro LLM (más pequeño y barato) que extraiga solo las oraciones relevantes para la pregunta.

Reduces el ruido en el contexto. El LLM principal trabaja con información más limpia. Las respuestas mejoran.

Parte 8: Evaluación — ¿cómo sabes si tu RAG funciona?

Este es el paso que nadie quiere hacer y todos deberían.

Las métricas que importan

Context Recall: ¿Qué tan bien el retriever encuentra los fragmentos que sí contienen la respuesta correcta? Si la respuesta está en el documento pero el retriever no la encuentra, el sistema falla antes de que el LLM haga nada.

Context Recall = chunks_relevantes_recuperados / total_chunks_relevantes_existentes

Context Precision: De los chunks que recuperaste, ¿cuántos eran realmente útiles? Un retriever que trae 100 chunks donde solo 3 son relevantes tiene baja precisión y le mete ruido al LLM.

Context Precision = chunks_relevantes_recuperados / total_chunks_recuperados

Faithfulness: ¿La respuesta del LLM está respaldada por los chunks recuperados, o empezó a inventar? Una respuesta puede ser plausible pero no estar en los documentos.

Answer Relevance: ¿La respuesta realmente responde la pregunta del usuario? Un LLM puede ser fiel a los documentos pero tangencial a la pregunta.

El framework RAGAS

RAGAS (RAG Assessment) es el framework open-source estándar para evaluar sistemas RAG. Mide automáticamente faithfulness, answer relevance, context recall y context precision usando un LLM como juez.

No lances tu RAG a producción sin correr RAGAS o algo equivalente sobre un conjunto de preguntas de prueba. Los números te van a sorprender — para bien o para mal.

Parte 9: El mapa completo — dónde estás y a dónde puedes ir

Lo que nadie te dice de RAG en producción

Después de implementar RAG en sistemas reales, hay verdades que los tutoriales omiten:

El garbage in, garbage out aplica doble aquí. Si tus documentos están mal estructurados, tienen información contradictoria, o simplemente están desactualizados, ninguna técnica de retrieval te va a salvar. La calidad del corpus es el techo de tu sistema.

El chunking es más arte que ciencia. No hay una fórmula universal. Lo que funciona para contratos legales no funciona para manuales técnicos. Prueba, evalúa, ajusta.

La latencia se acumula. Embedding → búsqueda → re-ranking → LLM. Cada paso agrega tiempo. Un RAG avanzado mal optimizado puede tardar 8-10 segundos en responder. Para algunos casos de uso eso está bien. Para otros, es inaceptable. Diseña con latencia en mente desde el inicio.

Evalúa antes de optimizar. El error más común es agregar complejidad (HyDE, re-ranking, query decomposition) sin medir si realmente mejoran tu caso específico. Mide primero. Agrega complejidad solo donde los números lo justifiquen.