---
title: Die Auswirkungen von HNSW auf die Degradation von Rag Systemen
canonical: https://kiagenturmagazin.de/die-auswirkungen-von-hnsw-auf-die-degradation-von-rag-systemen/
author: Provimedia GmbH
published: 2026-10-02
updated: 2026-10-02
language: de
category: Fehler & Herausforderungen
source: Provimedia GmbH
---

# Die Auswirkungen von HNSW auf die Degradation von Rag Systemen

> **Autor:** Provimedia GmbH | **Veröffentlicht:** 2026-10-02

## Warum HNSW bei wachsender Vektordatenbank an Recall verliert
Der Recall von HNSW sinkt nicht automatisch bei jedem Wachstumsschritt. Kritisch wird es, wenn der Graph größer wird, die Sucharbeit aber gleich bleibt. Dann muss die Abfrage einen immer kleineren Teil des möglichen Suchraums bewerten. Ein relevanter Vektor kann weiterhin im Index liegen, wird vom Suchpfad aber nicht mehr erreicht.

Der Grund liegt in der Struktur des Graphen. HNSW führt die Suche über mehrere Ebenen. Oben dienen wenige Verbindungen zur groben Orientierung, unten folgt die genauere Suche. Mit zunehmender Vektormenge entstehen mehr lokale Regionen und Übergänge. Ein Suchpfad, der bei 100.000 Einträgen gut funktioniert, kann bei mehreren Millionen an einer ungünstigen Stelle enden. Die Suche bleibt schnell, doch ihr Weg zum tatsächlichen Nachbarn wird brüchiger.

Besonders anfällig sind Anfragen mit schwacher oder mehrdeutiger semantischer Trennschärfe. Liegen mehrere Dokumentgruppen im Embedding-Raum dicht beieinander, reicht eine kleine Navigationsabweichung aus. HNSW folgt dann einer plausiblen, aber falschen Nachbarschaft. Für RAG ist das gefährlich: Die Treffer wirken thematisch passend, beantworten die konkrete Frage jedoch nicht.

Auch die Verteilung des Korpus spielt eine Rolle. Gleichmäßig verteilte Vektoren belasten den Graphen anders als stark verdichtete Cluster. Neue Dokumente können bestehende Regionen überfüllen. Dadurch verändert sich die lokale Nachbarschaft, während ältere Verbindungen nicht immer optimal zu den neuen Daten passen. Entscheidend ist also nicht nur die Anzahl der Vektoren, sondern auch ihre Geometrie.

Ein weiterer Effekt entsteht durch ungleiches Datenwachstum. Wenn ein Wissensbereich stark erweitert wird, steigt dort die Konkurrenz um ähnliche Treffer. Ein relevantes Dokument muss gegen mehr nahe Kandidaten bestehen. Seine Distanz zur Anfrage wird nicht schlechter, aber seine Chance, innerhalb des begrenzten Suchverlaufs aufzutauchen, kann sinken.

Für die Analyse ist die **Recall-Kurve über der Korpusgröße** aussagekräftiger als ein einzelner Messwert. Ein Rückgang um wenige Prozentpunkte kann bereits bedeuten, dass wichtige Belege in jeder zehnten Anfrage fehlen. Bei mehrstufigen Anwendungen summiert sich dieser Verlust: Wird zuerst die falsche Passage gefunden, kann auch ein späterer Reranker oder ein Sprachmodell den fehlenden Inhalt nicht zurückholen.

Die Degradation verläuft oft schleichend. Zuerst betrifft sie seltene Fragen, lange Dokumente und Inhalte mit ähnlicher Terminologie. Später verschlechtert sich die Trefferquote auch bei gewöhnlichen Anfragen. Deshalb sollte die Korpusgröße nicht nur als Speicher- oder Kostenwert gelten, sondern als Qualitätsvariable, die den erreichbaren Recall direkt beeinflusst.

## Wie die begrenzte Suchbreite relevante RAG-Dokumente übersieht
Die Suchbreite von HNSW legt fest, wie viele Kandidaten eine Anfrage während der Navigation tatsächlich erreicht. Wird dieser Bereich zu klein gewählt, kann ein relevantes Dokument trotz passender Vektordistanz außerhalb des geprüften Pfads bleiben. Für das RAG-System sieht es dann so aus, als wäre der Inhalt nicht vorhanden.

Das Übersehen entsteht häufig durch eine frühe Fehlentscheidung. HNSW wählt zunächst vielversprechende Knoten aus. Führt eine Verbindung in eine falsche Region, werden andere Äste des Graphen nur noch begrenzt oder gar nicht verfolgt. Der Algorithmus spart dadurch Rechenzeit, bezahlt aber mit einer blinden Stelle im Retrieval.

Ein kleines Beispiel macht den Effekt greifbar: Angenommen, eine Frage bezieht sich auf eine seltene Ausnahme in einer technischen Richtlinie. Im Vektorraum liegen viele allgemeine Passagen nahe beieinander, während die Ausnahme weiter entfernt liegt. Die Suchroutine findet zuerst mehrere allgemeine Abschnitte und beendet die Kandidatensuche, bevor sie die präzise Passage erreicht. Die Treffer sind semantisch verwandt, aber für die Antwort unzureichend.

Besonders riskant ist dieses Verhalten bei Dokumenten, deren relevante Aussage nur in einem kurzen Satz steht. Der übrige Abschnitt kann thematisch ähnlich wirken und dadurch eine gute Distanz erhalten. Beim anschließenden Kontextaufbau landen mehrere umfangreiche, aber wenig entscheidende Textstücke im Prompt. Die gesuchte Ausnahme fehlt, sodass das Sprachmodell keinen direkten Beleg erhält und eine Lücke schließen muss.

Die Folgen lassen sich nach Anfragearten unterscheiden:

- **Faktenfragen:** Eine konkrete Zahl, Frist oder Bedingung wird nicht gefunden.

- **Vergleichsfragen:** Nur eine Seite des Vergleichs erscheint im Kontext.

- **Mehrteilige Fragen:** Einzelne Teilaspekte fehlen, obwohl andere geliefert werden.

- **Seltene Suchbegriffe:** Nischenwissen wird von häufigen, allgemeineren Passagen verdrängt.

