Die meisten Teams bauen ihre erste Retrieval-Pipeline immer noch auf die gleiche Weise zusammen. Sie wählen ein festes Token-Limit, vielleicht 512, teilen d

Die meisten Teams bauen ihre erste Retrieval-Pipeline immer noch auf die gleiche Weise zusammen. Sie wählen ein festes Token-Limit, vielleicht 512, teilen Dokumente in gleichmäßige Blöcke auf und speisen diese Blöcke in eine Vektordatenbank ein. Bei einem kleinen Datensatz mit einfachen Fragen sieht das magisch aus. In der Produktion bricht es jedoch zusammen.

Rechtliche Verträge zerfallen in bedeutungslose Fragmente, wenn eine Klausel mitten im Satz zerschnitten wird. API-Dokumentationen verwandeln sich in ein unübersichtliches Durcheinander, wenn ein einzelner Chunk drei nicht zusammenhängende Funktionen verschluckt. Kundensupport-Tickets verlieren jeglichen roten Faden, wenn es keine Überlappungen zwischen den Segmenten gibt. Das Ergebnis ist vorhersehbar: erhöhte Latenz, schwacher Recall und Antworten, die den Generator zu Halluzinationen zwingen.

Wir haben unseren Retrieval-Layer abgerissen und neu aufgebaut. Das Ergebnis war ein Sprung beim Recall von 78 Prozent auf 95 Prozent, eine Reduzierung der Latenz um 62 Prozent und eine Pipeline, die sich endlich wie echte Infrastruktur verhält und nicht wie ein improvisierter Wochenend-Hack. Hier ist das, was tatsächlich funktioniert hat.

Smart Chunking: Struktur vor Token

Der erste Fehler besteht darin, anzunehmen, dass jedes Dokument die gleiche Sprache spricht. Ein 512-Token-Chunk ergibt für erzählende Prosa Sinn, aber fast nirgendwo sonst. Wir sind zu einer Strategie übergegangen, die die Anatomie der Quelle respektiert.

Für juristische Dokumente verwenden wir rekursives Chunking. Der Algorithmus versucht zuerst, an übergeordneten Grenzen wie Abschnitten und Artikeln zu trennen. Wenn ein Abschnitt immer noch zu lang ist, sucht er nach Unterabschnitten, dann nach Absätzen und schließlich nach Sätzen. Dies bewahrt die logische Verschachtelung der Klauseln. Ein Wettbewerbsverbot bleibt intakt. Definitionen vermischen sich nicht mit Entschädigungsklauseln.

API-Dokumentationen erfordern struktur-bewusstes Chunking. Eine Funktionssignatur, ihre Parametertabelle und ihr Beispiel-Request gehören zusammen. Das Aufteilen nach einer festen Token-Anzahl führt oft dazu, dass die Parameter in einem Chunk und die Beispiele in einem anderen landen. Stattdessen führen wir das Chunking nach Dokumentenobjekten durch. Ein Chunk enthält einen vollständigen Endpunkt oder eine einzelne Funktion. Der Retriever kann dann eine in sich geschlossene Referenz zurückgeben, die die Frage tatsächlich beantwortet.

Support-Tickets eignen sich von Natur aus für semantisches Chunking. Anstatt an einer Token-Grenze zu schneiden, erkennen wir, wo sich das Thema ändert. Ein Ticket, das mit einer Login-Beschwerde beginnt und dann zu einer Abrechnungsfrage übergeht, wird in zwei kohärente Teile aufgeteilt. Jedes Teil trägt die benötigten Metadaten, und das Modell muss nicht mehr raten, welches Problem dem Nutzer tatsächlich wichtig ist.

Interne Wikis sind unordentlicher. Sie mischen Prosa, Tabellen, Diagramme und eingebettete Threads. Für diese verwenden wir agentisches Chunking. Ein kleines Sprachmodell liest voraus und entscheidet, wo eine thematisch vollständige Einheit endet. Das kostet während der Ingestion etwas mehr, eliminiert aber die mühsame Handarbeit, Regeln für jedes neue Seitenformat manuell anpassen zu müssen.

Hybrid Retrieval: Alle Eventualitäten abdecken

Die Vektorsuche ist hervorragend darin, vage Bedeutungen zu erfassen. Fragt man nach langsamen Uploads, liefert sie bereitwillig Absätze über Latenz und Bandbreite. Aber sie ist berüchtigt dafür, exakte Treffer zu verfälschen. Wenn ein Entwickler nach dem Fehlercode ERR_CONNECTION_REFUSED sucht, behandeln dichte Embeddings diesen oft als allgemeines Rauschen.

BM25, der klassische Keyword-Algorithmus, macht das Gegenteil. Er trifft präzise Zeichenfolgen und seltene Begriffe, übersieht dabei aber semantische Nuancen. Eine Suchanfrage zum Thema „Unterzeichnung der Vereinbarung“ findet möglicherweise nie Inhalte, die mit „Ausführung des Vertrags“ verschlagwortet sind.