- Skald fue desarrollado con el objetivo de ser un sistema RAG completamente autoalojable, sin enviar datos a terceros
- Los componentes de un RAG se dividen en base de datos vectorial, modelo de embeddings, LLM, reranker y parser de documentos, y se presentan alternativas de código abierto para cada uno
- La pila local base de Skald está compuesta por Postgres+pgvector, Sentence Transformers, Docling y un LLM personalizado
- Según los resultados del benchmark, los modelos basados en la nube (Voyage+Claude) obtuvieron un promedio de 9.45, mientras que el GPT-OSS 20B totalmente local fue evaluado entre 7.10 y 8.63
- Este enfoque demuestra que es posible construir un RAG de alto rendimiento manteniendo la privacidad de los datos
Componentes de RAG y alternativas de código abierto
- Un RAG básico está compuesto por base de datos vectorial, modelo de embeddings y LLM, y adicionalmente puede incluir reranker y parser de documentos
- Cada componente puede sustituirse por alternativas locales en lugar de SaaS
- Alternativas presentadas en la tabla de ejemplo
- Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
- Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
- LLM: GPT, Claude → Llama, Mistral, GPT-OSS
- Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
- Document Parsing: Reducto → Docling
- Skald apunta a una pila completamente de código abierto, ejecutando cada componente en local
Configuración de la pila local de Skald
- Vector DB: usa Postgres + pgvector
- Es fácil de integrar con la infraestructura existente y puede manejar hasta cientos de miles de documentos
- Vector Embeddings: el valor predeterminado es Sentence Transformers (all-MiniLM-L6-v2)
- Solo para inglés, con un buen equilibrio entre velocidad y rendimiento de búsqueda
- También se probó el modelo bge-m3 (con soporte multilingüe)
- LLM: no se incluye uno por defecto; el usuario lo ejecuta por su cuenta
- En las pruebas, GPT-OSS 20B se ejecutó en EC2
- Reranker: el valor predeterminado es Sentence Transformers Cross-Encoder; también pueden usarse modelos multilingües como bge-reranker-v2-m3
- Document Parsing: se usa Docling, ejecutado con docling-serve
Resultados de rendimiento y despliegue
- El despliegue de una instancia de producción de Skald con toda la pila incluida tomó 8 minutos
- Incluye Postgres, servicios de embeddings y reranking, y Docling
- El LLM se ejecuta por separado (usando llama.cpp)
- El dataset de prueba se compuso de contenido del sitio web de PostHog (aprox. 2000 documentos) y un conjunto propio de preguntas y respuestas
- Configuración experimental
- Vector search topK=100, Reranking topK=50, Query rewriting=Off
- El criterio de evaluación se centró en la precisión
Comparación de resultados del benchmark
- Voyage + Claude (configuración en la nube)
- Puntaje promedio de 9.45, con todas las respuestas correctas
- Voyage + GPT-OSS 20B (parcialmente local)
- Puntaje promedio de 9.18, mayormente correcto pero con alguna información faltante
- Totalmente local + GPT-OSS 20B
- Modelo base en inglés (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2): promedio de 7.10
- Preciso en consultas en inglés, pero con debilidades en consultas multilingües, ambiguas y en agregación de múltiples documentos
- Modelo multilingüe (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1): promedio de 8.63
- Procesó con éxito consultas en portugués, aunque con algunas omisiones al agregar múltiples documentos
- La principal limitación es el procesamiento integrado de información dispersa en varios documentos
- Los modelos en la nube compensan esto con alto rendimiento, pero en entornos locales se necesitan técnicas adicionales
Planes a futuro
- Skald planea mejorar el rendimiento del RAG local y publicar benchmarks de modelos de código abierto
- Su objetivo es ofrecer una solución para empresas que necesitan operar herramientas de IA en entornos aislados de la red
- Quienes quieran participar pueden colaborar a través de GitHub(skaldlabs/skald) o la comunidad de Slack
7 comentarios
Quién sabe de dónde salió esa idea de que para RAG necesitas una base de datos vectorial…
Sea una base de datos vectorial o lo que sea, en realidad solo habría que implementar la búsqueda...
Gemini: Sí, el uso de una base de datos vectorial (Vector Database) en RAG (Retrieval-Augmented Generation) tiene su base conceptual desde que se publicó por primera vez el artículo relacionado en 2020.
RAG combina básicamente recuperación (Retrieval) y generación (Generation), y en esa etapa de recuperación los embeddings vectoriales y una base de datos vectorial que los almacene y los busque de forma eficiente cumplen un papel esencial.
💡 Punto de partida de RAG y las bases de datos vectoriales
La idea de que RAG necesita una base de datos vectorial parte de los siguientes artículos y conceptos clave.
La razón fundamental por la que una base de datos vectorial se volvió un componente esencial de RAG es la siguiente.
Resumen: por qué se necesita una base de datos vectorial
Para que un LLM pueda acceder a conocimiento reciente o específico de un dominio que no aprendió durante su entrenamiento, es necesario encontrar información con base en similitud semántica, no simplemente mediante keyword matching (búsqueda tradicional). La base de datos vectorial es la tecnología clave que se integró de forma natural al framework RAG para ejecutar eficientemente esa búsqueda basada en similitud semántica.
En realidad, lo que necesita RAG es la función de búsqueda; hacer embeddings con vectores densos, subirlos a una vectorDB y buscar por similitud de coseno es solo uno de los muchos métodos para implementar un motor de búsqueda... No es que haya una razón particular para no usar una vectorDB, pero si me preguntas si de verdad es indispensable, me deja un poco dudando, porque existen muchos algoritmos de motores de búsqueda que se han usado bien durante muchísimo tiempo.
Porque es barato y además lo usan la mayoría de los LLM de producción.
De hecho, si nos vamos por esa lógica, hasta un servidor web podría hacerlo todo desde disco si le agregas funciones de infraestructura, así que tampoco haría falta un DBMS jaja
Es cierto que se necesita una DB para una especie de búsqueda por similitud/semántica que usa como clave el valor de embedding (vector) de la query del usuario, y como la clave tiene forma de vector, una vector DB también tiene sentido.
Comentario en Hacker News
Al construir este tipo de sistemas, daría el consejo de no obsesionarse con las bases de datos vectoriales o los embeddings
La búsqueda de texto completo o herramientas como
grep/rgson mucho más rápidas y baratas, y además no hace falta mantener índicesSi le das herramientas de búsqueda a un buen LLM, puede generar por sí solo consultas como “dog OR canine” e ir mejorándolas de forma iterativa
Además, así ya no hace falta resolver el problema del chunking
Se puede ver en Search Sensei
En la primera carga descarga unos 50 MB de pesos del modelo y onnx runtime, pero después funciona sin problemas
Por ejemplo, BM25 no entiende que “j lo” y “jlo” se refieren a Jennifer Lopez, pero la búsqueda basada en embeddings maneja bien este tipo de errores tipográficos o alias
Realiza búsquedas sobre 1000 artículos de noticias entre 2016 y 2024
Pero da pena que no hayan publicado el rendimiento de BM25 por sí solo
En mis pruebas pequeñas, hubo casos donde los embeddings no encontraron páginas que sí contenían exactamente las palabras de la consulta — al final, Ctrl+F ganó
La búsqueda léxica tiene alta precisión pero baja cobertura, y la búsqueda semántica está en el punto opuesto
Siento que hace más falta el operador “NOT”. También quiero aprender más sobre RAG
He visto algunas herramientas tipo agente que generan estas consultas automáticamente, pero no sé si es algo inducido por el prompt o un comportamiento por defecto
Una de las razones del bajo rendimiento podría ser la falta de semantic chunking
Si incrustas el documento completo, se mezclan varios conceptos y baja la precisión
Hay que dividirlo por unidades semánticas con herramientas como Spacy, añadir el contexto de dónde está cada chunk dentro del documento, y luego generar los embeddings
El enfoque de contextual retrieval de Anthropic fue muy efectivo en sistemas RAG
Se puede generar el contexto con el modelo GPT OSS 20B
Creo que hubo una confusión porque hicimos las pruebas con preguntas que requerían agregar contexto de varios documentos
Me pregunto por qué se asume que la búsqueda semántica es superior a la léxica
En 2023, al compararla con Tantivy (BM25), la diferencia en resultados fue mínima
Incluso si hay una pequeña mejora en cobertura, no sé si vale la pena construir toda esa estructura compleja
En pruebas de desarrolladores tuvimos 90% de cobertura, pero en pruebas con usuarios reales bajó a alrededor de 30%
Como los usuarios no conocen la terminología exacta de los documentos, la búsqueda léxica sola no bastaba
Se puede poner un agente encima, pero la latencia aumenta y baja la satisfacción del usuario
En Wanderfugl, la búsqueda semántica encuentra bien partes con puntajes bajos en BM25
Al final, la respuesta puede ser un ranking híbrido
En última instancia, depende del caso de uso
Estoy buscando una herramienta open source para consultar localmente y sin conexión todos mis datos: correo, Slack, GDrive, código, wiki, etc.
Quisiera evitar construirla o personalizarla yo mismo, y preferiría que tuviera buenos valores por defecto y recomendaciones de modelos
Enlace de GitHub
Básicamente soporta CRUD, y si activas la búsqueda vectorial hace embeddings de documentos o notas
Soporta Ollama y OpenAI como proveedores de embeddings
El servidor MCP ofrece tanto búsqueda semántica + BM25 (qdrant fusion) como generación de respuestas mediante MCP sampling
El servidor no genera respuestas por sí mismo, así que puede integrarse con cualquier cliente LLM/MCP
Este patrón de MCP sampling/RAG es muy potente, y es muy posible que aparezca una versión open source generalizada para otras fuentes de datos
La herramienta que usamos es haiku.rag
Ofrece código Python amigable para desarrolladores y una estructura basada en pydantic-ai, además de benchmarks y funciones avanzadas de citas
Soporta agentes de investigación profunda y es un proyecto verdaderamente open source con mantenimiento a largo plazo
Estoy usando Sentence Transformers (all-MiniLM-L6-v2) como modelo de embeddings por defecto, pero me di cuenta de que es solo para inglés, así que podría ser un problema al construir un RAG en alemán
Me gustaría saber qué tan bueno es el rendimiento de los modelos no ingleses
Mira los apartados RTEB Multilingual o RTEB German en la sección “Retrieval”
Si vas a hacer self-hosting sobre CPU, conviene filtrar por modelos de menos de 100M de parámetros
Pero el alemán tiene relativamente muchos datos de entrenamiento, y también existen suficientes modelos multilingües
En particular, la mayoría de los modelos basados en API comercial tienen soporte multilingüe
Se puede consultar el artículo relacionado en Springer
En la época de GPT-4 (contexto de 8K), hice un script que dividía un libro completo en chunks y lo metía en GPT-4 para buscar pasajes relevantes
En ese entonces una sola búsqueda costaba alrededor de 1 dólar, pero ahora se ha vuelto mucho más barato
En el artículo de contextual retrieval de Anthropic también dicen que, si todo el documento cabe en el contexto, es mejor meterlo completo en vez de usar RAG
Pero cuando el contexto se hace largo, baja la calidad y también se vuelven problema el costo y la velocidad
Ahora incluso meter un libro completo en el contexto cuesta alrededor de 1 centavo
La parte más difícil en RAG es el parseo de documentos
Si solo trabajas con texto, está bien, pero cuando hay tablas, tablas de varias páginas, gráficos, índices, notas al pie, etc., la precisión cae drásticamente
Para mejorar esto existe un enfoque donde el LLM resume y formula preguntas sobre el contenido, como en el patrón RAPTOR, y luego lo guarda en una base de datos vectorial
Pero una pipeline RAG de propósito general que funcione en todos los casos sigue siendo un reto difícil
También me pregunto si una base de datos vectorial maneja mejor grupos largos de texto o formatos tabulares
Me pareció interesante esta nueva perspectiva de aplicar búsqueda de texto completo a RAG
Fueron especialmente valiosas las ideas sobre el bucle de herramientas tipo agente y la forma de manejar la búsqueda difusa (fuzzy search)
Me pregunto si existe una estandarización de los datasets de evaluación para este tipo de sistemas
Estaría bien tener un benchmark con documentos y conjuntos de preguntas donde cierto documento o chunk deba aparecer como el resultado más relevante