Rag System Langgraph im Detail: Techniken und Anwendungsmöglichkeiten

Dokumente laden und für die Suche aufbereiten

Eine belastbare RAG-Pipeline beginnt nicht beim Sprachmodell, sondern bei sauber erfassten Quellen. Webseiten, PDFs, Wikis und Datenbankeinträge müssen so geladen werden, dass Inhalt, Herkunft und Aktualität später erkennbar bleiben. Fehlen diese Angaben, kann der Agent zwar Text finden, aber keine verlässliche Antwort mit nachvollziehbarer Quelle bilden.

Für Webseiten eignet sich ein HTTP-Client mit Timeout, Statusprüfung und klarer Fehlerbehandlung. HTML sollte nicht ungefiltert in den Index gelangen: Navigation, Cookie-Hinweise, Werbung, Skripte und Fußzeilen erzeugen Suchrauschen. Mit einem HTML-Parser lassen sich Hauptinhalt, Überschriften und Tabellen gezielt extrahieren. Die Rohseite sollte dennoch separat gespeichert werden, damit eine erneute Verarbeitung möglich bleibt, wenn sich die Filterregeln ändern.

Jedes erzeugte Dokument braucht aussagekräftige Metadaten. Dazu gehören mindestens Quelle, Titel, Dokumenttyp, Abrufzeitpunkt und Versionsstand. Bei internen Dateien sind zusätzlich Abteilung, Sprache, Zugriffsgruppe und Gültigkeitszeitraum sinnvoll. Eine stabile Dokument-ID verhindert, dass ein erneuter Import denselben Inhalt mehrfach einträgt. Für Webseiten kann sie sich aus der bereinigten URL und einem Inhalts-Hash zusammensetzen.

Prüfe Zeichensatz, Leerzeichen und Zeilenumbrüche. Bei PDF-Dateien muss die Textextraktion gesondert kontrolliert werden, denn gescannte Seiten liefern oft nur Bilder. Dann ist eine OCR-Stufe nötig. Tabellen, Quellcode und Aufzählungen verlangen ebenfalls besondere Regeln: Werden sie zu stark geglättet, geht ihre Bedeutung verloren.

Ein robustes Ladeverfahren behandelt Fehler je Quelle getrennt. Ein nicht erreichbarer Blogbeitrag darf den Import anderer Dokumente nicht stoppen. Sinnvoll sind Wiederholungen mit wachsender Wartezeit, eine Begrenzung der Dateigröße und eine Liste fehlgeschlagener Quellen. Bei dynamischen Webseiten kann außerdem ein Browser-Renderer nötig sein.

Für geschützte oder personenbezogene Inhalte gelten eigene Zugriffsregeln. Solche Dokumente gehören nicht automatisch in einen gemeinsamen Index. Die Berechtigungsprüfung muss später bereits vor der Rückgabe eines Treffers erfolgen.

Erst danach folgt die Aufteilung in Suchabschnitte. Die passende Größe hängt vom Inhalt ab: Technische Handbücher benötigen oft größere Abschnitte als kurze FAQ-Antworten. Überschriften sollten möglichst mit dem zugehörigen Text zusammenbleiben. Ein Zusatz wie „Kapitel: Authentifizierung“ vor dem eigentlichen Text erleichtert die Einordnung.

Die Qualität lässt sich vor dem Indexieren mit kleinen Prüfungen absichern:

• Leere oder extrem kurze Dokumente aussortieren
• Duplikate über Hashwerte erkennen
• Fehlende Titel und Quellen markieren
• Sprache und Zeichencodierung prüfen
• Stichproben im Original gegen den extrahierten Text lesen
• Abrufzeit und Versionsnummer für spätere Aktualisierungen speichern

Für das LangGraph-System ist diese Vorarbeit entscheidend. Der Graph kann nur mit dem Material arbeiten, das der Index tatsächlich enthält. Gute Metadaten ermöglichen Filter, etwa nach Produktversion oder Nutzergruppe. So wird aus einer Textsammlung ein kontrollierbarer Wissensbestand.

Textabschnitte mit passender Größe und Überlappung erstellen

Die Aufteilung bestimmt, welche Textstellen später gemeinsam als Kontext erscheinen. Ein Abschnitt muss daher eine in sich verständliche Aussage tragen. Ein einzelner Satz mit Verweis auf einen vorherigen Absatz liefert dem Sprachmodell kaum Halt. Thema, Bedingung und Ergebnis sollten möglichst zusammenbleiben.

Eine feste Tokenzahl passt nicht für jede Quelle. Für kurze FAQ-Antworten reichen oft 150 bis 400 Tokens. Technische Erklärungen benötigen eher 400 bis 900 Tokens, wenn Definitionen, Code und Beispiele zusammengehören. Bei sehr langen Abschnitten steigt der Ballast im Kontext; bei zu kleinen Stücken zerfällt der Sinn. Der richtige Wert entsteht aus Inhalt, Fragestellung und Modellfenster.