Auch die Anzahl der angeforderten Treffer schützt nicht automatisch. Werden etwa zehn Ergebnisse verlangt, kann HNSW zwar zehn Kandidaten liefern, doch alle können aus derselben falschen Region stammen. **Mehr Treffer bedeuten daher nicht zwingend mehr Abdeckung.** Entscheidend ist, ob der Suchlauf verschiedene relevante Bereiche erreicht und nicht nur eine einzige semantische Nachbarschaft auffüllt.

Für die Fehlersuche sollte zunächst geprüft werden, ob das relevante Dokument bei einer exakten Suche überhaupt nahe genug wäre. Ist das der Fall, liefert HNSW es aber nicht, liegt der Verlust im Navigationspfad. Fehlt es bereits bei der exakten Suche, muss die Ursache eher bei Embedding, Textaufteilung oder Suchformulierung gesucht werden. Diese Trennung verhindert, dass ein Graphproblem fälschlich als Modellfehler behandelt wird.

Wichtig ist außerdem der Unterschied zwischen *Dokument gefunden* und *richtige Passage gefunden*. Ein Treffer auf Dokumentebene kann positiv wirken, obwohl genau der relevante Chunk nicht im Kontext landet. Deshalb sollte die Auswertung möglichst auf der Ebene der tatsächlich an das Sprachmodell übergebenen Textabschnitte erfolgen.

## Der Zielkonflikt zwischen Recall und Latenz bei `ef_search`
**`ef_search` ist kein Qualitätsregler mit einem festen Idealwert.** Der passende Wert hängt davon ab, wie viel Verzögerung eine Anfrage verträgt und wie teuer ein fehlender Treffer ist. Eine FAQ-Anfrage mit niedriger Bedeutung kann mit kleinerer Suchbreite auskommen. Bei einer rechtlich oder medizinisch relevanten Antwort ist derselbe Kompromiss oft nicht vertretbar.

Die Auswirkung zeigt sich vor allem in den oberen Latenzbereichen. Der Durchschnitt kann stabil wirken, während einzelne Abfragen deutlich länger dauern. Wird `ef_search` erhöht, wächst nicht nur die mittlere Rechenarbeit. Auch p95 und p99 können steigen. Für interaktive RAG-Anwendungen ist das wichtig: Nutzer erleben nicht den Mittelwert, sondern die langsamen Ausreißer.

Ein sinnvoller Vergleich betrachtet daher mindestens drei Größen gemeinsam:

- **Recall:** Wie viele relevante Treffer werden erreicht?

- **p95-Latenz:** Wie lange dauern 95 Prozent der Anfragen höchstens?

- **Ressourcen pro Anfrage:** Wie viel CPU-Zeit und Arbeitsspeicher werden zusätzlich benötigt?

Die Beziehung zwischen Suchbreite und Recall ist meist nicht linear. Eine Verdopplung von `ef_search` verdoppelt den Recall nicht automatisch. Häufig gibt es zunächst deutliche Gewinne, danach eine Sättigungszone. Dort liegt der praktische Entscheidungspunkt: Weitere Kandidaten kosten viel, liefern aber nur noch wenige zusätzliche relevante Treffer.

Für RAG ist die gesamte Antwortzeit entscheidend. Die Suche bildet nur einen Teil der Pipeline; danach folgen oft Filterung, Reranking, Kontextaufbereitung und Generierung. Steigt die HNSW-Latenz um 30 Millisekunden, kann sich die wahrgenommene Reaktionszeit stärker erhöhen, wenn nachgelagerte Schritte bereits nahe an ihrem Budget liegen.

Statt einen globalen Wert für jede Anfrage zu erzwingen, eignet sich eine **klassenbasierte Steuerung**. Die Einstufung kann vor der Vektorsuche erfolgen:

- einfache Informationsfrage: niedriges Suchbudget,

- mehrdeutige oder lange Frage: mittleres Suchbudget,

- hohe fachliche oder geschäftliche Relevanz: hohes Suchbudget.

Diese Strategie sollte nicht nur nach Benutzerrolle arbeiten. Auch die erkannte Unsicherheit der Anfrage ist ein brauchbares Signal. Enthält sie mehrere Themen, seltene Begriffe oder widersprüchliche Angaben, lohnt sich eine breitere Suche eher als bei einer klaren Einzelfrage.

Für die Abstimmung empfiehlt sich ein stufenweiser Test mit mehreren festgelegten Suchbudgets. Pro Stufe werden Recall, p95-Latenz und Antwortqualität gemessen. Der beste Wert ist nicht der mit dem höchsten Recall, sondern der mit dem besten Verhältnis aus zusätzlicher Trefferqualität und zusätzlicher Verzögerung.

Das erlaubte Ergebnislimit sollte zum Suchbudget passen. Werden sehr viele Treffer angefordert, obwohl nur wenige Kandidaten sinnvoll geprüft werden, kann die Rangfolge instabil werden. Umgekehrt verschenkt ein zu kleines Ergebnislimit den Nutzen einer breiteren Suche. *ef_search* und die Zahl der zurückgegebenen Treffer sind daher zusammengehörige Stellgrößen.

Für produktive Systeme ist ein festes Latenzbudget sinnvoll. Wird dieses Budget überschritten, kann die Anwendung auf eine kleinere Suchstufe zurückfallen oder die Anfrage anders behandeln. Umgekehrt darf ein besonders wichtiges Ergebnis mehr Zeit erhalten. So wird der Zielkonflikt bewusst gesteuert.

## Der Einfluss von `M` und `ef_construction` auf die Indexqualität
`M` und `ef_construction` prägen die Qualität des HNSW-Graphen bereits beim Aufbau. Ihre Wirkung zeigt sich daher nicht erst bei einzelnen Suchanfragen. Sie bestimmen, wie viele brauchbare Wege zwischen ähnlichen Vektoren entstehen und wie gut diese Wege verschiedene Regionen des Embedding-Raums verbinden.

**`M` steuert die Zahl der Verbindungen pro Knoten.** Ein kleiner Wert erzeugt einen sparsamen Graphen. Das spart Platz, kann aber zu Engpässen führen: Ein Knoten besitzt dann womöglich keine ausreichende Auswahl an Wegen zu benachbarten Clustern. Ein höherer Wert schafft mehr Querverbindungen. Dadurch wird der Graph robuster gegenüber ungünstigen Startpunkten und ungleich verteilten Daten.

