← Zurück zu den Artikeln
ragretrievaldata-engineeringdeterminism

Production RAG wird entschieden, bevor das Modell läuft

Juni 2026 · 6 Min. Lesezeit

Die meisten RAG-Demos funktionieren. Die meisten RAG-Systeme in Produktion nicht — und wenn sie scheitern, ist der Reflex, nach einem besseren Modell, einem größeren Context-Window, einem clevereren Prompt zu greifen. Das ist fast immer die falsche Schicht. Bis eine Frage das Sprachmodell erreicht, ist das Ergebnis längst weitgehend entschieden. Was es entscheidet, ist der Teil, den niemand demonstriert: wie die Wissensbasis in abrufbare Chunks verwandelt wurde. Das ist ein Plädoyer dafür, diese Schicht deterministisch zu machen — und dafür, was sie dann liefert.

Das Modell ist das Letzte, was zählt

Eine RAG-Antwort ist nur so gut wie die Chunks, die für sie abgerufen wurden. Wenn die richtige Passage nicht im abgerufenen Set ist, kann kein Modell — so fähig es auch sei — eine Antwort darin fundieren. Es wird die Tatsache entweder weglassen oder eine erfinden. Retrieval-Qualität ist also die Obergrenze für Antwortqualität, und Chunk-Qualität ist die Obergrenze für Retrieval. Alles weiter unten erbt, was immer die Ingestion-Schicht entschieden hat.

Das verschiebt, wohin der Engineering-Aufwand gehört. Generierung ist zunehmend ein gemanagter Modellaufruf — die API eines anderen, jedes Quartal besser ohne eigenes Zutun. Der Teil, der einem selbst gehört, der spezifisch für die eigene Wissensbasis ist, ist alles davor: Extraktion, Strukturwiederherstellung, Chunking, Indexierung, Retrieval. Dort wird ein Produktionssystem gewonnen oder verloren — und es ist der Teil, den keine Demo zeigt.

The RAG pipeline as a chain of ceilingsIngestion feeds retrieval feeds generation; chunk quality set during ingestion caps everything downstream.IngestionRetrievalGenerationdeterministicmeasurablemodel callchunk quality is the ceiling on everything downstream
Retrieval quality caps answer quality; chunk quality caps retrieval. The model inherits whatever the ingestion layer decided.

Warum deterministisch, nicht „KI-gestützt"

Der modische Zug ist, auch in den Ingestion-Pfad ein LLM zu setzen — es chunken zu lassen, zusammenfassen, taggen. Das ist verführerisch, und für eine Wissensbasis ist es meist ein Fehler. Eine deterministische, regelbasierte Pipeline bedeutet, dass dasselbe Quelldokument immer dieselben Chunks erzeugt. Das bringt drei Dinge, die mehr zählen als Bequemlichkeit:

Nichts davon ist anti-KI. Der Generierungsschritt ist weiterhin ein Modellaufruf. Der Punkt ist, das Modell aus der Schicht herauszuhalten, die vertrauenswürdig und reproduzierbar sein muss — und das Inferenz-Budget dort auszugeben, wo es die Antwort tatsächlich verändert.

  • Reproduzierbarkeit — die Ingestion lässt sich erneut laufen lassen und der Output diffen. Eine Änderung in den Chunks ist eine bewusst gemachte Änderung, nicht Wetter.
  • Auditierbarkeit — in einem regulierten Kontext muss „Warum weiß das System das?" eine Antwort haben. Eine deterministische Pipeline hat eine; ein LLM, das letzten Dienstag anders gechunkt hat, nicht.
  • Keine Halluzination im Korpus selbst — sobald ein LLM die Inhalte während der Ingestion umschreibt, enthält der Retrieval-Korpus Text, den kein Mensch geschrieben hat. Das Halluzinationsrisiko ist damit nach vorn verschoben, wo es schwerer zu sehen ist.

Der Chunk ist die Einheit des Retrievals

Wenn der Chunk das ist, was embedded und abgerufen wird, entscheiden seine Grenzen alles. Wird eine Prozedur in der Mitte geteilt, ruft keine Hälfte gut ab. Werden zwei unzusammenhängende Themen zusammengeführt, ist das Embedding ein Verschwimmen aus beiden. Chunking kann also nicht one-size-fits-all sein: eine Referenztabelle, eine Schritt-für-Schritt-Prozedur und eine Definitionsseite haben unterschiedliche natürliche Grenzen und brauchen unterschiedliche Strategien und Größenprofile. Content-Type-bewusstes Chunking — die Art der Seite erkennen, sie so teilen, wie diese Art Seite geteilt werden will — ist unspektakulär, und es ist der Großteil der Schlacht.

