Wie tauscht die HNSW-Suche in einer lokalen Vektordatenbank Speicher gegen Trefferquote ein?

HNSW tauscht Arbeitsspeicher gegen Trefferquote, indem ein navigierbarer Nachbarschaftsgraph gespeichert wird, dessen Konnektivität und Suchtiefe bestimmen, wie gründlich Abfragen nahegelegene Vektoren durchsuchen.

Eine lokale Vektordatenbank kann Embeddings für Haushaltsdokumente, OCR-Texte, Fotometadaten, Handbücher, Transkripte und Anwendungsdaten speichern. Bei einer Brute-Force-Suche wird die Abfrage mit jedem Vektor verglichen, während HNSW versucht, durch das Durchlaufen eines mehrschichtigen Graphen dieselbe relevante Nachbarschaft zu erreichen. Dieser Abkürzungsweg ist schnell, weil die Datenbank die zusätzliche Graphstruktur im Voraus speichert. Die Genauigkeit hängt davon ab, wie stark dieser Graph vernetzt ist und wie viele Kandidaten eine Abfrage durchsuchen darf.

HNSW ergänzt die gespeicherten Vektoren um einen mehrschichtigen Näherungsgraphen

Jeder Vektor wird zu einem Knoten, der mit ausgewählten Nachbarn verbunden ist. Eine kleine Teilmenge der Knoten erscheint außerdem in höheren Ebenen und bildet weitreichende Routen, über die sich die Suche schnell in die Region bewegen kann, in der wahrscheinlich nahe Vektoren liegen.

Ein mehrschichtiger Näherungsgraph bietet HNSW grobe Routen in den oberen Ebenen und eine zunehmend feinere Navigation zwischen Nachbarn nahe der untersten Hierarchieebene.

Diese gespeicherten Kanten sind der erste Kompromiss beim Arbeitsspeicher. Anders als ein flaches Vektorarray speichert der Index eine Topologie, die während des Durchlaufens verfügbar bleiben muss.

Die Hierarchie verringert, wie viel der Sammlung eine normale Abfrage besucht, ist aber nur näherungsweise: Der Pfad kann einen tatsächlichen Nachbarn verfehlen, wenn der Graph oder das Suchbudget den passenden Weg nicht zugänglich macht.

Der M-Parameter benötigt mehr Graphspeicher, um mehr Routen zu erzeugen

HNSW-Implementierungen bieten einen Konnektivitätsparameter, der üblicherweise `m` oder `M` genannt wird. Wird er erhöht, können Knoten mehr Nachbarschaftsverbindungen aufrechterhalten. Dadurch entstehen alternative Wege durch dichte oder unregelmäßige Bereiche des Vektorraums.

Ein höherer HNSW-m-Wert speichert mehr Nachbarschaftsverbindungen pro Knoten. Das verbessert typischerweise die Navigationsmöglichkeiten und die Trefferquote, erhöht aber den Graphspeicherbedarf und den Konstruktionsaufwand.

Der zusätzliche Speicherbedarf entsteht durch Graphkanten und zugehörige Indexstrukturen, nicht dadurch, dass die ursprünglichen Embedding-Werte größer werden. Bei Millionen von Vektoren summieren sich einige zusätzliche Verbindungen pro Knoten über die gesamte Sammlung. Ein niedrigerer `m` kann einen Arbeitsspeicher-beschränkten Heimserver entlasten. Ein zu dünn besetzter Graph bietet der Suche jedoch weniger Möglichkeiten, lokale Sackgassen zu umgehen, und kann die Trefferquote verringern.

Die Ef-Konstruktion erfordert mehr Erstellungsaufwand, um den Graphen selbst zu verbessern

Die Graphqualität wird auch beim Einfügen der Vektoren beeinflusst. `ef_construct` legt fest, wie groß die Kandidatennachbarschaft ist, die der Ersteller prüft, bevor er Verbindungen für einen neuen Knoten auswählt.

Mit efConstruction als Stellgröße für die Erstellungsqualität kann die Indexkonstruktion eine größere Kandidatennachbarschaft prüfen, bevor sie Kanten auswählt. Das verbessert die Graphqualität, erfordert aber mehr Arbeit beim Erstellen.

