LEANN z Berkeley: indeks wektorowy, który zamiast przechowywać embeddingi, liczy je na żądanie

Indeksy wektorowe potrafią zajmować więcej miejsca niż dane, które indeksują, co utrudnia ich wdrażanie na urządzeniach osobistych. Zespół Sky Computing Lab z UC Berkeley proponuje na to LEANN: indeks, który prawie nie przechowuje embeddingów, a wylicza je ponownie podczas zapytania. Według benchmarku w repozytorium LEANN indeks 60 mln fragmentów Wikipedii zmniejsza się z 201 GB do 6 GB. Praca opisująca LEANN trafiła do programu konferencji MLSys 2026, a według Marktechpost zdobyła nagrodę Best Research Paper.

Jak to działa

Autorzy w artykule naukowym pokazują skalę problemu. Korpus o rozmiarze 76 GB wymaga 173 GB embeddingów i 15 GB grafu HNSW, czyli ponad dwukrotnie więcej niż surowe dane. W opisie posteru MLSys piszą, że rozmiar takich indeksów może być wielokrotnie większy od oryginalnych danych, co utrudnia ich wdrażanie na urządzeniach osobistych.

LEANN trzyma przycięty graf oraz kompaktową tablicę kwantyzacji produktowej (PQ). Ponieważ graf typu HNSW odwiedza przy zapytaniu tylko niewielki zbiór węzłów, embeddingi są liczone wyłącznie dla tych na ścieżce wyszukiwania. Trzy techniki mają to uczynić praktycznym:

• wyszukiwanie dwupoziomowe – tanie odległości PQ wstępnie porządkują sąsiadów, a dokładne przeliczenie dostają tylko najlepsi kandydaci;
• dynamiczne batchowanie – kandydaci z kilku kroków są grupowani (np. po 64), by lepiej wykorzystać GPU;
• przycinanie z zachowaniem węzłów o wysokim stopniu – większość węzłów zachowuje niewiele krawędzi, a górne 2% „hubów” zatrzymuje ich więcej.

W testach ablacyjnych wyszukiwanie dwupoziomowe daje średnio 1,4-krotne przyspieszenie, a z batchowaniem 1,8-krotne. Mimo to ponowne liczenie embeddingów odpowiada nadal za ok. 76% opóźnienia zapytania.

Cena za oszczędność miejsca

Wszystkie poniższe liczby pochodzą z samego artykułu i nie zostały niezależnie zweryfikowane. Przy 90% recall@3 na pytaniach NQ, z modelem Qwen3-4B na RTX 4090, LEANN i HNSW osiągają tę samą dokładność końcową: 25,5%. LEANN potrzebuje do tego 4 GB, HNSW 188 GB. BM25 daje 18,3%, a kompresja PQ 17,9%. PQ zajmuje 20 GB.

Koszt to czas. Samo wyszukiwanie na NQ trwa 2,48 s zamiast 0,05 s u HNSW. Ponieważ generowanie odpowiedzi zajmuje ok. 20 s, całość rośnie z 20,95 s do 23,34 s. Dla różnych zbiorów danych na RTX 4090 retrieval w LEANN mieści się między 1,12 s (GPQA) a 7,12 s (HotpotQA). Na Macu z M1 Ultra HotpotQA to już 44,80 s, czyli 50,1% czasu całego potoku. Wariant IVF z rekomputacją, wzorowany na EdgeRAG, jest według autorów do 200 razy wolniejszy. Z kolei HNSW nie mieści się w stacji roboczej z 32 GB RAM, co LEANN omija.

Opublikowano też oszczędności na danych osobistych. Według repozytorium 400 tys. wiadomości z czatów kurczy się z 1,8 GB do 64 MB, a 38 tys. wpisów z przeglądarki ze 130 MB do 6,4 MB. Autorzy deklarują, że indeks zajmuje około 5% oryginalnych danych.

Zastosowania i licencja

Kod jest na licencji MIT, a repozytorium zawiera gotowe aplikacje do dokumentów, Apple Mail, historii Chrome, WeChata, iMessage oraz eksportów z ChatGPT i Claude’a. Czytniki MCP pobierają dane ze Slacka i zakładek z Twittera. LEANN działa też jako serwer MCP do wyszukiwania semantycznego dla Claude Code. Na 30 zadaniach SWE-Bench Pro z ContextBench zespół podaje, że na początkowym etapie wyszukiwania odnaleziono 24,2% istotnego kodu wobec 11,4% dla BM25, przy 8,4% mniejszym zużyciu tokenów.

Domyślnym backendem jest HNSW, a DiskANN służy do szybszego wyszukiwania. Domyślny embedder to Contriever (110 mln parametrów). Generowanie odpowiedzi współpracuje z Ollamą, Hugging Face, Anthropikiem i API zgodnymi z OpenAI. Obsługiwane są Ubuntu, Arch, WSL, macOS i Windows, choć część aplikacji, jak wyszukiwanie w Apple Mail, działa tylko na macOS. Istnieje instalacja wyłącznie na CPU, ale nie opublikowano wyników opóźnień dla takiej konfiguracji.