- En Hacker News, un usuario pregunta cómo están implementando Retrieval-Augmented Generation (RAG) en entornos locales
- En el RAG local aparece con fuerza la idea de que incluso sin una base de datos vectorial se puede hacer funcionar bien usando búsqueda de texto como SQLite FTS5, BM25 o grep
- En búsqueda de código, abundan las experiencias de que los embeddings son lentos y ruidosos, y también hay muchas opiniones de que un enfoque basado en palabras clave como BM25 + trigramas funciona mejor
- Incluso cuando se necesita búsqueda vectorial, siguen apareciendo casos que lo resuelven con configuraciones ligeras como Postgres + pgvector, guardar BLOBs vectoriales en SQLite o cargar FAISS en memoria
- Se puede mejorar la calidad de búsqueda con combinaciones como búsqueda híbrida que une BM25 + vectores, RRF (Reciprocal Rank Fusion), reranking y expansión multiconsulta
- En vez de fijar “RAG = base de datos vectorial”, se ve una tendencia a elegir búsqueda simple → híbrida → tipo agente según el tipo de documento, la escala y la carga operativa
Conclusiones comunes en la etapa de búsqueda
- Más que asumir que una base de datos vectorial o un grafo son imprescindibles, muchos optan por empezar de forma simple según la infraestructura existente, los tipos de archivo y el rendimiento requerido
- También se menciona que el enfoque donde el agente consulta directamente el sistema de archivos o APIs es más fácil de configurar y mantener, aunque puede ser algo más lento
- La idea de que “lo que RAG le pasa al LLM son fragmentos cortos de texto obtenidos por búsqueda” lleva a centrar los puntos de mejora del rendimiento en la calidad de la recuperación
- Sobre la “definición de RAG”, conviven tanto la postura de que si hay retrieval + generation, entonces es RAG incluso sin base de datos vectorial, como la de que normalmente el término se usa asumiendo una base de datos vectorial
Modelos de embeddings y búsqueda vectorial
- El modelo de embeddings mdbr-leaf-ir, desarrollado en MongoDB, funciona solo con CPU y ha registrado el primer lugar en varios leaderboards dentro de su categoría de tamaño
- Puede procesar alrededor de 22 documentos por segundo y 120 consultas por segundo en un servidor estándar de 2 vCPU
- Obtuvo 53.55 puntos en el benchmark BEIR (frente a 42.69 de all-MiniLM-L12-v2)
- Los embeddings estáticos de palabras como model2vec/minish tienen mayor velocidad de inferencia, pero menor precisión de búsqueda
- Como solo hacen tokenización + tabla de búsqueda + promedio, son más rápidos que los modelos basados en transformers
- También se usa un enfoque donde se generan vectores por chunk de texto con Meta-Llama-3-8B, se almacenan en una columna BLOB de SQLite y se buscan con FAISS
- Para 5 millones de chunks, usa alrededor de 40 GB de memoria
- En una A6000, faiss-gpu es muy rápido, y en una M1 Ultra, faiss-cpu es más lento, pero suficiente para unas pocas consultas al día
Recomendaciones para búsqueda de código
- Para código se recomienda evitar las bases de datos vectoriales y usar la combinación BM25 + trigramas
- Los embeddings son lentos y no encajan bien con código
- Sin un reranker, el ruido aumenta y reindexar archivos implica más carga
- La velocidad de respuesta es alta y la calidad de resultados también es buena
- En PostgreSQL se puede implementar búsqueda BM25 con plpgsql_bm25
- También soporta búsqueda híbrida con pgvector + Reciprocal Rank Fusion
- Aplicar embeddings a rutas de archivo + firmas y fusionarlos con BM25 también puede dar buenos resultados
- También resulta efectivo un enfoque agéntico que ejecuta gpt-oss 20B junto con ripgrep en un bucle
while
Soluciones basadas en bases de datos
- SQLite FTS5: adecuada para documentos basados en archivos Markdown, y permite implementar RAG sin base de datos vectorial
- Se puede explorar documentos con búsqueda por palabras clave manteniendo un campo de descripción corta para cada archivo
- También es posible un diseño en el que se guardan vectores fp16 como BLOB en SQLite, se crea un subconjunto con filtros y luego se calcula la similitud en memoria
- También existen opciones como sqlite-vec, sqlite-vector, vec0 y bm25 de SQLite
- “SQLite funciona sorprendentemente bien”
- PostgreSQL + pgvector: permite aprovechar el conocimiento existente de Postgres y facilita el traspaso al equipo de operaciones
- También existe la librería llmemory, que soporta BM25 híbrido, expansión multiconsulta y reranking
- LanceDB: puede usarse cómodamente como base de datos vectorial embebida
- Se usa junto con los embeddings nomic-embed-text de Ollama
- DuckDB: ofrece una extensión de búsqueda por similitud vectorial y es adecuada para proyectos pequeños de menos de 3 GB
- Meilisearch, Typesense, Manticore: su operación es más simple que Elasticsearch/OpenSearch
Búsqueda híbrida y agéntica
- nori (usenori.ai): combina búsqueda semántica y por palabras usando SQLite + vec0 + fts5
- Turbopuffer: soporta búsqueda híbrida vectorial + BM25
- Solo con la combinación de búsqueda agéntica y búsqueda de texto ya se pueden obtener resultados bastante buenos
- Si además se añade búsqueda vectorial y graph RAG, se puede mejorar un poco la velocidad y la calidad
- Claude Code/Codex usa internamente ripgrep
- Aplicar embeddings a rutas de archivo también es efectivo, y mejora aún más al fusionarlo con BM25
Casos de uso de BM25
- shebe: herramienta CLI/MCP para indexación y búsqueda de codebases basada en BM25
- Es especialmente útil en flujos de trabajo de refactorización (por ejemplo, enumerar los lugares que hay que cambiar al actualizar Istio)
- En el 85% de los casos, basta con hacer matching de etiquetas sin base de datos vectorial
- Los operadores añadieron etiquetas tanto a las entradas como a los documentos y lograron una coincidencia del 100%
- Hay quien opina que la mayoría de las bases de datos vectoriales son “un martillo que intenta resolver el problema de no poder encontrar algo”
Herramientas y librerías especializadas
- qmd: herramienta CLI para buscar archivos Markdown, con mejores resultados de consultas difusas que fzf
- ck: herramienta de semantic grep basada en Rust
- Kiln: permite agregar archivos con drag and drop y comparar distintas configuraciones
- Soporta comparar métodos de extracción, modelos de embeddings y modos de búsqueda (BM25, híbrido, vectorial)
- Incluye evaluación de precisión de búsqueda y generación automática de datasets de evaluación
- libragen: servidor CLI/MCP para crear librerías de contenido RAG versionadas
- Puede convertir repositorios de GitHub en bases de datos RAG
- piragi: librería sencilla de Python para RAG, con soporte para fuentes locales/S3/API y otras
- ragtune: herramienta CLI para depurar y hacer benchmarking de búsqueda RAG local
Procesamiento de documentos y OCR
- discovery: hace OCR de documentos con Qwen-3-VL-8B y guarda vectores en ChromaDB
- Implementa RAG híbrido con BM25 + embeddings
- docling: herramienta de extracción de documentos usada en varios proyectos RAG
- Al convertir PDF, es difícil manejar tablas, múltiples columnas y tablas que abarcan varias páginas
- El modelo Mistral OCR ofrece los mejores resultados (modelo no público)
Gestión de memoria y contexto
- Lo que RAG entrega al LLM son solo cadenas cortas de resultados de búsqueda
- En modelos pequeños, TOP_K=5 suele ser el límite; por encima de eso aparece olvido de contexto
- Se puede mejorar usando resúmenes previos de archivos y carpetas
- También se usa un enfoque de poner todo el contenido en contexto con Sonnet + ventana de contexto de 1M
- Hay casos de construcción de un sistema de memoria para Claude Code mediante búsqueda semántica sobre archivos de sesión
Uso empresarial y a gran escala
- Al procesar 300 mil interacciones de clientes al día, la latencia y la precisión son importantes
- Se usa un enfoque híbrido con embeddings + búsqueda de texto completo + IVF-HNSW
- El reto es gestionar la propagación de información entre unos 600 sistemas distribuidos
- Se está experimentando con el enfoque KAG (Knowledge Augmented Generation) para mapear reglas de negocio
- También se logró implementar con éxito un RAG completamente local sobre más de 500 mil artículos de noticias usando una base vectorial en Postgres
Otras herramientas y enfoques
- AnythingLLM: incluye una base de datos vectorial empaquetada para documentos
- LibreChat: también incluye una base de datos vectorial empaquetada para documentos
- ChromaDB: se usa en una extensión de Obsidian para implementar búsqueda semántica/híbrida
- SurrealDB: se usa en combinación con vectorización local
- Interfaz de consultas OData: resulta efectiva cuando se ofrece al LLM como herramienta; permite analizar archivos Excel de 40 mil filas
- Nextcloud MCP Server: usa Qdrant como base de datos vectorial y ofrece búsqueda semántica sobre documentos personales
- LSP (Language Server Protocol): se añadió a Claude Code, pero actualmente tiene bugs
- TreeSitter podría ser más útil (consultar por nombre de símbolo, explorar definiciones y usos)
3 comentarios
Tengo dudas de si maneja bien el coreano.
Al ver el rendimiento de un sistema RAG interno bastante deficiente, posts como este sí me hacen cambiar un poco la perspectiva.
Opiniones de Hacker News
Nuestro equipo opera una base de datos de preguntas y respuestas
Tanto las preguntas como las respuestas se indexan con índices trigram y embeddings, y se guardan en Postgres
Al buscar, usamos
pgvectorjunto con búsqueda trigram, y combinamos los resultados con una puntuación de relevanciaEn la etapa de búsqueda desarrollamos un modelo de embeddings de texto de alta eficiencia y amigable con CPU
Es el modelo MongoDB/mdbr-leaf-ir, que ocupa el primer lugar en el leaderboard entre modelos de su tamaño
Es compatible con el modelo Snowflake/snowflake-arctic-embed-m-v1.5
En el demo de search-sensei se puede comparar búsqueda semántica vs BM25 vs híbrida
Por ejemplo, el modelo de embeddings reconoce que “j lo” significa “Jennifer Lopez”
También publicamos la receta de entrenamiento, y se puede entrenar fácilmente incluso con hardware de nivel medio
Desde abril de 2024 generé vectores con Meta-Llama-3-8B
Usé Python y Transformers en una RTX-A6000; era rápido, pero el ruido y el calor eran fuertes
Después me pasé a una M1 Ultra y usé la librería MLX de Apple; la velocidad es parecida, pero mucho más silenciosa
El modelo Llama tiene 4k dimensiones, así que son 8KB por chunk en fp16, y los guardo con
numpy.save()en una columna BLOB de SQLiteAl buscar, cargo todos los vectores desde SQLite, los convierto a
numpy.arrayy luego busco con FAISSfaiss-gpuen la RTX6000 es muy rápido, yfaiss-cpuen la M1 Ultra también es suficientemente rápido para mi caso de uso (unas cuantas consultas al día)Con 5 millones de chunks, el uso de memoria es de unos 40GB, algo que ambas máquinas pueden manejar sin problema
La mayoría de los documentos complejos son archivos Markdown
Recomiendo una herramienta CLI simple llamada tobi/qmd
Antes usaba un flujo de trabajo basado en fzf, pero esta herramienta ofrece mejor búsqueda difusa
No la uso para búsqueda en código
Recomiendo no usar bases de datos vectoriales para búsqueda de código
Los embeddings son lentos y no encajan bien con código
La combinación BM25 + trigram da mejores resultados y además responde más rápido
Puedes revisar el proyecto plpgsql_bm25
Incluye ejemplos y notebooks de Jupyter que combinan BM25 y pgvector con Reciprocal Rank Fusion
Si usas modelos que no son para código, la búsqueda vectorial mete mucho ruido
Ahora hacer un loop con
gpt-oss 20Bjunto con ripgrep es mucho más rápido y precisoSi lo fusionas con BM25, mejora aún más
Para experimentar con RAG local hice local-LLM-with-RAG
Genera embeddings con “nomic-embed-text” de Ollama y usa LanceDB como base de datos vectorial
Últimamente lo actualicé a “agentic RAG”, aunque para proyectos pequeños quizá sea demasiado
Guardo vectores fp16 como BLOB en SQLite, y después de filtrar los cargo en memoria para calcular similitud con multiplicación matriz-vector (matvec)
Si numpy o torch aprovechan multithreading/BLAS/GPU, va muy rápido
Si aparece un cuello de botella, planeo migrar a sqlite-vector
Es eficiente porque filtros como fecha o ubicación reducen mucho los datos
El backend está oculto detrás de una interfaz intercambiable
El 95% de mis documentos son archivos Markdown pequeños, así que uso SQLite FTS5 con un índice de búsqueda de texto normal
Como el índice ya existía, lo conecté directamente a un agente de mastra
Cada archivo tiene un campo de descripción corto, así que después de buscar por palabras clave, si la descripción coincide, cargo el documento completo
Configurarlo tomó como una hora y funciona muy bien
La búsqueda basada en embeddings es más común, pero la esencia es la misma
Nosotros estábamos familiarizados con Postgres, así que empezamos con PGVector
Más adelante descubrimos que coincidía al 100% con contenido que necesitaba campos semiestructurados en el prompt
Eso fue porque los operadores empezaron a poner etiquetas tanto en la entrada como en los documentos (unas 50 piezas de documentación)
Entonces primero buscamos por campos, metemos ese archivo en el prompt y después hacemos búsqueda por embeddings
Al final, en el 85% de los casos no hace falta una vectordb
Hice llmemory y lo uso tanto localmente como en apps de mi empresa
Está basado en PostgreSQL + pgvector, e incluye BM25 híbrido, expansión multi-query y reranking
Es la primera vez que lo publico, así que puede tener algunos bugs
Estoy bastante satisfecho con el rendimiento