Kapitel 1 — Die Evolution der RAG-Architektur

Erster Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Darin: Die zwei strukturellen Grenzen eines Basismodells — eingefrorenes Wissen und fehlende Provenienz — haben dieselbe architektonische Antwort, und diese Antwort hat sich in drei Jahren in vier Gesichter ausdifferenziert.

Warum dieses Kapitel existiert

Ein Transformer, der auf einem festen Korpus trainiert wurde, hat zwei Grenzen, die kein zusätzliches Training restlos beseitigt. Sein Wissen endet an dem Tag, an dem der Korpus endete. Und er kann dir nicht sagen, aus welchem Dokument ein Satz stammt, weil der Satz ein statistischer Mittelwert über viele ist, kein Zitat aus einem einzigen. Die erste Schwäche produziert selbstbewusst falsche Antworten zu allem Aktuellen. Die zweite produziert selbstbewusst falsche Quellenangaben. Zusammen ergeben sie die inzwischen bekannte Enterprise-Pathologie: eine Antwort, die wie Autorität klingt und auf eine Klausel verlinkt, die so nicht existiert.

RAG ist die architektonische Antwort auf beides zugleich. Du hörst auf, vom Modell zu verlangen, alles im Voraus zu wissen, und beginnst, ihm zur Inferenzzeit das relevante Material zu reichen — abgerufen aus einem Korpus, den du kontrollierst. Der Korpus aktualisiert sich ohne Neutraining. Die abgerufenen Passagen werden zu Belegen, weil du sie gezielt geholt hast. Die Aufgabe des Modells schrumpft von Erinnerung zu Synthese. Der Rest des Kapitels ist die Geschichte, wie aus diesem einfachen Zug über drei Jahre vier zunehmend leistungsfähigere Architekturen wurden.

1.1 Naive RAG: einbetten, abrufen, einfüllen

Die einfachste Form ist die, die jedes öffentliche Tutorial bis heute beschreibt. Offline: Korpus in Chunks teilen, jeden Chunk einbetten, Vektoren in einen Index schreiben. Online: Query einbetten, die k nächsten Chunks holen, in einen Prompt zusammenstellen, ans Modell schicken, Antwort mit den Chunks als Quellen zurückgeben. Zwei Funktionsaufrufe und eine Vektorsuche.

Die Demo läuft. Das Produkt selten. Nearest-Neighbour-Ähnlichkeit ist ein Proxy für Relevanz, keine Messung von ihr, und Embedding-Modelle, die auf allgemeinem Webtext trainiert wurden, verwechseln routinemäßig Apfelplantagen-Erträge mit Apples Quartalszahlen. Der Chunker hat kein Signal dafür, wo Sätze enden oder Tabellen beginnen. Ein einzelner Retrieval-Durchgang kann keine Frage bedienen, deren Antwort über drei Dokumente verteilt liegt. Und wenn der Retriever versagt, synthetisiert das Modell aus dem, was zurückkam — die Quellenangaben sind echt, stützen aber nichts von der Antwort.

1.2 Advanced RAG: Heuristiken um dieselbe Pipeline

Die zweite Haltung behält das Einbetten-Abrufen-Generieren-Rückgrat und ergänzt Verarbeitung vor und nach dem Retrieval-Aufruf. Pre-Retrieval-Erweiterungen zielen auf die Query: Umschreiben, Erweitern, Zerlegen, HyDE (eine hypothetische Antwort entwerfen und diese als Query einbetten). Post-Retrieval-Erweiterungen zielen auf die Kandidaten: ein Cross-Encoder-Reranker, der Query und Passage gemeinsam bewertet statt sie getrennt zu embedden, Deduplikation, Metadaten-Filter, Kontextkompression.

Die Gewinne sind nicht klein. Ein Cross-Encoder-Reranker auf einem Vektor-Retriever bringt die Top-5-Relevanz typisch aus dem 50–70-Prozent-Band ins 75–90-Prozent-Band. Query-Rewriting bringt weitere fünf bis zehn Punkte, wenn die ursprüngliche Formulierung mehrdeutig war. Die meisten heute schlicht als "RAG" bezeichneten Produktionssysteme fahren diese Architektur, und für eine breite Klasse von Enterprise-Problemen — interne Dokumentations-Q&A, Support-Deflektion, Wissensdatenbank-Suche — ist sie das richtige Investitionsmaß. Was sie dir nicht gibt, ist Flexibilität. Jede Query läuft weiterhin durch dieselbe Pipeline.

1.3 Modular RAG: komponierbare Bausteine, explizites Routing

Bis 2024 hatten sich Forschung und Tooling auf Modular RAG geeinigt. Dieselben Techniken sind weiterhin da, aber sie liegen als diskrete, austauschbare Komponenten vor, und die Pipeline wird pro Request zusammengesetzt. Ein Router entscheidet, welche Retriever angesprochen werden — vielleicht ein Dense-Vektorindex, ein BM25-Index, ein SQL-Store, eine externe API — und die Ergebnisse werden fusioniert, häufig per Reciprocal Rank Fusion. Der Reranker wird nach Query-Typ ausgewählt. Der Generator nach geforderter Qualitätsstufe. Die Architektur ist ein Graph aus Komponenten geworden, keine Linie aus Stufen mehr.