Es gibt ein subtileres Problem, bevor das Chunking überhaupt beginnt: Struktur ist oft auf Weisen kodiert, die ein naiver Parser nicht sieht. Eine Seite trägt ihre echte Hierarchie vielleicht in UI-Widgets oder Formatierung statt in Überschriften, sodass eine flache Extraktion dieses Signal wegwirft. Es wiederherzustellen — die impliziten Überschriften zu echten zu befördern, bevor der Splitter läuft — ist es, was die semantische Struktur bis ins Embedding am Leben hält.

Bad versus good chunk boundariesSplitting a unit in the middle yields two halves that retrieve poorly; respecting its boundary keeps it retrievable as one.split mid-unithalfhalfneither half retrieves wellclean boundarywhole unitretrieves as one
Split a unit and both halves blur. Respect its boundary and it retrieves as one — a chunking decision, made before the model is ever called.

Die Vokabular-Lücke schließen

Embedding-Modelle sehen nur, was man ihnen gibt. Wenn der Chunk-Körper bloß Prosa ist und das Backend keine hybride (Keyword + Vektor) Suche als Rückfallebene hat, dann ist jedes strukturelle oder thematische Signal, das nicht im Körper steht, zur Retrieval-Zeit schlicht unsichtbar. Das Embedding kann keinen Kontext abrufen, den es nie gezeigt bekam.

Zwei Maßnahmen helfen, und sie müssen symmetrisch sein. Auf der Ingestion-Seite: den Chunk-Körper mit dem fehlenden Signal anreichern — den Abschnitt, zu dem er gehört, die Fachbegriffe, um die es geht. Auf der Query-Seite: die eingehende Frage mit demselben Glossar erweitern, sodass Fachterminologie und Alltagsformulierung sich in der Mitte treffen. Eine Seite anzureichern ohne die andere verschiebt die Lücke nur; beides zu tun schließt sie. Die Symmetrie ist der Punkt.

Closing the vocabulary gap symmetricallyQuery-side expansion and document-side enrichment meet at a shared glossary in the middle.queryquery sidechunkdoc sideglossaryexpandenrichenrich one side only and the gap just moves — the symmetry is the point
Query-side expansion and doc-side enrichment have to meet in the same vocabulary. Do one without the other and you only shift the gap.

Die Schicht messen, nicht behaupten

Diese Disziplin hält stand, weil Retrieval messbar ist. Es ist einer der wenigen Teile eines LLM-Systems mit ehrlichen, klassischen Metriken: Recall@k, MRR, nDCG — berechnet über ein gelabeltes Query-Set, mit Konfidenzintervallen, die zeigen, welche Unterschiede echt sind und welche Rauschen.

Sobald das vorliegt, ist jede Änderung an der Pipeline eine messbare Wette. Ein zweistufiges Retrieval — Vektor-Recall gefolgt von einem Reranker — bewegt den Recall entweder oder nicht, und um wie viel ist sichtbar. In dem System, aus dem das stammt, wird der Beitrag des Rerankers isoliert gegen ein experten-validiertes Gold-Set gemessen — nicht angenommen. Ist ein Regression-Gate mit diesen Zahlen verdrahtet, kann die Pipeline bei der nächsten Änderung nicht still schlechter werden.

Das Fazit

„Deterministisch" klingt wie das Gegenteil von schnellem Vorankommen mit KI. Ist es nicht. Es ist das, was schnelles Vorankommen erlaubt, ohne dass das System still verrottet — weil jeder Teil davon reproduzierbar, messbar und nachvollziehbar ist. Das Modell wird von allein besser. Die Ingestion-Schicht wird nur besser, wenn man sie baut. Diese Asymmetrie ist das ganze Argument dafür, wo die Zeit hingehört.

Sie bauen ein RAG- oder Retrieval-System und wollen diese Sorgfalt darin? Nehmen Sie Kontakt auf — oder sehen Sie sich die Projekte hinter den Artikeln an.