Die Überlappung verbindet benachbarte Abschnitte. Häufig genügen etwa 10 bis 20 Prozent der Abschnittslänge. Bei 500 Tokens wären das ungefähr 50 bis 100 Tokens. Eine größere Überlappung kann bei juristischen Klauseln oder Schrittfolgen helfen, erhöht aber Speicherbedarf und ähnliche Treffer.

Nutze möglichst strukturorientierte Trennregeln. Eine sinnvolle Reihenfolge lautet:

• Kapitel- und Abschnittsgrenzen
• Absätze
• Sätze
• Wörter
• Zeichen als letzte Notlösung

So bleiben Überschriften, Erläuterungen und Beispiele eher beieinander. Bei Quellcode sollte ein Block nicht mitten in einer Funktion enden. Tabellen brauchen eine eigene Behandlung, weil einzelne Zeilen ohne Spaltenüberschriften missverständlich werden. Auch Listen sollten möglichst vollständig in einem Abschnitt bleiben.

Für verschachtelte Dokumente lohnt sich eine hierarchische Strategie: Zuerst entstehen größere Elternabschnitte aus Kapiteln, daraus kleinere Suchabschnitte. Der Treffer enthält zusätzlich den Kapitelpfad. Das verbessert die Einordnung, ohne den gesamten Abschnitt in den Antwortkontext zu laden.

Die Abschnittsqualität sollte mit realen Suchfragen geprüft werden. Erstelle einen kleinen Testsatz aus einfachen, mehrdeutigen und mehrteiligen Fragen. Bewerte, ob der richtige Abschnitt gefunden wird und ob er die Antwort allein verständlich macht. Achte außerdem auf doppelte Treffer durch Überlappung. Ein hoher Trefferanteil genügt nicht, wenn der Agent anschließend fünf nahezu identische Passagen erhält.

Ein praktischer Test umfasst mindestens:

• Fragen nach Definitionen
• Fragen nach Voraussetzungen
• Vergleiche zwischen zwei Konzepten
• Fragen zu Ausnahmen und Grenzen
• mehrstufige Aufgaben mit mehreren benötigten Textstellen

Die Segmentierung ist damit eine eigene Qualitätsstufe des RAG-Systems. Anpassungen an Grenzen, Metadaten und Überlappung verändern die Antwortqualität oft stärker als ein Wechsel des Sprachmodells.

Techniken und Anwendungsmöglichkeiten eines RAG-Systems mit LangGraph

Embeddings und Vektorspeicher für den Retriever aufbauen

Embeddings übersetzen Text in Zahlenvektoren. Ähnliche Inhalte liegen in diesem Vektorraum näher beieinander als thematisch entfernte Passagen. Der Retriever sucht dadurch nicht nur nach identischen Wörtern, sondern auch nach verwandten Formulierungen. Eine Frage nach „Zugriff ohne Passwort“ kann etwa einen Abschnitt zu „tokenbasierter Anmeldung“ finden.

Dokumentabschnitte und spätere Suchanfragen müssen mit demselben Embedding-Modell verarbeitet werden. Werden beide Seiten unterschiedlich kodiert, verlieren Distanzwerte ihre Aussagekraft. Prüfe Modellname, Sprachunterstützung, Vektorlänge und Normalisierung. Bei mehrsprachigen Beständen ist ein Modell mit guter deutscher und englischer Abdeckung meist wichtiger als ein Spitzenwert in nur einer Sprache.

Die Vektorlänge beeinflusst den Speicherbedarf. Ein Modell mit 1.536 Dimensionen benötigt pro Eintrag mehr Speicher als eines mit 768 Dimensionen. Bei mehreren Millionen Abschnitten summiert sich das deutlich. Zusätzlich fallen Metadaten, Indexstrukturen und Sicherungskopien an. Für einen kleinen Test genügt ein lokaler Speicher; eine dauerhafte Anwendung braucht Persistenz, Backups und klare Regeln für Aktualisierungen.

Ein Vektorspeicher verwaltet meist drei Dinge:

• den Embedding-Vektor
• den ursprünglichen Textabschnitt
• Filterdaten wie Quelle, Version oder Berechtigungsgruppe

Die Suche liefert häufig die Top-k-Treffer. Ein Wert zwischen 4 und 10 ist ein brauchbarer Startpunkt, aber kein allgemeines Gesetz. Wenige Treffer halten den Kontext schlank, mehr Treffer erhöhen die Chance auf seltene Informationen, bringen jedoch auch Nebentexte in den Prompt. Ein nachgeschaltetes Reranking kann die erste Auswahl verbessern, indem ein zweites Modell die direkte Passung zwischen Anfrage und Treffer bewertet.

