RAG (Retrieval-Augmented Generation)

RAG (Generación Aumentada por Recuperación) es una arquitectura que combina modelos de lenguaje con sistemas de búsqueda para proporcionar respuestas fundamentadas en datos reales y actualizados. En lugar de depender solo del conocimiento aprendido durante el entrenamiento, el modelo consulta una base de conocimiento externa antes de generar su respuesta.

Por qué existe RAG

Los LLMs tienen limitaciones fundamentales:

• Conocimiento estático: Solo saben lo que aprendieron durante el entrenamiento. No conocen eventos recientes ni datos privados.
• Alucinaciones: Pueden inventar información que suena plausible pero es falsa.
• Sin fuentes verificables: No pueden citar de dónde obtuvieron la información.
• Límite de contexto: No pueden almacenar toda la documentación de una empresa en su ventana de contexto.

RAG resuelve estos problemas dando al modelo acceso a información externa relevante en el momento de la consulta.

Cómo funciona

El flujo de RAG tiene tres fases principales:

1. Indexación (offline)

Antes de que el usuario haga preguntas, los documentos se preparan para la búsqueda:

1. Carga de documentos: Se recopilan los datos fuente (PDFs, páginas web, bases de datos, wikis, código fuente).
2. Chunking (fragmentación): Los documentos se dividen en fragmentos más pequeños (chunks), típicamente de 256-1024 tokens.
3. Generación de embeddings: Cada chunk se convierte en un vector numérico usando un modelo de embeddings (como text-embedding-3-small de OpenAI o voyage-3 de Voyage AI).
4. Almacenamiento en vector store: Los vectores se almacenan en una base de datos vectorial para búsqueda eficiente por similitud.

2. Recuperación (retrieval)

Cuando el usuario hace una pregunta:

1. La pregunta se convierte en un vector usando el mismo modelo de embeddings.
2. Se buscan los chunks más similares en la base de datos vectorial (búsqueda por similitud coseno o producto punto).
3. Se recuperan los K fragmentos más relevantes (típicamente 3-10).

3. Generación (generation)

1. Los chunks recuperados se insertan en el prompt junto con la pregunta del usuario.
2. El LLM genera una respuesta basada en el contexto proporcionado.
3. El modelo puede citar las fuentes de donde extrajo la información.

Usuario: "¿Cuál es la política de devoluciones?"

    ┌──────────────┐
    │   Pregunta   │
    └──────┬───────┘
           │
    ┌──────▼───────┐     ┌─────────────────┐
    │  Embedding   │────▶│  Vector Store    │
    │  de consulta │     │  (búsqueda)     │
    └──────────────┘     └──────┬──────────┘
                                │
                    ┌───────────▼───────────┐
                    │  Chunks relevantes:   │
                    │  - Política devol...  │
                    │  - Plazos y condic... │
                    └───────────┬───────────┘
                                │
                    ┌───────────▼───────────┐
                    │  LLM genera respuesta │
                    │  con contexto real    │
                    └───────────────────────┘

Estrategias de Chunking

La forma en que se dividen los documentos es crítica para la calidad de los resultados:

• Por tamaño fijo: Dividir cada N tokens con solapamiento (overlap) entre chunks. Simple pero puede cortar ideas a mitad de frase.
• Por estructura: Respetar los límites naturales del documento (párrafos, secciones, headers). Preserva mejor el contexto semántico.
• Recursivo: Intentar dividir por párrafos; si son demasiado grandes, subdividir por frases. Es el enfoque más usado por frameworks como LangChain.
• Semántico: Usar embeddings para detectar cambios de tema y dividir en esos puntos. Mayor calidad pero más costoso computacionalmente.

Tamaño del chunk

Tamaño	Ventaja	Desventaja
Pequeño (128-256 tokens)	Mayor precisión en la recuperación	Puede perder contexto necesario
Mediano (256-512 tokens)	Buen equilibrio entre precisión y contexto	Estándar para la mayoría de casos
Grande (512-1024 tokens)	Más contexto por fragmento	Puede incluir información irrelevante

Embeddings y bases de datos vectoriales

Modelos de embeddings populares

• OpenAI text-embedding-3-small/large: Alta calidad, API sencilla.
• Voyage AI voyage-3: Optimizado para recuperación de documentos.
• Cohere embed-v3: Multilingüe con buen rendimiento.
• BGE / E5 (open source): Modelos abiertos competitivos que se pueden ejecutar en local.
• Nomic Embed: Open source con buen rendimiento en múltiples benchmarks.

Vector stores

• Pinecone: Servicio gestionado, escalable, sin infraestructura que mantener.
• Weaviate: Open source con búsqueda híbrida (vectorial + keyword).
• Qdrant: Open source, alto rendimiento, filtrado avanzado.
• ChromaDB: Ligero, ideal para prototipos y desarrollo local.
• pgvector: Extensión de PostgreSQL que añade búsqueda vectorial a tu base de datos existente.
• FAISS (Meta): Librería de búsqueda vectorial extremadamente rápida, ideal para grandes volúmenes.