Mehr Verbindungen sind jedoch kein Freifahrtschein. Der Speicherbedarf steigt grob mit der Zahl der Knoten und ihrer Kanten. Bei großen Embeddings kommen die Vektordaten selbst hinzu. Ein höheres `M` kann deshalb die Cache-Nutzung verschlechtern. Liegen Graphdaten nicht mehr effizient im Arbeitsspeicher, kann der theoretische Qualitätsgewinn durch zusätzliche Speicherzugriffe teilweise verloren gehen.

`ef_construction` wirkt während des Einfügens neuer Vektoren. Der Wert legt fest, wie gründlich nach geeigneten Nachbarn gesucht wird, bevor die Verbindungen eines neuen Knotens feststehen. Ein niedriger Wert führt zu einem schnelleren Aufbau, akzeptiert aber eher Nachbarschaften, die nur lokal gut aussehen. Ein höherer Wert erlaubt eine sorgfältigere Auswahl und kann die Struktur des fertigen Graphen deutlich verbessern.

Das Zusammenspiel beider Parameter ist entscheidend:

- **Niedriges `M`, niedriges `ef_construction`:** geringer Ressourcenbedarf, aber höheres Risiko für schwache Übergänge zwischen Regionen.

- **Hohes `M`, niedriges `ef_construction`:** viele mögliche Kanten, die Auswahl dieser Kanten kann jedoch unpräzise bleiben.

- **Niedriges `M`, hohes `ef_construction`:** die verfügbaren Verbindungen werden sorgfältig gewählt, ihre Zahl bleibt dennoch begrenzt.

- **Hohes `M`, hohes `ef_construction`:** meist die stabilste Graphstruktur, zugleich aber die aufwendigste Variante beim Aufbau.

Für RAG zählt vor allem die Qualität der Übergänge zwischen semantisch nahen, aber nicht identischen Themen. Ein Graph darf nicht nur innerhalb eines Clusters gut verbunden sein, sondern muss auch Wege zu angrenzenden Clustern bieten. Sonst können Fragen mit mehreren Begriffen, Synonymen oder wechselnder Fachsprache an einer lokalen Grenze hängen bleiben.

Auch die Reihenfolge der Indexierung kann eine Rolle spielen. Werden Dokumente stark blockweise eingefügt, entstehen zunächst lokale Strukturen. Eine sorgfältige Konstruktion hilft, spätere Verbindungen besser auszuwählen, beseitigt aber keine grundsätzlichen Verzerrungen in den Daten. Ein Korpus mit stark überrepräsentierten Themen braucht daher oft eine ausgewogene Zusammenstellung, bevor die Parameter fein abgestimmt werden.

Die passende Konfiguration lässt sich nicht zuverlässig aus einer allgemeinen Empfehlung ableiten. Sinnvoller ist ein kontrollierter Vergleich mehrerer Kombinationen mit denselben Vektoren, derselben Einfügefolge und denselben Prüfqueries. Nur so wird sichtbar, ob ein Gewinn aus der Graphstruktur stammt oder bloß aus einer veränderten Testgrundlage.

Änderungen an diesen Aufbauparametern wirken nicht rückwirkend. Wird der Graph bereits mit einer schwachen Nachbarschaftsstruktur erzeugt, lässt sich seine Qualität nicht einfach durch eine spätere Einstellung reparieren. In solchen Fällen ist ein Neuaufbau nötig. Das kostet Zeit, kann bei produktiven Systemen aber besser sein als dauerhaft fehlende RAG-Kontexte.

Als grobe Orientierung werden für viele RAG-Workloads `M`-Werte zwischen 12 und 48 sowie `ef_construction`-Werte zwischen 64 und 200 eingesetzt. Diese Bereiche sind kein Qualitätsversprechen. Die optimale Wahl hängt von Vektordimension, Clusterstruktur, Korpusgröße und Hardware ab. Ein kleiner, gut verknüpfter Graph kann einem größeren, schlecht konstruierten Graphen überlegen sein.

## Warum hohe Similarity Scores sinkende Retrieval-Qualität nicht ausschließen
Ein hoher Similarity Score bewertet die Nähe eines gefundenen Vektors zur Anfrage. Er sagt jedoch nicht, ob der Treffer die entscheidende Information enthält. Genau hier entsteht ein häufiger Messfehler: Das System meldet plausible Nachbarn, obwohl die inhaltlich notwendige Passage fehlt.

Der Wert hängt zudem von der verwendeten Distanzfunktion, dem Embedding-Modell und der Datenverteilung ab. Ein Score von 0,82 ist daher nicht allgemein besser als 0,76. Ohne eine feste Auswertung mit bekannten relevanten Antworten bleiben solche Zahlen schwer vergleichbar. Ein einzelner Schwellenwert taugt kaum als Qualitätsgarantie.

Auch die Rangfolge kann täuschen. Angenommen, die ersten fünf Treffer behandeln denselben allgemeinen Begriff. Sie sind einander sehr ähnlich und erhalten deshalb gute Werte. Die konkrete Ausnahme, Definition oder Einschränkung steht aber in einem sechsten Dokument mit geringerer Nähe. Der Retriever wirkt präzise, liefert für die eigentliche Frage jedoch einen einseitigen Kontext.

Ein weiterer Grund ist die sogenannte **Redundanzfalle**. Ähnliche Chunks aus demselben Dokument sammeln sich weit oben. Dadurch sinkt die thematische Breite des Kontextfensters. Der Score der einzelnen Treffer bleibt hoch, während wichtige Gegenpositionen, Voraussetzungen oder zeitliche Änderungen nicht erscheinen.

Für eine belastbare Bewertung sollten daher mehrere Signale zusammen betrachtet werden:

- **Relevanz:** Beantwortet der Chunk die konkrete Frage?

- **Abdeckung:** Sind alle benötigten Teilinformationen vertreten?

- **Vielfalt:** Kommen die Treffer aus unterschiedlichen passenden Quellen oder nur aus einem Cluster?

- **Belegbarkeit:** Enthält der Kontext eine klare Textstelle für die spätere Antwort?