Für die Ähnlichkeit kommen je nach Index Kosinusdistanz, Skalarprodukt oder euklidische Distanz zum Einsatz. Wichtig ist vor allem ihre einheitliche Verwendung. Die Schwelle für einen relevanten Treffer sollte anhand echter Testfragen festgelegt werden, nicht nach Gefühl.

Bei großen Beständen helfen Metadatenfilter. Eine Anfrage zur Version 4.45 sollte nicht automatisch Treffer aus Version 3 erhalten. Filter können Sprache, Produktstand, Mandant oder Freigabestatus berücksichtigen. Die Berechtigungsprüfung muss bereits vor der Rückgabe stattfinden.

Berechne Embeddings nur bei neuen oder geänderten Inhalten. Eine Inhalts-Hash-Prüfung verhindert unnötige Aufrufe. Für Löschungen braucht der Index einen kontrollierten Abgleich mit der Quelle. Sonst bleiben veraltete Abschnitte auffindbar, obwohl sie längst nicht mehr gelten.

Bewerte den Aufbau mit drei getrennten Fragen: Findet die Suche den richtigen Abschnitt? Steht darin genug Kontext? Verwendet die Antwort tatsächlich den passenden Treffer? Erst diese Kette zeigt, ob der Retriever im LangGraph-System zuverlässig arbeitet.

Retriever-Tools für den LangGraph-Agenten definieren

Ein Retriever-Tool ist die kontrollierte Schnittstelle zwischen dem LangGraph-Agenten und der Suche. Es sollte eine klar begrenzte Aufgabe erfüllen: Anfrage entgegennehmen, passende Treffer bestimmen und ein lesbares Ergebnis an den nächsten Graph-Schritt liefern.

Die Beschreibung des Tools wirkt wie eine Bedienungsanleitung für das Modell. Sie sollte Suchbereich, erwarteten Eingabeinhalt und Grenzen des Werkzeugs nennen. Verwende außerdem ein festes Schema, etwa ein einzelnes Feld query. Freie, verschachtelte Eingaben machen Tool-Aufrufe fehleranfällig.

Ein gutes Tool liefert neben dem Text auch Herkunftsinformationen. Dazu zählen Dokument-ID, Titel, Abschnitt und Rangfolge. Strukturierte Datensätze sind für weitere Nodes leichter zu verarbeiten als ein langer String.

Praktisch enthält ein Treffer zum Beispiel:

• content: der gefundene Abschnitt
• source: die Dokumentquelle
• score: der Suchwert
• metadata: Version, Bereich oder Zugriffsgruppe

Die Tool-Funktion muss Fehler sauber unterscheiden. Eine leere Ergebnisliste ist etwas anderes als ein ausgefallener Index. Bei einem technischen Fehler kann der Graph abbrechen oder eine Ersatzquelle wählen; bei fehlenden Treffern kann er die Anfrage verändern. Beides in eine Meldung wie „Keine Informationen gefunden“ zu pressen, führt den nächsten Schritt in die falsche Richtung.

Begrenze Rückgabemenge, Textlänge und Laufzeit. Für mehrere Wissensquellen sind getrennte Tools oft besser als eine Funktion mit vielen versteckten Parametern. Ein Tool für Produktdokumentation, eines für interne Richtlinien und eines für aktuelle Webdaten macht die Auswahl klarer.

Bei sensiblen Anwendungen gehört die Berechtigungsprüfung in die Tool-Schicht. Die Funktion erhält Identität oder Zugriffskontext aus der Anwendung und filtert vor der Rückgabe. Das ist eine technische Grenze, keine bloße Prompt-Regel.

Die Modellbindung sollte nur die Werkzeuge enthalten, die im jeweiligen Graph-Schritt erlaubt sind. So lässt sich verhindern, dass ein Antwort-Node erneut sucht oder ein Recherche-Node eine unpassende Aktion ausführt. Für deterministische Abläufe kann der Graph den Tool-Schritt direkt aufrufen; bei flexiblen Anfragen darf das Modell die Auswahl treffen.

Teste jedes Tool unabhängig vom Sprachmodell. Prüfe gültige Eingaben, leere Anfragen, sehr lange Fragen, Sonderzeichen, fehlende Rechte und einen nicht verfügbaren Index. Erst dann lohnt die Einbindung in den Agenten.

Zustände, Nodes und Kanten im RAG-Graphen nutzen

Ein LangGraph-RAG-System wird übersichtlich, wenn der Ablauf als Zustandsmaschine gedacht wird. Jeder Verarbeitungsschritt liest einen definierten Zustand und schreibt nur die Werte zurück, die er verändert. Dadurch bleibt nachvollziehbar, warum der Graph einen bestimmten Pfad genommen hat.

