Fortgeschritten 12 Min.Fortgeschritten

Agentic RAG lokal: Wann es die peine

Beim Agentic RAG übernimmt ein Modell die Steuerung der Suche: Es entscheidet, wonach gesucht wird, liest die Funde und startet eine weitere Abfrage, wenn ihm noch etwas fehlt. Diese Schleife hat ihren Preis, vor allem auf einem lokalen Rechner, wo jede Runde Generierungszeit kostet. Diese Anleitung erklärt, was sich gegenüber einem klassischen RAG ändert und in welchen Fällen sich der Mehraufwand rechtfertigt, und zeigt ein vollständiges Beispiel mit einem über Ollama bereitgestellten Modell und LangGraph.

Von Samir K.·Aktualisierung 2026-11-02·Unter Windows, macOS und Linux getestet

#Agentic RAG in Kürze

Ein klassisches RAG folgt einem festen Ablauf: Die Frage löst eine Suche aus, die gefundenen Passagen kommen in den Prompt, das Modell antwortet. Agentic RAG ersetzt diesen Ablauf durch eine Schleife. Das Modell verfügt über Suchtools und entscheidet selbst, ob es sie aufruft, mit welcher Suchanfrage und wie oft, bis es einschätzt, dass es antworten kann oder aufgeben muss.

Der Kurs AI Agents for Beginners von Microsoft beschreibt es als eine Arbeitsweise, bei der das Modell seine nächsten Schritte plant und zugleich Informationen aus externen Quellen abruft, mit einer Schleife nach dem „maker-checker“-Prinzip: erstellen, prüfen, korrigieren. Derselbe Kurs erinnert auch an die Grenze dieser Autonomie: Sie wirkt nur innerhalb der Aufgabe und der Tools, die Sie bereitgestellt haben.

Die praktische Schlussfolgerung passt in einen Satz. Wenn Ihr RAG scheitert, weil eine einzelne Suche nicht die gesamte Antwort zusammentragen kann, kann eine Schleife helfen. Wenn es scheitert, weil die Ingestion oder das Chunking schlecht sind, wiederholt sie das Problem nur, und zwar langsamer.

i
Was dieser Guide nicht behauptet
Hier wird kein Genauigkeitsgewinn angegeben, da keine Messung mit Ihren Daten vorliegt. Für diesen Guide wurde kein Benchmark durchgeführt: Die Größenordnungen sind illustrative Berechnungen und als solche gekennzeichnet.

#Agentic RAG oder RAG mit einem Durchlauf: der Unterschied

Das komplette Kit, um dein eigenes lokales RAG zu erstellen.

Profitiere von unserer Erfahrung und einem geführten Lernpfad, um dein lokales RAG aufzubauen und mit deinen eigenen Dokumenten zu arbeiten.

  • Lebenslanger Online-Zugang
  • PDF + Dateien
  • Erstattung binnen 30 Tagen

Die Grundbausteine bleiben dieselben: Embeddings, Vektordatenbank, Generierungsmodell. Falls Sie damit nicht vertraut sind, beginnen Sie mit der Einführung in lokales RAG. Was sich ändert, ist die Instanz, die über den Ablauf entscheidet. Bei einem klassischen RAG ist das Ihr Code, bei einem agentischen RAG das Modell, innerhalb der Grenzen, die der Code ihm setzt.

Abfrage
Klassisches RAG: die Frage des Benutzers, manchmal einmal umformuliert. Agentisch: Das Modell formuliert eigene Abfragen und kann eine Frage in mehrere zerlegen.
Anzahl der Suchen
Klassisches RAG: eine, im Voraus bekannt. Agentisch: von Frage zu Frage unterschiedlich, begrenzt durch ein von Ihnen festgelegtes Limit.
Quellen
Klassisches RAG: in der Regel ein einziger Index. Agentisch: mehrere mögliche Tools (Vektorindex, Stichwortsuche, SQL-Datenbank), zwischen denen das Modell wählt.
Ergebniskontrolle
Klassisches RAG: keine, das Modell formuliert mit dem, was es erhalten hat. Agentisch: Das Modell kann die Passagen als unzureichend beurteilen und erneut suchen, was jedoch keine Garantie ist: Es kann sich bei dieser Beurteilung auch irren.
Anforderung an das Modell
Klassisches RAG: jedes Modell, das aus Textauszügen eine Antwort formulieren kann. Agentisch: ein Modell, das Tool-Aufrufe korrekt beherrscht.
Vorhersehbarkeit
Klassisches RAG: recht gleichmäßige Antwortzeit. Agentisch: variable Zeit und ein Pfad, der in den Traces zu kontrollieren ist.