Besonders wichtig ist die Unterscheidung zwischen *semantischer Nähe* und *Beweiswert*. Ein Abschnitt über Kündigungsfristen kann einer Frage zur Vertragsverlängerung sehr nahe sein. Er liefert aber keinen ausreichenden Beleg, wenn die gesuchte Regel nur in einer Sonderklausel steht. Ähnlichkeit hilft beim Auffinden; sie ersetzt keine inhaltliche Prüfung.

Auch die Textlänge beeinflusst den Score. Ein langer Chunk kann viele Begriffe der Anfrage enthalten und dadurch gut abschneiden, obwohl die relevante Aussage darin untergeht. Kleine Chunks können dagegen präziser sein, verlieren aber manchmal den notwendigen Zusammenhang. Der Score misst diese redaktionelle Qualität nicht.

Eine bessere Auswertung kombiniert die Vektorsuche mit einer nachgelagerten Relevanzprüfung. Dabei wird nicht nur gefragt, ob ein Treffer nahe liegt, sondern ob er die erwartete Zielinformation tatsächlich stützt. Für Testmengen sollten positive und bewusst irreführende Beispiele enthalten sein. Erst dann wird sichtbar, ob hohe Werte echte Qualität oder nur sprachliche Ähnlichkeit anzeigen.

Ändert sich die Embedding-Verteilung oder wächst der Dokumentbestand, dürfen alte Score-Schwellen nicht blind weiterverwendet werden. Die Zahlen können stabil aussehen, obwohl sich die Bedeutung ihrer Rangordnung verschiebt. Aussagekräftig bleibt nur die Verbindung aus Score-Verlauf, inhaltlicher Trefferprüfung und der Qualität des erzeugten Kontexts.

## Recall@k als Messgröße für schleichende RAG-Degradation
**Recall@k zeigt, ob relevante Dokumente tatsächlich in den ersten k Treffern erscheinen.** Für ein RAG-System ist das aussagekräftiger als ein einzelner Ähnlichkeitswert. Ein sinkender Wert macht sichtbar, dass die Retrieval-Stufe zunehmend wichtige Belege verfehlt.

Die Kennzahl wird auf einer festgelegten Menge von Testfragen berechnet. Für jede Frage wird zuvor bestimmt, welche Dokumente oder Textabschnitte relevant sind. Anschließend prüft die Auswertung, wie viele davon in den obersten k Ergebnissen auftauchen:

*Recall@k = gefundene relevante Treffer innerhalb der Top-k / alle relevanten Treffer*

Bei **Recall@5** zählen die ersten fünf Ergebnisse, bei **Recall@10** die ersten zehn. Ein Wert von 0,8 bedeutet nicht, dass 80 Prozent des Textes richtig sind. Er bedeutet: Im Mittel wurden 80 Prozent der festgelegten relevanten Treffer innerhalb der betrachteten Ergebnisgrenze gefunden.

Für die Erkennung schleichender Degradation ist die zeitliche Entwicklung entscheidend. Wird derselbe Fragensatz nach jeder größeren Datenaufnahme ausgeführt, entsteht eine Verlaufskurve. Fällt Recall@10 beispielsweise von 0,91 auf 0,84, kann das auf einen relevanten Qualitätsverlust hindeuten, selbst wenn Nutzer weiterhin viele passende Antworten erhalten.

Eine einzelne Zahl reicht jedoch nicht. Der Mittelwert kann kritische Ausfälle verdecken. Deshalb sollten zusätzlich Verteilungen und Teilgruppen ausgewertet werden:

- **Fragetyp:** Faktenfrage, Vergleich, Zusammenfassung oder mehrteilige Aufgabe

- **Wissensbereich:** häufige Themen gegenüber seltenen Fachgebieten

- **Dokumentalter:** aktuelle Inhalte gegenüber älteren Versionen

- **Treffergrenze:** Recall@1, Recall@5 und Recall@10 im Vergleich

Gerade die Differenz zwischen diesen Grenzen ist aufschlussreich. Ein guter Recall@10 bei schwachem Recall@1 kann bedeuten, dass der richtige Inhalt zwar irgendwo im Kontext landet, aber nicht prominent genug erscheint. Bei kleinen Kontextfenstern oder strenger Rerank-Auswahl kann diese Position trotzdem praktisch verloren gehen.

Für die Testmenge müssen relevante Antworten eindeutig markiert sein. Eine Frage kann mehrere gültige Quellen besitzen. Werden davon nur einzelne als korrekt festgelegt, wirkt der Recall künstlich niedrig. Umgekehrt führt eine zu großzügige Markierung zu geschönten Werten. Die Kennzahl steht und fällt daher mit einer sauberen Relevanzdefinition.

Bei wachsenden Korpora sollte die Testmenge stabil bleiben. Ändern sich Fragen und Referenzdokumente gleichzeitig, lässt sich ein Rückgang nicht mehr eindeutig dem Index zuordnen. Neue Inhalte können zusätzliche Tests erfordern, dürfen aber die historische Vergleichsbasis nicht ersetzen.

Besonders hilfreich ist die Kombination aus Recall@k und **Miss-Rate**. Die Miss-Rate zeigt, bei welchem Anteil der Fragen mindestens ein notwendiger Beleg fehlt. Dieser Wert passt oft besser zur tatsächlichen RAG-Risikolage als ein hoher Durchschnitt. Bei einer Antwort, die drei Quellen braucht, genügt schon ein fehlender Treffer, damit die Aussage unvollständig wird.

Recall@k misst allerdings nur die Auffindbarkeit relevanter Inhalte. Er bewertet nicht, ob die Treffer widersprüchlich, veraltet oder redundant sind. Für eine belastbare Diagnose sollte die Kennzahl deshalb mit einer inhaltlichen Antwortprüfung verbunden werden. So wird sichtbar, ob ein sinkender Retrieval-Wert bereits konkrete Fehler in den erzeugten Antworten verursacht.

Als praktische Warnsignale gelten ein stetiger Abwärtstrend, größere Unterschiede zwischen Themenbereichen und eine wachsende Lücke zwischen exakter Referenzsuche und HNSW-Ergebnis. Dann liegt nahe, dass die Degradation mit der Entwicklung des Indexes zusammenhängt.

