LEANN: ein Vektorindex, der Embeddings nicht speichert, sondern neu berechnet

Das Speicherproblem, das LEANN adressiert

Ein klassischer Vektorindex speichert für jeden Chunk eines Korpus einen Vektor fester Dimension. Bei 60 Millionen Textabschnitten und einem gängigen Embedding-Modell ergibt das nach der Darstellung im Repository 201 GB. LEANN setzt für dieselben 60 Millionen Chunks 6 GB an. Der Faktor liegt damit im Bereich von etwa 33 zu 1, was die im README genannte Zahl von 97 Prozent Speicherersparnis erklärt. Zielgruppe sind nach der Projektbeschreibung Nutzer, die einen persönlichen Korpus auf dem eigenen Gerät durchsuchbar machen wollen: Dateisysteme, Apple Mail, Browserhistorie, WeChat- und iMessage-Verläufe, ChatGPT- und Claude-Konversationen, Slack-Nachrichten, Twitter-Lesezeichen oder eine Codebasis. Das README formuliert den Anspruch als RAG ohne Cloud-Kosten und ohne Telemetrie. Wer heute für solche Datenmengen einen gehosteten Vektordienst bezahlt oder eine lokale Instanz mit großem Speichervolumen betreibt, ist der adressierte Fall. Wer dagegen einen Korpus mit wenigen tausend Dokumenten verwaltet, gewinnt durch das Verfahren kaum etwas, weil dort auch die konventionelle Speicherung problemlos auf ein Notebook passt.

Selektive Neuberechnung statt vorgehaltener Vektoren

Der Mechanismus heißt im Repository graph-based selective recomputation mit high-degree preserving pruning. Der Index speichert also nicht die Embeddings selbst, sondern eine Graphstruktur über die Chunks, die während der Suche abgelaufen wird. Erst wenn ein Knoten für die Kandidatenmenge gebraucht wird, wird sein Embedding berechnet. Die Graphkanten werden als CSR-Struktur abgelegt, was den Verwaltungsaufwand des Graphen begrenzt. Das Pruning behält Knoten mit hohem Grad bevorzugt, weil diese im Graphen als Verbindungsstellen wirken und beim Entfernen die Erreichbarkeit zwischen Regionen zerstören würden. Für den Anwender bedeutet das eine Verschiebung der Kosten: Speicher und Arbeitsspeicher sinken, die Latenz einer Abfrage hängt dagegen davon ab, wie viele Embeddings während der Suche tatsächlich berechnet werden müssen. Das README nennt für diese Entscheidung keine Latenzzahlen. Wer eine Aussage über Antwortzeiten braucht, muss sie selbst erheben, weil das Material dazu nichts belegt. Der Graph selbst wird als portable Datei beschrieben, die zwischen Geräten übertragen werden kann, was für den Anwendungsfall persönlicher Wissensspeicher praktisch ist.

Installation über uv und die Plattformliste im README

Das Repository setzt auf uv als Paketwerkzeug. Zuerst wird uv installiert, im README per curl -LsSf https://astral.sh/uv/install.sh | sh. Danach folgt der Klon des Repositories, weil die Beispiele darin liegen: git clone https://github.com/yichuan-w/LEANN.git leann, dann cd leann. Die virtuelle Umgebung entsteht mit uv venv und wird mit source .venv/bin/activate aktiviert. Installiert wird das Paket anschließend aus PyPI mit uv pip install leann. Die unterstützten Python-Versionen reichen laut Badge von 3.10 bis 3.14. Bei den Plattformen nennt das README Ubuntu, Arch und WSL sowie macOS in den Varianten ARM64 und Intel und Windows. Diese Aufzählung ist die erste Prüfliste vor der Adoption, denn sie ist enger als bei einem reinen Python-Paket ohne native Bestandteile. Der Abschnitt zur Installation im vorliegenden Material endet an dieser Stelle, weitere Konfigurationsschlüssel für den Indexaufbau sind daraus nicht belegbar.

