RAG vs Agents: knowledge pipeline vs decision loop

RAG und Agents werden oft als Alternativen verglichen, aber sie sind nicht gegenseitig ausschliessend. In der Praxis sind es unterschiedliche Systemebenen: ein Wissensmuster versus ein Muster fuer Aktionsausfuehrung.

Vergleich in 30 Sekunden

RAG ist ein Ansatz, bei dem das System zuerst relevante Quellen findet und danach darauf basierend antwortet.

Agents ist ein Ansatz mit decision loop, bei dem das Modell Schritte entscheidet, tools aufruft und den Plan waehrend der Ausfuehrung anpasst.

Hauptunterschied: RAG ist fuer Faktqualitaet in der Antwort zustaendig, Agents fuer die Steuerung von mehrstufigem Verhalten.

Praktische Regel: wenn die Kernaufgabe "finde und erklaere mit Quellen" ist, starte mit RAG. Wenn die Aufgabe "loese und fuehre Schritte mit tools aus" ist, brauchst du einen Agent-Ansatz.

Vergleichstabelle

Der zentrale Architekturunterschied ist, was der "Kern" des Systems ist: Wissens-Retrieval oder decision loop.

Architektonischer Unterschied

RAG wird meist um einen kontrollierten retrieval-Flow gebaut. Agents werden um eine Schleife aus Entscheidungen und Aktionsausfuehrung gebaut.

Engineering-Analogie: RAG ist eine Request-Pipeline zur knowledge layer mit klaren Qualitaets-Gates.
Agents sind ein execution runtime, der entscheidet, welcher Schritt als naechstes kommt und welches tool aufgerufen wird.

In diesem Schema ist der Flow vorhersagbar, aber das System eignet sich schlecht fuer komplexe mehrstufige Aktionen.

Im Agent-Schema ist die Flexibilitaet deutlich hoeher, aber auch die Kontrollrisiken sind hoeher.

Was RAG ist

RAG ist ein Pattern, bei dem das System auf Basis externer Quellen antwortet und nicht nur aus dem parametric memory des Modells.

Typischer Flow:

request -> retrieval -> rerank -> grounded answer

Beispielidee RAG (Pseudocode)

Unten ist eine Logik-Illustration, keine woertliche API.

def run_rag(question):
    intent = plan_retrieval_intent(question)
    intent = validate_intent(intent, allowed_sources=ALLOWLIST, max_top_k=8)

    candidates = retriever.search(
        query=intent["query"],
        sources=intent["sources"],
        top_k=intent["top_k"],
    )
    ranked = rerank(candidates, query=intent["query"])
    context = select_context(ranked, min_score=0.72, token_cap=2200)

    if not context:
        return fail("insufficient_evidence")

    answer = compose_grounded_answer(question, context)

    if not citation_check(answer, context):
        return fail("citations_out_of_context")

    return answer

Starke Seite von RAG ist Faktqualitaetskontrolle. Schwache Seite: RAG alleine loest keine komplexe Aktionslogik und keine Tool-Orchestrierung.

Was Agents sind

Agents ist ein Ansatz, bei dem das Modell in einer Schleife entscheidet, tools aufruft und den Ausfuehrungsweg anhand von Beobachtungen aendert.

Typischer Flow:

request -> plan -> tool call -> observation -> next step

Beispielidee Agents (Pseudocode)

Unten ist eine Logik-Illustration, keine woertliche API.

def run_agent(request):
    # max_steps/budget sollten in init_state oder in der Infrastruktur-Konfig validiert werden.
    state = init_state(request, max_steps=12, budget_usd=0.8)

    while state.step < state.max_steps and state.cost_usd < state.budget_usd:
        action = planner.decide(state)

        verdict = policy.check(action)
        if verdict == "deny":
            return fail("policy_denied")

        if verdict == "needs_approval":
            if not wait_for_human_approval(state.trace_id, timeout_sec=90):
                return fail("approval_timeout")

        result = tool_gateway.call(action, timeout_sec=8, retries=1)
        state = observe(state, action, result)
        emit_trace(state.trace_id, action, result)

    if state.step >= state.max_steps:
        return fail("step_limit_exceeded")

    if state.cost_usd >= state.budget_usd:
        return fail("budget_exceeded")

    return finalize(state)

Starke Seite von Agents ist Adaptivitaet. Schwache Seite: ohne strikte governance-Schicht wird das System teuer und unvorhersagbar.

Wann RAG einsetzen

RAG passt, wenn der Hauptwert eine praezise, quellenbasierte Antwort ist und nicht mehrstufige Aktionen.

