Reranking ist ein zweiter Retrieval-Durchlauf, der jede Kandidatenpassage gegen die tatsächliche Frage liest und neu sortiert, sodass die wahre Antwort auf Rang 1 wandert. Die meisten Finance-RAG-Systeme lassen ihn aus, und so bleibt die korrekte Passage auf Rang 14 stehen, wo der Generator sie nie liest. Genau in dieser Lücke zwischen „abgerufen” und „sortiert” sickert die Genauigkeit leise ab.
First-Pass-Retrieval, ob Vektor, BM25 oder eine Hybridform aus beidem, ist auf Recall getrimmt. Es wirft ein weites Netz aus und liefert ein paar Dutzend Passagen zurück, die alle plausibel relevant aussehen. Das Generierungsmodell liest dann nur die obersten drei bis fünf Chunks. Wenn die Passage, die das richtige Umsatzsegment oder den richtigen Covenant-Schwellenwert nennt, auf Rang acht steht, antwortet das Modell aus dem, was es tatsächlich in die Auswahl geschafft hat. Die Antwort liest sich gut und ist falsch, oder sie stützt sich auf die falsche Entität. Nichts weiter unten in der Kette schlägt Alarm, weil das Retrieval-Log gesund aussieht. Der Recall war hoch. Die Precision am Punkt der Verwendung war es nicht.
Was ein First-Pass-Retriever falsch macht
Ein Bi-Encoder embedded Query und Passagen getrennt und vergleicht sie über ein Skalarprodukt. Er muss das, denn genau das macht den Index in Millisekunden über Millionen von Chunks durchsuchbar. Aber es bedeutet, dass das Modell Query und Passage nie gemeinsam sieht. Es approximiert Relevanz aus zwei isoliert berechneten Vektoren, und auf Finanztexten verrutscht diese Approximation auf vorhersehbare Weise.
- Zwei Passagen über dieselbe Kennzahl für unterschiedliche Entitäten sehen im Embedding-Raum nahezu identisch aus. Fragen Sie nach der Leverage Ratio des einen Emittenten, und die Top-Treffer mischen die eines Peers hinein, weil „net leverage” den Vektor dominiert und der Entitäts-Token ihn kaum bewegt.
- Point-in-Time-Unterscheidungen kollabieren. Die Q2- und die Q3-Version derselben Offenlegung sind semantisch fast derselbe Satz. Ein Bi-Encoder hat keinen Grund, die zu bevorzugen, die zum Stichtag in der Frage passt.
- Negationen und Bedingungen werden eingeebnet. „Der Covenant gilt unterhalb des Schwellenwerts nicht” und „Der Covenant gilt oberhalb des Schwellenwerts” liegen dicht beieinander, und der Retriever kann nicht erkennen, welchen der Analyst braucht.
Ein Cross-Encoder-Reranker behebt genau diese Fehlerklasse. Er nimmt Query und eine Kandidatenpassage als einen einzigen Input und lässt volle Attention über beide laufen, sodass Entität, Datum und Bedingung im Kontext gelesen und nicht zu einem Vektor gemittelt werden. Er ist viel zu langsam, um über einen ganzen Korpus zu laufen. Deshalb ersetzt er das First-Pass-Retrieval nie. Er läuft über die 30 oder 50 Kandidaten, auf die der First Pass bereits eingegrenzt hat, und das ist eine Aufgabe, die er innerhalb eines normalen Requests erledigen kann.
Den Reranker hinzufügen, ohne die Latenz zu sprengen
Die naive Befürchtung lautet, dass ein zweites Modell im Pfad die Latenz verdoppelt. In der Praxis ist der Reranker begrenzte Arbeit, und die Grenze steuern Sie selbst. Das Muster, das wir in den meisten Finance-Builds verwenden:
- Der First Pass liefert eine feste Kandidatenmenge. Wir holen üblicherweise 40 bis 60 aus dem hybriden Retrieval, nicht mehr. Darüber hinaus steigen die Reranker-Kosten und die Recall-Gewinne flachen ab.
- Der Cross-Encoder bewertet alle Kandidaten gegen die Query in einem gebatchten Forward-Pass. Batching zählt. 50 einzelne Requests zu schicken, ist grundlos langsam.
- Kürzen Sie die Passagenseite. Wenn Ihre Chunks groß sind, braucht der Reranker von jedem nur so viel, um die Relevanz zu beurteilen. Die Input-Länge zu deckeln, ist der größte Latenzhebel nach der Kandidatenanzahl.
- Halten Sie den Reranker auf derselben Maschine wie den Retriever, oder nah dran. Ein Netzwerk-Hop pro Kandidat macht den Sinn zunichte.
Es gibt eine günstigere Variante, die es zu kennen lohnt. Sie müssen nicht immer reranken. Wenn die First-Pass-Score-Lücke zwischen Rang 1 und Rang 2 groß ist, ist das Retrieval zuversichtlich und Reranking ändert die Reihenfolge selten. Sie können es also überspringen und das Budget für die mehrdeutigen Queries aufheben, bei denen es Rang 1 tatsächlich bewegt. Gaten Sie den Reranker über die Score-Marge, und Sie geben Rechenleistung dort aus, wo sie die Antwort verändert.
Die Modellwahl ist weniger exotisch, als es klingt. Ein kleiner Cross-Encoder im Bereich von 100 bis 300 Millionen Parametern, feinjustiert oder von der Stange, bewältigt die meisten Finance-Korpora. Die Domänenanpassung, die sich auszahlt, kommt aus Trainingspaaren, die aus Ihrem eigenen Korpus stammen, nicht aus einem größeren Modell. Füttern Sie ihn mit Entitäts-fehlangepassten Hard Negatives und Falsches-Quartal-Hard-Negatives, den verwechselbaren Fällen, die der Bi-Encoder immer wieder falsch macht. Ein paar tausend davon bringen dem Reranker die Unterscheidungen bei, die hier zählen.
Beweisen, dass es die Zahl bewegt hat, und dann weiter beobachten
Ein Reranker ist seine Latenz nur wert, wenn Sie zeigen können, dass er die Retrieval-Qualität in den Fällen verändert hat, die Ihnen wichtig sind. Der einzige Weg, das zu wissen, ist ein zurückgehaltenes Eval-Set mit gelabelten korrekten Passagen. Messen Sie die Kennzahl, die darauf abbildet, wie die Passagen tatsächlich verwendet werden. Da der Generator die obersten paar Chunks liest, sind Recall@3 und MRR die Zahlen, die zählen, nicht Recall@50, den der First Pass ohnehin schon ausgereizt hat. Wenn sich Recall@3 nach dem Reranking kaum bewegt, verdient sich der Reranker seinen Platz nicht, und das sollten Sie im Eval herausfinden, nicht in der Produktion.
Bauen Sie das Eval-Set aus echten Queries, mit der Antwortpassage identifiziert von jemandem, der den Korpus kennt, und frieren Sie es ein. Wenn Sie den Reranker austauschen, die Kandidatenanzahl ändern oder die Dokumente neu chunken, lassen Sie dasselbe Set erneut laufen und vergleichen Sie. Ein Reranker driftet außerdem, während der Korpus wächst: neue Dokumenttypen und neue Entitäten, die seine Trainingspaare nie abgedeckt haben. Die verwechselbaren Paare, die er heute bewältigt, sind nicht die, die die Geschäftsberichte des nächsten Quartals hervorbringen werden. Behandeln Sie den Reranker als Komponente, die Sie nach einem festen Zeitplan neu vermessen, mit ihren Scores und ihren Inputs in denselben Audit-Trail geschrieben wie der Rest des Retrieval-Pfads, damit Sie, wenn eine Antwort angezweifelt wird, zeigen können, welche Passagen sortiert wurden und warum die oberste gewonnen hat.
Häufige Fragen
Brauche ich einen Reranker, wenn mein hybrides Retrieval bereits gut funktioniert?
Wenn Ihr First Pass die korrekte Passage auf Ihrem Eval-Set bereits auf Rang 1 platziert, dann nicht. Ein Reranker verdient sich seinen Platz, wenn die richtige Passage üblicherweise unter den Top 30, aber nicht unter den Top 3 landet. Das kommt häufig vor, sobald ein Korpus Geschäftsberichte, Verträge und interne Notizen mischt.
Wie viel Latenz fügt ein Cross-Encoder hinzu?
30 bis 50 Kandidaten mit einem kleinen Cross-Encoder gegen eine Query zu bewerten, dauert auf einer GPU typischerweise 50 bis 200 ms, auf der CPU länger. Sie steuern das, indem Sie die Kandidatenanzahl deckeln, die Passagenlänge kürzen und nur dann reranken, wenn die First-Pass-Scores mehrdeutig sind.
Kann ich statt eines dedizierten Modells ein LLM als Reranker verwenden?
Das können Sie, und listwise LLM-Reranking schneidet gut ab, aber es ist pro Query langsamer und teurer und schwerer für Reproduzierbarkeit festzunageln. Wir behalten üblicherweise einen dedizierten Cross-Encoder im Online-Pfad und reservieren LLM-Reranking für Offline-Eval oder die Analyse harter Fälle.