Jak wyszukiwanie HNSW wymienia pamięć na wyższy poziom odtwarzania wyników w lokalnej bazie danych wektorowych?

HNSW wymienia pamięć na trafność, przechowując nawigowalny graf sąsiedztwa, którego spójność i zakres wyszukiwania określają, jak dokładnie zapytania badają pobliskie wektory.

Lokalna baza danych wektorowych może przechowywać osadzenia dokumentów domowych, tekst OCR, metadane zdjęć, instrukcje, transkrypcje i dane aplikacji. Wyszukiwanie metodą brute force porównuje zapytanie z każdym wektorem, podczas gdy HNSW próbuje dotrzeć do tego samego użytecznego sąsiedztwa, przechodząc przez warstwowy graf. Ten skrót jest szybki, ponieważ baza danych przechowuje wcześniej dodatkową strukturę grafu, a jego dokładność zależy od tego, jak gęsto graf jest połączony i jak wielu kandydatów zapytanie może zbadać.

HNSW dodaje warstwowy graf bliskości wokół przechowywanych wektorów

Każdy wektor staje się węzłem połączonym z wybranymi sąsiadami. Niewielki podzbiór węzłów pojawia się również w wyższych warstwach, tworząc trasy dalekiego zasięgu, które pomagają szybko przenieść wyszukiwanie do obszaru, w którym prawdopodobnie znajdują się bliskie wektory.

Wielowarstwowy graf bliskości zapewnia HNSW zgrubne trasy w górnych warstwach i coraz dokładniejszą nawigację po sąsiadach bliżej dołu hierarchii.

Te przechowywane krawędzie stanowią pierwszy kompromis pamięciowy. W przeciwieństwie do płaskiej tablicy wektorów indeks przechowuje topologię, która musi być dostępna podczas przechodzenia przez graf.

Hierarchia ogranicza ilość kolekcji odwiedzanej przez typowe zapytanie, ale metoda jest przybliżona: ścieżka może pominąć prawdziwego sąsiada, gdy graf lub budżet wyszukiwania nie udostępnia właściwej trasy.

Parametr M zużywa więcej pamięci grafu, aby tworzyć więcej tras

Implementacje HNSW udostępniają parametr spójności, powszechnie nazywany `m` lub `M`. Zwiększenie jego wartości pozwala węzłom utrzymywać więcej połączeń z sąsiadami, tworząc alternatywne ścieżki przez gęste lub nieregularne obszary przestrzeni wektorowej.

Wyższa wartość HNSW m przechowuje więcej połączeń z sąsiadami dla każdego węzła, zazwyczaj poprawiając możliwości nawigacji i trafność, ale zwiększając zużycie pamięci przez graf oraz nakład pracy potrzebny do jego zbudowania.

Wzrost zużycia pamięci wynika z krawędzi grafu i powiązanych struktur indeksu, a nie z powiększenia oryginalnych wartości osadzeń. Przy milionach wektorów kilka dodatkowych połączeń na węzeł sumuje się w całej kolekcji. Zmniejszenie `m` może poprawić komfort pracy domowego serwera z ograniczoną pamięcią, ale zbyt rzadki graf daje wyszukiwaniu mniej możliwości ominięcia lokalnych ślepych zaułków i może obniżyć trafność.

Budowanie Ef wykorzystuje więcej pracy, aby poprawić sam graf

Na jakość grafu wpływa również sposób dodawania wektorów. `ef_construct` określa, jak szerokie sąsiedztwo kandydatów analizuje konstruktor przed wybraniem połączeń dla nowego węzła.

Użycie efConstruction jako parametru jakości budowania pozwala konstruktorowi indeksu analizować szersze sąsiedztwo kandydatów przed wybraniem krawędzi, poprawiając jakość grafu kosztem większego nakładu pracy podczas budowania.

