Pipeline RAG 100% Local: Cómo Darle Memoria a tus Documentos con IA Sin Salir de tu Red

La mayoría de asistentes de IA son amnésicos. No recuerdan lo que les dijiste ayer, y mucho menos pueden consultar tus contratos, apuntes o manuales. Esto no es un bug: los LLMs no tienen acceso a tus archivos a menos que se los proporciones en el contexto de cada conversación. La solución técnica se llama RAG (Retrieval-Augmented Generation) y, a diferencia de los servicios en la nube, puedes montarlo tú mismo sin que un solo byte salga de tu red.

Qué es RAG y por qué importa para un homelab

RAG es un patrón de arquitectura, no un producto. Funciona en dos fases: primero convierte tus documentos en vectores numéricos (embeddings) y los almacena en una base de datos vectorial; luego, cuando haces una pregunta, busca los fragmentos más relevantes de tus documentos y se los inyecta al LLM como contexto. El modelo genera una respuesta basada en texto real que tú controlas, no en su memoria de entrenamiento.

Para un homelab esto es clave por tres razones: privacidad (tus documentos nunca salen de tu red), precisión (responde con datos reales, no alucinaciones sobre hechos que no conoce) y control (tú decides qué documentos son fuente de verdad).

Arquitectura de un pipeline RAG local

No hace falta una pila exótica. Un pipeline funcional se construye con componentes open source maduros que ya conoces:

• Ollama: sirve el modelo de lenguaje y, si lo configuras correctamente, también el modelo de embeddings. Es el punto de entrada de todo.
• PostgreSQL + pgvector: base de datos relacional con extensión vectorial. Es la opción más robusta para almacenar embeddings: respaldos estándar, consultas SQL complejas, y madurez de décadas.
• Python + FastAPI: orquesta el flujo: recibe documentos, los fragmenta, genera embeddings, almacena vectores y responde consultas. Es el pegamento del sistema.
• Apache Tika o pdfplumber: extrae texto de PDFs, Word, Excel y otros formatos. Tika es más generalista; pdfplumber funciona mejor con PDFs complejos (tablas, columnas).

Opcional pero recomendado: un frontend como Open WebUI conectado a tu pipeline RAG vía API. Da una interfaz conversacional sin tener que escribir curls.

Cómo funciona el flujo paso a paso

El proceso tiene dos modos: ingesta (subir documentos) y consulta (hacer preguntas). Veamos cada uno en detalle.

Fase 1: Ingesta de documentos

• 1. Extracción: El documento se procesa para obtener texto plano. Si es un PDF escaneado, necesitas OCR (Tesseract es la opción local estándar).
• 2. Fragmentación (chunking): El texto se divide en trozos de tamaño configurable —típicamente 512-1024 tokens con solapamiento del 10-20%. El tamaño del chunk es el parámetro más crítico: demasiado grande y el embedding pierde especificidad; demasiado pequeño y pierde contexto.
• 3. Generación de embeddings: Cada chunk se convierte en un vector numérico usando un modelo de embeddings. Modelos como nomic-embed-text o all-MiniLM-L6-v2 funcionan bien en español y consumen pocos recursos.
• 4. Almacenamiento: Los vectores se guardan en pgvector junto con el texto original y metadatos (nombre del archivo, página, fecha). Esto permite recuperar no solo el vector sino el fragmento textual exacto.

Fase 2: Consulta

• 1. Embedding de la pregunta: La consulta del usuario se convierte en un vector usando el mismo modelo de embeddings que en la ingesta.
• 2. Búsqueda vectorial: Se buscan los N vectores más cercanos en la base de datos (similitud coseno es el estándar). Típicamente recuperamos entre 3 y 10 chunks.
• 3. Construcción del prompt: El sistema ensambla un prompt que incluye instrucciones del sistema, los chunks recuperados y la pregunta del usuario. El prompt suele incluir una instrucción del tipo: 'Responde basándote ÚNICAMENTE en el contexto proporcionado. Si no encuentras la respuesta, di que no lo sabes.'
• 4. Generación de respuesta: El LLM recibe el prompt enriquecido y genera una respuesta fundamentada en los documentos. Opcionalmente puedes incluir referencias a qué chunks usó.

Modelos de embeddings que funcionan bien localmente

La calidad de un sistema RAG depende más del modelo de embeddings que del LLM. Si los vectores no capturan bien el significado semántico, el retrieval falla y el LLM no puede compensarlo. Estas son las opciones que he probado en producción:

• nomic-embed-text (v1.5): ~130MB, rápido, buen rendimiento multilingüe. Es mi elección por defecto para documentos en español.
• all-MiniLM-L6-v2: ~80MB, el estándar de facto. Menos potente que nomic para textos largos, pero imposible de mejorar en eficiencia.
• mxbai-embed-large: ~330MB. Mejor calidad que los anteriores, especialmente para textos técnicos y comparaciones semánticas sutiles. El coste computacional es mayor pero asumible en hardware moderno.

