← Alle Beitrage

KI-Systeme entwickeln: Von RAG zu Agenten

8 Min. Lesezeit

Die meisten Teams beginnen mit RAG, stoßen an dessen Grenzen und ergänzen dann Fine-Tuning. Beide lösen Retrieval und Reasoning. Keines von beiden löst die Orchestrierung: die Entscheidung, wann gehandelt werden soll, wie viele Agenten gestartet werden, wann gestoppt wird und was Konsens bedeutet. Ich habe ein Multi-Agenten-Deliberationssystem gebaut (3.500 Zeilen Python, 86 Hooks, 141 Tests), das alle drei Aspekte abdeckt.

Zusammenfassung

RAG ruft Dokumente zum Zeitpunkt der Abfrage ab. Fine-Tuning modifiziert Modellgewichte mit domänenspezifischen Daten. Beide sind Werkzeuge für Retrieval und Reasoning. Keines behandelt die Orchestrierung: die Koordination mehrerer Agenten, die Validierung von Konsens oder die Entscheidung, ob eine Aufgabe einen oder zwölf Modellaufrufe benötigt. Ich stieß auf diese Grenze beim Aufbau eines Blog-Qualitätssystems, das paralleles Linting, Tiefenbewertung, Quellenverifizierung und LLM-Evaluation über 33 Beiträge hinweg benötigte. Die Lösung war eine Agentenorchestrierungsschicht mit konfidenzgesteuerter Deliberation, Spawn-Budget-Management und Vier-Stufen-Konsensvalidierung. Dieser Beitrag behandelt die RAG-vs-Fine-Tuning-Entscheidung und geht dann dorthin, wo die meisten Leitfäden aufhören: was passiert, wenn Sie Agenten brauchen.

Teil 1: RAG vs. Fine-Tuning

Eine Databricks-Studie aus dem Jahr 2024 ergab, dass 78 % der KI-Teams in Unternehmen zuerst RAG wählten, doch 34 % später feststellten, dass Fine-Tuning der bessere Ansatz gewesen wäre – im Durchschnitt wurden 3,2 Monate Implementierungszeit verschwendet.1

Die Entscheidung ist kein Entweder-oder. Es geht darum, die Technik auf das Problem abzustimmen.

Wann RAG gewinnt

Häufig wechselndes Wissen. RAG ruft aktuelle Dokumente zum Zeitpunkt der Abfrage ab. Wenn sich die Wissensbasis täglich aktualisiert (Produktdokumentation, Support-Artikel, regulatorische Einreichungen), liefert RAG aktuelle Informationen ohne erneutes Training.2

Anforderungen an die Quellenangabe. RAG zitiert spezifische Dokumente, da der Retrieval-Prozess eine explizite Quellenliste erzeugt. In regulierten Branchen (Gesundheitswesen, Finanzwesen, Recht) ist die Quellenangabe häufig eine Compliance-Anforderung.3

Große Wissensbasen. Ein RAG-System über 10 Millionen Dokumente arbeitet vergleichbar mit einem über 1 Million, sofern die Retrieval-Qualität konsistent ist. Fine-tuned Modelle stoßen an Kapazitätsgrenzen, die durch die Modellgröße bestimmt werden.4

Wann Fine-Tuning gewinnt

Domänenspezifische Reasoning-Muster. RAG liefert Informationen. Fine-Tuning liefert Fähigkeiten. Ein Modell, das auf medizinischen Diagnosegesprächen fine-tuned wurde, lernt Differentialdiagnose-Muster: wie Symptome gewichtet werden, wann seltene Erkrankungen in Betracht gezogen werden, wie Nachfragen formuliert werden. RAG kann das medizinische Wissen bereitstellen, aber das Reasoning-Muster erfordert eine Anpassung der Gewichte.5

Strenge Anforderungen an das Ausgabeformat. Fine-Tuning erzwingt strukturierte Ausgaben (JSON, XML, spezifische Schemas) zuverlässiger als Prompt Engineering. Bei Systemen, in denen Formatfehler zu nachgelagerten Fehlern führen, bietet Fine-Tuning eine höhere Zuverlässigkeit.6

Latenzkritische Anwendungen. RAG fügt Retrieval-Latenz hinzu: die Abfrage einbetten, die Vektordatenbank durchsuchen, Dokumente abrufen, sie in den Prompt einfügen. Bei Anwendungen mit Antwortzeiten unter 200 ms kann es notwendig sein, den Retrieval-Prozess durch Fine-Tuning zu eliminieren.7

Die Vergleichsmatrix

