RAG op je laptop: 60 miljoen documenten in 6GB — hoe LEANN vectoropslag herdefinieert

Wie ooit een vector database heeft opgezet voor retrieval-augmented generation kent het moment: je hebt 2 miljoen documenten, de embeddings zijn gegenereerd, en dan zie je de opslag. 173 GB aan vectoren. Voor 60 miljoen chunks. Bovenop de 76 GB aan ruwe tekst. Je laptop hapt naar adem, je cloud-budget explodeert, en de CIO vraagt of dit echt nodig is.

Het antwoord is: nee. Het is niet nodig.

Een team van Berkeley's Sky Computing Lab, de groep achter Spark en Ray, heeft met LEANN een vectorindex gebouwd die het opslagprobleem op een radicaal andere manier aanpakt. In plaats van élke embedding op te slaan, slaat LEANN alleen een gesnoeide graafstructuur op en herberekent het embeddings alleen voor de nodes die tijdens een zoekopdracht bezocht worden. Het resultaat: 60 miljoen text chunks in 6 GB in plaats van 201 GB. Zelfde recall. Zelfde downstream RAG-accuracy. En alles draait lokaal.

Wat LEANN technisch doet

Traditionele vector-databases zoals FAISS-HNSW slaan twee dingen op: de embeddings zelf (173 GB voor 60M 768-dimensionale vectoren) en de graafmetadata die het zoeken efficiënt maakt (15 GB). Samen meer dan het dubbele van de ruwe data.

LEANN gooit beide componenten drastisch overboord via twee technieken:

Embedding-recomputation. Een HNSW-graaf bezoekt per zoekopdracht maar ongeveer O(log N) nodes. Een fractie van het totaal. LEANN herberekent embeddings alleen voor díe nodes, op het moment van de query. De embeddings worden nooit opgeslagen. Om te voorkomen dat je 60 miljoen keer een embedding-model moet draaien, gebruikt LEANN een two-level search: eerst een extreem gecomprimeerde approximate distance via product quantization (100× kleiner dan FP32), daarna exacte recomputation alleen voor de top-kandidaten. Dynamic batching groepeert recomputations over meerdere search-hops voor GPU-efficiëntie.

High-degree preserving graph pruning. Niet alle nodes in de graaf zijn even belangrijk. Een klein percentage hoog-verbonden "hub"-nodes wordt disproportioneel vaak bezocht tijdens searches. LEANN snoeit de edges van laag-verbonden nodes maar behoudt de hub-nodes intact. Dit halveert de graafopslag zonder meetbaar accuracy-verlies. Random pruning of generieke degree-limieten halen hetzelfde opslagvoordeel niet. Die verliezen tot 5.8× meer nodes om dezelfde recall te halen.

Het paper is gepubliceerd op MLsys2026, 17 pagina's, met evaluatie op vier QA-benchmarks (NQ, TriviaQA, GPQA, HotpotQA) plus FinanceBench, Enron Email, en LAION image retrieval. De code is MIT-gelicenseerd en staat op GitHub met 11.900 sterren.

De cijfers die ertoe doen

De opslagvergelijking op de RPJ-Wiki dataset (76 GB ruwe tekst, 60 miljoen chunks):

Methode	Opslag	Recall@3	Retrieval latency	RAG accuracy (EM)
HNSW (FAISS)	188 GB	90%	0.05s	25.5%
DiskANN	270 GB	90%	0.03s	,
PQ-compressie	20 GB	＜90%	,	17.9%
BM25 (keyword)	59 GB	＜90%	0.03s	18.3%
LEANN	4 GB	90%	2.48s	25.5%

De retrieval latency is hoger: 2.48 seconden tegenover 0.05 voor HNSW. Maar in een RAG-pipeline domineert LLM-generatie de totale tijd: 20 tot 70 seconden voor een Qwen3-4B model op een RTX 4090. LEANN voegt minder dan 15% overhead toe aan de end-to-end latency. Op GPQA, een graduate-level QA-benchmark waar het model 70 seconden nodig heeft voor chain-of-thought reasoning, is de overhead onder de 3%.

Voor persoonlijke datasets wordt het plaatje nog scherper:

Dataset	Chunks	LEANN	HNSW	Besparing
Email (780K)	780.000	79 MB	2,4 GB	97%
Chat (400K)	400.000	64 MB	1,8 GB	97%
Browser history (38K)	38.000	6,4 MB	130 MB	95%

Je volledige emailgeschiedenis in 79 MB. Je browserhistory in 6,4 MB. Dit zijn geen theoretische benchmarks. De LEANN repo bevat werkende apps voor Apple Mail, Chrome history, WeChat, ChatGPT exports, Claude exports, iMessage, Slack (via MCP), en Twitter bookmarks.

Waarom dit ertoe doet voor sovereign AI

Het dominante narratief in enterprise AI is: grootschalige RAG vereist cloud-infrastructuur. Je hebt nun eenmaal 200 GB aan embeddings, die passen niet op een laptop, dus je data moet naar een vector-database in de cloud. En daarmee verlaat je data het gebouw.