Die Schleife besteht aus drei Mechanismen. Die Planung: die Frage in Teilfragen zerlegen. Die Tool-Nutzung: jede Teilfrage in einen Aufruf übersetzen. Der erneute Anlauf: das Ergebnis lesen und entscheiden, ob umformuliert oder abgeschlossen werden soll. Zur allgemeinen Architektur eines Agenten (Speicher, Schutzmechanismen, Überwachung) lesen Sie bitte den entsprechenden Leitfaden: Hier interessiert uns nur die Suchschleife.

Es gibt auch eine oft vergessene Zwischenlösung: die Pipeline mit festen Schritten. Eine Umformulierung der Suchanfrage, eine hybride Suche und anschließend ein Reranker laufen immer in derselben Reihenfolge ab, ohne Entscheidung des Modells. Das ist nicht agentisch und oft das Erste, was man ausprobieren sollte.

#Wann sich Agentic RAG lohnt

Das richtige Kriterium ist die Form Ihrer Fragen, nicht der gewünschte Grad an Raffinesse. Sehen Sie sich an, woran Ihr aktuelles RAG tatsächlich scheitert, und ordnen Sie diese Fehlschläge dann ein.

Multi-Hop-Fragen
Die Antwort auf eine erste Suche bestimmt die zweite: den Lieferanten eines Vertrags finden, dann die Klausel, die für diesen Lieferanten gilt.
Vergleiche zwischen Dokumenten
„Vergleiche die Kündigungsfrist der Verträge A und B“ erfordert zwei getrennte Suchvorgänge. Eine einzige Abfrage kann fünf Passagen aus demselben Vertrag zurückliefern.
Mehrere Quellen unterschiedlicher Art
Eine Zahl in einer SQL-Datenbank und eine Erklärung in PDF-Dateien. Das Modell wählt das Tool je nach Frage aus, wie es der Kurs von Microsoft für komplexe Interaktionen mit einer Datenbank beschreibt.
Toleranz gegenüber Wartezeiten
Dokumentenrecherche, Vorbereitung eines Dossiers, Verarbeitung im Hintergrund: Einige Dutzend Sekunden mehr stören niemanden, wenn das Ergebnis gegengelesen wird.
Vorrangige Korrektur bei der Geschwindigkeit
Wenn eine unvollständige Antwort teuer zu stehen kommt, ist ein Prüfschritt vertretbar, sofern verbindliche Entscheidungen weiterhin von einem Menschen geprüft werden.

Bleiben Sie dagegen in diesen Situationen bei einem einfachen RAG:

FAQ und Fragen mit nur einer Quelle
Die Antwort steht in einer Passage: Eine Suche genügt, eine Schleife bringt nur zusätzliche Wartezeit.
Konversationsassistent auf kleiner Hardware
Der Benutzer erwartet eine schnelle Antwort, und das Modell läuft bereits nahe an seinen Grenzen.
Suche, die die richtigen Passagen verfehlt
Korrigieren Sie zuerst das Chunking, die Embeddings und die hybride Suche. Eine schlecht abgestimmte Suche erneut zu starten, liefert nur andere schlechte Ergebnisse.
Exakte Berechnung auf strukturierten Daten
Eine geschriebene und getestete SQL-Abfrage ist zuverlässiger als ein Agent, der spontan eine improvisiert.
Mehrfache Verknüpfungen zwischen Entitäten im gesamten Korpus
Wenn es darum geht, Beziehungen in großem Maßstab zu durchlaufen, löst ein graphbasierter Ansatz ein anderes Problem: Siehe den Leitfaden zu GraphRAG.

