Startseite / Artikel / Jenseits von Top-K: Relevanzschwellenwerte, hybride Suche und Neubewertung in RAG

RAG LLM Retrieval Reranking Hybrid Search AI Engineering

Jenseits von Top-K: Relevanzschwellenwerte, hybride Suche und Neubewertung in RAG

Erfahren Sie, warum eine Vektordatenbank zusammen mit einem LLM kein produktionsfähiges RAG-System darstellt, und wie Chunking, Ähnlichkeitsschwellenwerte, hybride Suche, Neubewertung und Evaluation diese Lücke schließen.

1628 Wörter

Retrieval-augmented Generation wird in der Regel als dreistufiger Prozess vorgestellt: Es werden Dokumente gefunden, die zur Frage passen, diese an ein Sprachmodell übergeben und dieses soll anschließend die Antwort schreiben. Das Konzept scheint einfach, doch seine Zuverlässigkeit zu gewährleisten ist nicht so einfach. Ein Pipeline-System, das eine Embedding-Suche direkt mit einem LLM verbindet, wird auch bei schwachem Kontext selbstbewusst antworten, genaue Identifikatoren übersehen und falsche Angaben machen, wenn in der Wissensdatenbank keine Informationen vorhanden sind. Genau hier versagt dieses naive Design – und welche Schritte, von der strukturorientierten Aufteilung bis zur messbaren Bewertung, es zu einer zuverlässigen Retrieval-Architektur machen.

Das naive Pipeline-System und seine versteckten Annahmen

Die Grundstruktur, auf der die meisten Tutorials basieren, sieht so aus: Dokumente werden in Abschnitte aufgeteilt, eingebettet, die Vektoren gespeichert, und bei einer Abfrage wird die Frage eingebettet, die top_k nächstgelegenen Abschnitte abgerufen und in die Anfrage eingefügt. Das funktioniert in einer Demo, geht aber stillschweigend davon aus, dass jeder Abschnitt eine sinnvolle Einheit ist und dass „nächstgelegen“ gleichbedeutend mit „relevant“ ist.

Abschnitte entlang der Dokumentstruktur

Betrachten wir ein Mitarbeiterhandbuch. Der schwache Ansatz teilt es in willkürliche 1.000-Zeichen-Schnitte auf, wodurch beispielsweise Richtlinien in der Mitte geteilt und das Ende eines Themas am Anfang eines anderen angehängt werden. Der stärkere Ansatz folgt dem eigenen Aufbau des Dokuments und erzeugt Abschnitte wie Fernarbeit, Sicherheit, Urlaub sowie Ausgaben.

Ein selbstständiger Abschnitt liefert dem Embedding-Modell genügend Kontext, um zu erfassen, worum es im Text tatsächlich geht und wie die darin enthaltenen Aussagen miteinander verbunden sind. Die resultierenden Vektoren sind sauberer, und die semantische Suche liefert relevantere Ergebnisse.

Top-K gibt die nächsten Ergebnisse zurück, nicht die relevanten

Bessere Abschnitte führen direkt zum nächsten Missverständnis. Die Einstellung top_k = 5 wird oft als „Gib mir die fünf relevanten Ergebnisse“ interpretiert. Tatsächlich werden damit jedoch die fünf nächsten Ergebnisse angefordert, unabhängig davon, ob einige davon gut sind oder nicht. Eine typische Score-Verteilung für eine Frage zum Remote Work könnte wie folgt aussehen:

Remote Work       0.62
Paid Time Off     0.36
Security          0.30
Expenses          0.28
Other Policy      0.24

Der erste Treffer ist vermutlich das, was der Benutzer benötigt. Die anderen vier sind schwache Übereinstimmungen, die nur auf der Liste stehen, weil etwas die Plätze füllen musste. Wenn alle fünf an das Modell übergeben werden, vermischen sich nützliche Informationen mit möglicherweise nützlichem, aber nur lose verbundenem und irrelevantem Text. Das Modell muss nun selbst Signal von Rauschen trennen, was die Tokenkosten erhöht und die Antwort weniger vorhersagbar macht.

Unbeantwortbare Fragen benötigen ein eigenes Verhalten

Ein besonders wichtiger Fall ist eine Frage, die in der Wissensdatenbank einfach nicht beantwortet werden kann – wie zum Beispiel „Wie hoch ist die Krankenversicherungs-Pauschale des Unternehmens?“ – wenn das Handbuch sie nie erwähnt. Top-K wird dennoch fünf Ergebnisse liefern, und ein naiver Ablauf wird das nächstliegende als Beweis betrachten und eine Schätzung abgeben.

