Die meisten RAG-Tutorials enden genau dort, wo die Produktion beginnt. Man teilt seine Dokumente in 512-Token-Chunks auf, schickt sie durch ein einzelnes Embedding-Modell und ruft eine Vektordatenbank mit einfachem Top-k-Retrieval auf. In einer Demo sieht das überzeugend aus. Fragt man den Bot nach der Urlaubsrichtlinie des Unternehmens, liefert er einen zusammenhängenden Absatz. Alle nicken. Leider lügen Demos.

Die Produktion deckt jede Abkürzung auf. Feste Chunks schneiden rechtliche Verträge mitten in Freistellungsklauseln durch. API-Dokumentationen verwandeln sich in überlappendes Rauschen, das das eigentlich benötigte Signal übertönt. Die Latenz schleicht sich ein, bis die Nutzer die Abfrage abbrechen, noch bevor die Antwort eintrifft. Wir sind gegen diese Wand gestoßen und mussten alles neu aufbauen. Unsere Retrieval-Schicht hat sich von „semantischer Suche und Hoffnung“ zu einer messbaren, instrumentierten Pipeline entwickelt. Das Ergebnis war ein Recall von 95 % und eine Reduzierung der Latenz um 40 %. Hier ist das, was tatsächlich funktioniert hat.

Passen Sie die Chunking-Strategie an das Dokument an

Der Standard von 512 Token hält sich nur deshalb, weil er einfach ist, nicht weil er korrekt ist. Verschiedene Dokumente vermitteln Informationen auf unterschiedliche Weise, und Ihre Chunking-Strategie sollte dies widerspiegeln.

Verwenden Sie für Rechtsverträge rekursives Chunking, das strukturelle Grenzen respektiert. Rechtssprache ist verschachtelt. Eine Klausel hängt von dem darüber liegenden Abschnitt ab, und ein fester Schnitt mitten im Satz zerstört die Logik einer Verpflichtung. Rekursives Chunking versucht zuerst, an natürlichen Trennzeichen zu splitten – erst Absätze, dann Sätze –, bevor ein Token-Limit erzwungen wird. So bleiben Freistellungs- oder Haftungsklauseln intakt.

Verwenden Sie für API-Dokumentationen funktionsbewusstes Chunking. Entwickler suchen nicht nach zufälligen Absätzen; sie suchen nach Endpunkten, Parametern und Fehlersignaturen. Ein Chunk sollte die vollständige Funktionssignatur, deren Beschreibung und das Return-Schema als eine logische Einheit enthalten. Wenn Sie diesen Block in der Mitte teilen, liefert das Retrieval-System nur die halbe Kontextmenge zurück, und das Generierungsmodell halluziniert den Rest.

Verlassen Sie sich bei Support-Tickets auf semantisches Chunking, das den Gesprächsverläufen folgt. Support-Threads sind linear und repetitiv. Ein Kunde wiederholt das Problem, ein Agent bittet um Logs, der Kunde hängt sie an. Jeder Gesprächsschritt ist eine eigene semantische Einheit. Das Chunking nach Gesprächsschritten bewahrt die Information, wer was wann gesagt hat – was entscheidend ist, wenn der Nutzer fragt: „Was hat der Agent am Dienstag vorgeschlagen?“

Versuchen Sie es bei internen Wikis mit agentischem Chunking. Geben Sie einem LLM einen Abschnitt und lassen Sie es entscheiden, wo ein Thema endet und ein anderes beginnt. Das kostet beim Ingest mehr Zeit, aber Wikis sind unordentlich. Seiten enthalten nicht zusammenhängende Updates von verschiedenen Teams, und eine vom Menschen definierte Grenze hilft selten. Wenn man ein Modell die Grenzen basierend auf Themenwechseln ziehen lässt, reduziert dies das Rauschen drastisch.

