LEANN : un index vectoriel qui recalcule les embeddings au lieu de les stocker

Ce que LEANN cherche à résoudre

Un index vectoriel classique stocke un vecteur par chunk de texte. Le README donne un ordre de grandeur : indexer 60 millions de chunks occuperait environ 201 Go dans une base traditionnelle, contre environ 6 Go avec LEANN. Le projet cible donc un problème de capacité de stockage, pas un problème de qualité de recherche. La cible est l'utilisateur d'un ordinateur personnel qui veut interroger ses propres données : système de fichiers, courriels, historique de navigation, conversations WeChat ou iMessage, historiques ChatGPT et Claude, signets Twitter, messages Slack. Le README présente aussi une intégration MCP pour Claude Code, avec un argument précis : Claude Code ne propose qu'une recherche par mots-clés de type grep, et LEANN s'installe comme service MCP de recherche sémantique sans changer le flux de travail. Le public visé est donc double : celui qui veut un RAG privé sur sa machine, et celui qui veut donner à un agent de codage un accès sémantique à un dépôt.

Recalcul sélectif et élagage de graphe

Le mécanisme décrit dans le README est un recalcul sélectif basé sur un graphe, avec un élagage qui préserve les sommets de fort degré. Concrètement, plutôt que de conserver tous les embeddings, LEANN construit un graphe de voisinage et recalcule les embeddings à la demande pendant la recherche. Le stockage de l'index se réduit donc à la structure de graphe, plus un mécanisme pour régénérer les vecteurs quand la traversée l'exige. Le README mentionne l'usage du format CSR pour limiter l'empreinte du graphe lui-même. Deux conséquences découlent de cette architecture. D'abord, le coût se déplace du disque vers le calcul : chaque requête qui touche un sommet non encore recalculé doit produire un embedding, ce qui suppose un modèle d'embeddings disponible localement et réactif. Ensuite, la qualité dépend de la qualité du graphe : un élagage trop agressif coupe des voies d'accès, un élagage trop faible fait gonfler le stockage. Le README affirme une absence de perte de précision, et renvoie à l'article arXiv 2506.08276 pour l'illustration et les détails. C'est le point à vérifier en priorité sur votre propre corpus, car c'est là que se joue le compromis central du projet.

Installation : uv, PyPI et le paquet leann

Le README commence par une dépendance externe : uv, l'outil de gestion d'environnements Python, installable via le script fourni par Astral. Ensuite, deux chemins. Le premier clone le dépôt pour accéder aux exemples : git clone https://github.com/yichuan-w/LEANN.git leann, puis cd leann. Le second installe le paquet depuis PyPI : uv venv, source .venv/bin/activate, puis uv pip install leann. Le README tronqué s'arrête sur cette commande, et la suite de la documentation n'est pas fournie ici. Je ne peux donc pas décrire la syntaxe exacte des commandes de construction d'index et de recherche au-delà de ce que le matériel contient. Ce qui est confirmé : le paquet s'appelle leann sur PyPI, la licence est MIT, les versions Python annoncées sont 3.10 à 3.14, et les plateformes citées sont Ubuntu, Arch, WSL, macOS ARM64 et Intel, ainsi que Windows. Les intégrations listées dans les topics couvrent LangChain, Llama Index et Ollama, ce qui suggère plusieurs points d'entrée, mais le README fourni ne détaille ni leurs clés de configuration ni leurs signatures d'appel.

Le benchmark ContextBench et ce qu'il ne prouve pas

Le README rapporte une comparaison entre LEANN et BM25 sur 30 tâches SWE-Bench Pro issues de ContextBench, avec un budget de récupération fixé à 8 192 tokens et un modèle, un agent et des outils constants. Les chiffres annoncés : 24,2 % contre 11,4 % de rappel initial du code pertinent, soit 2,1 fois plus, 38,4 % contre 25,8 % de couverture après exploration, et 3,22 M contre 3,51 M de tokens consommés, soit 8,4 % de moins. Le README précise que les résultats sont des moyennes macro de métriques annotées sur des lignes d'or, et ajoute une réserve explicite : un meilleur accès au contexte ne garantit pas la résolution du problème. Cette réserve est importante. Le benchmark mesure la récupération, pas la réussite de la tâche. Il compare aussi LEANN à BM25, une méthode lexicale, et non à une autre base vectorielle dense. Un lecteur qui cherche à savoir si LEANN bat FAISS ou un index HNSW classique en qualité de recherche n'aura pas de réponse ici, même si FAISS figure dans les topics du dépôt. Le protocole est reproductible via benchmarks/contextbench/README.md, ce qui permet de refaire la mesure, mais uniquement sur ce jeu de tâches.