Zwei praktische Folgen. Erstens ist das System testbar, wie es die früheren Haltungen nicht waren — jede Komponente lässt sich unabhängig evaluieren und ersetzen. Zweitens ist es pro Query-Klasse tunbar: Eine Faktenabfrage läuft durch einen schnellen Retriever und einen kleinen Generator, eine Multi-Dokument-Synthese durch mehrere Retriever und einen großen, beides aus derselben Komponentenbibliothek. Der Preis ist operativ. Wenn eine Antwort falsch ist, hat die Frage wo ist das schiefgegangen? jetzt viele mögliche Antworten, und das Team braucht Instrumentierung, die den Fehler bis auf eine einzelne Komponente herunterbricht. Investiere in die Observability vor der modularen Architektur, nicht danach.

1.4 Agentic RAG: das LLM fährt die Pipeline

Die vierte Haltung kehrt eine Annahme um, die die ersten drei stillschweigend teilten — dass das LLM der letzte Schritt ist. In Agentic RAG fährt das LLM die Pipeline. Mit einem Katalog von Werkzeugen (Vektorsuche, SQL, Web-Fetch, Reranker, Rechner) denkt das Modell, wählt ein Werkzeug, beobachtet das Ergebnis, denkt erneut, und terminiert, wenn es eine Antwort hat oder ein Step-Limit erreicht. Die Architektur ist keine Pipeline mehr, sondern ein kleines Programm, das das Modell für jede Query neu schreibt.

Das bringt mehrstufige Planung, dynamische Werkzeugwahl und Multi-Agent-Koordinationsmuster wie Planner/Retriever/Critic/Writer. Es kostet Latenz, Token-Budget und Reproduzierbarkeit — eine einzelne Query ist nun ein Entscheidungsbaum statt einer festen Sequenz, und pathologische Queries können viele Runden im Leerlauf drehen, bevor eine Antwort herauskommt. Produktive agentische Systeme brauchen Budget-Kontrollen, Step-Limits und Timeout-Regeln, über die feste Pipelines nie nachdenken mussten. Der richtige Use Case sind Fragen, deren Tiefe variabel und unvorhersagbar ist: Research-Synthese, juristische Recherche über Rechtsprechung, Literaturüberblick. Der falsche Use Case ist ein statischer Support-Bot, in dem die agentische Schleife Varianz hinzufügt, die der Workload nicht brauchte.

1.5 RAG gegen Fine-Tuning

Die Frage, die jedes Team irgendwann stellt. Die ehrliche Rahmung: Sie lösen verschiedene Probleme. RAG adressiert Wissensprobleme — das Modell kennt X nicht, X ändert sich, und der Nutzer braucht einen Beleg. Fine-Tuning adressiert Verhaltensprobleme — das Modell kennt die Antwort, präsentiert sie aber im falschen Format, weigert sich, der Firmenvorlage zu folgen, oder schwafelt, wo es knapp sein sollte. RAG ist günstig in der Einrichtung und teuer pro Query. Fine-Tuning ist einmal teuer und günstig pro Query. RAG iteriert in Minuten (ein Dokument ändern); Fine-Tuning iteriert in Tagen. Eine brauchbare Heuristik: Wenn der Fehler das Modell weiß es nicht ist, greif zu RAG. Wenn der Fehler das Modell weiß es, macht es aber falsch ist, greif zu Fine-Tuning. Viele gereifte Systeme machen am Ende beides, aber fang mit RAG an — die meisten Enterprise-Fehler sind Wissens-, keine Verhaltensfehler.

Was Kapitel 1 vorbereitet

Jede RAG-Architektur — welche der vier auch immer du wählst — ist darauf angewiesen, wie gut sie ihre Quelldokumente lesen kann. Eine state-of-the-art Modular-Pipeline mit agentischem Orchestrator arbeitet immer noch mit Chunks, die irgendwo upstream aus einem Parsing-Schritt kamen. Hat dieser Schritt die Tabellenstruktur verloren, die mehrspaltige Lesereihenfolge durcheinandergebracht oder Bildunterschriften mit unleserlichem OCR ersetzt, dann argumentiert jede nachgelagerte Komponente über korrupten Input. Die Architektur setzt die Decke des Systems. Der Parser setzt seinen Boden. In den meisten Produktionssystemen zählt der Boden mehr, weil die meisten Produktionssysteme weit von der Decke entfernt sind.

Als Nächstes — Kapitel 2: Intelligentes Document-Parsing. Warum ein naives PDF-zu-Text-Tool die Retrieval-Qualität still zerstört, was layoutbewusstes Parsing tatsächlich erhält und die multimodale Alternative, die direkt über Seitenbilder abruft.