Un índice de código abierto desarrollado en UC Berkeley reduce el almacenamiento necesario para buscar en decenas de millones de fragmentos al recalcular embeddings durante la consulta. Las pruebas reportan una precisión comparable a HNSW en NQ, pero tiempos de recuperación considerablemente mayores.
***
- El repositorio reporta que un índice de Wikipedia con 60 millones de fragmentos pasa de 201 GB a 6 GB.
- En una prueba de NQ, LEANN igualó el 25,5% de precisión downstream de HNSW con una fracción del almacenamiento.
- El ahorro implica más espera: la recuperación de NQ tomó 2,48 segundos frente a 0,05 segundos con HNSW.
🧠 LEANN reduce un índice RAG de 201 GB a 6 GB
El sistema de UC Berkeley reconstruye embeddings durante cada consulta.
En NQ igualó la precisión de HNSW: 25,5%.
El costo: recuperar resultados tomó 2,48 s, frente a 0,05 s con HNSW. pic.twitter.com/E9OTb9x5El
— Diario฿itcoin (@DiarioBitcoin) October 28, 2026
LEANN reduce el tamaño de índices vectoriales, pero tarda más en recuperar información
LEANN, un índice vectorial de código abierto creado por el Sky Computing Lab de UC Berkeley, busca resolver una limitación de los sistemas de recuperación para generación aumentada, o RAG: el espacio que ocupan los vectores almacenados. En el benchmark de su repositorio, un índice de Wikipedia con 60 millones de fragmentos baja de 201 GB a 6 GB, una reducción que abre la posibilidad de ejecutar búsquedas semánticas sobre grandes colecciones en equipos personales.
El ahorro no llega sin contrapartidas. En lugar de guardar todos los embeddings, LEANN los recalcula cuando recibe una consulta, por lo que las pruebas reportan tiempos de recuperación mucho más largos que los de índices como HNSW, aunque con precisión downstream comparable en algunos escenarios. La ficha de MLSys 2026 presenta el trabajo de LEANN como una ponencia oral, bajo el título LEANN: A Low-Storage Overhead Vector Index.
Un índice compacto que reconstruye los vectores al consultar
Los índices vectoriales permiten localizar fragmentos de texto relacionados con una pregunta aunque no repitan exactamente sus palabras. En sistemas RAG, esa búsqueda aporta información a un modelo generativo antes de que redacte una respuesta, pero almacenar los embeddings de cada fragmento puede exigir más disco que conservar los datos originales, un problema que LEANN intenta reducir mediante un diseño que prioriza el almacenamiento.
El equipo describe LEANN como un índice de vecinos más cercanos aproximados construido sobre FAISS. En vez de conservar todos los vectores completos, mantiene un grafo podado y los reconstruye bajo demanda; el documento de investigación expone un corpus de 76 GB cuyo almacenamiento convencional requiere 173 GB en embeddings y otros 15 GB para el grafo HNSW, más del doble del tamaño de los datos de origen.
El mecanismo se apoya en que una búsqueda sobre un grafo no necesita revisar cada elemento del corpus: recorre una ruta limitada de nodos candidatos. LEANN guarda el grafo y una tabla compacta de cuantización por producto, o PQ, y vuelve a generar embeddings solo para los nodos que participan en esa ruta, con el objetivo de evitar el costo de almacenar la representación completa de todos los fragmentos.
El sistema combina tres recursos para que ese recálculo resulte viable. Primero, usa distancias PQ de bajo costo para ordenar candidatos y vuelve a calcular con exactitud solo los mejores; además, agrupa candidatos de varios saltos en lotes, por ejemplo de 64, para aprovechar mejor la GPU, y conserva más conexiones para el 2% de los nodos que funcionan como hubs dentro del grafo.
Menos espacio, pero tiempos de búsqueda mayores
Las pruebas comparan LEANN con HNSW, DiskANN, una alternativa de recomputación basada en IVF y compresión PQ. En la configuración del artículo para un corpus de 76 GB, LEANN ocupa 4 GB frente a 188 GB de HNSW y 270 GB de DiskANN; el repositorio, por su parte, presenta otro benchmark con 60 millones de fragmentos cuyo índice pasa de 201 GB a 6 GB, por lo que las cifras corresponden a configuraciones distintas.
En el conjunto NQ, con Qwen3-4B y una tarjeta RTX 4090, LEANN y HNSW registraron ambos 25,5% de precisión downstream. LEANN necesitó 4 GB en la configuración reportada, mientras HNSW ocupó 188 GB; la compresión PQ obtuvo 17,9% y BM25, el método de búsqueda por palabras clave usado como referencia, alcanzó 18,3%.
La diferencia aparece con claridad en la latencia de recuperación. Al 90% de Recall@3, LEANN tardó 2,48 segundos en NQ, mientras HNSW necesitó 0,05 segundos; como la generación consumió alrededor de 20 segundos, el tiempo total del pipeline subió de 20,95 a 23,34 segundos con el índice compacto.
En la RTX 4090, la recuperación de LEANN osciló entre 1,12 segundos en GPQA y 7,12 segundos en HotpotQA, siempre bajo la medición al 90% de recall indicada en el artículo. El sistema de recomputación con IVF, inspirado en EdgeRAG, llegó a 307,61 segundos en NQ y 429,46 segundos en HotpotQA, mientras que la recomputación de embeddings siguió representando cerca del 76% de la latencia de consulta.
Uso en equipos personales y aplicaciones conectadas
El artículo señala que LEANN igualó la precisión downstream de HNSW en NQ mientras usaba una parte pequeña de su almacenamiento, pero esa equivalencia no significa que ambos índices respondan igual de rápido. En una estación de trabajo con 32 GB de RAM, LEANN pudo ejecutarse, mientras que HNSW agotó la memoria en la comparación descrita; el equipo también probó el sistema en una Mac M1 Ultra.
La diferencia de rendimiento depende del conjunto de datos y del equipo. En la prueba de HotpotQA sobre Mac, la recuperación tardó 44,80 segundos y representó el 50,1% del tiempo total del pipeline, un resultado que recuerda que el menor uso de disco puede trasladar parte del costo a la espera, especialmente en consultas que exigen recuperar información de varios fragmentos.
El repositorio también ofrece cifras de colecciones personales: 400.000 mensajes de chat pasan de 1,8 GB a 64 MB, mientras 38.000 entradas del navegador bajan de 130 MB a 6,4 MB. Esos ejemplos ilustran el objetivo del proyecto, que no se limita a corpora de investigación, sino que también contempla historiales y documentos que usuarios podrían preferir indexar localmente.
Entre las integraciones descritas figuran documentos, Apple Mail, historial de Chrome, WeChat, iMessage y exportaciones de ChatGPT o Claude, además de lectores MCP para Slack y marcadores de Twitter. LEANN también puede operar como servidor MCP de búsqueda semántica para Claude Code; para generar respuestas admite Ollama, Hugging Face, Anthropic y APIs compatibles con OpenAI.
Alcance, limitaciones y disponibilidad
En 30 tareas de SWE-Bench Pro de ContextBench, el equipo reportó que LEANN recuperó inicialmente código relevante en el 24,2% de los casos, frente al 11,4% de BM25, y que el agente usó 8,4% menos tokens. Son resultados reportados por los investigadores y corresponden a esa evaluación concreta, por lo que no permiten concluir que la herramienta mejore por igual todos los flujos de programación asistida.
El proyecto usa HNSW como backend predeterminado y ofrece DiskANN como alternativa para búsquedas más rápidas, de acuerdo con la descripción del repositorio. El código tiene licencia MIT y se instala con el paquete `uv pip install leann`; el sistema declara compatibilidad con Ubuntu, Arch, WSL, macOS y Windows, aunque algunas funciones, como la búsqueda en Apple Mail, solo están disponibles en macOS.
El balance que muestran las pruebas es concreto: LEANN reduce de forma marcada el espacio necesario para ciertos índices y, en NQ, conserva la precisión downstream de HNSW, pero demora más en recuperar resultados. Para quienes priorizan ejecutar búsquedas RAG en una computadora personal o manejar datos locales con menos almacenamiento, ese intercambio puede ser relevante; para aplicaciones sensibles a la latencia, los tiempos reportados plantean una limitación que conviene evaluar.
El proyecto no elimina el costo computacional de los índices vectoriales, sino que lo desplaza: en vez de pagar principalmente por conservar embeddings, recalcula parte de ellos durante la consulta. Sus resultados apuntan a una alternativa de menor tamaño para colecciones extensas, aunque la decisión de adoptarla dependerá de si el ahorro de disco compensa la espera adicional en cada búsqueda.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
IA
Firefox suma IA para llenar formularios y vigilar páginas web
California
Anthropic pide que los tribunales puedan frenar modelos de IA riesgosos
Empresas
Anthropic busca el sello FedRAMP Moderate para Claude Enterprise
Educación