#Der Preis bei Latenz und Modell

In der Cloud schlägt sich jede Schleifenrunde auf der Rechnung nieder. Lokal zeigt sie sich an der Uhr und im Speicher. Drei Posten fallen ins Gewicht.

#Die Latenz vervielfacht sich

Bei N Suchen generiert das Modell N + 1 Mal: einmal vor jeder Suche und ein letztes Mal für die Antwort. Ein RAG mit einem Durchlauf generiert nur einmal. Da der Prompt mit jeder Runde länger wird, liest jede Generierung mehr Text erneut, außer dem, was der Kontext-Cache der Runtime wiederverwenden kann. Die Gesamtzeit hängt vom Modell, von der Quantisierung und vom Rechner ab; messen Sie sie bei sich, statt sich auf einen allgemeinen Wert zu verlassen.

#Der Kontext füllt sich schnell

Beispielrechnung: 4 Passagen mit je 1 200 Zeichen entsprechen bei 3 bis 4 Zeichen pro Token etwa 1 400 Tokens. Fünf Suchvorgänge fügen also etwa 7 000 Tokens hinzu, ohne die Frage, die Anweisungen und die Überlegungen des Modells mitzuzählen. Bei num_ctx auf 8192 ist der Spielraum damit fast aufgebraucht. Ollama kürzt dann den Kontext, und die ersten Ergebnisse, manchmal auch die Anweisungen, können aus dem Fenster fallen, ohne dass die Anwendung dies deutlich meldet.

Eine Erhöhung von num_ctx verbraucht mehr Speicher und verlangsamt die folgenden Runden. Oft ist es besser, weniger Passagen zurückzugeben oder ihren Inhalt zusammenzufassen, bevor er erneut eingespeist wird.

#Das Modell muss die Schleife durchhalten

Das Modell muss wohlgeformte Tool-Aufrufe erzeugen und anschließend beurteilen, ob das Gelesene ausreicht. Prüfen Sie die Unterstützung mit ollama show: Im Abschnitt Capabilities muss tools aufgeführt sein. Diese Prüfung zeigt, dass das Format unterstützt wird, nicht dass das Modell gute Entscheidungen trifft.

RTX 3060 12 GB oder RTX 4070 12 GB
Ein Modell mit 7 bis 9B in Q4_K_M (Richtwert dieser Website: 7B ≈ 5 GB) lässt Platz für den Kontext und das Embedding. Das ist der Ausgangspunkt des folgenden Beispiels, mit qwen3.5:9b.
RTX 4080 16 GB
Ein 14B in Q4_K_M (≈ 9 GB) passt mit einem komfortableren Spielraum für einen erweiterten Kontext.
RTX 4090 24 GB oder M4 Pro 24 bis 48 GB
Ein größeres Modell kommt infrage, etwa qwen3.8:27b (ungefähr 18 GB). Behalten Sie bei 24 GB im Blick, wie viel nach der Erweiterung des Kontexts noch übrig bleibt.
!
Das Hin und Her zwischen zwei Modellen
Die Schleife wechselt zwischen Embedding und Generierung. Wenn die beiden Modelle nicht gemeinsam in den Speicher passen, kann Ollama in jeder Runde eines entladen, um das andere zu laden, und diese Zeit kommt zu allen anderen hinzu. Prüfen Sie dies während einer Ausführung mit ollama ps und passen Sie bei Bedarf OLLAMA_MAX_LOADED_MODELS an.

#Einen Orchestrator auswählen

Der Orchestrator führt die Schleife aus: Er leitet die Tool-Aufrufe weiter, gibt die Ergebnisse an das Modell zurück und setzt die Limits durch. Es gibt drei Wege, die alle mit einem lokalen Modell kompatibel sind.