Das Ausführen mehrerer Strategien in einer Pipeline erfordert, Dokumente beim Ingest nach Typ zu taggen. Diese kleine Portion Schema-Disziplin zahlt sich sofort aus.

Kombinieren Sie Suchmethoden, anstatt sich für eine zu entscheiden

Vektorsuche versteht die Absicht, scheitert aber routinemäßig an exakten Treffern. Fragt man nach dem Fehlercode ERR_CONNECTION_REFUSED oder einer bestimmten SKU, liefern dichte Embeddings oft konzeptionell ähnliche, aber faktisch falsche Ergebnisse. BM25, die klassische Sparse-Keyword-Retrieval-Methode, verarbeitet exakte Zeichenfolgen hervorragend, übersieht aber semantische Nuancen. Sie benötigen beides.

Nutzen Sie hybrides Retrieval. Führen Sie die Vektorsuche und BM25 parallel aus. Kombinieren Sie diese anschließend mit Reciprocal Rank Fusion (RRF). RRF belohnt Dokumente, bei denen sich beide Methoden auf die Relevanz einigen, während gleichzeitig starke Kandidaten aus beiden Ansätzen hervorgehoben werden. Die Mathematik dahinter ist einfach und das Ergebnis stabil: Keine einzelne Retrieval-Methode dominiert das endgültige Ranking.

Fügen Sie nach der Fusion einen Cross-Encoder-Reranker hinzu. Die erste Stufe – Vektor- plus Sparse-Retrieval – ist schnell und breit gefächert. Der Cross-Encoder bewertet dann jedes Abfrage-Dokument-Paar mit voller Aufmerksamkeit, was bedeutet, dass er den Kandidaten tatsächlich im Abgleich mit der ursprünglichen Frage liest. Ja, das erhöht die Latenz. In unserem Fall um etwa fünfzig bis hundert Millisekunden. Aber der Gewinn an Präzision ist so deutlich, dass der Kompromiss offensichtlich ist. Wenn Ihnen der Recall wichtig ist, können Sie es sich nicht leisten, diesen Schritt zu überspringen.

Korrigieren Sie die Abfrage, bevor Sie den Index korrigieren

Nutzer schreiben Abfragen nicht für Ihre Suchmaschine. Sie schreiben sie für Menschen. „Es funktioniert nicht“ ist eine häufige Support-Anfrage. Eine vage Funktionsbeschreibung ist eine typische Suche im internen Wiki. Wenn Sie den Index mit diesem rohen Input durchsuchen, erhalten Sie nur Müll zurück.

Transformieren Sie die Abfrage, bevor sie den Retriever erreicht.

Nutzen Sie Query-Expansion, um mehrere Versionen der Benutzeranfrage zu generieren. Wenn jemand „server down“ eingibt, sollte Ihr System auch nach „service unavailable“, „502 error“ und „connection timeout“ suchen. Die Abdeckung dieser Intent-Varianten hat unseren Recall von 78 % auf 96 % gesteigert. Es ist ein einziger Schritt, der im Vergleich zum Gewinn fast nichts kostet.

Nutzen Sie Query-Dekomposition für komplexe Fragen. Wenn ein Benutzer etwas fragt wie: „Wie migriere ich von der Legacy-Billing-API zur neuen und welche Breaking Changes betreffen Enterprise-Accounts?“, brechen Sie dies in Unterfragen auf. Eine Unterfrage zielt auf die Migrationsschritte ab. Eine andere auf unternehmensspezifische Breaking Changes. Jede trifft einen anderen Teil des Index. Das nachgelagerte Sprachmodell synthetisiert die endgültige Antwort aus gut abgerufenen Chunks, anstatt in einem verrauschten Kontextfenster zu raten.

Hören Sie auf, Hyperparameter zu raten