Der ContextBench-Vergleich und was er nicht aussagt

Das README beschreibt einen Versuch, bei dem LEANN als MCP-Dienst in Claude Code eingebunden und gegen BM25 auf 30 SWE-Bench-Pro-Aufgaben aus ContextBench verglichen wurde. Modell, Agent, Werkzeuge und ein Retrieval-Budget von 8.192 Token blieben konstant. Genannt werden 2,1-fache anfängliche Recall für relevanten Code, 24,2 Prozent gegen 11,4 Prozent, ein Zuwachs der Abdeckung nach der Exploration um 12,6 Prozentpunkte, 38,4 Prozent gegen 25,8 Prozent, und 8,4 Prozent weniger Token, 3,22 Millionen gegen 3,51 Millionen. Das Repository weist selbst darauf hin, dass es sich um makro-gemittelte annotierte Gold-Line-Metriken über 30 Aufgaben handelt und dass besserer Kontextzugriff nicht garantiert, dass ein Issue gelöst wird. Diese Einschränkung ist ernst zu nehmen: Gemessen wurde die Qualität der Retrieval-Schicht, nicht die Erfolgsquote des Agenten. Der Vergleichspartner ist zudem BM25, also lexikalische Suche, nicht ein dichter Vektorindex. Wer wissen will, wie LEANN gegen einen konventionellen Embedding-Index derselben Größe abschneidet, findet im vorliegenden Material keine Antwort.

Wo das Verfahren an seine Grenzen stößt

Die zentrale Einschränkung folgt direkt aus dem Entwurf. Wenn Embeddings nicht gespeichert werden, muss das Embedding-Modell zur Abfragezeit verfügbar sein und Rechenleistung liefern. Auf einem Laptop ohne dedizierte GPU ist das der Engpass, und das README nennt GPU-Beschleunigung ausdrücklich als offene Frage, über die eine Umfrage entscheiden soll. Wer den Index auf einem Server mit hoher Parallelität betreibt, tauscht dort Speicher gegen CPU-Zeit und verschlechtert möglicherweise den Durchsatz. Ein zweiter Punkt ist die Datenhoheit: Das README verspricht, dass Daten das Gerät nicht verlassen, aber diese Zusage hält nur, solange das konfigurierte Embedding-Modell lokal läuft. Wird ein entferntes Modell verwendet, ist die Privatsphäre-Zusage nicht mehr durch die Architektur gedeckt. Drittens eignet sich LEANN schlecht für Korpi, die bereits in einem bestehenden Vektorspeicher liegen und dort mit anderen Werkzeugen abgefragt werden. Ein Umstieg bedeutet, die Abfrageschicht zu ersetzen, ohne dass im Material ein Migrationspfad beschrieben wird.

Faiss als Gegenentwurf und der Unterschied im Ansatz

Faiss erscheint in den Topics des Repositories und ist der naheliegende Vergleichspunkt. Faiss ist eine Bibliothek für Ähnlichkeitssuche, die einen Index über vorberechnete Vektoren aufbaut und diesen im Speicher oder auf der Platte hält. Der Ansatz ist damit komplementär zu LEANN: Faiss optimiert die Suche in einem vorhandenen Vektorraum, LEANN verweigert die Vorhaltung dieses Vektorraums und rekonstruiert ihn stückweise während der Suche. Für einen Anwender heißt das: Mit Faiss sind Abfragen vorhersehbar schnell, aber der Speicherbedarf wächst linear mit dem Korpus. Mit LEANN bleibt der Speicherbedarf klein, aber jede Abfrage kostet Modellaufrufe. Wer einen Korpus hat, der ohnehin in den Arbeitsspeicher passt, hat keinen Grund, diesen Tausch einzugehen. Interessant wird LEANN dort, wo die Datenmenge die Speichergrenze des Geräts überschreitet, also genau bei den im README genannten 60 Millionen Chunks.