Dimension RAG Fine-Tuning Beide
Wissenaktualität Stunden Wochen–Monate Stunden
Einrichtungskosten Niedrig–mittel Mittel–hoch Hoch
Kosten pro Abfrage Höher (Retrieval + Generierung) Niedriger (nur Generierung) Am höchsten
Quellenangabe Nativ Schwierig Teilweise
Kontrolle des Ausgabeformats Moderat Hoch Hoch
Domänenspezifisches Reasoning Schwach Stark Stark
Größe der Wissensbasis Unbegrenzt Durch Modell begrenzt Unbegrenzt
Latenz Höher Niedriger Am höchsten
Halluzinationskontrolle Besser (auf Dokumenten basierend) Variabel Am besten

Der kombinierte Ansatz

Die meisten Produktionssysteme kombinieren beide Techniken. Fine-tunen Sie das Modell auf domänenspezifische Reasoning-Muster und Ausgabeformate. Nutzen Sie RAG, um aktuelles, belegbares Wissen zum Zeitpunkt der Abfrage bereitzustellen. Das fine-tuned Modell weiß, wie es über die Domäne argumentieren soll. Das RAG-System liefert, worüber argumentiert werden soll.8

Teil 2: Wann Sie Agenten brauchen

RAG und Fine-Tuning behandeln Retrieval und Reasoning. Keines behandelt Orchestrierung: die Entscheidung, ob eine Aufgabe einen oder zwölf Modellaufrufe benötigt, wann parallele Worker gestartet werden, wie deren Ausgaben validiert werden und wann an einen Menschen eskaliert wird.

Ich stieß auf diese Grenze beim Aufbau meiner Blog-Qualitätsinfrastruktur. Ich hatte 33 Blogbeiträge zu evaluieren, zu korrigieren und zu verifizieren. Ein einzelner Modellaufruf pro Beitrag reichte nicht aus. Jeder Beitrag benötigte Linting (12 Module), Tiefenbewertung (5 Signale), Lesbarkeitsanalyse, Quellenverifizierung und LLM-Evaluation. Sequentielle Ausführung dauerte zu lange. Parallele Ausführung ohne Koordination erzeugte Konflikte und inkonsistente Ergebnisse.

Die Lösung war weder mehr RAG noch besseres Fine-Tuning. Es war eine Agentenorchestrierungsschicht.

Was Agentenorchestrierung erfordert

Die traditionelle ML-Pipeline geht von einem linearen Ablauf aus: Daten, Vorverarbeitung, Modell, Evaluation, Deployment.9 Agentensysteme sind nichtlinear. Ein Agent könnte:

  1. Seine eigene Konfidenz bewerten und entscheiden, dass er Hilfe benötigt
  2. 5 parallele Sub-Agenten mit unterschiedlicher Expertise starten
  3. Deren Ausgaben sammeln und bewerten
  4. Erkennen, wenn Agenten zu schnell konvergieren (Gruppendenken)
  5. Konsens gegen Qualitätsschwellenwerte validieren
  6. Eine finale Empfehlung generieren

Jeder Schritt erfordert Infrastruktur, die RAG und Fine-Tuning nicht bieten.

Teil 3: Was ich gebaut habe

Die Architektur

Mein Deliberationssystem umfasst 3.500 Zeilen Python über 12 Module:

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

Das System basiert auf 86 Hooks, die Operationen an sechs Lebenszykluspunkten abfangen (PreToolUse, PostToolUse, Stop und drei weitere). Jeder Agentenstart, jeder Dateischreibvorgang, jeder Git-Befehl durchläuft eine Validierung.

Der Konfidenz-Trigger

Nicht jede Aufgabe erfordert fünf diskutierende Agenten. Ich habe einen Konfidenzbewertungsalgorithmus entwickelt, der vier Dimensionen evaluiert:

  1. Mehrdeutigkeit – Hat die Anfrage mehrere gültige Interpretationen? (Musterabgleich: „best way”, „should I”, „compare vs”, „pros and cons”)
  2. Domänenkomplexität – Erfordert sie Spezialwissen? (Musterabgleich: „architecture”, „security”, „performance”, „database schema”)
  3. Tragweite – Ist die Entscheidung reversibel? (Musterabgleich: „production”, „breaking change”, „delete”, „security vulnerability”)
  4. Kontextabhängigkeit – Erfordert sie ein Verständnis des Gesamtsystems?

Die Bewertung wird auf drei Stufen abgebildet:

  • HOCH (0,85+): Ohne Deliberation fortfahren
  • MITTEL (0,70–0,84): Fortfahren mit protokolliertem Konfidenzhinweis
  • NIEDRIG (unter 0,70): Vollständige Multi-Agenten-Deliberation auslösen