Diese Kosten fallen bei der Konstruktion oder Neuerstellung an und nicht bei jeder Abfrage. Bei einem privaten Datenbestand, der sich nur langsam verändert, kann ein längerer Erstellungsprozess akzeptabel sein, wenn er die Suchqualität verbessert, ohne die Vektorpräzision dauerhaft zu erhöhen.

Ein hoher Erstellungsaufwand kann einen stark zu klein dimensionierten Graphen jedoch nicht unbegrenzt ausgleichen. `m`, die Breite der Konstruktion, die Datenverteilung und die Einfügereihenfolge beeinflussen sich gegenseitig.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ef Search erhöht den Abfrageaufwand statt den permanenten Graphspeicher

Zur Abfragezeit verwaltet HNSW eine Kandidatenfront und durchsucht vielversprechende Graphknoten. Ein Parameter, der üblicherweise `ef`, `ef_search` oder `hnsw_ef` genannt wird, legt fest, wie viele Kandidaten während dieses Durchlaufs weiter berücksichtigt werden.

Eine größere Breite der Abfrageerkundung ermöglicht es einer Anfrage, mehr Graphkandidaten zu prüfen, bevor sie die nächstgelegenen Ergebnisse festlegt. Dadurch steigt die Trefferquote meist, während auch die Abfragelatenz zunimmt.

Anders als bei `m` müssen bei einem größeren Abfrage-`ef` nicht alle gespeicherten Knoten dauerhaft mehr Kanten enthalten. Die Hauptkosten entstehen durch zusätzliche Distanzberechnungen, Speicherzugriffe und Latenz für diese Anfrage. Dadurch stehen einem Heimserver zwei verschiedene Stellschrauben zur Verfügung: Die Graphkonnektivität bestimmt den dauerhaften Speicherbedarf des Index, während die Abfragebreite nur für schwierige Suchen erhöht werden kann, bei denen sich der zusätzliche Aufwand lohnt.

Vektorkomprimierung beseitigt die Kosten des HNSW-Graphen nicht

Durch die Quantisierung von Embeddings kann jeder gespeicherte Vektor deutlich kleiner werden, HNSW benötigt jedoch weiterhin seine Nachbarschaftsbeziehungen. Der gesamte Index enthält daher mindestens zwei große Speicherkomponenten: Vektordaten und Graph­topologie.

Auch wenn Vektorwerte komprimiert sind, verkleinert die Quantisierung die Graphverbindungen nicht; HNSW benötigt weiterhin Topologie, IDs und zugehörige Strukturen rund um diese Vektoren.

Deshalb führt ein 4-faches oder noch höheres Komprimierungsverhältnis der Vektoren nicht automatisch zu einer entsprechend großen Verringerung des gesamten HNSW-Speicherbedarfs. Graphkanten, Objekt-IDs, Metadaten, Allocator-Overhead und Caches bleiben bestehen.

Auf einem kleinen Heimserver sollte der gesamte residente Speicherbedarf der Sammlung gemessen werden, statt den RAM-Bedarf allein anhand der Vektordimensionen zu schätzen.

Die Trefferquote sollte anhand exakter Nachbarn gemessen und nicht aus den Einstellungen abgeleitet werden

Ein höheres `m` und `ef` führen das System normalerweise zu einer besseren Trefferquote, doch kein Parameterwert garantiert für jedes Embedding-Modell, jede Korpusgröße oder jede Dokumentverteilung eine bestimmte Genauigkeit.

Die Kosten des HNSW-Graphspeichers in mehreren RAG-Sammlungen summieren sich, wenn mehrere private Sammlungen neben lokalen Modellen, Metadatenindizes, Caches und anderen Heimserverdiensten aktiv bleiben.

Erstelle einen repräsentativen Abfragesatz und vergleiche die Näherungsergebnisse mit einem exakten Scan einer überschaubaren Stichprobe. Verfolge Trefferquote, Latenz, Index-RAM, Erstellungszeit und die Auswirkungen gleichzeitiger Anfragen. Der praktische HNSW-Kompromiss lautet daher nicht „mehr RAM bedeutet immer bessere Suche“. Entscheidend ist, ausreichend Graphkonnektivität und Abfrageerkundung zu wählen, um die gemessene Trefferquote zu erreichen, ohne den übrigen Heim-KI-Stack zu verdrängen.