RAG + Agent: Architektur der nächsten KI-Anwendungsgeneration

Ein Unternehmen baute drei Monate lang ein RAG-System – in der ersten Woche nach dem Go-live kritisierte der Chef es scharf: „Warum kann das Ding nicht mal eine einfache Frage zur Reisekostenabrechnung beantworten?“

Klassisches RAG gleicht einem Schüler, der nur im Wörterbuch nachschlägt: Frage rein, passender Eintrag raus – ohne die Absicht dahinter zu verstehen. Fragt jemand „Meine Reisekostenabrechnung vom letzten Monat wurde abgelehnt – warum?“, liefert klassisches RAG vielleicht einen Stapel Richtliniendokumente, holt aber nie zuerst den konkreten Abrechnungsdatensatz des Nutzers.

Genau das soll Agentic RAG lösen.

Dieser Artikel behandelt die RAG-+-Agent-Fusionsarchitektur – ein Ansatz, der Enterprise-KI-Anwendungen gerade neu formt. Von der Architekturevolution über Framework-Wahl bis zur konkreten Umsetzungsroadmap. Dazu ein Praxisbeispiel aus dem intelligenten Kundenservice – hoffentlich mit Anregungen für Ihr Projekt.

Vom klassischen RAG zu Agentic RAG: Architekturevolution

Klassisches RAG ist simpel: Nutzerfrage → Vektorsuche → relevante Dokumente → LLM generiert die Antwort. Drei Schritte, fertig.

Die Vorteile liegen auf der Hand: schnell, günstig, leicht umzusetzen. Die Probleme auch.

Ungenaues Retrieval. Bei vagen Fragen liefert Vektorähnlichkeit oft Dokumente, die „ähnlich aussehen“, aber nicht passen. Fragen Sie „Wie konfiguriere ich die Datenbankverbindung?“, können MySQL- und PostgreSQL-Dokumente durcheinandergeraten – der Nutzer muss selbst sortieren.

Kein Reasoning. Klassisches RAG macht nur „Retrieval → Generierung“. Bei mehrstufigen Fragen scheitert es. Fragen Sie „Vergleichen Sie Vor- und Nachteile von Option A und B“, findet es vielleicht nur Dokumente zu Option A – und antwortet trotzdem selbstsicher.

"McKinsey-Umfrage: 47 % der GenAI-Nutzer erlebten negative Folgen; nur 27 % prüfen jede Ausgabe"

Was Agentic RAG verändert

Die Kernidee: Die KI soll aktiv überlegen, wie sie ein Problem löst – statt mechanisch Retrieval und Generierung abzuspulen.

Der Kernzyklus:

Plan → Retrieve → Act → Reflect → Answer

Schritt für Schritt:

Plan (Planung): Die Nutzerfrage analysieren und in Teilaufgaben zerlegen. Bei „Meine Reisekostenabrechnung vom letzten Monat wurde abgelehnt“ etwa: Abrechnungsdatensatz laden, Reiserichtlinien prüfen, Ablehnungsgründe vergleichen.

Retrieve (Retrieval): Entscheiden, wo und was gesucht wird – Wissensbasis, Datenbank, externe APIs.

Act (Aktion): Retrieval ausführen, Tools aufrufen, Informationen sammeln. Neue Erkenntnisse können erneutes Planen auslösen.

Reflect (Reflexion): Prüfen, ob die Ergebnisse reichen und die Antwort stimmig ist. Bei Bedarf zurück zu Plan.

Answer (Antwort): Finale Antwort mit Quellenangaben.

Kurz gesagt: Klassisches RAG ist Wörterbuch-Nachschlagen; Agentic RAG ist ein Recherche-Assistent – analysiert, recherchiert, prüft und liefert eine belastbare Antwort.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Dahinter steht der Wunsch, von „funktioniert irgendwie“ zu „funktioniert wirklich gut“ zu kommen. Agentic RAG ist ein zentraler Schritt in dieser Evolution.

Zehn RAG-Architekturmuster im Detail

Der Stoff ist umfangreich – hier die Kernpunkte. Die vollständige Vergleichstabelle folgt weiter unten.

Naive RAG: Einstieg

Die einfachste Variante: Frage → Vektorsuche → Antwort. Gut für schnelle Ideenvalidierung, in Produktion meist zu schwach.

Typische Probleme: niedrige Retrieval-Genauigkeit, verschwendetes Kontextfenster, Halluzinationen. Für POC oder interne Tools vertretbar – sonst eher nicht.

Hybrid RAG: Enterprise-Standard

Inzwischen Benchmark in produktiven Systemen. Kombiniert lexikalisches Retrieval (Keyword-Matching) und semantisches Retrieval (Vektorähnlichkeit).

Warum? Lexikalisch punktet bei exakten Treffern, semantisch bei Intent-Verständnis. Zusammen wirkt es deutlich besser.

Praxis: BM25 für Lexikal, Vektordatenbank (Pinecone, Weaviate, Milvus) für Semantik, Zusammenführung per Reciprocal Rank Fusion (RRF).

