Anpassung von HNSW-Indizes und Skalierung der Vektorabfrage für produktive RAG-Anwendungen

Ein Prototyp für Retrieval-augmented Generation (RAG) mit einigen tausend Vektoren antwortet sofort auf nahezu jeder Plattform. Wenn die Menge an Daten auf Millionen anwächst, überwiegen Verzögerungen und Ressourcenverbrauch, und die Konfiguration des Indexes wird zu einem Problem in der Produktivumgebung. Dieser Leitfaden behandelt die beiden wichtigsten HNSW-Parameter, wie man sie in Chroma einstellt, sowie wann eine weitere Anpassung nicht mehr ausreicht und das System skaliert werden muss.

Die beiden HNSW-Parameter, die fast alles bestimmen

Man benötigt nicht die gesamte Theorie der HNSW-(Hierarchical Navigable Small World)-Graphen, um diese zu optimieren. Der Index verknüpft jeden Vektor mit benachbarten Vektoren in mehreren Ebenen, und eine Abfrage durchläuft diesen Graphen in Richtung ihrer nächsten Nachbarn. Zwei Parameter bestimmen diese Struktur des Graphen sowie den Ablauf der Abfrage. Weitere Informationen finden Sie in unserer Erklärung zu wie Vektordatenbanken funktionieren, von Embeddings bis hin zu hybriden Suchverfahren.

M: maximale Verbindungen pro Knoten

M legt die maximale Anzahl an Nachbarnverbindungen fest, die jeder Knoten im Graphen besitzt.

• Niedriges M: weniger Verbindungen, ein kleinerer Index, weniger Speicher und schnellere Durchsuchung – doch geringerer Recall, da die Suche über weniger Wege zu guten Kandidaten verfügt.

Hoch M: mehr Verknüpfungen pro Knoten, mehr Speicher, ein größeres Index und eine langsamere Erstellung. Die Abfragen werden etwas langsamer, doch die Treffgenauigkeit verbessert sich, da das Graph mehr Wege zu den tatsächlich nächstgelegenen Nachbarn anbietet.

M wird bei der Erstellung des Index festgelegt, daher bedeutet eine spätere Änderung eine Neuerrichtung des Index.

ef: Wie intensiv jede Suche vorgeht

ef steuert, wie viele Kandidaten der Index während der Suche nach den nächstgelegenen Nachbarn einer Abfrage berücksichtigt.

• Niedrig ef: Es werden weniger Kandidaten überprüft, wodurch die Abrufgeschwindigkeit hoch ist, aber relevante Dokumente könnten übersehen werden und die Genauigkeit sinkt.
• Hoch ef: Es werden mehr Kandidaten überprüft, wodurch die Abrufgeschwindigkeit niedriger ist, aber die Ergebnismenge kommt viel näher an die exakt nächstgelegenen Nachbarn heran.

Viele Engines teilen dies in einen Wert zur Konstruktionszeit auf, der bestimmt, wie sorgfältig das Graph erstellt wird, und einen Wert zur Suchzeit, den man in der Regel ohne Neukonstruktion ändern kann – wodurch er das günstigste Element zum Ausprobieren darstellt.

Ausgleich von Genauigkeit, Geschwindigkeit und Speicher

Die Anpassung von HNSW bedeutet einen dreifachen Kompromiss zwischen Genauigkeit, Geschwindigkeit und Speicher. Diese Kombinationen bilden sinnvolle Ausgangspunkte für typische Projektphasen, wobei ef den Wert zur Suchzeit bezeichnet:

+----------------+----+-----+----------+
| Use Case       | M  | ef  | Priority |
+----------------+----+-----+----------+
| Prototype      | 16 | 40  | Speed    |
| Production     | 16 | 100 | Balanced |
| High accuracy  | 32 | 200 | Accuracy |
+----------------+----+-----+----------+

Betrachten Sie sie als Referenzwerte zum Vergleichen: Messen Sie die Trefferquote und Latenz bei repräsentativen Abfragen vor und nach jeder Änderung.

