Agentic RAG for Dummies: LangGraph-Retrieval mit Parent-Child-Chunks und Query-Klärung

Welche Lücke das Repository schließt

Die meisten RAG-Einführungen enden bei einem einzelnen Retrieve-then-Generate-Schritt: Frage einbetten, ähnliche Chunks holen, an das Sprachmodell übergeben. Das funktioniert bei einer präzise formulierten Frage mit einem einzigen Informationsbedarf. Es scheitert, sobald die Frage mehrteilig ist, sich auf den vorherigen Turn bezieht oder schlicht zu vage formuliert wurde.

Genau dort setzt dieses Projekt an. Das README beschreibt den Anspruch selbst als Brücke zwischen Grundlagen-Tutorials und einer erweiterbaren Architektur. Die Zielgruppe sind Entwickler, die LangGraph kennenlernen und dabei nicht bei einem Spielzeugbeispiel stehen bleiben wollen. Das Repository liefert zwei Zugänge: ein Notebook unter notebooks/agentic_rag.ipynb für den Einstieg und ein modulares Projekt für den Aufbau. Wer bereits eine funktionierende RAG-Pipeline betreibt und nur die Latenz senken will, bekommt hier nichts, was nicht schon vorhanden wäre.

Warum zweimal zerlegt wird: Parent- und Child-Chunks

Der Dokumentenvorbereitung liegt eine Beobachtung zugrunde, die sich in der Praxis häufig bestätigt: kleine Chunks liefern präzisere Treffer, große Chunks liefern brauchbareren Kontext. Das Projekt löst den Zielkonflikt, indem es zweimal schneidet. Zuerst entstehen Parent Chunks entlang der Markdown-Überschriften H1, H2 und H3, also an inhaltlich sinnvollen Grenzen. Aus diesen Parents werden anschließend Child Chunks fester Größe abgeleitet.

Zur Suchzeit durchsucht der Agent die kleinen Child Chunks und zieht bei einem Treffer den zugehörigen Parent als Kontext nach. Das ist ein etabliertes Muster, und die Wahl der Überschriften als Schnittgrenze ist dann sinnvoll, wenn die Quelldokumente tatsächlich strukturiertes Markdown sind. Bei Fließtext ohne Überschriften oder bei PDFs, die erst konvertiert werden müssen, fällt diese Struktur nicht vom Himmel. Das README verweist für diesen Schritt auf ein separates Toolkit namens Chunky, das PDFs nach Markdown überführt, Dokumente bereinigt und Chunking-Strategien vergleichbar macht. Wer ausschließlich saubere Markdown-Dateien einliest, braucht dieses Werkzeug nicht.

Die vier Stufen vom Nutzer-Input zur Antwort

Das README skizziert den Ablauf als Kette: User Query, Conversation Summary, Query Rewriting, Query Clarification, parallele Agenten, Aggregation, finale Antwort.

Stufe eins hält einen rollierenden Gesprächszusammenfassung plus die jüngste Historie vor. Der Zweck ist explizit, den Kontext nicht unbegrenzt wachsen zu lassen. Stufe zwei ist der interessanteste Teil. Hier werden Referenzen aufgelöst, das README nennt das Beispiel von "How do I update it?" zu "How do I update SQL?". Mehrteilige Fragen werden in fokussierte Sub-Queries zerlegt, unklare Eingaben erkannt und Anfragen für die Suche umformuliert. Wenn die Klärung nicht automatisch gelingt, pausiert der Graph und fragt den Nutzer. Das ist der Human-in-the-loop-Punkt, den die Projektbeschreibung im Kopf des README nennt.

Stufe drei startet pro Sub-Query einen eigenen Agenten-Subgraphen. Diese laufen parallel. Jeder durchsucht Child Chunks, holt Parents, korrigiert sich selbst, wenn die Treffer nicht ausreichen, komprimiert den Kontext, um redundante Abrufe zu vermeiden, und fällt kontrolliert zurück, wenn das Suchbudget erschöpft ist. Als Beispiel nennt das README die Doppelfrage nach JavaScript und Python, die zwei gleichzeitige Agenten erzeugt. Stufe vier führt die Einzelantworten zu einer Antwort zusammen. Wer wissen will, wie das Suchbudget konkret gezählt wird, findet im vorliegenden Material keine Angabe dazu.

