El stack RAG open source en 2026: piezas, coste real y build vs buy

En 2026 el ecosistema RAG open source se ha estabilizado en cuatro capas: parsers para extraer texto de los documentos, modelos de embeddings, bases de datos vectoriales y un orquestador que conecta todo con el modelo de lenguaje. Montar su propio stack le da control total sobre los datos y el coste marginal por pregunta, pero exige mantener infraestructura, actualizar modelos y vigilar la calidad de las respuestas. Esta guía repasa las piezas habituales, lo que realmente cuesta operarlas y cuándo compensa más contratar un servicio gestionado en lugar de construirlo desde cero.

Qué significa «stack RAG» en la práctica

Un sistema RAG (Retrieval Augmented Generation) recupera pasajes relevantes de sus documentos y los inyecta en el prompt antes de generar una respuesta. Técnicamente eso implica una cadena de pasos: extraer el texto, dividirlo en fragmentos (chunks), convertir cada fragmento en un vector numérico, guardarlo en un índice que permita buscar por similitud y, al llegar una pregunta, recuperar los fragmentos más cercanos y pasárselos al modelo junto con la pregunta. Cada uno de esos pasos tiene hoy varias alternativas open source maduras, lo que ha democratizado montar un prototipo, pero también ha multiplicado las decisiones de ingeniería que hay que tomar antes de llegar a producción.

Parsers y extracción de documentos

Antes de pensar en embeddings hay que resolver algo menos glamuroso: sacar texto limpio de PDF, Word, HTML o escaneados. Librerías como Unstructured, Docling, PyMuPDF o Apache Tika cubren los formatos más comunes, pero los problemas reales aparecen con tablas complejas, PDF escaneados que necesitan OCR, o documentos con maquetación a varias columnas que mezclan el orden de lectura. Un parser mediocre produce fragmentos con frases cortadas o tablas convertidas en texto ilegible, y eso contamina todo lo que viene después por muy bueno que sea el modelo de embeddings. La fase de chunking, es decir cómo se trocea ese texto limpio, también influye directamente en la calidad de las respuestas; conviene revisar las distintas estrategias de chunking para RAG antes de fijar un tamaño de fragmento por defecto.

Modelos de embeddings open source

Los modelos de embeddings traducen un fragmento de texto en un vector que captura su significado. Familias como BGE, E5 o Nomic Embed ofrecen buen rendimiento y versiones multilingües razonables para contenido en español, aunque conviene probarlas con sus propios documentos antes de asumir que funcionarán igual que en los benchmarks publicados. Si no está familiarizado con el concepto, merece la pena repasar qué son los embeddings antes de elegir modelo, porque la decisión afecta al tamaño del índice, a la latencia de búsqueda y al coste si decide reindexar todo su corpus cada vez que aparece una versión nueva. Ejecutar estos modelos localmente requiere GPU para volúmenes altos, aunque para catálogos pequeños una CPU moderna o una API de inferencia por lotes puede ser suficiente.

Bases de datos vectoriales y motores de búsqueda

pgvector (una extensión de PostgreSQL), Qdrant, Milvus y Weaviate son las opciones open source más citadas para almacenar e indexar vectores. Todas soportan búsqueda por similitud, pero difieren bastante en escalabilidad, facilidad de despliegue y soporte de búsqueda híbrida (combinar palabras clave exactas con similitud semántica). Esta combinación suele dar mejores resultados que cualquiera de las dos técnicas por separado, especialmente cuando los usuarios buscan códigos, referencias o nombres propios que un embedding puro puede pasar por alto; conviene leer por qué la búsqueda híbrida gana a keywords o vectores por separado antes de descartar el componente de texto completo. Si ya evalúa alternativas a Pinecone, tenga en cuenta que el coste real no está solo en la licencia sino en el tiempo de alguien del equipo dedicado a backups, escalado y actualización de índices.

Orquestación: frameworks y pipelines

LangChain, LlamaIndex, Haystack o DSPy conectan las piezas anteriores: reciben la pregunta, deciden qué recuperar, construyen el prompt y gestionan la llamada al modelo de lenguaje. Son muy útiles para prototipar rápido, pero cada versión nueva del framework puede romper integraciones y cada actualización de dependencias exige pruebas de regresión. En equipos pequeños es habitual terminar sustituyendo buena parte del framework por código propio más simple, precisamente porque la capa de orquestación es la que más cambia y la que menos valor diferencial aporta frente a mantener el control sobre el resto del stack.

Qué cuesta realmente operar un stack open source

El coste de licencia es cero, pero eso no significa gratis. Operar un stack RAG open source en producción implica servidores o GPU para inferencia de embeddings, hosting de la base vectorial con sus backups, monitorización de la calidad de las respuestas y, sobre todo, tiempo de ingeniería para mantener todo actualizado. Si quiere comparar cifras concretas frente a otras opciones, el artículo sobre cuánto cuesta realmente un sistema RAG desglosa partidas típicas mes a mes.

Build vs buy: cuándo construir y cuándo contratar un RAG as a service

Construir su propio stack tiene sentido cuando necesita control fino sobre cada componente, tiene un equipo de ingeniería disponible de forma continuada y el volumen de consultas justifica la inversión en infraestructura propia. Comprar, es decir contratar un servicio de RAG as a service, tiene sentido cuando quiere lanzar en días en lugar de meses, no dispone de equipo dedicado al mantenimiento de la capa de datos, o simplemente prefiere pagar por pregunta y olvidarse del resto. Si está evaluando ambas rutas en detalle, la comparativa de plataformas de RAG as a service repasa pipelines gestionados y marketplaces frente a montar cada pieza por su cuenta.

Kopik (kopik.io) es un ejemplo de la vía «comprar»: cualquiera puede crear una base de conocimiento gratis subiendo PDF, Word, texto o Markdown desde crear una base de conocimiento; Kopik se encarga de extraer, trocear e indexar los documentos para búsqueda híbrida (texto completo más expansión semántica), sin que usted tenga que elegir modelo de embeddings ni base vectorial. Las bases pueden ser privadas (solo usted y sus claves de API) o públicas en el catálogo de bases de conocimiento, donde quien pregunta paga por consulta y el creador se queda el 70 % del precio que fije. Las consultas se hacen desde la web, por API con claves propias o mediante un servidor MCP que funciona desde Claude, Cursor, ChatGPT y otros clientes compatibles.

También existe una vía intermedia: usar piezas open source para el desarrollo y las pruebas internas, y mover a producción solo la parte que realmente necesita escalar con un servicio gestionado. Esto es especialmente útil cuando se construye sobre una aplicación propia; la guía para añadir una API de base de conocimiento a su aplicación explica cómo integrar ese componente sin reescribir el resto del backend.

Preguntas frecuentes