Du hast einen Chatbot auf die eigenen Dokumente gesetzt, die Wissensbasis ist sauber gepflegt, und trotzdem kommt bei bestimmten Fragen eine Antwort zurück, die falsch ist. Du suchst die Stelle im Dokument, und sie ist da. Sauber formuliert, eindeutig, genau die Antwort auf die Frage. Der Bot hat sie nur nie gesehen.
Das ist eine eigene Sorte Fehler, und sie liegt selten am Sprachmodell. Sie liegt an der Reihenfolge, in der die Suche ihre Treffer ausgibt.
Warum findet der Chatbot die Antwort nicht, obwohl sie im Dokument steht?
Der Index deiner Wissensbasis entsteht bevor die erste Frage gestellt wird. Beim Einlesen wird jeder Textabschnitt in einen Vektor übersetzt, also in eine Liste von Zahlen, die festhält, worum es in dem Abschnitt ungefähr geht. Kommt später eine Frage herein, wird auch die in einen Vektor übersetzt und mit allen gespeicherten verglichen. Gemessen wird dabei thematische Nähe. Ob ein Absatz genau die gestellte Frage beantwortet steckt in dieser Zahl nicht drin.
Das fällt erst auf, wenn du dir ansiehst, was die Suche zurückgibt. Die Stelle mit der Antwort ist dabei, aber vielleicht steht sie auf Platz acht. Weitergereicht ans Sprachmodell werden Platz eins bis fünf. Für das Modell existiert der richtige Absatz also nicht, und es formuliert seine Antwort aus dem, was thematisch am nächsten liegt. Heraus kommt etwas, das plausibel klingt aber daneben liegt.
In einer normalen Suchmaske wäre das kein Problem. Du überfliegst die ersten Treffer, scrollst weiter, klickst auf Platz acht und bist fertig. Ein RAG-System scrollt nicht. Es nimmt die obersten Treffer, packt sie in den Prompt und wirft den Rest weg. Wie so ein Aufbau grundsätzlich funktioniert, habe ich in Teil 2 der Selbstbau-Serie beschrieben, dort geht es um abgeschottete Wissens-Agenten auf dem eigenen Server.
Was passiert bei einer Suche in der Wissensbasis wirklich?
Die Kette ist kurz: Die Frage kommt herein, die Suche liefert Kandidaten, die obersten K wandern in den Prompt, das Modell formuliert daraus die Antwort.
Dieses K ist fix, und in den verbreiteten Baukästen ist es überraschend klein. LangChain gibt einem Retriever standardmäßig vier Treffer mit, LlamaIndex zwei. Wer eines der Frameworks nimmt und diesen Wert nie angreift, füttert sein Modell also mit zwei bis vier Absätzen. Wer misst und nachjustiert, landet meistens höher. Anthropic hat für die eigene Pipeline 5, 10 und 20 Abschnitte verglichen und mit 20 die besten Ergebnisse erzielt.
Das Prinzip bleibt in beiden Fällen dasselbe. Jeder Platz in der Rangliste ist eine Entscheidung darüber, was das Modell überhaupt wissen darf, und alles darunter könnte genauso gut gelöscht sein. Je kleiner dein K, desto härter trifft dich eine mittelmäßige Sortierung.
Dazu kommt eine zweite Schwäche. Reine Vektorsuche verallgemeinert gut und verliert dabei exakte Treffer. Fehlercodes, Artikelnummern, Eigennamen und Fachbegriffe landen in einer ungefähren Nachbarschaft, statt wörtlich zu matchen. Eine Stichwortsuche trifft die zuverlässig und scheitert dafür an Umschreibungen: Wer nach „Rückgabe" fragt, bekommt das Dokument nicht zu sehen, in dem durchgehend von „Retoure" die Rede ist. Lässt du beide Verfahren nebeneinander laufen und führst die Ergebnisse zusammen, holst du dir den Recall zurück, den jede Methode für sich liegen lässt. Recall heißt hier: wie viel von dem, was eigentlich passt, überhaupt im Kandidatenpool auftaucht.
Der Klassiker unter den Stichwortverfahren heißt BM25, ein Ranking nach Worthäufigkeit, das seltene Wörter höher gewichtet als häufige. Die Kombination aus beidem läuft unter dem Namen hybride Suche.
Beim Zusammenführen gibt es einen Stolperstein. Die Bewertungen der beiden Verfahren lassen sich nicht direkt vergleichen, weil sie auf verschiedenen Skalen liegen. Der übliche Ausweg heißt Reciprocal Rank Fusion und ignoriert die Bewertungen komplett: Gezählt wird ausschließlich der Platz in der jeweiligen Liste, und was in beiden Listen weit oben auftaucht, steigt dabei von selbst nach vorne.
Was macht ein Reranker anders?
Ein Reranker sortiert die Kandidaten noch einmal, bevor das Sprachmodell etwas zu sehen bekommt. Der Unterschied zur ersten Suche liegt darin, wie gerechnet wird. Die Vektorsuche übersetzt Frage und Dokument getrennt voneinander in Zahlen und vergleicht danach die beiden Ergebnisse. Ein Reranker bekommt beides gemeinsam als Paar vorgelegt und beurteilt genau diese Kombination: Beantwortet dieser Text diese Frage?
In der Fachsprache heißt das erste Bi-Encoder, weil beide Seiten einzeln kodiert werden, und das zweite Cross-Encoder, weil Frage und Text zusammen durch das Modell laufen. Der Cross-Encoder ist deutlich genauer und deutlich teurer, weil er für jedes Paar einmal rechnen muss, während der Bi-Encoder einmal pro Dokument beim Einlesen rechnet und danach nur noch vergleicht. Bei zehntausend Dokumenten wären das zehntausend Modellläufe pro Anfrage.
Deshalb läuft ein Reranker nur über die Handvoll Kandidaten aus der ersten Suche und nie über den ganzen Bestand. Die erste Stufe sorgt dafür, dass die richtige Stelle überhaupt dabei ist. Die zweite sorgt dafür, dass sie nach oben kommt.
Daraus folgt die wichtigste Grenze dieser Technik: Ein Reranker findet nichts. Er sieht ausschließlich die Liste, die ihm die Suche übergeben hat. Steht die entscheidende Stelle auf Platz 300 und du holst 20 Kandidaten, hilft dir keine noch so gute Neusortierung. Wer nach dem Einbau eines Rerankers keinen Effekt misst, sollte zuerst prüfen, ob die richtige Stelle überhaupt im Kandidatenpool landet. Wenn nicht, liegt das Problem bei der Suche oder beim Zerschneiden der Dokumente.
Wann lohnt sich ein Reranker, wann nicht?
Die Antwort lautet nicht „immer". Vier Situationen, in denen sich der zusätzliche Schritt auszahlt:
Viele ähnliche Dokumente im Bestand. Mehrere Fassungen derselben Richtlinie, ein Dutzend FAQ-Einträge zum selben Thema, Produktvarianten, die sich in einer Zeile unterscheiden. Hier liegen alle Kandidaten thematisch gleich nah, und die erste Suche hat kein Kriterium mehr, um zu unterscheiden.
Antworten, die in einem Detail stecken. Die Frage zielt auf eine Ausnahme, eine Frist, eine Bedingung. Das Dokument handelt im Großen von etwas anderem, und der eine Absatz, auf den es ankommt, prägt den Vektor des Abschnitts kaum.
Ein kleines, festes K. Sobald das Modell ohnehin nur eine Handvoll Abschnitte liest, entscheidet die Reihenfolge alles. Bei einem großzügigen K fällt eine mittelmäßige Sortierung weniger ins Gewicht.
Wenn eine falsche Auskunft weh tut. Compliance, Support mit rechtlicher Relevanz, medizinische oder technische Sicherheitsthemen. Dort ist eine falsche Antwort mehr als eine schlechte Kennzahl.
Die Gegenprobe gehört dazu. Bei einer kleinen Wissensbasis mit klar getrennten Themen bringt Reranking wenig. Wenn die Suche ohnehin fast immer den richtigen Treffer auf Platz eins hat, verschiebt der zweite Durchgang nur noch Rauschen und kostet dich Latenz und Geld.
Und mehr Kandidaten sind nicht automatisch besser. Eine Untersuchung mehrerer Reranker über akademische und Unternehmensdatensätze hinweg zeigt, dass die Qualität mit wachsender Kandidatenzahl zuerst steigt, dann abflacht und ab einer bestimmten Grenze wieder fällt (Drowning in Documents, arXiv, November 2024). Die Erklärung ist plausibel: Je mehr Schrott in der Liste steht, desto größer die Chance, dass ein irrelevanter Absatz zufällig hoch bewertet wird und den richtigen verdrängt. Interessant an derselben Arbeit ist, dass listenweise arbeitende Sprachmodell-Reranker beim Hochskalieren robuster blieben als klassische Cross-Encoder. Wo dein eigenes Optimum liegt, musst du messen, üblicherweise irgendwo zwischen 20 und 200 Kandidaten.
Was bringt das messbar?
Belastbare unabhängige Benchmarks zu Reranking in der Praxis gibt es kaum. Die brauchbarste öffentliche Zahlenbasis kommt von Anthropic selbst, gemessen an der eigenen Pipeline über mehrere Wissensdomänen hinweg, darunter Codebases, Belletristik und wissenschaftliche Papers. Als Fehler zählt dabei ein Durchlauf, bei dem der benötigte Abschnitt in den Top 20 gar nicht auftaucht. Der Reranker bekam dort 150 Kandidaten vorgelegt und gab die besten 20 weiter.
| Aufbau | Fehlerrate bei den Top-20-Treffern | Verbesserung |
|---|---|---|
| Basis (Embeddings) | 5,7 % | |
| Contextual Embeddings | 3,7 % | 35 % weniger Fehltreffer |
| plus Contextual BM25 | 2,9 % | 49 % |
| plus Reranking | 1,9 % | 67 % |
Quelle: Anthropic, „Introducing Contextual Retrieval", 19.09.2024. Das ist deren eigene Auswertung an der eigenen Pipeline, keine unabhängige Studie, und die Größenordnung deiner eigenen Daten kann davon abweichen.
Zwei Dinge sind an der Tabelle bemerkenswert. Der letzte Schritt schneidet noch einmal ein Drittel der verbliebenen Fehler weg, und er ist der einzige, für den du deine Dokumente nicht neu einlesen musst. Alle Stufen darüber bedeuten einen weiteren Durchlauf über den gesamten Bestand. Den Reranker hängst du zwischen Suche und Prompt, der Rest deiner Pipeline bleibt, wie er ist.
Den Vorbehalt schreibt Anthropic selbst dazu: Mehr Kandidaten zu reranken bringt bessere Ergebnisse und kostet mehr Latenz und Geld. Diese Abwägung nimmt dir niemand ab.
Läuft der Reranker immer mit?
Bei ServasBot, meiner Chatbot-Plattform, ist er produktiv im Einsatz und pro Chatbot zuschaltbar. Standardmäßig bleibt er aus. Ein Bot mit einer überschaubaren, thematisch klar getrennten Wissensbasis kommt ohne ihn aus, und jeder Modellaufruf, den du dir sparst, ist Latenz und Geld, das du nicht ausgibst. Eingeschaltet wird er dort, wo viele ähnliche Dokumente im Spiel sind.
Dazu gehört, dass ein Ausfall nichts umbringt. Scheitert der zusätzliche Schritt, fällt die Suche auf ihre vorherige Reihenfolge zurück und die Antwort kommt trotzdem.
Was du davon mitnimmst
Reranking ist kein Schalter, den man für mehr Qualität umlegt. Es beantwortet eine bestimmte Sorte Fehler: Die Antwort war da, sie ist nur nicht oben gelandet. Wenn du diese Sorte Fehler in deinen Logs wiederfindest, lohnt sich der zweite Durchgang. Wenn nicht, sparst du dir einen Modellaufruf pro Anfrage.
Womit die eigentliche Frage offen bleibt, nämlich woher du weißt, ob eine Änderung an der Suche etwas gebracht hat. Reranken kannst du, messen musst du. Ein fixer Satz typischer Fragen mit den erwarteten Quellen, gegen den jede Änderung läuft, klärt das an einem Nachmittag. Wie so ein Golden Set aufgebaut wird und welche Metriken sich dafür eignen, steht in KI-Evaluation mit Golden Set.