Sobald Sie über mehrere Chunking-Strategien, hybrides Retrieval und Query-Transformation verfügen, stehen Sie vor einem kombinatorischen Problem. Chunk-Größe, Overlap, Fusionsgewichte, Reranker-Tiefe und die Anzahl der Expansionen interagieren alle miteinander. Das isolierte Anpassen eines Parameters beeinträchtigt einen anderen. Eine Grid Search über diesen gesamten Raum zu führen, ist verschwenderisch und langsam.

Nutzen Sie stattdessen die Bayessche Optimierung. Betrachten Sie dies wie einen Machine-Learning-Tuning-Job. Definieren Sie Ihr Ziel klar: Maximieren Sie den Recall, während Sie die Latenz unter einem bestimmten Schwellenwert halten. Erstellen Sie einen Golden Dataset – ein paar hundert repräsentative Fragen, bei denen Sie genau wissen, welche Chunks abgerufen werden sollten. Lassen Sie die Bayessche Suche dann den Konfigurationsraum effizient explorieren. Sie erstellt ein probabilistisches Modell dessen, was funktioniert, und testet als Nächstes die vielversprechendsten Bereiche.

Jede Kandidatenkonfiguration muss den Golden Dataset bestehen, bevor sie das Staging erreicht. Wenn eine neue Chunk-Größe den Recall senkt oder ein schwererer Reranker Sie über das Latenzbudget hinaus treibt, erkennt die Optimierung dies automatisch. Das nimmt die Subjektivität aus der Diskussion. Sie hören auf zu debattieren, ob 256 oder 512 Token „besser“ sind, und fangen an, die Ergebnisse zu lesen.

Das Ergebnis

Die Änderungen an der Pipeline haben sich genau so multipliziert, wie wir es gehofft hatten.

  • Recall@10 stieg von 78 % auf 95 %.
  • P95-Latenz sank von 850 ms auf 320 ms.
  • Halluzinationsrate fiel von 12 % auf 3 %.
  • Kosten pro Abfrage sanken um 38 %, hauptsächlich weil ein besseres Retrieval es uns ermöglichte, ein kleineres Generierungsmodell und weniger Prompt-Token zu verwenden.

Die Reduzierung der Latenz hat einige Teammitglieder überrascht. Das Hinzufügen von Rerankern und Query-Expansion klingt danach, als würde es die Prozesse verlangsamen. Aber da sich die Retrieval-Qualität verbesserte, benötigte das Generierungsmodell weniger Prompting, weniger Spekulationen und weniger Wiederholungsversuche. Gutes Retrieval macht alles nachgelagerte günstiger.

Behandeln Sie Retrieval wie Infrastruktur

Retrieval ist kein Notebook, das man einmal ausführt und dann vergisst. Es ist Infrastruktur und sollte wie Code verwaltet werden. Versionieren Sie Ihre Chunking-Strategien. Wenn das Rechtsteam eine neue Vertragsvorlage veröffentlicht, testen Sie Ihren rekursiven Splitter, bevor er in die Produktion geht. Pflegen Sie Ihren Golden Dataset als lebendige Dokumente, nicht als eine statische CSV aus dem letzten Quartal. Automatisieren Sie Ihre Evaluierungen in der CI, sodass ein Pull Request, der ein Embedding-Modell oder ein Fusionsgewicht ändert, einen Kommentar mit Recall- und Latenzzahlen erhält, noch bevor ein Mensch ihn überhaupt prüft.

Ihre Benutzer werden nie fragen, welches Embedding-Modell Sie verwenden. Sie werden sich nicht für Ihre Chunking-Heuristik oder Ihre Reranker-Architektur interessieren. Ihnen ist wichtig, ob die Antwort korrekt ist, ob sie schnell eintrifft und ob sie ihr vertrauen können. Bauen Sie eine Pipeline, die dieses Vertrauen verdient, messen Sie sie ehrlich und hören Sie auf, Retrieval wie einen nachträglichen Gedanken zu behandeln.

Quelle: Optimizing RAG At Scale
Diskutieren Sie mit: GyaanSetu AI Community