Qué es el RAG y cómo funciona (guía principiante)

#RAG en 30 segundos

RAG significa Retrieval-Augmented Generation: generación de texto aumentada mediante búsqueda. En lugar de pedir directamente al LLM «responde a esta pregunta», primero se buscan los pasajes más relevantes en una base de documentos y luego se incorporan al prompt diciendo: «aquí están las fuentes, responde basándote en ellas».

Una analogía que funciona bien: un LLM por sí solo es un estudiante brillante que responde de memoria en un examen. Un RAG es ese mismo estudiante al que se le permite consultar los apuntes sobre la mesa. Inventa menos, cita la página correcta y, si se le dan unos apuntes que nunca ha visto (tus PDF, tus correos, tu wiki interna), puede responder sobre ellos de todos modos.

#Por qué (y cuándo) necesitarlo

Un LLM tiene dos grandes defectos que se hacen evidentes en cuanto lo utilizas en serio: inventa cuando no sabe (las famosas «alucinaciones») y solo conoce los datos que vio durante el entrenamiento. Qwen 3.5 9B nunca ha leído tu contrato, tu wiki de Notion ni tu base de datos de incidentes. Pedirle que responda directamente sobre su contenido es pedirle a alguien que imagine el contenido de un libro que no ha abierto.

El RAG resuelve ambos a la vez: se introducen los fragmentos adecuados en el prompt, el LLM los utiliza como base factual y las respuestas se vuelven rastreables: puedes mostrar las fuentes.

Hablar con tus PDF

Documentación técnica, contratos, artículos científicos, manuales: todo lo que ocupa demasiado espacio para caber en una ventana de contexto.

Asistente interno de equipo

Wiki, base de conocimientos de soporte, documentación del producto. En lugar de un Ctrl+F impreciso, una respuesta en francés que cita las páginas correctas.

Monitoreo y síntesis

Indexar cientos de artículos o informes, hacer preguntas transversales, comparar fuentes.

Datos recientes o privados

Todo lo que el LLM no ha podido ver: tu código, tus correos, publicaciones posteriores a su fecha de corte.

#El pipeline en 4 etapas

Un RAG consta de dos fases: la indexación (una sola vez, previamente) y la consulta (con cada pregunta). Estas son las cuatro piezas que se encadenan.

1. 01
   1. Chunking — dividir los documentos

   Tus PDF, archivos Markdown o páginas web se dividen primero en fragmentos (chunks) de aproximadamente 200 a 800 palabras. No se pueden generar embeddings de un libro entero de una sola vez y, en cualquier caso, se busca recuperar el pasaje preciso que responde a la pregunta, no todo el documento.
2. 02
   2. Embeddings — convertir texto en vectores

   Cada chunk pasa por un modelo de embeddings que lo convierte en un vector de números (normalmente de 384 a 1024 dimensiones). Dos pasajes que hablan de lo mismo darán vectores cercanos en este espacio: esa es la magia que permite la búsqueda semántica.
3. 03
   3. Almacenamiento en una base vectorial

   Los vectores más el texto original se almacenan en una base especializada (Chroma, Qdrant, FAISS…) que sabe responder rápidamente a la pregunta «¿cuáles son los vectores más cercanos al mío?».
4. 04
   4. Recuperación + generación

   Cuando el usuario hace una pregunta, se calcula el embedding de esa pregunta, se recuperan los 3 a 10 chunks más cercanos, se incorporan al prompt del LLM con una instrucción del tipo «responde basándote en estos fragmentos» y el LLM genera la respuesta.

# Phase 1 : INDEXATION (une fois)
for doc in documents:
    chunks = split(doc, taille=500)              # 1. chunking
    for chunk in chunks:
        vector = embedder.embed(chunk)            # 2. embedding
        vector_db.add(vector, chunk)              # 3. stockage

# Phase 2 : INTERROGATION (à chaque question)
question = "Quel est le délai de résiliation ?"
q_vector = embedder.embed(question)               # même modèle qu'à l'indexation
top_chunks = vector_db.search(q_vector, k=5)      # 4a. retrieval