Todos están disponibles en Ollama con un simple 'ollama pull'. No necesitas frameworks adicionales.

Chunking: el arte de cortar sin destruir

La estrategia de fragmentación tiene más impacto del que parece. He probado tres enfoques con diferencias notables:

• Chunking fijo: corta cada N caracteres o tokens. Simple, rápido, pero rompe oraciones a la mitad y pierde coherencia entre párrafos.
• Chunking por párrafos: respeta la estructura del documento. Funciona bien para textos bien formateados, pero genera chunks de tamaño muy desigual.
• Chunking recursivo con solapamiento: el estándar actual. Divide por párrafos primero, luego por oraciones si el párrafo es demasiado largo, y mantiene un solapamiento del 10-20% entre chunks adyacentes. Es el que uso por defecto.

Un detalle frecuentemente ignorado: los documentos técnicos (manuales, contratos) necesitan chunking más conservador porque una referencia cruzada en la página 5 puede ser esencial para entender la página 12. Para esos casos, prefiero chunks de 300-400 tokens con solapamiento del 25%.

Prompt engineering para RAG: no es opcional

El prompt de sistema es la diferencia entre un asistente que cita tus documentos con precisión y uno que inventa datos porque 'suena bien'. Este es el patrón que uso:

'Eres un asistente especializado que responde preguntas basándose EXCLUSIVAMENTE en el contexto proporcionado a continuación. Si la respuesta no está en el contexto, di claramente que no tienes información suficiente. No inventes datos. No uses conocimiento externo. Cita las fuentes cuando sea posible.'

Incluir la instrucción 'cita las fuentes' permite que el LLM referencie qué chunks utilizó, lo que ayuda al usuario a verificar la información. En la práctica, modelos de 7B-14B siguen esta instrucción con una fiabilidad del 85-90% si el contexto es claro.

Escalabilidad y límites reales

Un pipeline RAG local en un Mac Mini M2 con 16GB puede manejar cómodamente 10.000-50.000 páginas de documentos. Más allá de eso, pgvector empieza a necesitar índices específicos (IVFFlat o HNSW) para mantener tiempos de búsqueda por debajo de los 200ms.

Los cuellos de botella que encontrarás primero no son la base de datos, sino:

• Extracción de texto de PDFs escaneados: el OCR es lento y consume CPU. Considera preprocesar los documentos escaneados en batches nocturnos.
• Generación de embeddings en bulk: para miles de documentos, hazlo por lotes de 50-100 chunks, no todo de golpe. Ollama puede saturarse con peticiones concurrentes masivas.
• Contexto del LLM: si recuperas 10 chunks de 1024 tokens cada uno, sumados al prompt de sistema y la pregunta, puedes superar el límite de contexto del modelo. Un modelo de 8B suele soportar 8K-32K tokens, pero la calidad de atención decae con contextos muy largos.

Casos de uso reales donde un RAG local brilla

He desplegado pipelines RAG locales para varios escenarios. Estos son los que más valor aportan:

• Asistente legal/contratos: subes todos tus contratos, facturas y documentos legales. Preguntas '¿qué contratos vencen en los próximos 3 meses?' y el sistema busca en el texto real.
• Segundo cerebro digital: notas personales, apuntes de cursos, libros resumidos. Un RAG bien configurado supera a cualquier sistema de búsqueda por keywords tradicional.
• Documentación técnica interna: manuales de equipos, runbooks de operaciones, procedimientos de empresa. Reduce el tiempo de búsqueda de información técnica en un 70-80%.
• Análisis de documentos académicos: subes papers y libros, y haces preguntas comparativas entre autores o buscas contradicciones entre fuentes.

Conclusión

Un pipeline RAG local no es magia: es arquitectura disciplinada. Consiste en fragmentar bien tus documentos, elegir un modelo de embeddings adecuado, almacenar vectores de forma eficiente y construir prompts que obliguen al LLM a ceñirse al contexto. Nada de esto requiere hardware exótico ni servicios de terceros.

En mi experiencia, el 80% del trabajo está en la preparación de datos: limpiar PDFs mal formateados, normalizar encabezados, y ajustar el chunking hasta que las consultas devuelven los fragmentos correctos. El otro 20% es iterar el prompt de sistema hasta que el LLM deje de alucinar.

Si ya tienes Ollama corriendo en tu homelab, añadir un pipeline RAG es el siguiente paso lógico. Transforma un modelo amnésico en un asistente con memoria documental completa. Y lo hace sin que tus contratos, apuntes o diarios personales crucen nunca la puerta de tu router.