Die meisten Engineering-Teams stoßen bei der Retrieval-Augmented Generation an dieselbe Wand. Sie folgen dem Standard-Leitfaden aus Tutorials: Dokumente in feste Chunks von 512 oder 1024 Token zerlegen, diese durch ein einzelnes Embedding-Modell schleusen und eine Vektordatenbank mit einem einfachen Top-k-Lookup abfragen. In einer Präsentation sieht das solide aus. In der Produktion bricht es zusammen.

Feste Chunks berücksichtigen den Inhalt nicht. Sie teilen einen Rechtsvertrag bereitwillig mitten im Satz auf und lassen Haftungsklauseln zwischen zwei nicht zusammenhängenden Textstücken hängen. Sie werfen eine gesamte API-Endpunkt-Beschreibung in einen einzigen aufgeblähten Chunk, der so groß ist, dass der spezifische Parameter, nach dem Ihr Nutzer gefragt hat, im Rauschen untergeht. Und wenn das Retrieval langsam ist, wirkt sich jede Millisekunde Latenz direkt negativ auf die Benutzererfahrung aus. Das haben wir auf die harte Tour gelernt. Dann haben wir unseren Retrieval-Layer abgerissen und neu aufgebaut. Unser Recall bei zehn sprang von 78 % auf 95 %. Die Latenz stieg nicht an. Sie brach ein.

Das Problem mit Copy-Paste-RAG

Der Standard-RAG-Stack ist zu einer Art Standardeinstellung geworden. Kleine Chunks, ein Embedding-Modell, Vektorsuche, fertig. Dieser Ansatz übersteht eine Demo, weil Demos saubere Fragen und ordentliche Dokumente verwenden. Produktionsdaten sind niemals ordentlich.

Rechtsdokumente haben eine hierarchische Struktur. Abschnitte enthalten Unterabschnitte. Unterabschnitte enthalten Klauseln. Wenn man sie mit einem stumpfen Token-Zähler zerschneidet, zerstört man genau die Beziehungen, die das Modell für seine Schlussfolgerungen benötigt. API-Dokumentationen haben ebenfalls eine Struktur, aber sie ist anders. Eine Funktionssignatur, ihre Parameter, ihr Rückgabewert und ein Anwendungsbeispiel bilden eine logische Einheit. Presst man dies in ein festes Token-Fenster, schneidet man entweder das Beispiel ab oder füllt den Chunk mit nicht zusammenhängenden Funktionen auf. Support-Tickets sind unordentlich, konversationell und voller plötzlicher Themenwechsel. Wikis sind weitläufig und vernetzt. Eine einzige Chunking-Strategie kann nicht all diese Anforderungen erfüllen, und doch setzen Teams routinemäßig genau das ein. Wir haben aufgehört, so zu tun, als ginge das.

Strategisches Chunking: Die Methode an das Material anpassen

Wir sind zu inhaltsbewusstem Chunking übergegangen. Für Rechtsdokumente verwenden wir rekursives Chunking, das die Dokumentenhierarchie respektiert. Es hält Klauseln intakt und bewahrt die Eltern-Kind-Beziehungen zwischen den Abschnitten. Für die API-Dokumentation haben wir ein funktionsbewusstes Chunking entwickelt, das jede Funktion oder jeden Endpunkt als Grenze behandelt. Wenn eine Parameterbeschreibung länger ist, erweitert sich der Chunk um diese Funktion herum, nicht um ein Token-Limit. Für Support-Tickets verwenden wir semantisches Chunking, das natürliche Themenübergänge erkennt. Wenn ein Kunde plötzlich von einer Abrechnungsklage zu einem technischen Fehler wechselt, erfolgt der Split genau an diesem Punkt. Für Wikis und unstrukturierte Wissensdatenbanken verwenden wir agentisches Chunking, bei dem ein leichtgewichtiges LLM den Text auswertet und entscheidet, wo eine sinnvolle Grenze liegen sollte. Die Einrichtung dauert länger als bei einem Character-Split, aber es ist der Unterschied zwischen einem Retrieval, das funktioniert, und einem, das nur rät.

Hybrides Retrieval: Warum Vektorsuche allein nicht ausreicht

Die Vektorsuche versteht die Bedeutung, kann aber exakte Treffer übersehen. Wenn ein Nutzer einen Fehlercode wie ERR_CONNECTION_RESET_0x5F3 einfügt, könnte die semantische Ähnlichkeit ihn unter Absätzen einordnen, die lediglich allgemeine Netzfehler diskutieren. BM25 hingegen findet exakte Zeichenfolgen, übersieht aber die konzeptionelle Verwandtschaft. Man braucht beides.

Wir führen die Vektorsuche und BM25 parallel aus. Dann kombinieren wir die Ergebnisse mit Reciprocal Rank Fusion (RRF), das die Scores aus den zwei verschiedenen Suchräumen normalisiert, ohne sie in dieselbe Skala zu zwingen. Nach der Fusion senden wir die Top-Kandidaten durch einen Cross-Encoder-Reranker. Dies fügt eine geringe Latenz hinzu, aber der Gewinn an Präzision ist erheblich. Der Reranker liest die Anfrage und jeden Kandidaten gemeinsam und weist einen Relevanz-Score zu, der weitaus genauer ist als die Kosinus-Ähnlichkeit des ursprünglichen Embeddings. In der Praxis erfasst diese Kombination exakte Fehlercodes, die eine reine Vektorsuche übersehen würde, während sie gleichzeitig konzeptionell verwandte Schritte zur Fehlerbehebung liefert, die eine Stichwortsuche ignorieren würde.

Query Expansion: Benutzereingaben korrigieren, bevor sie den Index erreichen

Nutzer schreiben keine perfekten Suchanfragen. Sie stellen Multi-Hop-Fragen wie „Warum ist mein letztes Deployment fehlgeschlagen und wie führe ich ein Rollback durch?“, was erfordert, zwei separate Wissensbereiche zu finden und sie miteinander zu verknüpfen. Oder sie stellen vage Fragen, die nur schlecht auf den Index abgebildet werden können.

Wir transformieren Abfragen vor der Suche. Eine Multi-Hop-Frage wird in Teilfragen zerlegt. Eine vage Absicht wird in mehrere spezifische Suchanfragen erweitert. Wir haben festgestellt, dass die Erweiterung einer Benutzeranfrage auf fünf verschiedene Suchanfragen den Recall von achtundsiebzig Prozent auf sechsundneunzig Prozent steigern kann. Hierbei geht es nicht darum, das LLM intensiver zu prompten. Es geht darum, dem Retrieval-System mehr Möglichkeiten zu geben, den richtigen Kontext zu finden. Jede generierte Abfrage erfasst einen anderen Aspekt oder eine andere Terminologie, und die zusammengeführten Ergebnisse zeichnen ein vollständiges Bild.

Bayessche Optimierung: Schluss mit dem Raten

Sobald Sie über mehrere Chunking-Strategien, hybrides Retrieval und Query Expansion verfügen, stehen Sie vor einem neuen Problem. Es gibt zu viele Stellschrauben. Chunk-Größe, Überlappungsprozentsatz, Vektorgewichtung gegenüber BM25-Gewichtung, Reranking-Schwellenwerte und Top-k-Werte interagieren alle auf nichtlineare Weise. Manuelles Tuning wird zu einem Ratespiel.

Wir haben aufgehört zu raten. Wir behandeln den