Arquitectura 5 min de lectura

RAG (Retrieval-Augmented Generation) desde cero

Publicado el 24 de noviembre de 2025

RAG (Retrieval-Augmented Generation) desde cero

Los modelos de lenguaje (LLMs) son potentes pero tienen un límite claro: no conocen tu documentación, tu base de conocimiento ni tus datos internos. Si les preguntas algo que no está en lo que “vieron” en el entrenamiento, pueden alucinar: inventar respuestas que parecen plausibles pero son falsas. RAG (Retrieval-Augmented Generation) es la técnica que reduce ese problema: en lugar de confiar solo en lo que el modelo “sabe”, recuperas fragmentos relevantes de tus propios documentos y se los inyectas en el contexto del LLM. Así la IA responde apoyándose en tus datos, no solo en su memoria.

En este artículo explico qué es RAG, por qué ayuda contra las alucinaciones y cómo montarlo desde cero con documentos propios.

El problema: alucinaciones y conocimiento cerrado

Un LLM genera texto a partir de patrones aprendidos. No tiene “memoria” de tus PDFs, tu wiki ni tu base de datos. Si le preguntas por un procedimiento interno o por un producto que solo existe en tu empresa, puede:

  • Inventar detalles que no existen.
  • Mezclar información de entrenamiento con “suposiciones”.
  • Dar respuestas coherentes pero incorrectas.

Además, el conocimiento del modelo tiene una fecha de corte: no sabe lo que pasó después ni lo que solo existe en tus sistemas. Para usar la IA en soporte, documentación interna o asistentes de producto, necesitas anclar las respuestas a tus fuentes.

Qué es RAG

RAG combina dos cosas:

  1. Retrieval (recuperación): Dada una pregunta del usuario, buscas en tu colección de documentos los fragmentos más relevantes (por ejemplo, por similitud semántica usando embeddings).
  2. Augmented Generation (generación aumentada): Esos fragmentos se pasan al LLM como contexto junto con la pregunta. El modelo genera la respuesta basándose en ese contexto, no solo en lo que “sabe” de memoria.

Flujo típico:

  1. Usuario hace una pregunta.
  2. La pregunta se convierte en un vector (embedding) con el mismo modelo que usaste para indexar.
  3. Buscas en un vector store (o índice de similitud) los fragmentos con embeddings más parecidos a la pregunta.
  4. Construyes un prompt que incluye: instrucciones + fragmentos recuperados + pregunta.
  5. El LLM genera la respuesta usando ese prompt.
  6. Opcionalmente citas las fuentes (qué fragmentos usaste) para que el usuario pueda comprobar.

Así, la IA “lee” tus documentos en el momento de la consulta y responde con lo que encuentra, lo que reduce alucinaciones cuando la respuesta correcta está en tus datos.

Por qué reduce alucinaciones

  • Contexto explícito: El modelo no tiene que “recordar” tu documentación; se la das en cada pregunta. Si la respuesta está en el contexto, tiende a apoyarse en él.
  • Fuentes verificables: Puedes mostrar de qué párrafo o documento salió la información (citas), lo que permite auditar y corregir.
  • Actualización sin reentrenar: Cambias documentos, reindexas, y el sistema usa la versión nueva. No dependes de una fecha de corte del modelo.

RAG no elimina alucinaciones al 100 % (el modelo puede ignorar contexto o mezclar mal), pero las reduce mucho cuando el contenido relevante está bien recuperado y bien presentado en el prompt.

Cómo montar RAG desde cero (conceptos)

1. Documentos y troceado (chunking)

  • Fuentes: PDFs, Markdown, páginas web, tickets, FAQs, etc.
  • Troceado: Divides cada documento en fragmentos (chunks) de tamaño manejable (por ejemplo, 500–1000 tokens o por párrafos). Demasiado pequeño pierdes contexto; demasiado grande diluye la relevancia.
  • Metadata: Guardas título, fuente, fecha, etc., para filtrar y para mostrar “fuente: X” al usuario.

2. Embeddings

  • Cada chunk se pasa por un modelo de embeddings (por ejemplo, OpenAI, Cohere, o modelos open source como sentence-transformers) y obtienes un vector de dimensión fija.
  • Esos vectores se guardan en un vector store (Pinecone, Weaviate, Chroma, pgvector, etc.) o en un índice de similitud (FAISS, Annoy).

3. Retrieval

  • Cuando llega una pregunta, la conviertes en embedding con el mismo modelo.
  • Buscas los k chunks más similares (por producto escalar o distancia coseno).
  • Opcional: filtros por metadata (solo docs de un producto, solo de un año, etc.).

4. Prompt y generación

  • Construyes el prompt, por ejemplo: “Responde solo usando el siguiente contexto. Si la respuesta no está en el contexto, di que no lo sabes. Contexto: [chunks]. Pregunta: [pregunta].”
  • Llamas al LLM (GPT-4, Claude, Llama, etc.) con ese prompt.
  • Devuelves la respuesta y, si quieres, los fragmentos usados como “fuentes”.

5. Mejoras opcionales

  • Re-ranking: Un segundo modelo reordena los chunks recuperados por relevancia real para la pregunta.
  • HyDE: Generas una “respuesta hipotética” a la pregunta, la embedas y buscas con eso; a veces mejora la recuperación.
  • Multi-query: Generas varias reformulaciones de la pregunta y recuperas con todas; fusionas resultados.
  • Chunk overlap: Chunks que se solapan un poco para no cortar frases por la mitad.

Stack típico (ejemplo)

  • Documentos: Markdown/PDF → parser + chunker (LangChain, LlamaIndex, o código propio).
  • Embeddings: API de OpenAI/Cohere o modelo local (sentence-transformers).
  • Vector store: Chroma, Pinecone, Weaviate, pgvector (si ya usas Postgres).
  • LLM: API de OpenAI/Anthropic o modelo local (Llama, Mistral).
  • Orquestación: Un servicio que recibe la pregunta, hace retrieval, construye el prompt y llama al LLM; opcionalmente un framework (LangChain, LlamaIndex) para encadenar pasos.

Mi perspectiva personal

RAG es la forma más práctica de conectar un LLM con tu conocimiento sin fine-tuning: añades documentos, reindexas y el asistente puede responder con lo que tienes en tu wiki, tus manuales o tus datos. Las alucinaciones bajan cuando la respuesta está en el contexto; si no está, un buen prompt (“di que no lo sabes”) evita inventar.

Montarlo “desde cero” implica decidir chunking, embeddings, vector store y prompt; después puedes iterar (re-ranking, HyDE, múltiples fuentes). No hace falta empezar con el stack más complejo: un solo tipo de documentos, un embedding model y un vector store sencillo ya te dan el 80 % del valor. A partir de ahí, mejoras según necesites más precisión, más fuentes o mejor citación.