Graph RAG: Multi-Hop-Reasoning

Wenn Fragen nach „Warum“ und „Wie hängt das zusammen?“ gehen, lohnt Graph RAG.

Entitäten werden extrahiert und als Wissensgraph modelliert – Multi-Hop-Reasoning möglich. Frage: „Welche Produkte nutzen Teile dieses Lieferanten?“ – Antwort entlang der Graph-Kanten.

Kosten: etwa 3–5× höher als Basis-RAG – Graph-Aufbau und -Pflege sind aufwendig.

Agentic RAG: aktiv denkend

Der Kernzyklus wurde oben erklärt. Ergänzung: Flexibilität ist zweischneidig.

Komplexe Fragen ja – aber höhere Latenz und schwer kontrollierbare Kosten. Eine einfache Frage kann mehrere Retrieval- und Tool-Runden auslösen. Deshalb Routing in der Praxis: einfache Fälle klassisches RAG, komplexe Agentic RAG.

Self-RAG: Selbstkorrektur

Das Modell bewertet die eigene Ausgabe: Sind die Dokumente relevant? Halluziniert die Antwort?

Bei schlechter Bewertung: erneutes Retrieval oder Korrektur. Elegant – aber teurer und die Bewertung selbst kann fehlerhaft sein.

Agentic Graph RAG: Obergrenze

Derzeit das fortgeschrittenste Muster: Agent-Orchestrierung in Graph-Retrieval eingebettet – Multi-Hop plus aktive Planung.

Kosten entsprechend – nur für Kerngeschäftsszenarien empfohlen.

Vergleich der Architekturmuster

Empfehlung: Mit Hybrid RAG starten und je nach Bedarf upgraden – nicht gleich das Neueste anstreben.

Framework-Wahl: LangChain vs. LlamaIndex vs. CrewAI vs. AutoGen

Hier habe ich selbst Fehler gemacht: Ein Projekt startete mit einem Framework, dessen Ökosystem halb durch war – Refactoring kostete Zeit und Nerven.

Framework-Wahl zählt. Kurz die gängigen Optionen:

LangChain / LangGraph: breitestes Ökosystem

Unsicher? LangChain ist meist eine sichere Wahl – reife Docs, aktive Community, LangGraph über 25K GitHub-Stars.

LangGraph ist LangChains Graph-State-Machine für zustandsbehaftete Agent-Workflows. Stärke: produktionsreife Persistenz – Agent-Zustand in der DB, Checkpointing, Time-Travel-Debugging.

Passend für: produktive Workflows, persistente Zustände, komplexe Agent-Orchestrierung.

# LangGraph-Vereinfachung: Query-Planning-Agent
from langgraph.graph import StateGraph

def plan_query(state):
    """Nutzerfrage analysieren und Retrieval-Schritte planen"""
    query = state["query"]
    # Frage zerlegen, Sub-Queries erzeugen
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """Retrieval ausführen"""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# Workflow aufbauen
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex: datenintensive RAG

Viel unstrukturierte Daten (Dokumente, DBs, APIs)? LlamaIndex oft die bessere Wahl.

Starke Query Engines: Vektor-, Keyword-, Hybrid- und Graph-Retrieval. Viele Datenquellen-Connectors.

Passend für: datenintensive RAG, heterogene Quellen, Fokus auf Retrieval-Qualität.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

CrewAI: schnelle Prototypen

Rollenbasierte Multi-Agent-Teams: mehrere Agent-Rollen arbeiten zusammen.

Beispiel Content-Team: Researcher sammelt, Autor schreibt, Editor prüft – je Rolle eigene Ziele und Tools.

Passend für: schnelle Prototypen, Prozessautomatisierung, klar getrennte Rollen.

Community 100.000+ Entwickler, GitHub 20K+ Stars – schnell wachsend.

AutoGen: Multi-Agent mit Microsoft-Hintergrund

Microsoft Research, dialogbasierte Zusammenarbeit mehrerer Agenten – für mehrstufige Interaktion.

Mensch-in-the-Loop: Menschen können jederzeit eingreifen und korrigieren.

Passend für: Forschung, Human-in-the-Loop, dialoglastige Szenarien.

Über 50K GitHub-Stars – eines der größten Agent-Frameworks.

Entscheidungsbaum

Welcher Projekttyp?
├── Produktive persistente Workflows → LangGraph
├── Datenintensive RAG → LlamaIndex
├── Schnelle Prototypen / Geschäftsprozesse → CrewAI
├── Forschung / dialogbasierte Multi-Agenten → AutoGen
└── Unsicher / maximale Flexibilität → LangChain + LangGraph

Kein absolutes Urteil – Team-Stack, Anforderungen und Community-Aktivität der Frameworks mitdenken; das prägt spätere Wartungskosten.

Enterprise-Umsetzungsroadmap

90-Tage-Vorlage aus mehreren Unternehmensprojekten – an Ihr Tempo anpassbar.