Der Zustand kann neben Nachrichten weitere Felder enthalten, zum Beispiel aktuelle Anfrage, Suchstatus, Treffer, Qualitätsurteil, Versuchszähler und Fehlerstatus. Für Nachrichten eignet sich ein Verlauf mit eigenem Zusammenführungsmechanismus. Treffer sollten dagegen nicht unkontrolliert angehängt werden, damit der Agent bei jedem Durchlauf nicht alte und neue Ergebnisse zugleich verarbeitet.

Ein schlanker Zustand könnte logisch so aussehen:

• Nachrichtenverlauf für Nutzer, Modell und Werkzeuge
• normalisierte Suchanfrage
• aktuelle Trefferliste
• Bewertung der Trefferqualität
• Anzahl der Suchversuche
• finale Antwort oder kontrollierte Abbruchmeldung

Nodes sind zustandsbezogene Funktionen. Jeder sollte eine klar abgegrenzte Aufgabe besitzen und möglichst keine versteckten Seiteneffekte auslösen. Typische Rollen sind Anfrageplanung, Ergebnisauswertung, Kontextauswahl und Antwortprüfung. Kleine Nodes lassen sich leichter testen als eine Funktion, die Suche, Bewertung und Ausgabe bündelt.

Kanten legen den Ablauf fest. Eine feste Kante eignet sich, wenn der nächste Schritt immer folgt; eine bedingte Kante, sobald der Zustand den Weg bestimmt. Ein Qualitätsfeld kann etwa zur Antwort, zu einer neuen Suche oder zum Abbruch führen. Die Entscheidung sollte aus sichtbaren Zustandswerten hervorgehen.

Ein zentraler Einstiegspunkt ist der Planungs-Node. Er kann die Frage klassifizieren und einen passenden Pfad vorbereiten. Bei einer reinen Wissensfrage genügt möglicherweise die Antworterzeugung. Bei unsicherem oder spezialisiertem Inhalt wird der Recherchepfad aktiviert. Danach bewertet ein eigener Node, ob die Treffer die Frage tatsächlich abdecken.

Begrenze Schleifen mit einem Versuchszähler. Nach zwei oder drei erfolglosen Durchläufen sollte der Graph eine verständliche Meldung ausgeben oder einen alternativen Weg wählen. Ein solcher Abbruch ist ein definierter Betriebszustand.

Für längere Vorgänge bietet sich eine Unterteilung in Teilgraphen an. Ein Recherche-Teilgraph sammelt und bewertet Informationen, ein Antwort-Teilgraph verarbeitet nur den freigegebenen Kontext. LangGraph unterstützt außerdem Unterbrechungen und Fortsetzungen. Ein Workflow kann vor einer kostenintensiven oder folgenreichen Aktion pausieren und nach einer Freigabe am gespeicherten Zustand fortsetzen.

Plane jeden Übergang mit einem klaren Vertrag: Welche Felder müssen vorhanden sein, welche Werte sind erlaubt, und was passiert bei einem Fehler? Typisierte Zustände, kleine Testfälle und begrenzte Schleifen machen die Graphstruktur prüfbar.

Zwischen direkter Antwort und Retrieval entscheiden

Die Routing-Entscheidung sollte nicht allein auf dem Gefühl des Sprachmodells beruhen. Entscheidend ist, ob die Frage zeitloses Allgemeinwissen, domänenspezifische Fakten oder aktuellen Quelleninhalt verlangt. Eine kurze Klassifikation vor dem Antwortschritt schafft dafür ein klares Raster.

Direktes Antworten passt bei kleinen Rechenaufgaben, Begriffsfragen oder einer einfachen Umformulierung. Retrieval ist sinnvoll, sobald eine konkrete Dokumentensammlung maßgeblich ist, eine Version genannt wird oder die Antwort belegbare Einzelheiten enthalten soll. Formulierungen wie „laut Handbuch“, „in unserer Richtlinie“ oder „für Release 4.2“ sind starke Suchsignale.

Ein praktisches Routing-Schema kann drei Klassen verwenden:

• direct: keine externe Wissensbasis erforderlich
• retrieve: interne oder fachliche Dokumente werden benötigt
• web: die Frage verlangt Informationen, die sich laufend ändern

Die Klassifikation kann als strukturierte Modellausgabe erfolgen. Erlaube nur feste Werte und ergänze ein Feld für Begründung oder erkannte Zeitbindung. Harte Regeln sollten Vorrang erhalten: Eine explizit verlangte Quelle löst die Suche aus, selbst wenn das Modell die Frage auch ohne sie beantworten könnte.

Mehrdeutige Fragen verdienen einen eigenen Pfad. Bei „Wie funktioniert die Anmeldung?“ fehlen oft Produkt, Version und Zielgruppe. Statt vorschnell zu suchen, kann der Graph eine kurze Rückfrage stellen. Bei dringenden Abläufen ist auch eine vorsichtige Standardsuche möglich, sofern der Agent die Annahme offen nennt.