Was das Projekt anbietet und was es dem Leser überlässt

Die Funktionsliste ist lang: hierarchisches Indexing, Gesprächsgedächtnis, Query-Klärung, Agenten-Orchestrierung, Map-Reduce über mehrere Agenten, Selbstkorrektur, Kontextkompression, Observability über Langfuse und Evaluation über RAGAS. Das ist keine schmale Bibliothek, sondern eine Sammlung von Bausteinen, die als Beispielsammlung organisiert ist.

Das ist zugleich die Einschränkung. Ein Repository, das Beobachtbarkeit und Evaluierung als Features auflistet, liefert damit noch keine Aussage über Trefferqualität. Die RAGAS-Metriken müssen selbst erhoben und interpretiert werden, und das README nennt keine Schwellenwerte, ab denen eine Konfiguration als brauchbar gilt. Wer das Projekt als Lernmaterial nutzt, sollte diesen Punkt ernst nehmen: die Pipeline läuft, aber ob sie für den eigenen Korpus gut genug läuft, ist eine offene Frage, die nur ein eigener Evaluationslauf beantwortet.

Inbetriebnahme: Ollama, Qdrant und der Startpunkt

Der lauffähige Teil der Anwendung ist Ollama-first. Das README gibt als Installationsschritt den Bezug eines Modells an:

ollama pull granite4.1:8b

Die Initialisierung erfolgt über ChatOllama aus dem Paket langchain_ollama mit den Parametern model="granite4.1:8b", temperature=0 und seed=42. Die feste Temperatur und der Seed sind eine bewusste Entscheidung für reproduzierbare Läufe, was bei einer Pipeline mit mehreren Entscheidungspunkten sinnvoll ist.

Für Cloud-Anbieter zeigt das README das Muster am Beispiel von ChatOpenAI aus langchain_openai, installiert per pip install -qU langchain-openai, mit dem API-Schlüssel aus der Umgebungsvariable OPENAI_API_KEY. Genannt werden außerdem Anthropic und Google. Der Hinweis im README ist wichtig und wird leicht überlesen: für zuverlässiges Tool Calling und Instruction Following sollten Modelle mit mindestens 8B Parametern verwendet werden, weil kleinere Modelle Retrieval-Anweisungen ignorieren oder halluzinieren können. Das ist keine Nebenbemerkung, sondern die praktische Untergrenze für dieses Design, das stark auf Anweisungsbefolgung angewiesen ist.

Als Vektordatenbank kommt Qdrant zum Einsatz, Python 3.11 oder neuer wird vorausgesetzt, LangGraph in Version 1.2 oder neuer. Ein Notebook lässt sich direkt in Colab öffnen, was den Einstieg ohne lokale Installation ermöglicht.

Grenzen, Fehlerbilder und der falsche Einsatzort

Die erste Einschränkung betrifft die Wissensbasis. Das hierarchische Indexing setzt Markdown-Struktur mit Überschriften voraus. Ein Korpus aus gescannten Verträgen, in dem die Konvertierung nur Fließtext liefert, verliert die Parent-Bildung an inhaltlichen Grenzen, und die zweistufige Zerlegung bringt dann weniger als erhofft.

Die zweite Einschränkung betrifft die Sprachunterstützung. Zu den Themen des Repositories gehört bm25, also lexikalische Suche. BM25 ist tokenisierungsabhängig, und das vorliegende Material nennt keine Angaben zur Tokenisierung für nicht-englische Texte. Für deutschsprachige Korpora ist das ein ungeklärter Punkt, den man vor dem Produktiveinsatz selbst prüfen muss, statt ihn anzunehmen.

