Qué propone LEANN
El proyecto, desarrollado por el Sky Computing Lab de la Universidad de California en Berkeley, no intenta guardar todos los vectores en memoria o en disco como hacen muchos índices aproximados clásicos. En su lugar, conserva un grafo podado y reconstruye parte de la información vectorial en tiempo de consulta. La idea central es aceptar más trabajo durante la búsqueda para reducir de forma radical el tamaño del índice.
La publicación describe LEANN como un índice sobre FAISS orientado a un problema muy concreto: los índices vectoriales suelen acabar ocupando más espacio que los propios datos a los que dan servicio. En el ejemplo incluido, un corpus de 76 GB requeriría 173 GB de *embeddings* y 15 GB adicionales para un grafo HNSW, lo que hace que el sistema termine duplicando o triplicando el almacenamiento respecto al conjunto original.
Cómo reduce tanto el tamaño
LEANN combina tres piezas técnicas. La primera es un grafo podado, en el que no se guardan todas las conexiones posibles. La segunda es un esquema de distancia con cuantización de producto para filtrar candidatos de forma barata. La tercera es la recomputación de *embeddings* solo para los nodos que el recorrido de búsqueda considera realmente relevantes.
Ese diseño se apoya en una observación práctica: los índices tipo HNSW no exploran todo el grafo, sino una fracción pequeña por consulta. LEANN aprovecha ese recorrido parcial para limitar cuánto tiene que volver a calcular. Además, el sistema agrupa candidatos en lotes dinámicos para aprovechar mejor la GPU y conserva más conexiones en los nodos de mayor grado, lo que intenta preservar calidad de recuperación sin disparar el tamaño del índice.
Qué gana y qué pierde frente a HNSW
La comparación más llamativa está en el equilibrio entre memoria y velocidad. En la prueba destacada con NQ, LEANN alcanza la misma precisión que HNSW en una configuración de 90% de *recall*, pero usando 4 GB en lugar de 188 GB. La versión resumida del proyecto también afirma que, con 60 millones de fragmentos, el índice baja de 201 GB a 6 GB.
El precio de esa compresión es la latencia. En la misma prueba, la recuperación con LEANN tarda 2,48 segundos frente a 0,05 segundos con HNSW. En HotpotQA, la búsqueda sube hasta 7,12 segundos. La propia descripción del proyecto subraya que la recomputación de *embeddings* sigue siendo la mayor parte del tiempo de consulta, alrededor del 76% de la latencia.
Eso cambia el tipo de sistema para el que LEANN tiene sentido. No parece pensado para el caso en el que una respuesta debe salir casi en tiempo real, sino para escenarios en los que importa más poder ejecutar RAG sobre un portátil o sobre una máquina con recursos limitados que exprimir el último milisegundo. En otras palabras: reduce la huella de almacenamiento a costa de aceptar que la búsqueda no será instantánea.
Qué dice el proyecto sobre uso real
El repositorio asociado añade ejemplos que apuntan a usos personales y de productividad: documentos, correo de Apple, historial de Chrome, WeChat, iMessage y exportaciones de ChatGPT o Claude. También menciona un servidor MCP para Claude Code y conectores para fuentes como Slack o marcadores de Twitter. Según el material publicado, el sistema puede ejecutarse en Ubuntu, Arch, WSL, macOS y Windows, con algunas funciones reservadas a macOS.
El proyecto también afirma que, en datos personales, 400.000 mensajes de chat pasan de 1,8 GB a 64 MB y 38.000 entradas del navegador de 130 MB a 6,4 MB. Son cifras útiles para entender el objetivo del sistema: llevar búsquedas semánticas y RAG a equipos donde el espacio local es escaso, sin depender de una gran infraestructura para guardar todos los vectores.
Lo que sigue sin estar cerrado
Aunque la publicación presenta el trabajo como premiado en MLSys 2026, lo relevante para un usuario práctico sigue siendo otro dato: cuánto penaliza esa recomputación en su propio caso de uso. El artículo reconoce que la latencia depende mucho del recorrido, del hardware y del tipo de consulta. En la versión descrita no hay una cifra universal que permita decir que LEANN es una alternativa directa a HNSW para cualquier despliegue.
Por eso, la utilidad del proyecto no está en sustituir todos los índices vectoriales, sino en abrir una vía distinta para quienes prefieren compacidad y ejecución local frente a búsquedas submilisegundo. La pregunta pendiente es cuánta de esa ventaja de almacenamiento se mantiene cuando el corpus, el modelo de *embeddings* o el hardware cambian.
