RAG local: introduction

#RAG local: la definición y lo que esperas de él

RAG significa generación aumentada por recuperación: se recuperan primero pasajes relevantes de una base de documentos, luego se pide al modelo que redacte una respuesta a partir de ellos. La palabra local indica que cada paso (lectura de documentos, cálculo de embeddings, almacenamiento, generación) se ejecuta en tu hardware. Es el uso más útil de un modelo privado: preguntas sobre contratos, notas o una base de conocimientos interna, con respuestas que citan sus fuentes.

#¿Por qué usar RAG en lugar de enviar todo al modelo?

Primera idea: copiar todos tus documentos en el prompt. Hay dos limitaciones que lo impiden. La ventana de contexto es limitada: 300 PDF representan millones de tokens, mucho más de lo que acepta un modelo local. E incluso cuando un documento cabe, la calidad baja: un estudio de referencia (Liu et al., Stanford) muestra que el rendimiento puede caer considerablemente cuando la información útil se encuentra en medio de un contexto largo, incluso en modelos diseñados para contextos largos. Este fenómeno se llama lost in the middle.

El RAG evita estos dos problemas al transmitir al modelo solo unos pocos pasajes seleccionados para la pregunta. El modelo lee unos cientos de tokens bien seleccionados en lugar de decenas de miles de tokens poco útiles, con un menor coste de cálculo y una menor latencia. La clave está en recuperar bien los pasajes.

Un orden de magnitud, con un cálculo ilustrativo: 300 PDF de 20 páginas con unos 600 tokens por página representan 3,6 millones de tokens, es decir, cientos de veces la ventana de 8.000 tokens que suele configurarse en un modelo local. Divididos en pasajes de 400 tokens, dan aproximadamente 9.000 pasajes. Una pregunta selecciona cinco, es decir, 2.000 tokens: el modelo lee el 0,06 % del corpus, pero el 0,06 % adecuado si la búsqueda tiene éxito.

#El concepto en dos minutos: embeddings y distancia

Un embedding es una lista de números que representa el significado de un texto. Dos textos que hablan de la misma cosa tienen vectores cercanos, incluso si no usan las mismas palabras. La documentación de Ollama describe los embeddings como vectores numéricos que se pueden almacenar en una base vectorial, buscar por similitud coseno o usar en un RAG, con una longitud que depende del modelo, típicamente entre 384 y 1024 dimensiones.

Una pregunta se convierte en un vector mediante el mismo modelo y luego se compara con todos los pasajes indexados: se devuelven los más cercanos. Un error habitual entre principiantes: el modelo de embeddings usado para el índice y el usado para las preguntas deben ser idénticos. La documentación de LlamaIndex lo recuerda en su ejemplo de recarga del índice: es importante usar el mismo embed_model que se utilizó para construirlo.

#Anatomía de un RAG: dos fases

#Fase 1: la indexación, realizada una vez por documento

1. 01
   Ingesta

   Leer archivos (PDF, Word, Markdown, HTML) y extraer el texto limpio. Es la etapa más subestimada.
2. 02
   Segmentación

   Dividir en fragmentos lo suficientemente pequeños para ser precisos y lo suficientemente grandes para conservar el sentido. Los fragmentos de 200 a 500 tokens son un punto de partida habitual.
3. 03
   Embedding

   Pasar cada fragmento por el modelo de embedding, por ejemplo con el comando ollama run embeddinggemma o la API /api/embed.
4. 04
   Almacenamiento

   Guardar los vectores junto con el texto original y metadatos (nombre del archivo, página, fecha).

#Fase 2: la consulta, para cada pregunta

1. 01
   Embedding de la pregunta

   Con el mismo modelo que para la indexación.
2. 02
   Búsqueda

   Encontrar los N pasajes cuyos vectores sean los más cercanos, utilizando la similitud coseno como medida.
3. 03
   Construcción del prompt

   Crear un mensaje que contenga los extractos y la instrucción de responder citando las fuentes y de indicar cuándo la respuesta no figura en ellos.
4. 04
   Generación

   Enviar este prompt al modelo local, que redacta la respuesta.

#La pila mínima y las opciones sin código

Para un RAG local que funcione, cuatro módulos son suficientes: un modelo de generación servido por Ollama, un modelo de embedding, una base vectorial y una capa que los conecte. Para el francés, elige un modelo de embedding multilingüe; la página de Ollama recomienda tres (embeddinggemma, qwen3-embedding, all-minilm), y los tamaños de vector son modestos, lo que permite ejecutarlos en un portátil.

Para evitar programar, la guía sobre RAG en LM Studio y la de AnythingLLM detallan cada opción; la guía sobre NotebookLM y las alternativas locales cubre la consulta «notebook lm rag».