Ein Kostenmodell hilft bei der Feinabstimmung. Direkte Antworten sind meist schneller und benötigen weniger externe Aufrufe. Retrieval erhöht Laufzeit und Rechenaufwand, kann aber sachliche Fehler senken. Für zeitkritische Anwendungen lässt sich ein Schwellenwert definieren: Niedrige Unsicherheit erlaubt den direkten Pfad, hohe Unsicherheit aktiviert die Wissenssuche.

Nutze dabei nicht nur die Sicherheit des Modells. Aussagekräftiger sind zusätzliche Signale:

• enthält die Frage konkrete Fachbegriffe oder Versionsnummern?
• wird eine Quelle, Richtlinie oder Datei erwähnt?
• ist die Information zeitabhängig?
• gibt es im bisherigen Gespräch bereits belastbaren Kontext?
• droht bei einer falschen Antwort ein hoher Schaden?

Im Graphen führt das Routing zu klar getrennten Zuständen. Der direkte Pfad erzeugt eine Antwort aus dem Gesprächskontext, der Suchpfad fordert Informationen an, und ein dritter Pfad kann fehlende Angaben abfragen. So wird eine Vermutung nicht unbemerkt als recherchierte Tatsache ausgegeben.

Teste die Weiche mit absichtlich ähnlichen Fragen: Eine allgemeine Erklärung sollte direkt laufen, dieselbe Frage mit einer bestimmten Dokumentversion jedoch recherchieren. Erst solche Grenzfälle zeigen, ob die Entscheidung auf dem Informationsbedarf beruht.

Relevanz prüfen und Suchanfragen gezielt umformulieren

Ein Treffer ist nicht automatisch brauchbarer Kontext. Für eine belastbare Entscheidung müssen Inhalt, Fragestellung und Belegfunktion zusammenpassen. Deshalb sollte der Graph die Treffer mit einem eigenen Bewertungsauftrag prüfen.

Der Bewertungs-Node kann jeden Treffer nach drei Kriterien einordnen: Beantwortet er einen Teil der Frage? Enthält er konkrete Aussagen statt nur Schlagwörter? Reicht der Kontext für eine sichere Schlussfolgerung? Eine strukturierte Ausgabe mit relevant, partly_relevant oder irrelevant macht die nächste Kante eindeutig. Zusätzlich kann ein kurzer Grund gespeichert werden.

Für die Bewertung eignet sich eine Kombination aus Regeln und Modellprüfung. Regeln erkennen etwa einen fehlenden Versionsbezug oder zu kurze Treffer. Ein Sprachmodell beurteilt anschließend die inhaltliche Passung. Bei wichtigen Antworten sollte es die konkrete Textstelle nennen, auf der das Urteil beruht.

Eine Suchanfrage ist oft zu knapp, umgangssprachlich oder vom Gesprächskontext abhängig. Der Umformulierungs-Node macht daraus eine eigenständige Suchfrage, ergänzt fehlende Begriffe, löst Pronomen auf und trennt mehrere Teilfragen. Aus „Und was gilt dort für Tokens?“ wird beispielsweise eine Anfrage, die Produkt, Thema und gewünschte Eigenschaft ausdrücklich nennt.

Die ursprüngliche Frage darf dabei nicht überschrieben werden. Speichere beide Varianten:

• user_query: unveränderte Eingabe
• search_query: aktuelle Fassung für die Suche
• query_history: frühere Suchvarianten mit Ergebnis

So bleibt nachvollziehbar, ob eine schlechte Antwort durch die Quelle oder durch die Suchformulierung entstand. Außerdem verhindert die Historie nahezu identische Wiederholungen.

Eine gute Umformulierung erhält Zeitangaben, Produktversionen, Zielgruppen und Vergleichsmerkmale. Bei mehrteiligen Fragen kann der Node mehrere Suchanfragen erzeugen. Die Ergebnisse werden danach zusammengeführt, statt eine einzelne überladene Anfrage zu erzwingen.

Begrenze die Zahl der Iterationen und ändere die Strategie sichtbar. Nach einem schwachen Treffer kann der Agent Fachbegriffe ergänzen, Synonyme hinzufügen oder die Frage in Teilfragen zerlegen. Bleibt die Abdeckung unzureichend, sollte er die Wissenslücke benennen.

Bewerte die Schleife mit Trefferabdeckung, Anteil relevanter Passagen, Anzahl der Suchversuche und Antwortgenauigkeit. Erst wenn der Graph eine Verbesserung erkennt, sollte er den neuen Suchlauf ausführen.

Mehrere Quellen mit Qdrant und Websuche verbinden