Passt

Wann Agents einsetzen

Agents passen, wenn das System zur Laufzeit entscheiden und Schritte ueber tools ausfuehren muss.

Passt

Nachteile von RAG

RAG kontrolliert Wissensantworten gut, loest aber nicht automatisch alle Production-Risiken.

Nachteile von Agents

Agents geben Flexibilitaet, werden ohne Disziplin aber schnell zur Quelle von Incidents und Zusatzkosten.

In der Praxis funktioniert oft ein hybrider Ansatz

Ein haeufiges Praxisszenario ist die Entwicklung eines Support-Systems von reinem RAG zu hybrider Architektur.

Zum Start hat das Team nur RAG eingefuehrt: Policies finden, Quellen zitieren, Standardfragen beantworten.

Nach einigen Monaten kam ein Split-Trigger:

• ein Teil der Anfragen wechselte von "erklaeren" zu "Aktion ausfuehren" (Tarifwechsel, Ticket erstellen, Kompensation)
• Anzahl bedingter Routen und manueller approvals stieg
• Aktionslogik in einem festen retrieval-Flow wurde schwer skalierbar

Was in RAG blieb:

• retrieval pipeline und reranking fuer Wissensantworten
• grounded Generierung mit citation checks
• read-only FAQ-Szenarien

Was in Agent/Custom-Schicht ausgelagert wurde:

• decision loop fuer mehrstufige Operationen
• Tool-Orchestrierung zwischen CRM, billing und ticketing
• approvals, budgets, stop conditions und Aktions-Audit

Warum das funktionierte:

• RAG hielt Stabilitaet und Genauigkeit im Wissensanteil
• Agents deckten komplexes operatives Verhalten ab
• Team schrieb nicht alles neu, sondern isolierte nur die schwierigsten Runtime-Segmente

Kurz gesagt

FAQ

Q: Was sollten wir zuerst waehlen: RAG oder Agents?
A: Wenn die Aufgabe Wissen und Quellen betrifft, starte mit RAG. Wenn die Aufgabe Aktionen und bedingte Schritte betrifft, starte direkt mit Agent-Ansatz. Fuer viele Teams ist Fehler #1, mit Agent zu starten, wo RAG reicht.

Q: Wann reicht RAG nicht mehr aus?
A: Wenn Anfragen systematisch Aktionen statt nur Erklaerungen verlangen. Typische Signale: viele Write-Operationen, approvals, bedingte Uebergaenge und Abhaengigkeiten zwischen mehreren tools.

Q: Wann braucht ein Agent RAG als eines der tools?
A: Wenn Agent Schritte nicht nur "ausfuehren", sondern auf verifizierten Fakten ausfuehren soll. Wenn Entscheidungen von Policies, Vertraegen, Handbuechern oder Wissensbasis abhaengen, ist RAG als Agent-Tool oft noetig und verbessert die Zuverlaessigkeit meist deutlich.

Q: Kann RAG einen Agent in einem komplexen Business-Prozess ersetzen?
A: Meist nein. RAG antwortet gut, steuert aber mehrstufige Operationen schlecht. Wenn eine Entscheidungsschleife mit Aktionen noetig ist, wird Architektur ohne Agent-Orchestrierung schnell fragil.

Q: Wann sind Agents schon Overengineering?
A: Wenn zwei Signale gleichzeitig auftreten: der meiste Traffic sind lineare read-only Anfragen und das Team verbringt mehr Zeit mit Loop/Tool-Wartung als mit Value-Release. In dieser Phase gewinnt meist einfacheres RAG oder workflow.

Q: Welche Mindestkontrolle braucht man fuer RAG und fuer Agents?
A: Fuer RAG Minimum: retrieval constraints (query/top_k), source allowlist, grounding/citation checks, latency und token caps; fuer Agents Minimum: policy checks, budgets, stop conditions, approvals fuer riskante Aktionen, tracing und Entscheidungs-Audit.

Verwandte Vergleiche

Wenn du die Architektur eines Agent-Systems waehlst, helfen auch diese Seiten:

• LLM Agents vs Workflows - wann ein Agent-Loop noetig ist und wann workflow reicht.
• OpenAI Agents vs LangChain - gemanagter runtime versus flexible Kontrollschicht.
• LangChain vs LangGraph - Komponenten versus explizite Graph-Kontrolle von Uebergaengen.
• OpenAI Agents vs LangGraph - schneller gemanagter Start versus formalisierter stateful workflow.
• OpenAI Agents vs Custom Agents - gemanagte Plattform versus eigene Agent-Architektur.