Pflegeaufwand, Release-Kadenz und Lizenz

Die letzten Releases liegen bei v0.3.7 vom März 2026, v0.3.6 vom Januar 2026 und v0.3.5 vom November 2025. Der letzte Push ins Repository ist mit September 2026 datiert, das Projekt ist also aktiv. Die Versionsnummern im 0.3-Bereich deuten auf eine Vorabphase mit möglichen Schnittstellenänderungen hin. Das README verweist auf eine Umfrage zur Planung von v0.4 und nennt GPU-Beschleunigung und weitere Integrationen als mögliche Schwerpunkte. Wer LEANN produktiv einsetzt, sollte damit rechnen, dass sich APIs zwischen Minor-Versionen bewegen können. Die Lizenz ist MIT, was die Nutzung, Änderung und Weitergabe mit Namensnennung erlaubt. Für eingebettete kommerzielle Nutzung ist das eine der permissivsten Varianten. Zu beachten ist, dass die MIT-Lizenz nur den Code des Projekts abdeckt. Die Lizenzbedingungen der separat geladenen Embedding-Modelle und der Datenquellen, etwa Mailarchive oder Chatverläufe, sind davon nicht berührt und müssen getrennt geprüft werden. Eine rechtliche Bewertung ist an dieser Stelle nicht möglich und auch nicht beabsichtigt.

Für wen sich der Wechsel lohnt und was zuerst zu prüfen ist

Der stärkste Fall für LEANN ist ein einzelner Nutzer mit einem großen, unstrukturierten persönlichen Korpus auf einem Gerät, das ohnehin schon mit einem lokalen Modell arbeitet. Dort fällt die zusätzliche Rechenlast für Embeddings kaum ins Gewicht, weil das Modell ohnehin geladen ist, und der eingesparte Speicher entscheidet darüber, ob der Korpus überhaupt auf das Gerät passt. Der zweite plausible Fall ist die Anbindung an einen Coding-Agenten über MCP, weil das README dafür einen konkreten Vergleich mit BM25 und einen Reproduktionspfad unter benchmarks/contextbench/README.md nennt. Weniger geeignet ist LEANN für Mehrbenutzerdienste mit hoher Abfragelast und für Umgebungen, in denen ein entferntes Embedding-Modell vorgeschrieben ist, weil dann die Zusage der lokalen Verarbeitung nicht mehr trägt. Vor dem ersten produktiven Index sollte man drei Dinge klären: ob die eigene Plattform in der README-Liste steht, ob das gewählte Embedding-Modell ohne Netzwerkzugriff läuft, und wie sich die Abfragelatenz auf der Zielhardware verhält, denn dazu liefert das Repository keine Zahl. Ohne diese drei Messungen bleibt die Speicherersparnis eine Zusage auf Papier.

Redaktionelles Fazit

Wer eine lokale, offline betriebene RAG-Schicht für persönliche Dateien, Mailarchive oder Coding-Agenten sucht und bereit ist, Rechenzeit gegen Speicherplatz zu tauschen, findet in LEANN einen MIT-lizenzierten Kandidaten mit reproduzierbaren Benchmarks im Repository. Wer einen dauerhaft niedrig ausgelasteten Server mit vielen gleichzeitigen Abfragen betreibt oder dessen Daten bereits vollständig in einem bestehenden Vektorspeicher liegen, sollte den Wechsel nicht ohne Messung angehen, weil LEANN die Einsparung an anderer Stelle mit Rechenzeit bezahlt. Vor der Adoption ist zu prüfen, ob die Zielplattform in der Liste Ubuntu, Arch, WSL, macOS ARM64 oder Intel und Windows enthalten ist, welche Python-Version zwischen 3.10 und 3.14 im Einsatz ist und ob das verwendete Embedding-Modell lokal ausführbar ist, denn ohne lokales Modell entfällt die Zusage der Datenhoheit.

Offizielle Quellen

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