Das richtige Verhalten in einem Unternehmensumfeld besteht darin, mitzuteilen, dass die verfügbaren Dokumente nicht ausreichende Informationen enthalten. Ein gut konzipiertes System sollte in der Lage sein, etwas wie Folgendes zurückzugeben:

No sufficiently relevant context was found.

Fügen Sie einen Relevanzfilter zwischen der Abfrage und dem Modell hinzu

Um sowohl schwache Übereinstimmungen als auch unbeantwortbare Fragen zu handhaben, ist ein weiterer Schritt erforderlich. Der naive Ablauf ist:

Vector Search
   ↓
Top-K
   ↓
LLM

Der verbesserte Ablauf betrachtet Top-K als Kandidatenliste und fügt einen Filter vor dem Modell ein:

Vector Search
   ↓
Top-K candidates
   ↓
Relevance Filter
   ↓
LLM

Der einfachste Filter ist eine Ähnlichkeitsschwelle. Kandidaten, die dieser Schwelle entsprechen oder sie überschreiten, bleiben bestehen:

score >= threshold
    → keep

und alles darunter wird verworfen:

score < threshold
    → discard

Falls nichts übrig bleibt, gibt das System anstelle eines Aufrufs des Modells mit Störungen die Antwort „kein relevanter Kontext“ zurück.

Aus Messungen die Schwelle bestimmen

Die Schwellenwert sollte aus den Daten abgeleitet werden. Ein kleines Experiment mit einem Datensatz zu Unternehmenshandbüchern verglich die Erinnerungsrate bei beantwortbaren („bekannten“) Abfragen mit der Ablehnungsrate bei unbeantwortbaren („unbekannten“) Abfragen für mehrere Werte:

| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
|      0.20 |               100% |                      0% |
|      0.25 |               100% |                      0% |
|      0.30 |               100% |                     50% |
|      0.35 |               100% |                     50% |
|      0.40 |               100% |                     50% |
|  **0.45** |           **100%** |                **100%** |
|      0.50 |               100% |                    100% |
|      0.55 |               100% |                    100% |

In diesem Datensatz war 0,45 die erste Schwellenwert, die alle bekannten Abfragen berücksichtigte und gleichzeitig alle unbekannten abwies, wodurch sie die beste Trennung unter den getesteten Werten darstellte. Diese Zahl ist jedoch nicht übertragbar. Ähnlichkeitswerte hängen vom Embedding-Modell, dem Korpus, der Formulierung der Abfragen sowie der Suchkonfiguration ab; unterschiedliche Modelle liefern ihre Werte in sehr verschiedenen Bereichen. Die Abweisungsrate, die in 50%-Schritten variiert, deutet zudem auf eine sehr kleine Anzahl unbekannter Abfragen hin. Daher benötigt eine echte Implementierung ein größeres, gelabeltes Datensatz, bevor man dem Schwellenwert vertrauen kann. Was übertragen werden kann, ist die Methode: Das Suchverhalten anhand bekannter und unbekannter Abfragen messen und den Schwellenwert auf der Grundlage von Belegen statt aus Intuition wählen.

Suchen und Ranglisten erstellen sind unterschiedliche Aufgaben

Nehmen wir an, die Abfrage liefert 20 Kandidaten. Sie hat ihre Aufgabe erfüllt: Sie fand 20 Textabschnitte, die wahrscheinlich miteinander verbunden sind. Es bleibt noch eine Frage: Welche fünf davon bilden den besten Kontext für diese spezielle Frage? Das ist die Aufgabe der Neubewertung.

Die Abfrage wird so optimiert, dass möglichst viele Ergebnisse aus einer großen Sammlung erfasst werden, wodurch beispielsweise 10.000 Textabschnitte auf eine handhabbare Anzahl von Kandidaten reduziert werden:

10,000 chunks
      ↓
retrieval
      ↓
50 candidates

Die Neubewertung bewertet diese kleine Menge anschließend genauer, in der Regel mit einem Modell, das die Frage sowie jeden Kandidaten gemeinsam auswertet und die stärksten Ergebnisse behält:

50 candidates
      ↓
reranker
      ↓
5 strongest candidates

Der Ablauf sieht nun so aus:

Question
   ↓
Embedding
   ↓
Vector / Hybrid Search
   ↓
Candidate Set
   ↓
Reranking
   ↓
Best Context
   ↓
LLM

Semantische Suche übersieht exakte Begriffe

Embeddings sind hervorragend bei der Bedeutungserkennung, doch Unternehmensdaten enthalten viele Token, deren Wert in ihrer genauen Schreibweise liegt:

INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345

Ein Embedding-Modell kann erkennen, dass eine Anfrage auf einen Verbindungsfehler Bezug hat, indem es den Abschnitt mit dem genauen Code ERR_CONNECTION_RESET unter einem allgemeinen Netzwerktext rangiert.