prompt = f"""Réponds en t'appuyant uniquement sur les extraits ci-dessous.

Extraits :
{top_chunks}

Question : {question}"""
reponse = llm.generate(prompt)                    # 4b. génération

#Embeddings: el corazón de la recuperación

Un modelo de embeddings es un mini-LLM especializado en una sola tarea: transformar un fragmento de texto en un vector de números que capta su «sentido». Dos frases que hablan del mismo tema darán vectores cercanos, incluso si no comparten ninguna palabra. Es esto lo que distingue al RAG de un simple Ctrl+F.

La calidad final del RAG depende tanto del modelo de embeddings como del LLM que hay detrás, y a menudo más del primero. Un mal embedding recupera los fragmentos equivocados, y el mejor LLM del mundo no podrá responder correctamente a partir de fragmentos de texto que no tengan relación con el tema.

nomic-embed-text

137M parámetros, 768 dimensiones, contexto de 8192 tokens. La opción predeterminada sensata que propone Ollama. Bueno en inglés, correcto en francés.

mxbai-embed-large

335M parámetros, 1024 dimensiones. Más preciso, 3 veces más lento. Útil cuando la calidad de la recuperación es el factor limitante.

multilingual-e5-large

560M, 1024 dimensiones. La mejor opción si tus documentos están en francés o son multilingües.

bge-m3

Excelente en francés, admite contextos largos. Requiere más recursos para ejecutarse, pero es una referencia para el contenido multilingüe.

#La base vectorial: dónde viven los vectores

Una base vectorial es una base de datos especializada en una operación: «encuentra los N vectores más cercanos a este». En el fondo, utiliza algoritmos (HNSW, IVF…) que hacen que esta búsqueda sea rápida incluso con millones de vectores. Para comenzar, no necesitas entender nada de estos algoritmos —basta con saber cuál elegir.

Chroma

Base de datos vectorial de código abierto, integrada en tu proyecto Python o ejecutada como servidor. Ideal para comenzar: cero configuración, persistencia en disco.

Qdrant

Más robusto para producción: servidor dedicado, filtros, multi-tenant. Corre en un contenedor Docker con un solo comando.

FAISS

Biblioteca de Facebook (Meta). Muy rápida, pero es solo un índice — sin gestión de metadatos. Buena para casos con exigencias de rendimiento crítico.

Guardada en la herramienta

Open WebUI, AnythingLLM, LM Studio incluyen su propia base vectorial. Es invisible — al subir un PDF, se indexa. Ideal para comenzar sin codificar.

#El LLM: generación guiada

El LLM es el último eslabón. Recibe un prompt similar a este: «Aquí tienes 5 extractos de la documentación. Responde a la pregunta basándote exclusivamente en ellos. Si la información no está en los extractos, dilo».

Este enfoque lo cambia todo. Sin contexto añadido, el LLM responde a partir de su memoria de entrenamiento e inventa información si esta es incompleta. Con los fragmentos adecuados en el prompt, tiene una base factual a la vista y se limita a reformular o sintetizar.

¿Qué tamaño de LLM?

Para un RAG sencillo, un modelo pequeño de 2026 que quepa en 8 GB (Qwen 3.5 9B, Granite 4.2 8B) es más que suficiente. La calidad del retrieval importa más que el tamaño del LLM.

¿Qué ventana de contexto?

Al menos 4096 tokens. Los chunks recuperados más la pregunta más la instrucción del sistema consumen rápidamente entre 2000 y 3000 tokens. Con 8192 o más, tienes margen suficiente.

¿Qué prompt de sistema?

Algo así: «Respondes en francés basándote únicamente en los fragmentos proporcionados. Si la información no está en ellos, dilo claramente».

#RAG local vs API en la nube

Puedes montar un RAG con la API de OpenAI o Claude (rápido de implementar, rendimiento máximo) o completamente local con Ollama + una base vectorial + un modelo de embeddings (sin fugas de datos, sin costo de uso). La elección depende de la sensibilidad de los documentos y de tu presupuesto.

RAG a través de una API en la nube

Tus documentos se envían al proveedor (OpenAI, Anthropic, Mistral…) durante la indexación y con cada pregunta. Rendimiento y calidad excelentes, pero incompatible con datos confidenciales (RGPD, secreto médico, contratos de clientes).