Der Schwellenwert passt sich dem Aufgabentyp an. Sicherheitsentscheidungen erfordern 85 % Konsens. Dokumentationsänderungen benötigen nur 50 %. Dies verhindert Over-Engineering bei einfachen Aufgaben und stellt gleichzeitig sicher, dass riskante Entscheidungen angemessen geprüft werden.

Das Spawn-Budget-Problem

Meine erste Implementierung verwendete tiefenbasierte Rekursionsgrenzen: Ein Agent auf Tiefe 0 startet Tiefe 1, die Tiefe 2 startet, blockiert bei Tiefe 3. Das scheiterte sofort. Deliberationsagenten müssen parallel laufen, nicht seriell. Fünf Agenten auf Tiefe 1 sind keine tiefe Rekursion. Es ist breite Zusammenarbeit.

Die Lösung: ein Spawn-Budget-Modell. Der Root-Agent erhält ein Budget (maximal 12 Agenten). Er verbraucht dieses Budget zum Starten paralleler Worker. Worker erben das verbleibende Budget, können es aber nicht überschreiten. Dies verhindert unkontrollierte Ketten und ermöglicht gleichzeitig die parallele Ausführung, die Deliberation erfordert.

Der Praxistest kam, als ich 10 Review-Agenten über übersetzte Blogbeiträge laufen ließ. Die Rekursionssperre blockierte die Agenten 4 bis 10, weil sie Starts als Tiefeninkrement zählte. Nach dem Wechsel zum Budget-Modell liefen alle 10 erfolgreich. Die Tiefe überschritt nie 1. Die Breite erweiterte sich passend zur Aufgabe.10

Konsensvalidierung

Nach Abschluss der Agenten führt ein Post-Deliberation-Hook vier Prüfungen durch:

  1. Phasenbereitschaft – Ist die Deliberation über die Recherche hinaus in die Bewertungsphase fortgeschritten?
  2. Agenten-Quorum – Haben mindestens 2 Agenten abgeschlossen? (Pro Aufgabentyp konfigurierbar)
  3. Konsensschwellenwert – Erreicht die Übereinstimmung das erforderliche Niveau? (70 % Basis, 85 % für Sicherheit)
  4. Dissens-Dokumentation – Sind bei Uneinigkeit der Agenten die Bedenken dokumentiert?

Prüfung 4 war die Erkenntnis, die ich nicht erwartet hatte. Frühe Durchläufe produzierten „Konsens”, bei dem Agenten einfach der ersten Antwort zustimmten. Der Konformitätsdetektor markiert nun vorzeitige Konvergenz: Wenn alle Agenten in der ersten Runde mit hohen Ähnlichkeitswerten übereinstimmen, erzwingt das System eine zweite Runde adversarialer Analyse.

Was ich auf die harte Tour gelernt habe

Atomare Dateischreibvorgänge sind wichtig. Mehrere Agenten, die gleichzeitig in dieselbe Statusdatei schrieben, korrumpierten JSON. Die Lösung: in .tmp-Dateien schreiben, dann atomar mit mv verschieben. Das Betriebssystem garantiert, dass mv auf demselben Dateisystem atomar ist. Diese einzeilige Änderung eliminierte eine ganze Kategorie von Race Conditions.

Kontextisolation verhindert Gruppendenken. Jeder Agent erhält unabhängigen Kontext über vier Schichten (L0: Basiswissen, L1: aufgabenspezifisch, L2: personaspezifisch, L3: rundenspezifisch). Ohne Isolation konvergieren Agenten auf die erste plausible Antwort, anstatt den Lösungsraum zu erkunden. Mit Isolation gelangen der Security-Agent und der Performance-Agent zu genuinen unterschiedlichen Schlussfolgerungen, weil sie von verschiedenen Annahmen ausgehen.

Agenteninfrastruktur testen ist schwieriger als Anwendungscode. Das System hat 141 Tests: 48 Bash-Integrationstests für Hook-Verhalten, 81 Python-Unit-Tests für Bibliotheksmodule und 12 End-to-End-Pipeline-Simulationen. Jede Fehlergeschichte in meinem Projektspeicher (Spawn-Budget-Blockierung, Anführungszeichen-Erkennungs-Falschpositive, Blog-Plan-Dateien versehentlich als Beiträge ausgeliefert) wurde nach der Behebung zu einem Testfall. Agenten-Bugs sind schwerer zu reproduzieren als Anwendungs-Bugs, weil sie von Timing, Reihenfolge und nebenläufigem Zustand abhängen.