Mehrere Quellen werden nützlich, wenn der Graph ihre Rollen trennt. Ein Qdrant-Index eignet sich für kuratierte Dokumente mit stabilen Versionen. Eine Websuche ergänzt Inhalte, die sich häufig ändern oder außerhalb des internen Bestands liegen. Beide Wege sollten eigene Werkzeuge, Rückgabeformate und Qualitätsregeln besitzen.

Der Agent kann die Quellen nach Aufgabe auswählen oder parallel abfragen. Für interne Produktdokumentation genügt meist der passende Qdrant-Bestand. Bei einer zusätzlichen aktuellen Sicherheitsmeldung kommt die Websuche hinzu. Vergleichsfragen erhalten Ergebnisse aus beiden Pfaden, markiert mit einer gemeinsamen Dokument-ID und einem Feld wie source_type.

Eine einfache Quellenlogik sieht so aus:

• intern: freigegebene Handbücher, Richtlinien und Wissensartikel
• extern: aktuelle Webseiten und öffentliche Bekanntmachungen
• kombiniert: stabile Erklärung plus zeitabhängige Ergänzung

Webtreffer brauchen eine strengere Behandlung als kuratierte Dokumente. Speichere Titel, URL, Veröffentlichungsdatum und Abrufzeit. Prüfe außerdem, ob eine Seite Zusammenfassung, Meinungsäußerung oder Primärquelle ist. Ein hoher Rang in der Suchmaschine belegt keine fachliche Richtigkeit.

Qdrant kann mehrere Collections oder Payload-Filter verwenden. Collections trennen stark unterschiedliche Embedding-Räume oder Datenmodelle. Payload-Filter eignen sich für Version, Sprache, Mandant und Freigabestatus innerhalb eines Bestands.

Bei parallelen Abrufen müssen doppelte Aussagen zusammengeführt werden. Ein Normalisierungsschritt erkennt gleiche URLs, identische Textpassagen und nahezu gleiche Meldungen. Danach erhalten Primärquellen Vorrang. Widersprüchliche Aussagen dürfen nicht still verschmolzen werden; der Antwortpfad sollte den Konflikt weitergeben.

Besonders wichtig ist die Zeitlogik. Interne Dokumente erklären oft den vorgesehenen Prozess, während eine Webquelle eine spätere Änderung meldet. Beide Angaben müssen anhand ihres Datums eingeordnet werden. Bei Rechts-, Sicherheits- oder Versionsfragen gewinnt die jüngere Quelle nicht automatisch; maßgeblich sind Gültigkeit, Zuständigkeit und Belegqualität.

Für die Zusammenführung hilft ein einheitliches Ergebnisobjekt mit:

• Quelle und Quellentyp
• Zeitstempel und Versionsangabe
• relevantem Textauszug
• Vertrauens- oder Prioritätsstufe
• Hinweis auf mögliche Widersprüche

Die Websuche sollte nur mit begrenzter Tiefe laufen. Öffne nicht jede gefundene Seite automatisch. Ein sinnvoller Ablauf folgt wenigen Links, prüft deren Inhalt und beendet die Recherche, sobald die offene Teilfrage belegt ist.

Datenschutz und Zugriffsschutz gelten für beide Pfade. Interne Qdrant-Treffer brauchen eine Nutzerprüfung. Externe Inhalte erfordern eine Kontrolle auf personenbezogene Daten, Nutzungsrechte und schädliche Anweisungen in Webseiten. Fremder Text ist Datenmaterial, kein Befehl an den Agenten.

Die Verbindung ist gelungen, wenn jede Antwort erkennen lässt, welche Quelle welchen Teil beigetragen hat. Qdrant liefert den stabilen Wissenssockel, die Websuche den aktuellen Rand.

Antworten aus geprüften Dokumenten erzeugen

Die Antworterzeugung sollte erst beginnen, wenn der Graph einen freigegebenen Kontext übergibt. Der Antwort-Node erhält nicht die komplette Trefferliste, sondern eine kuratierte Auswahl mit klarer Herkunft. Das hält den Prompt schlank und reduziert Ablenkungen durch Randinformationen.

Die zentrale Anweisung muss eindeutig sein: Nutze ausschließlich den bereitgestellten Kontext für überprüfbare Tatsachen. Fehlt eine nötige Information, soll das Modell dies offen sagen. Vermutungen dürfen nicht wie Ergebnisse der Dokumentensuche klingen.

Ein stabiler Antwort-Prompt enthält mindestens:

• die Nutzerfrage
• den freigegebenen Kontext
• Regeln für Unsicherheit und Widersprüche
• das gewünschte Ausgabeformat
• die Kennzeichnung der verwendeten Quellen

Die Textabschnitte sollten mit kurzen Belegmarken erscheinen, etwa [Quelle 1] oder [Dokument B, Abschnitt 3]. Das Modell kann diese Marken anschließend passenden Aussagen zuordnen. Sie dürfen nicht nachträglich aus einer freien Antwort erraten werden, sondern müssen vor der Generierung eindeutig mit den Textstellen verbunden sein.