Phase 1: Tag 0–15 – Problem und KPIs

Nicht mit Tool-Wahl starten. Zuerst: Welches Problem lösen wir?

Kernfragen:

1. Wer nutzt es? Interne Mitarbeitende oder externe Kunden?
2. Welches Szenario? Q&A, Suche oder komplexes Reasoning?
3. Erfolgsmetriken? Genauigkeit, Antwortzeit, Zufriedenheit?

Kleine Nutzerbefragung: 50–100 echte Fragen sammeln – später Test- und Evaluierungssatz.

Phase 2: Tag 16–45 – Daten und Retrieval-Schicht

Datenarbeit ist mühsam – setzt aber die Obergrenze.

Datenbereinigung: Duplikate, Veraltetes, Sensibles entfernen. Schmutzige Daten ruinieren Retrieval.

Chunking: Passende Blockgröße je Dokumenttyp – Technikdocs 500–1000 Zeichen, Rechtstexte oft nach Paragraphen.

Embeddings: OpenAI text-embedding-3, Cohere, BGE – auf kleinem Datensatz vergleichen.

Retrieval-Schicht: Mit Hybrid RAG starten – BM25 plus Vektorsuche.

Phase 3: Tag 46–75 – Agent-Orchestrierung und Tools

Jetzt Agent-Fähigkeiten.

Routing: Nicht jede Frage braucht einen Agent. FAQ → klassisches RAG; Komplexes → Agent-Flow. So bleiben Kosten und Latenz im Rahmen.

Tool-Integration: Interne Systeme per MCP – DB-Queries, APIs, Dokumentensuche.

Orchestrierung: LangGraph o. Ä. – mit ReAct beginnen, Komplexität schrittweise erhöhen.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Phase 4: Tag 76–90 – Evaluierung, Tests, Härtung

RAGAS empfohlen – drei Kernmetriken:

• Faithfulness: Antwort treu zu den retrieved Docs, Ziel >= 0,8
• Answer Relevance: Beantwortet die Frage?
• Context Relevance: Sind die Docs relevant genug?

Weitere technische Metriken:

• Recall@K >= 0,85
• P95-Latenz <= 2,5 s
• Kosten: API-Calls und Token pro Anfrage

Typische Fallen

1. Zugriffskontrolle umgehen: Agent-Tools können Berechtigungen aushebeln – Security-Tests ernst nehmen
2. Veralteter Kontext: In langen Dialogen geht Frühinformation verloren – Kontextmanagement planen
3. Kostenexplosion: Mehrfach-Retrieval summiert API-Kosten schnell

Praxisbeispiel: Intelligenter Kundenservice-Assistent

Fall aus einem Unternehmensprojekt – solide Ergebnisse.

Szenario: Support zu Produkt, Bestellung, After-Sales, Richtlinien – verteilt über Wissensbasis, CRM, Order-System, ERP.

Problem: Klassisches RAG durchsucht nur die Wissensbasis – keine personalisierten Bestell- oder Historiendaten.

Architektur

Dreistufige Agent-Architektur:

Ebene 1: Routing Agent

Frage analysieren, Branch wählen:

• „Wie benutze ich das Produkt?“ → Wissensbasis
• „Wo ist meine Bestellung?“ → Order-System
• „Wie lautet die Rückerstattungsrichtlinie?“ → Policy-Dokumente

Ebene 2: Query Planning Agent

Komplexe Fragen in Sub-Queries zerlegen. „Kann ich das Handy vom letzten Monat zurückgeben?“ erfordert:

1. Bestellhistorie des Nutzers
2. Rückgaberichtlinie
3. Abgleich Datum vs. Frist

Ebene 3: ReAct Agent

Konkretes Retrieval und Tool-Calls, mehrere Iterationen möglich.

Tool-Integration

Interne Systeme per MCP:

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

Ergebnisvergleich

Nach dem Go-live – klassisches vs. Agentic RAG:

+33 Prozentpunkte Problemlösung, Eskalation halbiert. Preis: längere Antwortzeit – typischer Agent-Trade-off zwischen Erlebnis und Effizienz.

Fazit

RAG + Agent wird zur Standardarchitektur für Enterprise-KI – vom passiven Retrieval zum aktiven Reasoning für wirklich komplexe Fragen.

Empfehlungen:

1. Einfach starten. Nicht sofort Agentic Graph RAG – Hybrid RAG, Wert beweisen, dann upgraden.

2. Kosten im Blick. Agent-Flexibilität kostet – Routing und Caching sind Pflicht.

3. Evaluierung ernst nehmen. Ohne Metriken wissen Sie nicht, ob es gut läuft. RAGAS plus eigener Testdatensatz.

4. Offene Protokolle. MCP als Tool-Standard; A2A für Framework-übergreifende Zusammenarbeit – beides prägt das Agent-Ökosystem.

Wenn Sie gerade ein RAG-System bauen, hoffe ich, dieser Artikel hilft. Fragen gerne in den Kommentaren.