Die Mensch-Agent-Arbeitsteilung

Menschliche Verantwortung Agentenverantwortung
Problemdefinition Pipeline-Ausführung
Konfidenzschwellenwerte Ausführung innerhalb der Schwellenwerte
Konsensanforderungen Konsensberechnung
Quality-Gate-Kriterien Quality-Gate-Durchsetzung
Fehleranalyse Fehlererkennung
Architekturentscheidungen Architekturoptionen
Domänenkontextinjektion Dokumentationsgenerierung

Das Muster: Menschen verantworten Entscheidungen, die organisatorischen Kontext, ethisches Urteilsvermögen oder strategische Ausrichtung erfordern. Agenten verantworten Entscheidungen, die rechnerische Suche über große Möglichkeitsräume erfordern.11 Ich habe diese Arbeitsteilung weiter in meiner Agentenarchitektur-Analyse untersucht.

Der agentische ML-Ingenieur programmiert keine Pipelines von Hand. Der agentische ML-Ingenieur definiert Ziele, Einschränkungen und Evaluationskriterien. Agenten übernehmen die Implementierungsschleife: vorschlagen, ausführen, evaluieren, iterieren. Die menschliche Rolle verschiebt sich vom Entwickler zum Architekten: Leitplanken setzen, Ausgaben überprüfen und Urteilsentscheidungen treffen, die Domänenkontext erfordern, der Agenten fehlt.12

Zentrale Erkenntnisse

Für Ingenieure, die mit KI-Systemen beginnen: - Starten Sie mit RAG für jeden Anwendungsfall, der häufig wechselndes Wissen oder Anforderungen an die Quellenangabe umfasst; RAG liefert eine funktionale Basis in Tagen, während Fine-Tuning Wochen der Datenaufbereitung erfordert - Kombinieren Sie RAG und Fine-Tuning, wenn die Anwendung sowohl domänenspezifisches Reasoning ALS AUCH aktuelles Wissen benötigt - Wenn Sie mehr als einen Modellaufruf pro Aufgabe benötigen, brauchen Sie Agentenorchestrierung – und das ist ein anderes Engineering-Problem als RAG oder Fine-Tuning

Für Teams, die Agentensysteme entwickeln: - Entwickeln Sie Konfidenzbewertung vor dem Aufbau von Agenten; die meisten Aufgaben benötigen keine Deliberation, und das System, das weiß, wann Agenten eingesetzt werden sollen, ist wertvoller als die Agenten selbst - Verwenden Sie Spawn-Budgets statt Tiefenbegrenzungen für parallele Agentenarchitekturen; Tiefenbegrenzungen blockieren breite Zusammenarbeitsmuster, die Agentendeliberation erfordert - Testen Sie die Konsensqualität, nicht nur die Konsensexistenz; vorzeitige Übereinstimmung ist schlimmer als keine Übereinstimmung, weil sie falsches Vertrauen erzeugt

Referenzen

  1. Databricks, “State of Enterprise AI Architecture,” Databricks Research, 2024. ↩

  2. Lewis, Patrick et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS 2020. ↩

  3. Gao, Luyu et al., “Precise Zero-Shot Dense Retrieval without Relevance Labels,” ACL 2023. ↩

  4. Borgeaud, Sebastian et al., “Improving Language Models by Retrieving from Trillions of Tokens,” ICML 2022. ↩

  5. Singhal, Karan et al., “Large Language Models Encode Clinical Knowledge,” Nature, 620, 172-180, 2023. ↩

  6. Hu, Edward J. et al., “LoRA: Low-Rank Adaptation of Large Language Models,” ICLR 2022. ↩

  7. Miao, Xupeng et al., “Towards Efficient Generative LLM Serving: A Survey from Algorithms to Systems,” arXiv:2312.15234, 2023. ↩

  8. Anthropic, “RAG + Fine-Tuning: A Practical Architecture Guide,” Anthropic Cookbook, 2024. ↩

  9. Sculley, D. et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015. ↩

  10. Eigene Erfahrung beim Aufbau der Multi-Agenten-Deliberationsinfrastruktur, dokumentiert in der Projekt-MEMORY.md. 86 Hooks, 141 Tests, 12 Python-Module. ↩

  11. Sambasivan, Nithya et al., “‘Everyone Wants to Do the Model Work, Not the Data Work’: Data Cascades in High-Stakes AI,” CHI 2021, ACM. ↩

  12. Hollmann, Noah et al., “Large Language Models for Automated Machine Learning,” arXiv:2402.08355, 2024. ↩