Von Hand geschriebene Schleife
Rund zwanzig Zeilen um die Chat-API von Ollama und ihren Parameter tools. Geeignet, um den Mechanismus zu verstehen, oder für einen sehr einfachen Fall. Limits und Traces schreiben Sie selbst.
LangGraph
Die Schleife ist ein expliziter Graph aus Knoten und Kanten, mit Zustand, Rekursionslimit und Streaming der Schritte. Eine gute Wahl, wenn Sie jeden Übergang kontrollieren möchten. Diese Lösung verwendet unser Beispiel.
LlamaIndex
Interessant, wenn Ihre Ingestion und Ihre Indizes bereits dort liegen: Die Agenten nutzen Ihre Query-Engines als Tools weiter.

Entscheiden Sie nicht nach Beliebtheit. Wenn Ihre Pipeline bereits mit einem Framework läuft, bleiben Sie dabei. Pinnen Sie in jedem Fall Ihre Versionen: Diese Bibliotheken entwickeln sich schnell, und ihre vorgefertigten Funktionen ändern sich. Unser Beispiel schreibt den Graphen daher explizit, was auch die Schleife gut lesbar macht.

#Voraussetzungen

Ollama
Installiert und empfangsbereit auf http://localhost:11434.
Python
Eine aktuelle virtuelle Umgebung. Prüfen Sie bei der Installation, welche Version die Pakete voraussetzen.
Dokumente
Einige Markdown- oder Textdateien in einem Ordner mes_documents. Für PDFs übernehmen Sie die Ingestion aus dem ChromaDB-Tutorial.
Speicher
Etwa 6 GB frei für ein 9B-Modell und seinen Kontext, mehr, wenn Sie num_ctx erhöhen.

#Beispiel für Agentic RAG mit LangGraph und Ollama

Das Beispiel erstellt einen Agenten mit einem einzigen Suchwerkzeug, das auf einem lokalen ChromaDB-Index aufsetzt. Es bleibt bewusst minimal, damit die Schleife sichtbar ist.

!
Code für diesen Leitfaden nicht ausgeführt
Dieser Code folgt den dokumentierten APIs dieser Bibliotheken, wurde beim Verfassen jedoch nicht ausgeführt, und hier wird keine Ausgabe wiedergegeben. Testen Sie ihn an einem kleinen Korpus und ziehen Sie die Dokumentation der von Ihnen installierten Version zu Rate.

#Schritt 1: Modelle und Pakete installieren

Terminal
ollama pull qwen3.5:9b
ollama pull nomic-embed-text
ollama show qwen3.5:9b

python -m venv .venv
source .venv/bin/activate
pip install langgraph langchain-ollama chromadb ollama
pip freeze > requirements.txt

#Schritt 2: Dokumente indexieren

Die zeichenbasierte Aufteilung dient nur dazu, das Beispiel kurz zu halten. Verwenden Sie bei einem echten Korpus ein Chunking, das die Struktur berücksichtigt, und ein Embedding-Modell, das auf Ihren französischsprachigen Texten validiert wurde.

index.py
from pathlib import Path

import chromadb
import ollama

EMBED_MODEL = "nomic-embed-text"

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection(
    "docs", metadata={"hnsw:space": "cosine"}
)


def decouper(texte, taille=1200, recouvrement=150):
    pas = taille - recouvrement
    return [texte[i:i + taille] for i in range(0, len(texte), pas)]


for fichier in Path("mes_documents").glob("*.md"):
    morceaux = decouper(fichier.read_text(encoding="utf-8"))
    if not morceaux:
        continue
    vecteurs = ollama.embed(model=EMBED_MODEL, input=morceaux)["embeddings"]
    collection.upsert(
        ids=[f"{fichier.name}-{i}" for i in range(len(morceaux))],
        documents=morceaux,
        embeddings=vecteurs,
        metadatas=[{"source": fichier.name} for _ in morceaux],
    )

print(collection.count(), "passages indexés")

#Schritt 3: Das Tool und die Schleife schreiben

Die Beschreibung des Tools ist wichtig: Sie liest das Modell, um zu entscheiden, ob es das Tool aufruft. Die Systemanweisung schreibt vor, vor dem Antworten zu suchen, Teilfragen zu trennen und das Fehlen von Informationen einzuräumen.