Hybride Suche kombiniert beide Signale

Die gängige Lösung ist die hybride Suche, bei der semantische und lexikalische Suchverfahren gemeinsam genutzt werden:

Semantic Search
+
Keyword / Lexical Search

Sowohl Suchverfahren laufen für dieselbe Frage, und ihre Ergebnisse werden zu einem einzigen Kandidatensatz zusammengeführt – oft mithilfe einer Fusionsmethode, die die beiden Ranglisten kombiniert:

Question
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
   Semantic Search      Keyword Search
          │                   │
          └─────────┬─────────┘
                    ↓
              Candidate Set

Das System erkennt semantische Ähnlichkeit bei paraphrasierten Fragen sowie eine exakte Termbestimmung für Identifikatoren.

Der produktionsorientierte Workflow

Sobald alle Schritte vorhanden sind, sieht der gesamte Ablauf wie folgt aus:

Documents
    ↓
Semantic Chunking
    ↓
Embeddings
    ↓
Vector / Hybrid Retrieval
    ↓
Relevance Filtering
    ↓
Reranking
    ↓
LLM
    ↓
Answer + Sources
    ↓
Evaluation + Observability

Das Modell befindet sich nicht mehr direkt hinter einer Vektordatenbank. Eine echte Abrufarchitektur steht nun zwischen dem Benutzer und dem LLM. Für einen tieferen Einblick in die Rangierungsphase sowie in die Situationen, in denen ihre Latenz sich lohnt, lesen Sie unseren Artikel darüber, warum eine erneute Rangierung ihre Latenz rechtfertigen muss.

Eine Basis, die man zuerst erstellen sollte

Eine gute Möglichkeit, diese Abwägungen kennenzulernen, besteht darin, schrittweise zu entwickeln. Eine einfache Basis kann Python, FastAPI, OpenAI-Embeddings und LLMs sowie Pinecone als Vektorlagereinrichtung kombinieren, zusammen mit:

heading-basiertes Aufteilen in Blöcke und Metadaten zu diesen Blöcken
semantischer Abruf mit einer konfigurierbaren top_k-Wertung
Filtern nach Ähnlichkeit
Zuordnung der Quelle
Bewertung des Abrufs

Ihr Ablauf ist wie folgt:

Question
   ↓
Embedding
   ↓
Pinecone Retrieval
   ↓
Top-K Candidates
   ↓
Similarity Threshold
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer + Sources

Der natürliche nächste Schritt besteht darin, hybride Suchverfahren sowie Neubewertungsmethoden hinzuzufügen und diese mit derselben Bewertungsgrundlage unter Verwendung desselben Datensatzes zu vergleichen, sodass jede Verbesserung gemessen und nicht nur angenommen wird.

Messung der Zuverlässigkeit des Systems

„Funktioniert der Chatbot?“ ist keine nützliche Frage. Teilen Sie sie in messbare Dimensionen auf:

Qualität der Informationsbeschaffung: Wurde überhaupt die richtige Information zurückgegeben?
Qualität der Rangliste: Landete der nützlichste Kontext ganz oben?
Begründetheit: Wird die Antwort durch den gefundenen Kontext gestützt?
Genauigkeit der Zitationen: Untermauern die zitierten Quellen die Aussagen?
Bearbeitung unbekannter Abfragen: Erkennt das System, wenn die Antwort nicht in der Wissensdatenbank vorhanden ist?

Verzögerung: Wie lange dauern die Abruf- und Generierungsprozesse zusammen?

Kosten: Wie viel kostet jede Abfrage?

Das Ziel verschiebt sich von „Kann die App Fragen beantworten?“ zu „Können wir messen, ob die Abrufarchitektur zuverlässig ist?“

Wichtige Erkenntnisse

RAG bedeutet mehr als nur dem LLM Zugang zu Dokumenten zu geben; die schwierigen Entscheidungen betreffen, was abgerufen werden soll, wem man vertrauen kann, was weitergeleitet werden muss und wann abgelehnt werden sollte.
top_k garantiert die Menge, nicht jedoch die Relevanz – filtern Sie daher die Kandidaten mit einem auf Ihren eigenen Daten kalibrierten Schwellenwert.
Hybride Suchverfahren erkennen die genauen Identifikatoren, die durch Embeddings unklar werden, und das Neuranking wandelt eine breite Kandidatenliste in präzisen Kontext um.
Die Qualität der Antworten wird größtenteils bereits vor dem Zugriff des Modells auf den Kontext bestimmt: Besserer Kontext führt zu besseren Antworten und zu zuverlässigeren Systemen.
Betrachten Sie die Produktions-RAG-Lösung als ein Architekturproblem mit messbaren Phasen und nicht als eine einfache Integration von LLMs.