Kapitel 5 — Die Retrieval-Pipeline architektonisch denken

Fünfter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Eine einzelne Vektorsuche ist der Ort, an dem die meisten Prototypen aufhören, und der Ort, an dem die meisten Produktionsfehler beginnen. Das Kapitel geht den vollen Weg von einer halbfertigen Query zu den finalen Kandidaten, die den Generator erreichen — und warum es jede Stufe gibt.

Warum dieses Kapitel existiert

Die Kapitel 2 bis 4 haben einen Vektor-Store produziert: geparste Dokumente, sauber zerlegt, eingebettet, indiziert. Der naive nächste Schritt ist, die Nutzerquery einzubetten, eine Nearest-Neighbour-Suche zu fahren und die Top-k an den Generator zu füttern. Für triviale Korpora funktioniert das. In Produktion fast nie. Queries kommen unterspezifiziert herein und voll von Eigennamen, die der Embedder nie gesehen hat; Korpora enthalten Near-Duplikate, die jede einzelne Rangliste oben verstopfen; Bezeichner und Codes tragen Bedeutung, die der Embedder glättet.

Kapitel 5 handelt von der Architektur, auf die gereifte Systeme zulaufen. Das ist kein Forschungsartefakt. Das ist die Form, die Teams tatsächlich fahren, wenn Recall, Präzision und Latenz alle gleichzeitig halten müssen.

5.1 Warum eine einzelne Vektorsuche nicht reicht

Dense Retrieval schreibt die Ökonomie der Suche um, aber genau die Toleranz für Paraphrasen, die Embeddings nützlich macht, macht sie auch brüchig. Numerische Tokens, Paragraphenverweise, Transaktionscodes, Teilenummern — alles, wo die Oberflächenform die Bedeutung ist — landen in willkürlichen Ecken des Vektorraums. BM25, das einfach zählt, was da ist, hat dieses Problem nicht.

Die zwei Methoden versagen auf disjunkten Eingaben. Diese eine Beobachtung ist der ganze Fall für hybrides Retrieval und das erste Prinzip, auf dem das Kapitel ruht. Der Rest folgt: Wenn kein einzelner Retriever ausreicht, muss die Pipeline mehrere kombinieren, ihre Ranglisten ehrlich vereinen, echten Rechenaufwand auf einen finalen präzisen Durchgang verwenden und die Query vorbereiten, bevor irgendetwas davon beginnt.

5.2 Hybride Suche: Dense-Vektoren und BM25 parallel

Zwei Indizes über dieselben Chunks: ein Dense-HNSW- oder IVF-Index vom Embedder und ein sparse-invertierter Index aus BM25 oder SPLADE. Beide werden abgefragt, beide liefern Ranglisten, und die Ingestion-Pipeline schreibt im Gleichschritt in beide. BM25 ist nicht Legacy; es ist die zuverlässigste Keyword-Ranking-Funktion, die je entwickelt wurde, parameterarm aber nicht parameterfrei, und über die BEIR-Benchmark-Suite hinweg schlägt hybrides Retrieval Dense-only auf der Mehrheit der Out-of-Domain-Aufgaben. Der Abstand wächst, je weiter die Domäne von der Trainingsverteilung des Embedders abweicht.

Ein spezifisches Versagensmuster, das einen Namen verdient: BM25 muss für jede Sprache im Geltungsbereich korrekt tokenisiert werden. Einen japanischen Korpus mit dem englischen Default-Analyzer auszuliefern macht den BM25-Schenkel stumm zu purem Rauschen, und das System scheint zu funktionieren, weil der Dense-Schenkel die ganze Arbeit erledigt. Auch sparse Retrieval ist weitergezogen — SPLADE-artige gelernte sparse Modelle erben die operative Einfachheit von BM25 mit dem Recall-Verhalten eines Dense-Retrievers.

5.3 Reciprocal Rank Fusion und Cross-Encoder-Reranking