agent.py
import chromadb
import ollama
from langchain_core.messages import HumanMessage, SystemMessage
from langchain_core.tools import tool
from langchain_ollama import ChatOllama
from langgraph.graph import START, MessagesState, StateGraph
from langgraph.prebuilt import ToolNode, tools_condition

EMBED_MODEL = "nomic-embed-text"
collection = chromadb.PersistentClient(path="./chroma_db").get_collection("docs")


@tool
def chercher_documents(requete: str) -> str:
    """Cherche dans les documents internes. Utiliser une requête courte
    portant sur un seul sujet. Renvoie des passages précédés de leur source."""
    vecteur = ollama.embed(model=EMBED_MODEL, input=requete)["embeddings"][0]
    res = collection.query(query_embeddings=[vecteur], n_results=4)
    passages = zip(res["documents"][0], res["metadatas"][0])
    return "\n\n".join(f"[{m['source']}] {d}" for d, m in passages) or "Aucun passage."


outils = [chercher_documents]
llm = ChatOllama(model="qwen3.5:9b", temperature=0, num_ctx=8192).bind_tools(outils)

CONSIGNE = SystemMessage(content=(
    "Tu réponds uniquement à partir des résultats de chercher_documents. "
    "Si la question porte sur plusieurs sujets, fais une recherche par sujet. "
    "Si les passages ne suffisent pas, reformule une fois puis dis clairement "
    "ce que tu n'as pas trouvé. Cite la source entre crochets."
))


def agent(state: MessagesState):
    return {"messages": [llm.invoke([CONSIGNE] + state["messages"])]}


graphe = StateGraph(MessagesState)
graphe.add_node("agent", agent)
graphe.add_node("tools", ToolNode(outils))
graphe.add_edge(START, "agent")
graphe.add_conditional_edges("agent", tools_condition)
graphe.add_edge("tools", "agent")
app = graphe.compile()

if __name__ == "__main__":
    question = "Compare la durée de préavis du contrat A et du contrat B."
    entree = {"messages": [HumanMessage(content=question)]}
    for etape in app.stream(entree, {"recursion_limit": 12}, stream_mode="values"):
        etape["messages"][-1].pretty_print()

#Schritt 4: Den Trace lesen

Der Vorteil von stream_mode="values" besteht darin, dass jede Nachricht angezeigt wird. Lesen Sie den Trace vor der endgültigen Antwort und nutzen Sie dabei dieses Raster:

  1. 01
    Ruft das Modell das Tool auf?
    Wenn es direkt antwortet, sucht es nicht: Verschärfen Sie die Anweisung oder wechseln Sie das Modell.
  2. 02
    Sind die Suchanfragen sinnvoll?
    Beim Vergleich erwartet man idealerweise eine Suchanfrage pro Vertrag. Eine einzige Suchanfrage, die die gesamte Frage wiederholt, zeigt, dass die Zerlegung nicht stattfindet.
  3. 03
    Beantworten die Passagen die Frage?
    Wenn die Textauszüge nicht zum Thema passen, liegt das Problem am Index, nicht am Agenten.
  4. 04
    Stützt sich die Antwort auf die Textauszüge?
    Überprüfen Sie jedes Zitat in eckigen Klammern anhand der entsprechenden Passage.

#Schritt 5: Die Schleife begrenzen

Jede Suche verbraucht zwei Schritte des Graphen (Agent, dann Tool). Ein Limit von 12 erlaubt also fünf Suchen und anschließend die endgültige Antwort. Darüber hinaus löst LangGraph einen GraphRecursionError aus (Modul langgraph.errors): Fangen Sie ihn in Ihrer Anwendung ab und geben Sie eine aussagekräftige Meldung zurück, statt den Benutzer mit einem Stacktrace allein zu lassen.

#Fallstricke und Fehlerbehebung

