Die meisten RAG-Prototypen sehen unter der Haube gleich aus. Jemand füttert eine Pipeline mit einem PDF, schneidet den Text in ordentliche 512-Token-Chunks, lädt sie in eine Vektordatenbank und hält die Arbeit für erledigt. Für eine Flur-Demo mag das beeindruckend wirken. In der Produktion bricht es zusammen.

Ein fester Chunk kümmert sich nicht darum, was er abschneidet. Er wird einen Rechtsvertrag mitten in einer Freistellungsklausel teilen. Er wird fünf nicht zusammenhängende API-Endpunkte in dasselbe Kontextfenster stopfen und das Modell in Rauschen ertränken. Er wird Sie dazu zwingen, mehr Fragmente als nötig abzurufen, was die Latenz aufbläht und Token verschwendet. Das Ergebnis sind halbe Antworten, Halluzinationen und frustrierte Nutzer.

Wir haben unsere Retrieval-Schicht bis auf die Grundmauern abgerissen und komplett neu aufgebaut. Das Ergebnis war ein System, das eine Recall-Rate von 95 Prozent erreichte, während die Latenz um 40 Prozent gesenkt wurde. Hier ist genau erklärt, wie wir das gemacht haben.

Warum feste Chunks in der Produktion scheitern

Der Standardwert von 512 Token ist keine Designentscheidung. Er ist ein Nebenprodukt der Kontextfenster früher Embedding-Modelle und der sauberen Standardeinstellungen gängiger Bibliotheken. Er ist leicht zu implementieren, aber katastrophal, wenn man sich darauf verlässt.

Dokumente sind nicht einheitlich. Eine Rechtsklausel kann siebenhundert Token lang sein, ohne dass ein klarer Bruch erfolgt. Schneidet man sie bei fünfhundertzwölf ab, entstehen zwei verwaiste Fragmente. Wenn ein Anwalt oder ein Compliance-Beauftragter nach Haftungsobergrenzen fragt, liefert das System nur die halbe Verpflichtung zurück. Das Sprachmodell halluziniert die fehlende Hälfte oder, schlimmer noch, leugnet, dass eine Obergrenze existiert.

API-Dokumentationen leiden unter dem umgekehrten Problem. Ein 500-Token-Chunk könnte ein ganzes Modul verschlucken: Authentifizierungs-Header, Fehlercodes, Rate-Limits und Webhook-Schemas. Wenn ein Entwickler fragt, wie er AUTH_4027 behandeln soll, liefert der Retriever ein Durcheinander nicht zusammenhängender Funktionen. Das Modell hat keine andere Wahl, als sie zu einem generischen Brei zusammenzufassen.

Schlechtes Chunking bläht zudem die Latenz auf. Schwache Fragmente bedeuten, dass Sie ein größeres top-k benötigen, um ein Thema abzudecken. Mehr Chunks bedeuten längere Prompts. Längere Prompts bedeuten langsamere Generierung und höhere Kosten. Die User Experience stirbt durch tausend kleine Schnitte.

Den Chunk an das Dokument anpassen

Wir haben aufgehört, Token zu zählen, und angefangen, das Material zu lesen. Die richtige Chunking-Strategie hängt von der Struktur der Quelle ab.

Rechtsdokumente benötigen rekursives Character-Chunking mit klauselbewussten Grenzen. Der Splitter respektiert die Hierarchie: Er sucht zuerst nach Abschnittsüberschriften, dann nach nummerierten Absätzen und schließlich nach natürlichen Satzenden. Er trennt niemals eine Unterklausel oder spaltet eine Verpflichtungsphrase über Chunks hinweg. Wenn Sie einen Abschnitt über Freistellungen abrufen, erhalten Sie die vollständige Klausel, die Obergrenze und die Ausnahmen.

API-Dokumentationen erfordern struktur-awarem Chunking. Wir parsen nach Funktionsdefinitionen, nicht nach Token-Budget. Jeder Chunk enthält eine vollständige Funktionssignatur, ihre Parameterbeschreibungen und die unmittelbar angrenzenden Hinweise zur Fehlerbehandlung. Wenn ein Entwickler nach einer bestimmten Methode sucht, erhält er den gesamten Vertrag und nicht nur ein Fragment, das in einem willkürlichen Split gefangen ist.

Support-Tickets sind verrauscht und nicht linear. Ein Thread kann mit einem Bug-Report beginnen, einen Workaround einführen und mit einer internen Eskalationsnotiz enden. Semantisches Chunking erkennt Themenwechsel, indem es die Embedding-Ähnlichkeit zwischen Sätzen misst. Wir erlauben Brüche nur an natürlichen thematischen Grenzen, sodass eine Konversation über Login-Fehler getrennt von einem Follow-up zu Abrechnungszyklen bleibt.

Wikis waren am schwierigsten. Sie sind weitläufig, vernetzt und locker organisiert. Wir haben agentisches Chunking eingesetzt, bei dem ein leichtgewichtiges LLM eine Seite liest und die Brüche basierend auf der thematischen Kohärenz entscheidet. Das kostet bei der Ingestion etwas mehr, aber die resultierenden Chunks sind in sich geschlossen und abrufbereit. Eine Seite über Best Practices für das Deployment wird in logische Einheiten unterteilt: Pre-Flight-Checks, Rollback-Verfahren und Monitoring-Setup, anstatt in willkürliche Textblöcke.

Hybrides Retrieval: Keywords und Vektoren vereint

Dichte Vektorsuche versteht Bedeutung. Sie ist jedoch miserabel bei exakten Zeichenfolgen. Wenn ein Nutzer nach einem präzisen Fehlercode wie AUTH_4027 oder einem Kundennamen wie "Stark Industries" sucht, können Vektor-Embeddings das Ziel verfehlen, da sie auf konzeptionelle Nähe und nicht auf Genauigkeit auf Zeichenebene optimiert sind.

Die reine Stichwortsuche mittels BM25 hat den umgekehrten Nachteil. Sie wird AUTH_4027 perfekt finden, aber die konzeptionelle Brücke zwischen "Authorization Failure" und "Login denied" verpassen.

We run both in parallel. BM25 and vector search operate independently over the same corpus. Their result lists are merged using Reciprocal Rank Fusion, which reorders candidates by balancing their positional ranks. You do not need calibrated weights. You simply get the precision of exact match and the intuition of semantic search in a single ranked list.

Then we add a cross-encoder reranker. This is a separate model that scores each passage against the original query, producing a relevance signal far finer than either retriever alone. It adds about 50 milliseconds of latency. It increases recall by 15 percent. If you care about answer quality, that trade is non-negotiable.

Query Expansion: Fix the Search Before It Starts

Bad queries are the dirty secret of every retrieval system. Users do not write like your embedding space. They type "it broke." They paste truncated stack traces. They use internal jargon your index has never seen.

We transform the query before it ever touches the index. First, we expand a single query into three to five diverse search terms. If the original is "payment failed," we also search for "transaction error," "billing declined," and "charge unsuccessful