LEANN doorbreekt dit narratief op het technische niveau. Het is geen "lightweight alternatief" dat accuracy inlevert voor draagbaarheid. Het is een peer-reviewed MLsys-publicatie van een Berkeley-team met Ion Stoica, Matei Zaharia en Joseph Gonzalez als co-auteurs. De mensen die de distributed systems-bouwstenen hebben gemaakt waar de halve industrie op draait. De boodschap is: 60 miljoen documenten passen op je laptop. De accuracy is identiek. De latency is acceptabel. Cloud is een keuze, geen noodzaak.

Voor organisaties die onder BIO2, NIS2 of AVG vallen is dit een technisch argument met juridische consequenties. Als grootschalige RAG technisch mogelijk is zonder data-exfiltratie, wordt "we moeten wel naar de cloud" een architectuurkeuze, geen technische noodzaak. En architectuurkeuzes moet je kunnen verantwoorden in een DPIA.

De BIO2-compliance vraag

LEANN's "RAG on Everything" apps zijn ontworpen voor persoonlijke productiviteit. Email, browser history, Slack, ChatGPT-geschiedenis. Indexeer alles, doorzoek alles, lokaal. Maar er is een spanning die het paper niet adresseert.

Als een ambtenaar LEANN op zijn overheidslaptop draait en zijn dienst-email indexeert, bouwt hij een doorzoekbare vector-database van potentieel gerubriceerde informatie. BIO2 zegt: data moet geclassificeerd en beschermd zijn. LEANN zegt: indexeer alles, het blijft lokaal.

"Lokaal" is geen classificatie. Een laptop in een trein is geen beveiligde omgeving. De tool is technisch indrukwekkend, maar de governance-laag ontbreekt. Wat je wél kunt doen:

• Databronnen whitelisten. Niet "indexeer alles" maar "indexeer documenten in directory X met classificatie Y". LEANN's metadata filtering ondersteunt dit: je kunt per chunk metadata meegeven en queries filteren op classificatieniveau.
• Embedding-modellen goedkeuren. Welke embedding-modellen mogen gebruikt worden voor welke data? Een goedgekeurde whitelist voorkomt dat gevoelige tekst door een onbekend model gaat.
• MCP-integraties sandboxen. Slack- en Twitter-MCP-servers injecteren externe content in je index. Die content moet gevalideerd worden vóór indexering.

Dit is geen kritiek op LEANN. Het is een tool, geen compliance-framework. Maar de combinatie van technische capaciteit (indexeer alles lokaal) en governance-gap (geen classificatiebewustzijn) maakt het een perfect voorbeeld van waarom sovereign AI meer is dan "draai het lokaal". Het is: draai het lokaal, met classificatie, met goedgekeurde modellen, met auditeerbare indexering.

De praktische kant

LEANN is verrassend eenvoudig te installeren:

uv tool install leann-core --with leann
leann build mijn-docs --docs ./documenten/
leann ask mijn-docs --interactive

Het ondersteunt PDF, TXT, MD, DOCX, PPTX, en code-bestanden met AST-aware chunking voor Python, Java, C#, en TypeScript. Er is een Claude Code MCP-integratie die de basic grep-style keyword search van Claude Code vervangt door semantische codebase-search, volledig lokaal. Er is ColQwen-integratie voor multimodale PDF-retrieval die zowel tekst als figuren en diagrammen begrijpt.

De embedding-modellen zijn configureerbaar: Contriever (110M parameters) voor maximale accuracy, GTE-small (33M) voor 2.3× snelheidswinst met minder dan 2% accuracy-verlies. De generatie-modellen ondersteunen Ollama, HuggingFace, Anthropic, en elke OpenAI-compatible API.

Wat me opviel tijdens het testen: de index bouwen voor een paar duizend documenten duurt seconden. De search is responsief. De CLI is clean. En het feit dat je geen API-key nodig hebt. Geen OpenAI, geen cloud, geen "terms of service", is verfrissend.

Wat dit betekent

LEANN is geen incremental improvement op bestaande vector-databases. Het is een architectonische herdefinitie van wat een vectorindex is. In plaats van "sla alle embeddings op en comprimeer ze" zegt het: "sla geen embeddings op, herbereken ze alleen wanneer nodig." Dat is een radicaal andere aanname.

De implicatie voor sovereign AI is helder: het technische argument dat grootschalige RAG cloud-infrastructuur vereist, is weerlegd. Niet door een startup-pitch, maar door een peer-reviewed paper van een top-onderzoeksgroep. De vraag verschuift van "kunnen we dit lokaal draaien?" naar "onder welke governance-voorwaarden doen we dat?"

Voor organisaties die lokale document-parsing al hebben ingericht, vormt LEANN de natuurlijke volgende laag: OmniParse parsed de documenten, LEANN indexeert ze, een lokaal model genereert de antwoorden. De hele RAG-pipeline draait binnen de organisatie. Geen data die het gebouw verlaat.

---

Gebaseerd op: Yichuan Wang, Zhifei Li, Shu Liu, Yongji Wu, Ziming Mao, Yilong Zhao, Xiao Yan, Zhiying Xu, Yang Zhou, Ion Stoica, Sewon Min, Matei Zaharia, Joseph E. Gonzalez (2025). "LEANN: A Low-Storage Vector Index" (PDF). MLsys2026. Berkeley Sky Computing Lab. Code: github.com/StarTrail-org/LEANN (MIT-license, 11.9K stars).