Einstellen der HNSW-Parameter in Chroma

Jede Vektor-Datenbank stellt diese Einstellungen auf unterschiedliche Weise zur Verfügung. In Chroma können sie als Metadaten der Sammlung beim Erstellen dieser übergeben werden. Das folgende Beispiel setzt M auf 16, den ef-Wert zur Erstellung der Sammlung auf 100 und den ef-Wert zur Suche auf 50:

#Chroma-HNSW Settings
collection=client.create_collection(
name='new_collection',
metadata={
'hnsw:M':16,
'hnsw:construction_ef': 100,
'hnsw:search_ef': 50
}
)

Der Metadaten-Schlüssel-Format kann in neueren Chroma-Versionen abweichen, da dort auch ein spezielles Konfigurationsobjekt angeboten wird. Prüfen Sie daher die aktuelle Dokumentation für Ihre Version. Setzen Sie M sowie den ef-Wert zur Erstellung der Sammlung vor dem Einlesen von Daten, da diese in das Graphen integriert werden.

Wenn Feinabstimmungen nicht mehr ausreichen

Auch ein gut abgestimmter Index erreicht letztendlich eine Obergrenze. Wenn die Abfrage regelmäßig 100 ms oder länger dauert, liegt eine häufige Ursache darin, dass der Index nicht mehr bequem in den Speicher passt, und weitere Anpassungen der Parameter werden das Problem nicht lösen. Eine grobe Schätzung hilft: Die Speicherkapazität für Rohvektoren beträgt die Anzahl der Vektoren mal ihre Dimensionen mal 4 Bytes für 32-Bit-Flottenzahlen, und das HNSW-Graph fügt eine Overhead-Komponente hinzu, die mit M zunimmt. In diesem Fall ist Skalierung erforderlich, die in zwei Formen auftreten kann.

Vertikale Skalierung

Für Sammlungen mit etwa 5 bis 10 Millionen Vektoren ist es in der Regel der erste Schritt, dem vorhandenen Rechner mehr RAM oder CPU hinzuzufügen. Mit ausreichendem Speicher passt der gesamte Index in den RAM, was eine schnelle Abfrage wieder ermöglicht und die Gesamtleistung verbessert.

Die vertikale Skalierung erfordert keine architektonischen oder kodischen Änderungen, doch eine einzelne Maschine hat eine Speichergrenze, und größere Instanzen werden schnell teuer.

Horizontale Skalierung

Zurückgeblieben bei etwa 10 Millionen Vektoren wird die horizontale Skalierung zur praktischen Option. Die Sammlung wird in Teile aufgeteilt, wodurch die Daten über mehrere Instanzen verteilt werden und jeder Teil seine eigene Datensammlung speichert und durchsucht.

Dadurch entfällt die Grenze der einzelnen Maschine. Der Preis dafür ist die Komplexität: Jede Abfrage wird an die verschiedenen Teile verteilt, und ihre teilweisen Ergebnisse müssen zu einer einzigen gerankten Liste zusammengeführt werden, was zu Verzögerungen und zusätzlicher Arbeitslast führt.

Kernpunkte

• M prägt das Diagramm: Höhere Werte erhöhen die Trefferquote und den Speicherverbrauch, und eine Änderung erfordert einen Neubau.
• ef prägt die Suche: Die Erhöhung des Suchzeitwerts ist der günstigste Weg, um Verzögerungen zugunsten einer höheren Trefferquote zu kompensieren.

Beginnen Sie mit einer ausgewogenen Konfiguration wie M 16 mit einer Suchfunktion ef von 100 und messen Sie anschließend die Leistung mit Ihren eigenen Abfragen.

Die meisten Produktions-RAG-Systeme kommen mit Indexanpassungen sowie vertikaler Skalierung aus; Sharding ist zwar mächtig, wird aber selten benötigt – reservieren Sie es daher für Sammlungen, die tatsächlich eine einzelne Maschine übersteigen.