Técnicas avanzadas de RAG

Búsqueda híbrida

Combina búsqueda vectorial (semántica) con búsqueda por palabras clave (BM25). La búsqueda semántica entiende sinónimos y paráfrasis; la búsqueda por keywords es precisa con términos técnicos, nombres propios y códigos. Juntas cubren más casos.

Reranking

Después de recuperar los chunks iniciales, un modelo de reranking (como Cohere Rerank o bge-reranker) reordena los resultados por relevancia real respecto a la pregunta. Mejora significativamente la calidad sin cambiar la indexación.

Multi-query RAG

En lugar de una sola búsqueda, el LLM genera múltiples reformulaciones de la pregunta del usuario. Cada variante busca en el vector store, y los resultados se combinan. Esto captura diferentes aspectos semánticos de la consulta.

RAG con agentes

El sistema decide dinámicamente si necesita buscar información, qué fuentes consultar y si la información recuperada es suficiente. Los agentes de IA pueden iterar: buscar, evaluar la relevancia, refinar la búsqueda y volver a buscar hasta obtener contexto suficiente.

Parent Document Retrieval

Se indexan chunks pequeños para precisión en la búsqueda, pero se devuelve el documento padre (más grande) al LLM para darle más contexto. Combina lo mejor de ambos tamaños de chunk.

Corrective RAG (CRAG)

El sistema evalúa la relevancia de los documentos recuperados antes de generar la respuesta. Si los documentos no son suficientemente relevantes, puede reformular la búsqueda, consultar fuentes alternativas o indicar que no tiene información suficiente.

RAG vs. Fine-tuning

Aspecto	RAG	Fine-tuning
Datos	Se actualizan en tiempo real	Requiere re-entrenar el modelo
Coste	Infraestructura de vector store	Coste de entrenamiento (GPU)
Alucinaciones	Reducidas (respuestas fundamentadas)	Puede seguir alucinando
Citabilidad	Puede citar fuentes exactas	No puede citar fuentes
Conocimiento privado	Ideal para datos internos	Riesgo de memorización de datos
Mejor para	Preguntas sobre datos específicos	Cambiar el estilo o comportamiento del modelo

RAG y fine-tuning no son excluyentes — muchos sistemas de producción combinan ambos. El fine-tuning ajusta el comportamiento y estilo del modelo, mientras que RAG le da acceso a conocimiento actualizado.

Frameworks y herramientas

• LangChain: El framework más popular para construir pipelines de RAG, con integraciones para decenas de vector stores, embeddings y LLMs.
• LlamaIndex: Especializado en RAG, con abstracciones optimizadas para indexación y recuperación de documentos.
• Haystack (deepset): Framework open source para pipelines de búsqueda y RAG de nivel producción.
• Vercel AI SDK: Integra RAG en aplicaciones web con soporte para streaming.
• Semantic Kernel (Microsoft): SDK para integrar RAG en aplicaciones empresariales .NET y Python.

Casos de uso

• Chatbots sobre documentación: Asistentes que responden preguntas sobre la documentación de un producto, API o base de conocimiento interna.
• Búsqueda semántica empresarial: Buscar información en miles de documentos internos usando lenguaje natural.
• Asistentes legales y médicos: Sistemas que consultan bases de datos especializadas para fundamentar sus respuestas.
• Soporte al cliente: Bots que acceden a la base de conocimiento de soporte para resolver tickets.
• Análisis de código: Herramientas como los agentes de programación que indexan un codebase completo para responder preguntas sobre la arquitectura.

Desafíos

• Calidad del chunking: Una mala fragmentación degrada toda la cadena. Si los chunks no capturan la información relevante, el LLM no puede generar buenas respuestas.
• Relevancia de la recuperación: Recuperar documentos incorrectos es peor que no recuperar nada — puede inducir al modelo a dar respuestas erróneas con confianza.
• Latencia: Añadir la fase de búsqueda incrementa el tiempo de respuesta. Optimizar embeddings y vector stores es crucial.
• Coste de indexación: Mantener actualizada una base de datos vectorial grande requiere re-procesar documentos cuando cambian.
• Evaluación: Medir la calidad de un sistema RAG es complejo — hay que evaluar tanto la recuperación como la generación.

RAG se ha convertido en la arquitectura estándar para construir aplicaciones de IA que necesitan acceso a conocimiento específico, actualizado y verificable. Su combinación con modelos de lenguaje potentes hace posible crear sistemas que fundamentan sus respuestas en datos reales en lugar de depender exclusivamente de lo aprendido durante el entrenamiento.