Das Modell ruft das Tool nie auf
Prüfen Sie tools in ollama show, formulieren Sie die Tool-Beschreibung um und probieren Sie ein anderes Modell aus. Versuchen Sie nicht, das Problem durch eine immer längere Anweisung auszugleichen.
Es wiederholt dieselbe Suche
Das Modell dreht sich im Kreis. Senken Sie das Limit und geben Sie im Tool eine klare Meldung zurück, wenn die Abfrage bereits ausgeführt wurde.
Die Antwort vergisst die ersten Ergebnisse
Wahrscheinliches Anzeichen für einen abgeschnittenen Kontext. Verringern Sie n_results, teilen Sie feiner auf oder erhöhen Sie num_ctx, wenn der Speicher es zulässt.
Die Antworten werden sehr langsam
Prüfen Sie ollama ps: Möglicherweise läuft ein Teil des Modells auf dem Prozessor, oder die Modelle wechseln sich im Speicher ab. Zählen Sie auch die Anzahl der Durchläufe im Trace.
Es erfindet etwas, obwohl es nichts gefunden hat
Die Schleife verhindert keine erfundenen Inhalte. Prüfen Sie die Quellenangaben programmatisch: Jede zitierte Quelle muss in den Tool-Ergebnissen der Konversation vorkommen.
Ein zu mächtiges Tool
Ein Agent, der Dokumente liest, erhält auch deren Inhalt, der unter Umständen bösartig sein kann. Geben Sie ihm Tools mit reinem Lesezugriff und sehen Sie eine menschliche Freigabe für jede Aktion vor, die etwas verändert.
→
Versuchen Sie es zuerst ohne Agenten
Bevor Sie eine Schleife hinzufügen, testen Sie eine feste Zerlegung: eine Generierung, die die Frage in Teilfragen aufteilt, eine Suche pro Teilfrage und dann eine Antwort. Wenn das Ihre Vergleiche löst, behalten Sie eine vorhersehbare Antwortzeit und einfacheren Code.

#Anhand Ihrer eigenen Fragen entscheiden

Anderswo veröffentlichte Zahlen beziehen sich auf andere Korpora, andere Modelle und andere Einstellungen. Nur ein Vergleich mit Ihren eigenen Daten schafft Klarheit, und dafür ist nicht viel Hardware nötig.

  1. 01
    Einen Fragensatz zusammenstellen
    Nehmen Sie echte Fragen, deren Antwort und Quellpassagen Sie kennen, und mischen Sie dabei einfache Fragen mit Multi-Hop-Fragen. Halten Sie fest, welchen Typ jede Frage hat.
  2. 02
    Einen Referenzwert festlegen
    Lassen Sie sie ohne Agenten durch Ihr aktuelles RAG laufen. Notieren Sie, ob die richtige Passage gefunden wurde, ob die Antwort korrekt ist und wie lange es insgesamt gedauert hat.
  3. 03
    Nur eine einzige Sache ändern
    Führen Sie denselben Testsatz mit dem Agenten aus, mit demselben Index und demselben Modell, auf demselben Rechner.
  4. 04
    Nach Fragetyp lesen
    Betrachten Sie das Ergebnis getrennt für einfache und komplexe Fragen, und erfassen Sie die Anzahl der Suchen pro Frage. Ein Gesamtdurchschnitt kann einen Gewinn bei den einen und einen Zeitverlust bei den anderen verdecken.
  5. 05
    Behalten, was sich rechtfertigen lässt
    Wenn nur bestimmte Fragen davon profitieren, kann ein Routing genügen: standardmäßig direktes RAG, die Schleife für Fragen, die als komplex erkannt werden.

Um den Qualitätsteil dieses Vergleichs zu automatisieren, stellt der Leitfaden zu Ragas passende Metriken vor. Notieren Sie außerdem die Paketversionen, das Modell, die Quantisierung und num_ctx: Andernfalls ist Ihr Ergebnis im Folgemonat nicht mehr vergleichbar.


#Weiterführende Informationen

Agentic RAG setzt auf einem bereits funktionierenden RAG auf. Diese Anleitungen behandeln die Grundlage, die zuerst stabil laufen sollte, verwandte Ansätze und die Agentenarchitektur.

Hat Ihnen dieser Guide geholfen?

Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.