## Experimentelle Befunde zum Verhalten von HNSW bei großen Korpora
Kontrollierte Tests zeigen, dass HNSW bei wachsendem Korpus nicht mit einem plötzlichen Fehler ausfällt. Die Veränderung ist schleichend: Zwischen kleinen und großen Indexständen bleibt die Suche funktionsfähig, doch die Trefferquote entwickelt sich nicht mehr proportional zur Datenmenge. Gerade diese unspektakuläre Verschiebung macht die Degradation schwer erkennbar.

Ein typisches Versuchsdesign hält die Suchkonfiguration konstant und vergrößert den Index in mehreren Stufen. Für jede Stufe werden dieselben Queries ausgeführt. Eine exakte Suche liefert die Referenz, während HNSW zeigt, wie viele der bekannten Nachbarn tatsächlich erreicht werden. So lässt sich der Verlust dem Indexverhalten zuordnen, statt ihn vorschnell dem Sprachmodell zuzuschreiben.

Die Ergebnisse weisen meist auf drei Muster hin:

- Bei kleinen Korpora liegen approximative und exakte Treffer näher beieinander.

- Mit zunehmender Größe wächst die Differenz zwischen beiden Verfahren.

- Die Latenz kann dabei wesentlich stabiler bleiben als die Retrieval-Qualität.

Besonders aussagekräftig ist die Betrachtung mehrerer Datenbereiche. Häufige, klar getrennte Inhalte bleiben länger stabil. Seltene Beispiele, eng benachbarte Themen und Queries mit mehreren relevanten Zielvektoren verlieren früher. Ein globaler Mittelwert kann diese Unterschiede verschleiern. Die Untersuchung sollte deshalb nach Themen, Query-Länge und Anzahl erwarteter Treffer aufgeteilt werden.

Experimente mit rund 200.000 CLIP-Vektoren aus dem Datensatz LAION-Aesthetics zeigen zugleich die Stärke und die Grenze solcher Tests. Textbeschreibungen dienen als Queries, ein bekannter Vektor als Referenz. Das schafft reproduzierbare Bedingungen. Bild- und Textsuche sind jedoch nicht vollständig gleichzusetzen. Die Resultate belegen daher das Skalierungsverhalten von HNSW, liefern aber keine direkte Qualitätsgarantie für jedes RAG-Korpus.

Ein weiterer Befund betrifft die Interpretation von Ähnlichkeitswerten. Selbst wenn sich deren Verteilung nur wenig verändert, kann die Position des korrekten Nachbarn wechseln. Das System findet dann weiterhin plausible Vektoren, aber nicht mehr zuverlässig den besten oder einen der notwendigen Belege. Die Rangordnung verschiebt sich leise, fast wie Sand unter einer Tür.

Wird der Versuch mit verschiedenen Graphkonfigurationen wiederholt, zeigt sich außerdem: Nicht alle HNSW-Indizes reagieren gleich. Ein dichterer, sorgfältiger aufgebauter Graph kann die Stabilität verbessern. Er beseitigt den Skalierungseffekt jedoch nicht grundsätzlich. Die Kurven verschieben sich; das Grundproblem bleibt messbar.

Für eine belastbare Studie sollten mindestens folgende Bedingungen dokumentiert werden:

- identische Embeddings und unveränderte Query-Sets,

- mehrere Korpusgrößen statt nur ein Vorher-nachher-Vergleich,

- exakte Referenzsuche für eine repräsentative Stichprobe,

- getrennte Auswertung seltener und häufiger Themen,

- Messung von Durchschnitts- und Perzentil-Latenzen,

- mehrere Wiederholungen zur Kontrolle zufälliger Einflüsse.

Der wichtigste Schluss aus solchen Tests lautet nicht, dass HNSW ungeeignet sei. Vielmehr muss seine Qualität als variable Systemeigenschaft behandelt werden. Ein Index, der bei 100.000 Vektoren ausreichend arbeitet, ist nicht automatisch für zehn Millionen Vektoren gleich gut. Erst die gemeinsame Betrachtung von Korpusgröße, Trefferverhalten und Referenzsuche zeigt, wann die RAG-Pipeline in eine kritische Zone gerät.

## Wie fehlender Kontext die Qualität von LLM-Antworten verschlechtert
Fehlt im abgerufenen Kontext eine entscheidende Passage, sinkt die Antwortqualität nicht nur wegen eines einzelnen falschen Treffers. Das Sprachmodell verliert die Grundlage, auf der es Aussagen prüfen, Bedingungen einordnen und Widersprüche erkennen kann. Es kann dann sprachlich überzeugend formulieren, obwohl die sachliche Basis lückenhaft ist.

Besonders kritisch ist der Verlust von **einschränkenden Informationen**. Eine Regel ohne Ausnahme klingt eindeutig. Fehlt jedoch der Satz „gilt nicht für …“, entsteht eine Antwort, die formal sauber, aber inhaltlich falsch ist. Ähnlich problematisch sind fehlende Gültigkeitsdaten, Definitionen oder Voraussetzungen. Sie bestimmen, ob eine Aussage überhaupt auf die konkrete Frage passt.

In RAG-Pipelines treten dabei mehrere Fehlermuster auf:

- **Verallgemeinerung:** Das Modell überträgt eine Regel auf Fälle, die im fehlenden Abschnitt ausgenommen werden.

- **Unvollständige Synthese:** Einzelne Teilinformationen sind vorhanden, ihre Verbindung fehlt.

- **Falsche Sicherheit:** Der Kontext enthält keinen Beleg für die Behauptung, klingt aber thematisch passend.

- **Widerspruchsverlust:** Eine spätere oder speziellere Quelle wird nicht gefunden und kann eine ältere Aussage nicht korrigieren.

Der Schaden steigt, wenn die Frage mehrere Belege benötigt. Bei einer einfachen Definition genügt oft ein passender Abschnitt. Bei einer Entscheidung mit Bedingungen, Fristen und Ausnahmen muss der Kontext dagegen mehrere Informationseinheiten zusammenführen. Fehlt nur eine davon, kann sich die Bedeutung des gesamten Ergebnisses verschieben.

Auch die Position im Kontext beeinflusst die Verarbeitung. Ein relevanter Beleg, der erst spät oder zwischen vielen ähnlichen Passagen erscheint, wird nicht immer gleich stark berücksichtigt. Das gilt besonders bei langen Eingaben. Ein Sprachmodell kann dann einzelne Details schwächer gewichten, obwohl sie technisch im Prompt vorhanden sind.