Der naive Weg, zwei Ranglisten zu kombinieren, ist ihre Scores zu addieren. Das funktioniert nicht — BM25-Magnituden sind unbegrenzt und korpusabhängig; Kosinus-Ähnlichkeiten liegen grob in [-1, 1]. Sie sind nicht kommensurabel, und jede feste Gewichtung ist ein dauerhaftes Tuning-Problem. Reciprocal Rank Fusion umgeht das, indem es die Scores wegwirft. Für jeden Kandidaten ist der fusionierte Score die Summe von 1/(k + Rang) über die Retriever, mit k = 60. Die Form ist oben steil und im Tail flach, Ergebnisse sind unempfindlich gegenüber k, und der Algorithmus komponiert natürlich mit Multi-Query-Expansion — sechs Listen aus drei Paraphrasen gegen zwei Retriever fusionieren mit derselben Code-Zeile.

RRF kann kein Dokument retten, das keiner der Retriever erfasst hat; diese Aufgabe gehört dem Query-Rewriting. Was es leistet, billig und ohne Hyperparameter, ist Retriever zu versöhnen, die unabhängig aufgerüstet und ausgetauscht werden — eine Pipeline, deren Fusion nicht nachjustiert werden muss, wenn ein Schenkel wechselt, ist dramatisch billiger zu warten.

Die Bi-Encoder, die diese Ranglisten produzierten, haben Query und Chunk nie zusammen gesehen. Ein Cross-Encoder-Reranker tut es — er konkateniert das Paar und lässt es gemeinsam durch einen Transformer laufen, der darauf feingetunt ist, einen Relevanz-Score auszugeben. Jeder Attention-Head sieht beide Seiten zugleich, und das Modell kann auf die spezifische Phrase in der Query achten, die zur spezifischen Phrase im Chunk passen soll. Es kann nicht vorberechnet werden, also ist es zu langsam als primärer Retriever, aber perfekt über die 50 bis 200 Kandidaten, die hybrides Retrieval an die Oberfläche bringt. Der Auftrieb auf NDCG@10 liegt typisch bei 5 bis 15 Punkten — größer als ein Wechsel des Embedding-Modells innerhalb der Bi-Encoder-Familie.

5.4 Query-Understanding: Rewriting, Expansion, HyDE

Alles oben nahm an, die Query sei wohlgeformt. Sie ist es selten. Ein Helpdesk-Nutzer tippt "Urlaub"; die Richtlinie sagt "Anspruch auf Jahresurlaub". Ein Entwickler tippt "auth fails 500"; das Runbook beschreibt "Authentifizierungsdienst gibt HTTP 500 mit Token-Validierungsfehler zurück". Die Arbeit muss auf der Query-Seite passieren. Drei Muster komponieren: Rewriting der Query in eine eigenständige Form (Pronomen auflösen, Akronyme erweitern, Sprache an den Korpus anpassen); Expansion in eine Handvoll Paraphrasen, die jede auf beide Retriever ausfächern; und HyDE, das ein kleines Modell um eine hypothetische Antwort bittet und diese statt der Frage einbettet. Der Korpus ist voll von Antworten, und Antworten sehen anderen Antworten ähnlicher als Fragen.

Das defensive Muster ist, die ursprüngliche Query neben der umgeschriebenen zu behalten und beide abzusenden. Der Output des Rewriters ist eine Hypothese, kein Ersatz. Die meisten "Retrieval-Regressionen" in agentischen Systemen sind tatsächlich Rewriting-Regressionen, und sie sind ohne stufenweise Telemetrie unsichtbar.

Was Kapitel 5 vorbereitet

Die so gezeichnete Pipeline ist zugleich die ganze Oberfläche, die ein Angreifer braucht, um sie zu unterwandern. Jede Stufe nimmt Input, produziert Output und vertraut den Daten, auf denen sie arbeitet. Der Korpus kann beim Ingest vergiftet werden; der Embedder kann durch adversariale Chunks manipuliert werden; der Reranker kann verzerrt werden; der Generator kann durch in abgerufenen Inhalten versteckte Anweisungen ausgetrickst werden. Von hier öffnet das Buch Teil IV, und der Rahmen wechselt von wie retrieve ich gut zu was passiert, wenn Retrieval angegriffen wird.

Als Nächstes — Kapitel 6: Bedrohungsmodelle und Schwachstellen von RAG. Dieselbe Offenheit, die RAG nützlich macht, ist auch die Oberfläche, die Angreifer ausnutzen — Korpus-Vergiftung, adversariales Retrieval, indirekte Prompt Injection, Embedding-Inversion und der Confused Deputy.