Bei RAG geht es nicht um KI, sondern um Engineering

(In Bearbeitung)

RAG ist eine technische Herausforderung

Beim Durchstöbern der AI & Machine Learning Community Gruppe bin ich auf einen Beitrag [1] und eine Präsentation von Hastika Cheddy gestoßen, der den Nagel auf den Kopf traf. Ihre These zu KI-Implementierungen war brutal ehrlich:

„Ich habe über 10 RAG-Implementierungen in Unternehmen geprüft. Jede einzelne ist im Produktivbetrieb gescheitert. Nicht wegen des LLMs. Nicht wegen des Embedding-Modells. Sondern wegen einer fehlerhaften Architektur“.

Diese Worte haben sofort bei mir resonniert. Da das Fundament öfter versagt als die Modelle selbst, ist es an der Zeit, dass ich meinen Senf dazu gebe, wie man effektive RAG-Systeme aufbaut.

RAG: 5 Minuten im Tutorial, 5 Monate in der Produktion

Analysiert man die allgemein verfügbaren Beispiele für RAG-Systeme, drängt sich der Eindruck auf, dass wir in einer Phase naiver und zu hastiger Implementierungen feststecken. Diese Technologie verspricht zwar das Blaue vom Himmel, ist aber in Wirklichkeit extrem anspruchsvoll und launisch. Die Versuchung, schnell eine einfache Sequenz abzufeuern – „Text in Stücke schneiden, in die Vektordatenbank werfen, suchen“ – ist so groß, dass entscheidende ingenieurtechnische Grundlagen oft in den Hintergrund rücken.

Aspekte wie verlässliche Datenqualität, Auditierbarkeit des Prozesses oder Angriffsresistenz erhalten eine gefährlich niedrige Priorität. Erschwerend kommt hinzu, dass fundamentale Designentscheidungen im Vorbeigehen getroffen werden. Ein Beispiel ist der massenhafte Einsatz von festem Chunking (fixed-size chunking), das im Vergleich zu realen Geschäftsdokumenten fast immer gegen raffiniertere, semantische Segmentierungstechniken verliert.

Natürlich gibt es fortgeschrittenere RAG-Systeme, die über solide architektonische Grundlagen verfügen und in Produktionsumgebungen recht effizient arbeiten. Diese werden jedoch in Tutorials kaum besprochen – vielleicht, weil sie für Menschen, die nach schnellen Erfolgen dürsten, nicht so attraktiv erscheinen. Sie werden nämlich mit dem langwierigen und akribischen Aufbau eines komplexen, mehrschichtigen Systems assoziiert.

Meiner Meinung nach ist genau diese Komplexität der Kern des Ganzen und das Interessanteste daran. Deshalb ermutige ich dich, Leser, RAG als eine ingenieurtechnische Herausforderung zu betrachten. Hier suchen wir nicht nach den „tief hängenden Früchten“, sondern gehen das Thema mit Senior-Ernsthaftigkeit an – so, wie man an den Entwurf jedes kritischen und komplexen Systems herangeht.

Von drei Kacheln im Diagramm zum hundertköpfigen Monster

Die meisten Schemata, auf die wir im Netz stoßen, stellen RAG als einen eleganten und fast wartungsfreien Mechanismus dar. Das Bild ist verlockend: Ein Dokument gelangt in die Maschine, verwandelt sich in Vektoren, durchläuft „drei Blöcke insgesamt“ und generiert die ideale Antwort. Leider hält diese Vision des „Happy Path“ der ersten Kollision mit der Realität selten stand.

Stellen, an denen diese schematischen Vereinfachungen die tatsächliche Komplexität des Prozesses maskieren, gibt es zur Genüge:
(TBD: Hier folgt die Liste der Beispiele)

In der realen Welt sind deine Daten keine steril sauberen Textdateien, sondern „schmutzige“ PDFs mit mehrstöckigen Tabellen, Fußzeilen und unoffensichtlichen Strukturen. Hinzu kommen Nutzer, die Fragen selten auf vorhersehbare und geordnete Weise stellen. Damit das System aufhört zu halluzinieren und anfängt, Probleme real zu lösen, müssen wir die Illusion der Einfachheit zugunsten einer soliden Ingenieursarbeit aufgeben, die den Prozess auf jeder Stufe absichert.

Warum ein Produktionssystem 15+ Module benötigt und nicht nur drei?

Die wahre Anatomie eines professionellen RAG-Systems reduziert sich nicht nur auf die drei einfachen Schritte, die das Akronym selbst suggeriert: Abrufen (Retrieve), Erweitern (Augment) und Generieren (Generate). Das ist nur die Spitze des Eisbergs. Wenn du eine Lösung baust, die resistent gegen ungeordnete Daten, desorientierte Nutzer und sogar böswillige Manipulationsversuche sein soll, musst du viel tiefer blicken.

Unten findest du eine Liste von 20 Komponenten, die in Betracht gezogen werden sollten – und unter Geschäftsbedingungen meist einfach implementiert werden müssen –, damit RAG nicht mehr nur eine technische Kuriosität ist, sondern zu einem zuverlässigen Werkzeug der Enterprise-Klasse wird.

Erst eine Architektur, die diese Aspekte berücksichtigt, ermöglicht es, ein System zu schaffen, das für Krisensituationen, Audits oder potenzielle Rechtsstreitigkeiten bereit ist. Man sollte sich ein Prinzip merken: Bei RAG ist der größte technische Aufwand keineswegs mit der Wahl des Sprachmodells selbst verbunden, sondern mit dem Bau der „Rohre“, durch die die Daten fließen. Genau in dieser auf den ersten Blick unsichtbaren Infrastruktur entscheidet sich, ob dein System eine echte Unterstützung oder ein spektakulärer Implementierungsfehlschlag wird.

RAG ist kein fertiges Schachtelprodukt, sondern ein kontinuierlicher Prozess. Der Erfolg hängt nicht vom Kauf eines Abonnements für die teuersten LLMs ab, sondern von der mühsamen Arbeit an der Qualität und dem Informationsfluss. Die kognitive Dissonanz wird erst verschwinden, wenn wir aufhören, KI wie Magie zu behandeln, und anfangen, in ihr ein weiteres, komplexes Element moderner Softwarearchitektur zu sehen.

...work in progress...