Die dritte Einschränkung ist die Kostenstruktur. Die parallele Zerlegung in Sub-Queries erzeugt mehrere Agentenläufe pro Nutzerfrage, jeder mit eigenem Retrieval, Selbstkorrektur und Kompression. Bei einem lokalen Modell kostet das vor allem Zeit. Bei einem Cloud-Anbieter kostet es Tokens, und die Zahl der Modellaufrufe pro Frage steigt mit der Zahl der Sub-Queries. Wer eine Frage mit niedriger Latenz und vorhersehbaren Kosten pro Anfrage braucht, fährt mit einem einzelnen Retrieval-Schritt besser. Der agentische Ansatz ist dann sinnvoll, wenn die Fragen tatsächlich mehrteilig oder unklar sind und die Antwortqualität wichtiger ist als die Antwortzeit.

Alternative: LlamaIndex und der Unterschied im Ansatz

Als Vergleichsmaßstab bietet sich LlamaIndex an, ebenfalls ein Framework für Retrieval über eigene Daten, aber mit anderer Grundausrichtung. LlamaIndex stellt eine breite Sammlung von Index- und Query-Engines bereit, die über Konfiguration kombiniert werden. Der Fokus liegt auf Abfragestrategien und Datenkonnektoren.

Der Unterschied liegt in der Zuständigkeit für den Kontrollfluss. Bei LlamaIndex beschreibt man in der Regel eine Abfragekette, die deterministisch abläuft. Bei diesem Projekt beschreibt man einen Graphen mit Knoten und Kanten, in dem das Modell entscheidet, ob nachgefasst, erneut gesucht oder komprimiert wird. Das macht das Verhalten schwerer vorhersagbar und die Fehlersuche aufwendiger, ermöglicht aber Fälle, die eine feste Kette nicht abdeckt, etwa die Rückfrage an den Nutzer mitten in der Verarbeitung. Wer die Kontrolle über jeden Schritt behalten muss, ist mit LlamaIndex oder einer handgeschriebenen Pipeline besser bedient. Wer die Entscheidung über den nächsten Schritt an das Modell abgeben will, findet in LangGraph das passendere Werkzeug.

Wartung, Lizenz und was vor dem Fork zu klären ist

Das Repository steht unter der MIT-Lizenz. Diese erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass der Lizenztext und der Urheberrechtsvermerk in Kopien oder wesentlichen Teilen der Software erhalten bleiben. Das ist eine übliche und wenig einschränkende Regelung. Wer Code übernimmt, sollte den Vermerk nicht entfernen. Das ist keine Rechtsberatung, sondern eine Beschreibung dessen, was die Lizenzkennung im Repository bezeichnet.

Die Wartungslast liegt bei diesem Projekt weniger im Repository selbst als im Umfeld. Die Versionshistorie zeigt drei Releases zwischen April und Juni 2026, was auf eine gewisse Aktivität hindeutet, aber nichts über die Stabilität der Schnittstellen aussagt. Das README warnt ausdrücklich, dass sich Modellnamen häufig ändern und die offizielle Dokumentation vor dem Deployment geprüft werden sollte. Diese Warnung gilt für die Modellbezeichnungen ebenso wie für die LangChain-Integrationen, die den Anbieterwechsel tragen. Ein Team, das dieses Projekt forkt, übernimmt damit die Pflege von vier Anbieter-Integrationen, der Qdrant-Anbindung und der LangGraph-Version. Für ein Lernprojekt ist das vertretbar. Für eine Komponente, die jahrelang ohne Betreuung laufen soll, ist es ein Posten, der eingeplant werden muss.

Redaktionelles Fazit

Wer LangGraph und agentische Retrieval-Schleifen an einem lauffähigen Beispiel verstehen will, findet hier einen kompakten Einstieg, der sich über die Notebooks in Colab ohne lokale Installation öffnen lässt. Für mehrsprachige Korpora mit hohen Recall-Anforderungen an BM25 ist das Projekt die falsche Grundlage, weil die Dokumentation keine Tokenisierung für andere Sprachen nennt. Vor dem ersten Commit in ein eigenes Repository zu prüfen: die Modellbezeichnung granite4.1:8b in der Ollama-Konfiguration, die Lizenztexte der vier Cloud-Anbieter und die Frage, ob das Team die LangGraph-Version 1.2 oder neuer mitpflegen kann.

Offizielle Quellen

1. GiovanniPasq/agentic-rag-for-dummies on GitHub
2. Issues
3. License: MIT
4. README
5. Releases