#El pipeline en Python, paso a paso

El ejemplo a continuación sigue el esquema oficial del tutorial LlamaIndex con modelos locales: un lector de carpetas, un modelo de embeddings, un modelo servido por Ollama, y luego un motor de consulta. Instala primero los paquetes llama-index-llms-ollama y llama-index-embeddings-huggingface. Ajusta los nombres de los modelos según los que hayas descargado.

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.ollama import Ollama
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

Settings.embed_model = HuggingFaceEmbedding(model_name="intfloat/multilingual-e5-large")
Settings.llm = Ollama(model="qwen3.5:9b", request_timeout=360.0, context_window=8000)

documents = SimpleDirectoryReader("mes_documents").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=5)

response = query_engine.query("Quelles sont les échéances du contrat Dupont ?")
print(response)
print(response.source_nodes)

La primera ejecución calcula todos los embeddings, lo que tarda más o menos según el volumen y la máquina. Para evitar recalcularlo todo, guarda el índice con index.storage_context.persist, luego cárgalo nuevamente con load_index_from_storage reutilizando el mismo modelo de embeddings. El parámetro context_window limita la memoria consumida, como indica el tutorial.

#Los errores que hacen fracasar los primeros intentos

La segmentación ingenua rompe las estructuras

Un corte en medio de una tabla produce fragmentos ilegibles. Utiliza una herramienta de segmentación que respete los títulos y las tablas, o convierte primero los documentos con Docling.

El idioma del embedding cuenta

Un modelo de embedding entrenado principalmente en inglés recupera peor los pasajes en francés. Usa un modelo multilingüe y pruébalo con 10 preguntas reales antes de indexar todo el corpus.

Un único valor de top-k rara vez resulta adecuado

Muy pocos pasajes empobrecen la respuesta; demasiados saturan el modelo. Ajusta según la naturaleza de los documentos y comprueba los resultados con preguntas cuya respuesta conozcas.

Una mala búsqueda produce una respuesta formulada con seguridad y falsa

Un modelo que reciba extractos irrelevantes puede inventar una respuesta que parezca convincente. Mide primero la relevancia de los extractos.

Los PDF pueden dar problemas

Dos columnas, pies de página, tablas, documentos escaneados: una parte importante del trabajo consiste en limpiar los datos durante la ingesta. Un PDF escaneado requiere OCR antes de cualquier otro procesamiento.

Mezclar modelos de embedding

Indexar con un modelo y consultar con otro da resultados absurdos, sin mensaje de error.

#Cuándo no usar RAG

La guía que compara fine-tuning y RAG detalla este último caso.

#Hardware y confidencialidad: lo que permanece en tu entorno

En un RAG completamente local, los documentos, los vectores y las preguntas permanecen en la máquina, siempre que cada componente sea local: un modelo de embeddings servido por Ollama o cargado desde el disco, una base vectorial en un archivo o en un servicio local y un modelo de generación local. Comprueba que ningún componente llame a un servicio en línea: un modelo de embeddings o un modelo en la nube seleccionado por error enviaría tus pasajes al exterior.

En cuanto al hardware, el componente que más recursos consume es el modelo de generación: en Q4, un modelo de 8 a 9 mil millones de parámetros cabe en unos 5 GB de memoria, más el contexto. Aquí el contexto aumenta porque contiene los fragmentos: prevé un margen si aumentas el número de pasajes. El embedding, por su parte, es ligero; la indexación inicial de un corpus grande sigue siendo la operación más larga y se realiza una sola vez. La guía sobre los LLM sin GPU indica qué permite cada cantidad de RAM.

#¿Y después? Las mejoras en orden

Un RAG básico suele responder bien a preguntas sencillas. Para ir más allá, el orden más rentable es el siguiente: primero, una división en fragmentos que respete la estructura; después, la búsqueda híbrida (vectorial y por palabras clave con BM25, para no pasar por alto un término exacto como un número de contrato); luego, un reranker que reordene los primeros resultados; y, por último, una evaluación con un conjunto de unas cincuenta preguntas cuyas respuestas conoces. Sin mediciones, cada cambio sigue siendo una impresión.

• ¿Qué es el RAG? Guía para principiantes
• Estrategias de división de documentos
• Embeddings para el francés
• RAG en LM Studio
• AnythingLLM: tutorial RAG
• Evaluar un RAG con Ragas

• Fuente: embeddings en Ollama
• Fuente: tutorial LlamaIndex con modelos locales
• Fuente: Lost in the Middle (Liu et al.)
• Fuente: LM Studio, Chat with Documents