LEANN

Wer schon einmal versucht hat, Retrieval-Augmented Generation über die eigenen Dateien zu bauen, stößt schnell auf eine versteckte Steuer: den Vektorindex. Das Einbetten eines persönlichen Korpus aus E-Mails, PDFs, Chatverläufen und Quellcode erzeugt gigabyteweise dichte Vektoren, die auf der Festplatte liegen müssen und das Ausgangsmaterial oft weit übertreffen. Genau dieser Aufwand hält ernsthaftes, privates RAG auf dem eigenen Gerät für die meisten Laptops außer Reichweite. LEANN vom Team der StarTrail-org und dem Sky Computing Lab in Berkeley ist eine Python-Vektordatenbank, die diese Steuer abschaffen will. Sie versteht sich als RAG für alles, indexiert vielfältige persönliche Quellen lokal und ohne Telemetrie. Die zentrale Behauptung lautet rund 97% Speicherersparnis gegenüber einem klassischen Index wie FAISS, bei weiterhin konkurrenzfähiger Trefferqualität. Ob das für die eigenen Daten gilt, ist die Frage, die diese Analyse ehrlich einordnen will.

Die besondere Idee besteht darin, die meisten Embeddings gar nicht erst zu speichern. Statt für jeden Chunk einen Vektor abzulegen, hält LEANN einen beschnittenen Nachbarschaftsgraphen vor und berechnet Embeddings nur für jene Knoten neu, die die Suche während einer Anfrage tatsächlich besucht. Ein Pruning-Schritt erhält gut vernetzte Hub-Knoten und entfernt redundante Kanten, während dynamisches Batching und eine zweistufige Suche die Neuberechnung effizient halten. Das voreingestellte HNSW-Backend maximiert die Speicherersparnis durch Neuberechnung zur Suchzeit, ein optionales DiskANN-Backend tauscht einen Teil davon gegen Tempo, mittels Produktquantisierung und Reranking. Der Ansatz ist in einem begutachteten Paper für MLsys 2026 dokumentiert, LEANN: A Low-Storage Vector Index, was ein stärkeres Validitätssignal ist, als die meisten Open-Source-Projekte vorweisen können.

LEANN richtet sich an Entwickler und technische Anwender, die privates Retrieval über persönliche Daten wollen, ohne diese an einen Cloud-Dienst zu schicken oder die Speicherkosten eines vollen Vektorspeichers zu zahlen. Konkret indexierbare Quellen sind unter anderem PDFs, Markdown- und Office-Dokumente, Apple Mail, Chrome-Verlauf, WeChat, iMessage und Slack, exportierte ChatGPT- und Claude-Konversationen, Code-Repositories mit AST-bewusstem Chunking sowie alles, was über einen MCP-Server erreichbar ist. Es läuft als nativer MCP-Dienst und kann so als direkte semantische Suchschicht für Claude Code dienen, das sonst auf Keyword-Suche setzt. Embeddings können von lokalen Modellen über Ollama, LM Studio oder llama.cpp kommen oder von gehosteten Anbietern, mit getrennter Wahl für Embedding und Generierung. Der natürliche Einsatz ist eine persönliche Wissensbasis, die man zwischen Geräten mitnimmt.

Die Kompromisse sind real und vor der Einführung abzuwägen. Die Speicherersparnis wird in Rechenleistung zurückgezahlt: Jede Anfrage berechnet Embeddings für besuchte Knoten neu, weshalb das Retrieval langsamer ist als das Lesen vorberechneter Vektoren und auf eine leistungsfähige CPU oder GPU angewiesen ist. Das Projekt steht bei v0.x, was auf eine instabile API hindeutet, und jüngste Commits drehen sich eher um Fixes und CI als um neue Features, sodass das Tempo zu beobachten ist. Die Einrichtung ist nicht ohne: Sie hängt von kompilierten nativen Bibliotheken (libomp, Boost, Protobuf, ZeroMQ) und einem Embedding-Stack ab, was unter Linux freundlicher ausfällt als unter Windows. Mehrere Komfortfunktionen, etwa einige E-Mail- und Messaging-Konnektoren, sind macOS-zentriert, Windows-Unterstützung ist als kommend aufgeführt. Die starken Recall- und 97%-Werte sind die eigenen Benchmarks des Projekts, also am eigenen Korpus prüfen.

Gegenüber verwalteten Diensten wie Pinecone oder Weaviate spielt LEANN ein anderes Spiel. Diese Plattformen optimieren auf latenzarmes Retrieval im großen Maßstab mit operativer Reife, und sie speichern volle Vektoren auf einer Infrastruktur, für die man zahlt und der man seine Daten anvertraut. LEANN optimiert die Gegenecke: alles lokal halten, den Index winzig halten und die Neuberechnungslatenz als Preis akzeptieren. Für privates On-Device-RAG über E-Mails, Chatverläufe und Code, wo Speicher und Vertraulichkeit mehr wiegen als Millisekunden, ist es eine glaubwürdige und gut erforschte Wahl. Zu früh ist es dort, wo man latenzkritisches Produktions-Retrieval im großen Maßstab, Mehrbenutzerbetrieb oder eine stabile API für ein Produkt braucht. Für Tüftler und datenschutzbewusste Entwickler lohnt ein ernsthafter Test, für Produktionsteams gilt: die Reife beobachten.