Fehlender Kontext kann außerdem eine falsche Begründung auslösen. Das Modell erkennt vielleicht die Richtung der Antwort, ergänzt aber den fehlenden Schritt aus allgemeinen Sprachmustern. Diese Ergänzung wirkt plausibel, stammt jedoch nicht aus dem Wissensbestand. Genau daraus entstehen Halluzinationen: nicht zwingend aus völliger Unwissenheit, sondern aus einer Lücke zwischen Frage und Beleg.

Für die Qualitätsprüfung sollte die Antwort auf ihre zentralen Belege zurückgeführt werden:

- Welche Aussage in der Antwort ist wesentlich?

- Welcher Kontextabschnitt stützt sie?

- Enthält dieser Abschnitt auch Bedingungen und Ausnahmen?

- Gibt es eine widersprechende oder aktuellere Passage?

Fehlt für einen wichtigen Satz ein belastbarer Beleg, sollte das System nicht einfach mit größerer sprachlicher Sicherheit antworten. Besser ist eine erkennbare Unsicherheitsmarkierung oder eine Rückfrage. Das verhindert, dass eine Lücke im Retrieval als scheinbares Wissen ausgegeben wird.

Die Wirkung zeigt sich nicht nur in einzelnen Antworten. Wenn zentrale Dokumente dauerhaft seltener im Kontext erscheinen, beantwortet das System Standardfragen weiterhin gut, versagt aber häufiger bei Sonderfällen, Aktualisierungen und mehrteiligen Aufgaben. Diese stille Verschiebung macht die Degradation für Nutzer oft erst spät sichtbar.

## Warum Flat Search als Referenz für den HNSW-Recall dient
Flat Search vergleicht eine Anfrage mit jedem Vektor im geprüften Bestand. Dadurch entsteht eine Rangliste, die nicht von einem begrenzten Navigationspfad im Graphen abhängt. Für dieselbe Anfrage und Datenbasis liefert dieses Verfahren somit die praktisch exakte Referenz der Nachbarschaftssuche.

Diese Referenz ist wichtig, weil ein HNSW-Treffer allein keine Aussage über den entgangenen Recall macht. Erst der Vergleich zeigt, ob ein relevantes Ergebnis nur niedriger gerankt wurde oder vollständig aus der approximativen Suche verschwunden ist. Genau diese Unterscheidung trennt ein Rankingproblem von einem echten Retrieval-Verlust.

Für jede Testanfrage werden die Top-k-Ergebnisse beider Verfahren gegenübergestellt. Die exakte Rangliste bildet den Sollbestand. Anschließend lässt sich prüfen:

- Welche relevanten Vektoren liefert HNSW ebenfalls?

- Welche fehlen vollständig?

- Wie stark verschieben sich ihre Rangplätze?

- Bleibt die Übereinstimmung bei größeren Indexständen stabil?

Der Vergleich sollte auf derselben Embedding-Menge erfolgen. Schon kleine Unterschiede bei Datenbestand, Distanzmaß oder Normalisierung können den Befund verfälschen. Auch Filter müssen identisch angewendet werden. Wird bei Flat Search ein anderer Dokumentbereich durchsucht, misst der Test nicht die Indexqualität, sondern zwei verschiedene Suchaufgaben.

Flat Search ist kein Produktionsvorschlag für jeden Anfragepfad. Bei Millionen oder Milliarden Vektoren wächst der Rechenaufwand mit der Bestandsgröße. Seine Stärke liegt vielmehr in einer gezielten Kontrollmessung. Eine repräsentative Stichprobe kann genügen, um die Qualität von HNSW zu kalibrieren und Veränderungen früh zu erkennen.

Besonders nützlich ist ein **Recall-Verhältnis** zwischen approximativer und exakter Suche. Der exakte Suchlauf liefert den Nenner für die tatsächlich besten Nachbarn; HNSW liefert den zu bewertenden Anteil. So wird sichtbar, ob ein scheinbar stabiler Score-Verlauf mit einer schlechteren Übereinstimmung der Ranglisten einhergeht.

Für die Diagnose sollten mehrere k-Werte verwendet werden. Eine Übereinstimmung bei den Top 100 kann gut aussehen, während die Top 5 deutlich abweichen. Das ist für RAG relevant, wenn nachgelagerte Filter nur wenige Passagen behalten. Die Referenz muss daher zur tatsächlichen Kontextgröße der Anwendung passen.

Ein fairer Test berücksichtigt auch Metadatenfilter. Ein globaler exakter Vergleich kann einen hohen Recall zeigen, obwohl die produktive Anfrage zusätzlich nach Sprache, Mandant oder Gültigkeitsdatum filtert. Entscheidend ist die Referenz innerhalb genau derselben zulässigen Dokumentmenge.

Die Ergebnisse sollten zusammen mit Konfidenzintervallen oder zumindest mit der Zahl der Testfragen dokumentiert werden. Ein Unterschied von zwei Prozentpunkten ist bei 50 Queries kaum belastbar, bei mehreren tausend sorgfältig ausgewählten Queries dagegen deutlich aussagekräftiger.

Flat Search beantwortet damit eine konkrete Frage: **Wie viel Qualität verliert HNSW gegenüber der bestmöglichen Suche unter identischen Bedingungen?** Ohne diese Kontrolllinie bleibt unklar, ob eine RAG-Degradation aus dem Index, aus der Datenaufbereitung oder aus einer veränderten Query-Verteilung stammt.

## Monitoring von Retrieval-Qualität und Datenbankwachstum
Monitoring muss den Zustand des Indexes mit der inhaltlichen Trefferqualität verbinden. Ein einzelner Latenzwert oder die Zahl erfolgreicher Suchanfragen reicht dafür nicht. Entscheidend ist, ob die Retrieval-Leistung bei wachsendem Bestand erhalten bleibt.

Erfasst werden sollten mehrere Zeitreihen: die Zahl der Vektoren, der Anteil neu hinzugefügter Dokumente, die Verteilung der Dokumente auf Themenbereiche und der Anteil aktualisierter oder gelöschter Einträge. Besonders nützlich ist eine getrennte Betrachtung von aktivem Bestand und veralteten Datensätzen. Ein großer Index kann äußerlich wachsen, obwohl ein Teil seiner Inhalte nicht mehr verwendet werden darf.