Bei unterschiedlichen Werten in mehreren Dokumenten nennt der Antwort-Node beide Positionen und erklärt den Unterschied, sofern der Kontext das zulässt. Fehlt eine erkennbare Rangfolge, ist ein transparenter Hinweis auf den Konflikt besser als eine scheinbar sichere Entscheidung.

Die Ausgabeform hängt von der Aufgabe ab. Eine kurze Sachfrage braucht meist zwei bis vier Sätze. Ein Vergleich profitiert von einer kompakten Tabelle, eine Anleitung von nummerierten Schritten. Ein nachgelagerter Prüf-Node kann kontrollieren, ob Pflichtfelder, Quellenmarken und gewünschte Struktur vorhanden sind.

Ein nützlicher Prüfablauf kontrolliert:

• Wurde jede zentrale Aussage durch den Kontext gedeckt?
• Gibt es unbelegte Zahlen, Namen oder Zeitangaben?
• Sind Quellenmarken eindeutig zugeordnet?
• Wurden Einschränkungen der Dokumente erhalten?
• Enthält die Antwort eine klare Aussage bei fehlenden Informationen?

Bei einem negativen Prüfergebnis sollte der Graph nicht denselben Prompt erneut senden. Besser sind gezielte Korrekturen: unbelegte Sätze entfernen, eine Quelle ergänzen oder die Antwort als unvollständig kennzeichnen. Bleibt der Belegstatus unklar, endet der Ablauf mit einer ehrlichen Wissenslücke.

Trenne Antworttext und Quellenliste logisch. Der Text bleibt lesbar, während die Quellen am Ende die Nachprüfung ermöglichen. Bei internen Anwendungen kann zusätzlich eine Dokument-ID angezeigt werden; bei öffentlichen Quellen gehört ein anklickbarer Verweis dazu, sofern die Nutzung rechtlich und technisch erlaubt ist.

So entsteht keine bloße Textfortsetzung, sondern eine belegorientierte Antwort. Der Graph steuert, welche Aussagen zulässig sind; das Sprachmodell übernimmt Formulierung, Ordnung und Ton.

LangSmith für Tracing und Fehleranalyse einsetzen

LangSmith macht sichtbar, was in einem agentischen RAG-Lauf tatsächlich passiert. Statt nur die fertige Antwort zu betrachten, lässt sich die komplette Kette untersuchen: Routing, Graph-Knoten, Tool-Aufrufe, Modellantworten und Zustandsübergänge. Gerade bei bedingten Pfaden liegt die Ursache eines Fehlers oft an einer früheren Entscheidung.

Für jeden Lauf sollten aussagekräftige Metadaten gesetzt werden. Dazu zählen etwa Umgebung, Anwendungsversion, Graph-Version, Nutzeranfrage, Modellname und verwendete Datenquelle. Eine Run-ID verbindet Teilvorgänge zu einem gemeinsamen Trace. So bleibt erkennbar, ob ein langsamer Lauf durch Modell, Retriever, externen Dienst oder Schleife verursacht wurde.

Die zeitliche Sicht auf einzelne Spans zeigt:

• welcher Node gestartet wurde
• wie lange der Modellaufruf dauerte
• welches Tool mit welchen Parametern lief
• wie viele Tokens verarbeitet wurden
• an welcher Stelle ein Fehler oder Timeout entstand

Traces dürfen keine geheimen Inhalte unkontrolliert speichern. API-Schlüssel, Passwörter und vollständige personenbezogene Datensätze gehören nicht in Protokolle. Nutze Maskierung, Feldfilter und kurze Aufbewahrungszeiten. Für sensible Anwendungen ist zu dokumentieren, wer Traces einsehen darf und in welcher Region sie verarbeitet werden.

Die Auswertung wird stärker, wenn Läufe mit Rückmeldungen verknüpft werden. Nutzer können Antworten bewerten, Fachteams die Belegqualität prüfen und automatische Prüfer Quellenabdeckung sowie Format messen. Diese Signale helfen, schlechte Routing-Entscheidungen und schwache Graphpfade gezielt zu finden.

Für reproduzierbare Tests lassen sich Datensätze mit Referenzfragen und erwarteten Kriterien anlegen. Nach einer Änderung an Prompt, Modell oder Graph wird derselbe Satz erneut ausgeführt. Verglichen werden nicht nur Endantworten, sondern auch:

• Trefferquote der richtigen Quelle
• Anzahl der Graph-Schritte
• Fehlerrate bei Tool-Aufrufen
• Antwortlatenz und Tokenverbrauch
• Abweichungen bei Quellenmarken