RAG 100% local

Ollama para el LLM, nomic o bge para los embeddings, Chroma o Qdrant para la base. Ningún dato abandona la máquina. Ideal para profesionales (juristas, médicos, personal de RR. HH.), empresas sujetas al RGPD y todos aquellos que quieren mantener el control.

Híbrido

Embeddings en local, LLM a través de API: limita la exposición (los documentos completos permanecen en local; solo los fragmentos pertinentes se envían a la nube al formular una pregunta). Un compromiso pragmático, pero desaconsejado si los propios fragmentos son sensibles.

#¿Por dónde empezar concretamente?

Tres caminos según tu perfil. Todos los tres funcionan 100% local en tu máquina.

1. 01
   Sin programar, con una interfaz (Open WebUI o AnythingLLM)

   Instalas Ollama, arrancas Open WebUI o AnythingLLM en Docker, subes tus PDF a una «Knowledge Base» y conversas. Todo —chunking, embeddings, recuperación— se gestiona por ti. 30 minutos desde el principio hasta el final.
2. 02
   Sin programar, en modo todo en uno (LM Studio)

   Desde la versión 0.3, LM Studio tiene la funcionalidad «Chat with Documents»: adjuntas un archivo al chat y LM Studio se encarga de procesarlo. Límite: 5 archivos por chat y formatos restringidos (PDF de texto, DOCX, TXT, MD). Perfecto para preguntas puntuales sobre un documento.
3. 03
   En Python con LangChain o LlamaIndex

   Control total: elección del chunker, del modelo de embeddings, de la base, del LLM, del prompt. Prevé media jornada para un primer prototipo bien hecho, más si quieres optimizar (reranker, búsqueda híbrida, etc.).

# 1. Installer Ollama (https://ollama.com)
# 2. Récupérer un LLM et un modèle d'embeddings
ollama pull qwen3.5:9b
ollama pull nomic-embed-text

# 3. Vérifier que le daemon répond
curl http://localhost:11434/api/tags

# 4. Lancer Open WebUI (interface ChatGPT-like avec RAG intégré)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Ouvrir http://localhost:3000
# Settings -> Documents -> uploader des PDF
# Dans un chat : taper # pour attacher une Knowledge Base

#Los errores típicos al empezar

Embedder en inglés, documentos en francés

La causa número 1 de resultados decepcionantes con RAG en Francia. Comprueba que tu modelo de embeddings sea compatible con el francés (multilingual-e5, bge-m3).

Chunks demasiado grandes o demasiado pequeños

500 palabras son un buen punto de partida. Si los chunks son demasiado pequeños (< 100 palabras), pierden su contexto; si son demasiado grandes (> 1500), el embedding promedia todo y pierde precisión.

Cambiar de embedder sin reindexar

Los vectores de un modelo no son compatibles con los de otro. Si pasas de nomic a bge, hay que reindexar todo; de lo contrario, la recuperación devuelve resultados sin sentido.

Demasiados chunks en el contexto

Por encima de 8-10 chunks, el LLM empieza a perderse. Es mejor contar con 5 chunks muy relevantes que con 20 medianamente relevantes (ahí es donde entra en juego un reranker, en un nivel más avanzado).

No se muestran citas

Para comprobar que un RAG funciona realmente, muestra las fuentes utilizadas en cada respuesta. Si no tienes esta visibilidad, no podrás distinguir una buena respuesta de una alucinación convincente.

#Para ir más allá

Ahora que sabes qué es el RAG, estas guías son el siguiente paso lógico para pasar a la práctica.

RAG local con Ollama sin programar

Guía paso a paso Open WebUI + AnythingLLM para montar tu primer RAG en 30 minutos, incluso sin GPU.

Los mejores modelos de embeddings en francés

Comparativo detallado para elegir entre nomic, multilingual-e5, bge-m3 y Solon según tu corpus.

RAG local: introducción

La guía conceptual detallada: chunking, recuperación, reordenamiento y métricas de evaluación.

Qué es Ollama y cómo funciona

Si aún no has instalado Ollama, por aquí.