Für die Qualitätsseite sollte ein unveränderter Prüfbestand regelmäßig durch die produktive Suchpipeline laufen. Wichtig ist dabei die Versionierung von Embedding-Modell, Chunking-Regeln, Filtern und Indexkonfiguration. Ohne diese Angaben bleibt ein Messwert kaum erklärbar. Ein Rückgang kann sonst ebenso durch eine neue Datenaufbereitung wie durch das Wachstum des Graphen entstanden sein.

Ein robustes Dashboard verbindet mindestens vier Blickwinkel:

- **Bestandsentwicklung:** Vektoranzahl, Datenvolumen und Wachstumsrate

- **Retrieval:** Recall-Verlauf nach Query-Gruppe und Dokumenttyp

- **Betrieb:** p50-, p95- und p99-Latenz sowie Fehlerrate

- **Antwortwirkung:** Anteil belegter Kernaussagen und unvollständiger Antworten

Alarme sollten nicht erst bei einem Totalausfall auslösen. Sinnvoller sind Schwellen für Trends, etwa ein anhaltender Rückgang über mehrere Messperioden oder eine ungewöhnlich große Lücke zwischen neuem und historischem Prüfbestand. Ein einzelner Ausreißer kann Zufall sein; ein stetiger Drift ist dagegen ein Frühwarnsignal.

Die Daten sollten nach relevanten Segmenten ausgewertet werden. Bei mehrsprachigen Korpora können einzelne Sprachen früher an Qualität verlieren. Ebenso können neue Themen, sehr kurze Dokumente oder stark aktualisierte Inhalte auffällig sein. Ein globaler Durchschnitt würde solche lokalen Brüche leicht verschlucken.

Wichtig ist außerdem die Messung der Indexfrische. Zwischen Dokumentänderung und verfügbarer, korrekt eingebetteter Version darf keine unbemerkte Lücke entstehen. Für RAG-Anwendungen mit Richtlinien oder Produktdaten ist das besonders heikel: Ein Treffer kann formal passen, aber eine überholte Fassung enthalten.

Für jede Messung sollte der Datenstand eindeutig festgehalten werden. Dazu gehören Zeitstempel, Indexversion und die Zahl der gültigen Vektoren. So lässt sich später prüfen, ob ein Qualitätsabfall mit einem Import, einer Löschung, einem Neuaufbau oder einer Änderung der Metadatenfilter zusammenfällt.

Ein praktikabler Überwachungsprozess arbeitet mit drei Ebenen: kontinuierliche Betriebsmetriken, regelmäßige Qualitätsläufe und vertiefte Ursachenanalysen bei Abweichungen. Die erste erkennt Auffälligkeiten schnell, die zweite zeigt ihre fachliche Bedeutung, die dritte trennt Indexeffekte von Problemen in Daten und Anwendung.

Der zentrale Steuerungswert ist damit nicht die reine Größe der Vektordatenbank, sondern die **Qualität pro wachsendem Datenbestand**. Erst wenn beide Entwicklungen gemeinsam sichtbar sind, lässt sich erkennen, ob zusätzliche Dokumente den Nutzwert erhöhen oder den Retriever zunehmend unzuverlässig machen.

## Strategien zur Stabilisierung von Recall und Antwortqualität
Die Stabilisierung von Recall und Antwortqualität gelingt nicht mit einem einzelnen Parameter. Entscheidend ist eine belastbare Retrieval-Pipeline, die Unsicherheit erkennt, Quellen sauber zusammenführt und bei riskanten Lücken nicht einfach weitergeneriert.

Eine wirksame Maßnahme ist die **Abfragezerlegung**. Mehrteilige Fragen werden in einzelne Suchaufgaben aufgeteilt. Jede Teilfrage erhält eigene Treffer, die anschließend zusammengeführt werden. Dadurch muss eine einzige Vektorsuche nicht gleichzeitig mehrere Themen, Bedingungen und Zeitbezüge abdecken. Das reduziert die Gefahr, dass ein wichtiger Aspekt zwischen allgemein passenden Ergebnissen verschwindet.

Bei langen oder unklaren Nutzerfragen hilft zunächst eine Suchanfrage-Reformulierung. Dabei werden Fachbegriffe vereinheitlicht, Synonyme ergänzt und zeitliche Einschränkungen ausdrücklich gemacht. Wichtig ist, die ursprüngliche Nutzerfrage zusätzlich zu bewahren. Sonst kann die Reformulierung zwar bessere Treffer liefern, aber die eigentliche Absicht verfehlen.

Für heterogene Korpora empfiehlt sich eine **hybride Suche**. Vektorähnlichkeit findet sinngemäß verwandte Inhalte, während eine lexikalische Suche exakte Begriffe, Produktcodes, Paragrafen oder seltene Namen schützt. Beide Ergebnislisten können zusammengeführt und danach neu bewertet werden. Dieser Ansatz ist besonders nützlich, wenn einzelne Schlüsselwörter fachlich unverzichtbar sind.

Ein Reranker kann die Reihenfolge der gelieferten Kandidaten verbessern, ersetzt jedoch keine fehlenden Dokumente. Deshalb sollte die Pipeline zuerst ausreichend unterschiedliche Kandidaten sammeln und erst danach streng sortieren. Sonst wird ein kleiner Fehler am Anfang lediglich präziser präsentiert.

Für widersprüchliche oder zeitabhängige Wissensbestände sind Metadaten ein zentraler Schutz. Treffer sollten nach Sprache, Gültigkeitszeitraum, Dokumentstatus und Berechtigungsbereich gefiltert werden. Zusätzlich kann die Antwortlogik neuere Fassungen bevorzugen, ohne ältere Quellen vollständig zu verwerfen. So bleiben Änderungen nachvollziehbar, statt stillschweigend vermischt zu werden.

Die Kontextaufbereitung sollte nicht nur nach Rangplatz arbeiten. Sinnvoll sind Regeln, die ähnliche Chunks begrenzen, verschiedene Dokumente bevorzugen und zusammengehörige Passagen als Einheit behandeln. Ein kompakter Kontext mit hoher Abdeckung ist meist hilfreicher als eine lange Liste nahezu identischer Textstücke.