Ten koszt jest ponoszony podczas budowania lub przebudowy, a nie przy każdym zapytaniu. W przypadku prywatnego zbioru danych, który zmienia się powoli, większy czas budowania może być akceptowalny, jeśli poprawia jakość wyszukiwania bez trwałego zwiększania precyzji wektorów.

Jednak nakład pracy podczas budowania nie może bez końca kompensować zbyt małego grafu. `m`, szerokość budowania, rozkład danych i historia dodawania wektorów wzajemnie na siebie wpływają.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Wyszukiwanie Ef wykorzystuje zasoby zapytania zamiast stałej pamięci grafu

W czasie zapytania HNSW utrzymuje zbiór kandydatów i odwiedza obiecujące węzły grafu. Parametr powszechnie nazywany `ef`, `ef_search` lub `hnsw_ef` określa, ilu kandydatów pozostaje branych pod uwagę podczas tego przechodzenia.

Zwiększenie szerokości eksploracji zapytania pozwala żądaniu sprawdzić więcej kandydatów grafu przed wybraniem najbliższych wyników, zazwyczaj zwiększając trafność, ale także opóźnienie zapytania.

W przeciwieństwie do `m` większa wartość `ef` zapytania nie wymaga, aby każdy przechowywany węzeł utrzymywał więcej trwałych krawędzi. Głównym kosztem są dodatkowe obliczenia odległości, dostępy do pamięci i opóźnienie tego żądania. To rozróżnienie daje domowemu serwerowi dwa różne pokrętła: spójność grafu określa stały rozmiar indeksu w pamięci, natomiast szerokość zapytania można zwiększać tylko dla trudnych wyszukiwań, które uzasadniają dodatkową pracę.

Kompresja wektorów nie usuwa kosztu grafu HNSW

Kwantyzacja osadzeń może znacznie zmniejszyć rozmiar każdego przechowywanego wektora, ale HNSW nadal potrzebuje relacji między sąsiadami. Cały indeks zawiera więc co najmniej dwa główne składniki pamięci: dane wektorowe i topologię grafu.

Nawet gdy wartości wektorów są skompresowane, kwantyzacja nie zmniejsza połączeń grafu; HNSW nadal potrzebuje topologii, identyfikatorów i powiązanych struktur wokół tych wektorów.

Dlatego współczynnik kompresji wektorów 4x lub większy nie oznacza automatycznie podobnego ogólnego zmniejszenia zużycia pamięci przez HNSW. Krawędzie grafu, identyfikatory obiektów, metadane, narzut alokatora i pamięci podręczne pozostają.

Na małym domowym serwerze mierz pełny rezydentny rozmiar kolekcji, zamiast szacować pamięć RAM wyłącznie na podstawie wymiarów wektorów.

Trafność należy mierzyć względem dokładnych sąsiadów, a nie wywnioskowywać z ustawień

Wyższe wartości `m` i `ef` zazwyczaj przesuwają system w kierunku lepszej trafności, ale żadna wartość parametru nie gwarantuje stałej dokładności dla każdego modelu osadzeń, rozmiaru zbioru danych czy rozkładu dokumentów.

Koszt pamięci grafu HNSW w wielu kolekcjach RAG kumuluje się, gdy kilka prywatnych kolekcji pozostaje aktywnych obok modeli lokalnych, indeksów metadanych, pamięci podręcznych i innych usług domowego serwera.

Utwórz reprezentatywny zestaw zapytań i porównaj przybliżone wyniki z dokładnym skanowaniem na próbce o rozsądnym rozmiarze. Śledź trafność, opóźnienie, pamięć RAM indeksu, czas budowania oraz wpływ równoczesnych żądań. Praktyczny kompromis HNSW nie polega więc na tym, że „więcej pamięci RAM zawsze oznacza lepsze wyszukiwanie”. Chodzi o dobranie wystarczającej spójności grafu i zakresu eksploracji zapytań, aby osiągnąć zmierzoną trafność bez wypierania pozostałych elementów domowego stosu AI.