Les limites du stockage compressé

La promesse de 97 % d'économie de stockage a un revers structurel. Un index qui ne stocke pas les vecteurs doit les recalculer, donc chaque recherche coûte du calcul là où une base classique coûte surtout des entrées-sorties disque. Sur un ordinateur portable sans accélération GPU, le README ne donne aucune mesure de latence, et le fait qu'une enquête communautaire demande aux utilisateurs de voter entre accélération GPU et intégrations supplémentaires suggère que l'accélération GPU n'est pas encore acquise. Autre limite : le projet cible des données personnelles et des historiques, c'est-à-dire des corpus qui changent souvent. Le README ne décrit pas de stratégie d'indexation incrémentale ni de compaction. Si un chunk est modifié, la question de savoir si le graphe doit être reconstruit partiellement ou entièrement reste ouverte dans le matériel fourni. Enfin, les intégrations MCP et les connecteurs listés (Slack, Twitter, WeChat, iMessage, ChatGPT, Claude) sont présentés comme des cas d'usage, sans documentation de configuration dans le README fourni. Ce sont des promesses de couverture, pas des preuves de maturité.

Face à FAISS et aux bases vectorielles classiques

FAISS est l'alternative la plus directe, et elle figure justement dans les topics du dépôt. La différence d'approche est nette : FAISS construit et conserve des structures d'index contenant les vecteurs, avec des variantes de quantification (PQ, IVF, HNSW) pour compresser ou accélérer la recherche. LEANN déplace le compromis : il conserve un graphe élagué et recalcule les vecteurs à la demande. Un index FAISS avec quantification produit des distances approximatives du fait de la compression des vecteurs ; LEANN, d'après le README, recalcule les embeddings exacts des sommets visités, ce qui explique la revendication d'absence de perte de précision. Le prix à payer est le calcul. Une base vectorielle classique comme Qdrant ou Milvus offre en plus des filtres de métadonnées, des transactions et une gestion multi-utilisateurs, que LEANN n'annonce pas. Le choix se résume donc à ceci : si vous avez besoin de filtres riches, de mises à jour concurrentes et d'un service partagé, une base classique reste l'outil adapté. Si votre contrainte est l'espace disque sur une machine personnelle et que vous acceptez de payer en calcul, l'approche de LEANN est cohérente.

Maintenance, versions et licence

Le rythme de publication est modéré : v0.3.5 en novembre 2025, v0.3.6 en janvier 2026, v0.3.7 en mars 2026, avec un dernier push sur main en septembre 2026. La version reste en 0.3.x, ce qui indique une API encore susceptible de bouger. Une migration entre versions mineures peut donc demander de reconstruire des index, surtout si le format de graphe évolue. Le projet est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver la notice de copyright et le texte de la licence. Le README ne mentionne aucune clause supplémentaire, mais il cite des dépendances et des intégrations tierces (Ollama, LangChain, Llama Index) dont les licences respectives s'appliquent séparément. Le README indique aussi que le projet ne collecte aucune télémétrie, ce qui est cohérent avec l'argument de confidentialité, mais cela ne dit rien du comportement des modèles d'embeddings que vous branchez : si vous utilisez un modèle distant, les textes indexés quittent la machine. La confidentialité dépend du modèle choisi, pas de LEANN seul.

Conclusion éditoriale

LEANN convient aux développeurs qui veulent une recherche sémantique locale sur des données personnelles volumineuses (courriels, historique de navigation, dépôts de code) et qui acceptent de gérer un backend d'embeddings et des chemins d'index persistants. Il ne convient pas aux équipes qui ont besoin d'un filtrage métadonnées riche, de transactions ou de mises à jour à haut débit : ce n'est pas un moteur de recherche d'entreprise. Avant d'adopter, vérifiez trois choses concrètes : le coût de recalcul des embeddings sur votre matériel avec un petit corpus, la disponibilité de votre modèle d'embeddings en local, et le comportement des commandes leann build et leann search sur un fichier unique avant de lancer une indexation massive.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. StarTrail-org/LEANN on GitHub