Ein typischer Fehler wird dadurch schnell greifbar: Der Agent sucht die richtige Quelle, verliert aber beim Übergang zum Antwort-Node die Treffer. Ein anderer Lauf zeigt vielleicht, dass ein Timeout als leere Ergebnisliste behandelt wird. Beide Probleme sehen für Nutzer ähnlich aus, benötigen technisch jedoch unterschiedliche Korrekturen.

Lege für produktive Systeme Warnwerte fest. Ein ungewöhnlich hoher Anteil an Suchwiederholungen, steigende Laufzeiten oder viele leere Treffer können auf einen defekten Index, eine Änderung der Dokumentstruktur oder eine fehlerhafte Modellversion hinweisen. Benachrichtigungen sollten auch schleichende Qualitätsverluste erfassen.

LangSmith ersetzt keine fachliche Bewertung. Es liefert die Spur, mit der sich Entscheidungen prüfen und Verbesserungen messen lassen. Zusammen mit versionierten Prompts, Testfällen und klaren Betriebskennzahlen wird aus dem Graphen ein beobachtbares System.

Fazit: Agentic RAG gezielt planen und schrittweise erweitern

Ein tragfähiges Agentic-RAG-System entsteht nicht durch möglichst viele Tools, sondern durch klare Entscheidungen im Ablauf. Der Graph sollte nur so komplex sein, wie es die Aufgabe verlangt. Für einen ersten Prototyp genügen meist ein begrenzter Wissensbestand, ein Suchpfad und ein Antwortpfad. Erweiterungen kommen hinzu, wenn Tests eine konkrete Lücke zeigen.

Plane den Aufbau in messbaren Ausbaustufen. Definiere vor dem Start, welche Fragen das System beantworten soll, welche Quellen gelten und wann eine Antwort als gelungen gilt. Geeignete Kennzahlen sind Antwortgenauigkeit, Quellenabdeckung, Fehlerrate, Latenz und Kosten pro Anfrage. Ohne diese Basis bleibt unklar, ob eine neue Graph-Kante Fortschritt bringt oder nur mehr Bewegung erzeugt.

Für den Betrieb lohnt sich eine feste Versionslogik. Halte Änderungen an Prompts, Modellen, Graphen und Datenbeständen getrennt fest. So lässt sich ein Qualitätseinbruch zuordnen: Ein neues Sprachmodell kann andere Suchanfragen erzeugen, ein neuer Datenimport dagegen die Trefferbasis verändern.

Behandle Fehler als erwartete Zustände. Für unklare Fragen, fehlende Quellen oder nicht erreichbare Schnittstellen sollte jeweils ein definierter Ausgang existieren:

• Rückfrage bei fehlenden Angaben
• klare Wissenslücke bei fehlender Abdeckung
• begrenzter Abbruch bei technischen Fehlern
• Weiterleitung an ein zuständiges Team bei hohem Risiko

Besondere Aufmerksamkeit verdient die Trennung zwischen Vorschlag und Handlung. Ein RAG-Agent darf zunächst Informationen sammeln und Antworten formulieren. Aktionen wie das Ändern eines Kontos, das Versenden einer Nachricht oder das Auslösen eines Kaufs brauchen zusätzliche Freigaben. Im europäischen Rechtsrahmen können je nach Einsatzbereich außerdem Pflichten aus der Verordnung (EU) 2024/1689, dem EU AI Act, greifen. Prüfe Einstufung, Transparenz und Dokumentation vor dem produktiven Einsatz.

Wähle das Modell nach Aufgabe, nicht nach Schlagzeile. Ein kleineres Modell reicht oft für Klassifikation, Feldprüfung oder einfache Umformulierung. Ein stärkeres Modell kann bei mehrdeutigen Fragen und schwierigen Belegen nötig sein. Diese Aufteilung senkt häufig Kosten und stabilisiert den Ablauf.

Die beste Erweiterung behebt eine nachgewiesene Schwäche. Fehlen aktuelle Daten, braucht der Graph eine zeitnahe Quelle. Sind Treffer thematisch passend, aber zu ungenau, hilft ein Reranking. Scheitern mehrteilige Fragen, ist eine Zerlegung sinnvoll. So wächst das System kontrolliert statt nach dem Prinzip „noch ein Tool wird es schon richten“.

Als Abschlusskriterium genügt keine eindrucksvolle Demo. Ein fertiger Agent muss auch bei missverständlichen, veralteten und absichtlich schwierigen Fragen nachvollziehbar reagieren. Er sollte seine Grenzen kennen, Änderungen reproduzierbar machen und für Nutzer wie Betreiber verständlich bleiben. Genau darin liegt der Wert von LangGraph: nicht in der bloßen Verkettung von Modellen, sondern in einem überprüfbaren Rahmen für Entscheidungen.

Häufige Fragen zu agentischen RAG-Systemen mit LangGraph