Vor der Generierung kann ein **Beleg-Check** prüfen, ob jede wesentliche Teilfrage mindestens eine tragfähige Quelle besitzt. Fehlt ein Beleg, sollte das System gezielt nachsuchen, die Frage aufteilen oder die Lücke offen benennen. Eine kurze, begrenzte Nachsuche ist oft wirksamer als ein pauschal riesiger Kontext.

Auch die Antwortvorgaben beeinflussen die Robustheit. Das Modell sollte zwischen belegten Aussagen, Schlussfolgerungen und fehlenden Informationen unterscheiden. Bei widersprüchlichen Quellen muss es den Konflikt nennen, statt eine Seite still auszuwählen. Klare Ausgabeformate mit Quellenbezug erleichtern zudem die spätere Prüfung.

Für kritische Anwendungen eignet sich ein **Abstufungsmodell**: Niedrige Unsicherheit erlaubt eine direkte Antwort. Mittlere Unsicherheit löst eine zusätzliche Suchrunde aus. Hohe Unsicherheit führt zu einer Rückfrage oder zu einer ausdrücklich begrenzten Antwort. So wird Retrieval-Qualität in konkrete Systementscheidungen übersetzt.

Schließlich sollten Verbesserungen isoliert getestet werden. Abfragezerlegung, hybride Suche, Reranking und Beleg-Check dürfen nicht gleichzeitig eingeführt werden, wenn ihre Wirkung nachvollziehbar bleiben soll. Getestet werden sollten nicht nur Durchschnittswerte, sondern auch seltene Fragen, widersprüchliche Dokumente und Fälle mit fehlender Information. Dort zeigt sich, ob die Stabilisierung wirklich trägt oder nur die einfachen Anfragen besser aussehen lässt.

## Fazit: HNSW regelmäßig evaluieren und an das Korpuswachstum anpassen
HNSW muss als **veränderliche Qualitätskomponente** eines RAG-Systems behandelt werden. Ein einmal erreichter Recall bleibt nicht automatisch erhalten, wenn der Korpus wächst, sich thematisch verschiebt oder viele Dokumente ersetzt werden. Die entscheidende Frage lautet deshalb nicht, ob der Index heute funktioniert, sondern ob seine Qualität unter den geplanten Betriebsbedingungen stabil bleibt.

Für die Praxis bedeutet das: Korpuswachstum sollte an klare Qualitätsgrenzen gekoppelt werden. Wird ein festgelegter Schwellenwert unterschritten, darf der Bestand nicht einfach weiter anwachsen. Stattdessen braucht es eine technische Entscheidung zwischen Neuaufbau, geänderter Suchkonfiguration, zusätzlicher Suchstufe oder einer anderen Indexstrategie. So wird aus einer stillen Verschlechterung ein steuerbarer Prozess.

Ein belastbares Betriebsmodell enthält mindestens drei Zeitpunkte:

- **Vor dem Rollout:** Baseline für Trefferqualität, Antwortqualität und Ressourcenverbrauch festlegen.

- **Bei wichtigen Änderungen:** neue Embeddings, große Importe, Löschungen und Reorganisationen gesondert prüfen.

- **Im laufenden Betrieb:** Qualitätsentwicklung mit versionierten Testfällen und nachvollziehbaren Freigabekriterien bewerten.

Besondere Aufmerksamkeit verdient die Grenze zwischen technischer und fachlicher Verantwortung. Das Index-Team kann die Suche messen, aber nicht allein entscheiden, ob ein fehlender Treffer für den Geschäftsprozess tolerierbar ist. Für kritische Inhalte müssen Fachverantwortliche festlegen, welche Dokumente zwingend gefunden werden müssen und wann eine Antwort lieber ausbleibt.

Eine sinnvolle Architektur plant außerdem Rückfallpfade ein. Dazu gehören eine breitere Suche für einzelne Anfragen, eine zweite Retrieval-Methode oder eine gezielte Prüfung gegen einen kleineren, besonders wichtigen Dokumentbestand. Der Rückfallpfad sollte nicht erst nach einem Vorfall entstehen. Wenn er vorbereitet ist, lässt sich die Antwortqualität auch während eines Indexwechsels oder eines größeren Imports besser schützen.

Beim Neuaufbau zählt nicht nur die technische Fertigstellung. Der neue Index sollte erst freigegeben werden, wenn seine Ergebnisse gegen die bisherige Version und eine exakte Referenz geprüft wurden. Dabei sind Verschlechterungen in einzelnen Fachbereichen wichtiger als ein kleiner Gewinn im Gesamtdurchschnitt. Ein hübscher Mittelwert kann an entscheidender Stelle trotzdem danebenliegen.

Ebenso wichtig ist eine klare Dokumentation. Festgehalten werden sollten Korpusstand, Indexparameter, Embedding-Version, Filterregeln, Testumfang und Freigabeentscheidung. Diese Angaben machen spätere Vergleiche möglich und verhindern, dass Teams bei jeder Abweichung wieder bei null anfangen.

HNSW ist daher weder grundsätzlich ungeeignet noch dauerhaft selbststabilisierend. Seine Stärke liegt in der schnellen Suche großer Bestände; seine Schwäche zeigt sich dort, wo wachsende Datenmengen mit unveränderten Annahmen betrieben werden. Wer Qualitätsgrenzen, Rückfallpfade und regelmäßige Freigaben einplant, kann diesen Zielkonflikt beherrschen.

**Die wichtigste Schlussfolgerung:** Ein RAG-System ist erst dann produktionsreif, wenn seine Retrieval-Qualität nicht nur beim Start, sondern auch nach dem nächsten großen Datenimport verlässlich bleibt. Korpuswachstum ist kein reiner Speicherfall. Es ist ein Auslöser für neue Qualitätsprüfungen, technische Entscheidungen und gegebenenfalls einen kontrollierten Indexwechsel.

---

*Dieser Artikel wurde ursprünglich veröffentlicht auf [kiagenturmagazin.de](https://kiagenturmagazin.de/die-auswirkungen-von-hnsw-auf-die-degradation-von-rag-systemen/)*
*© 2026 Provimedia GmbH*