rag agentic-rag retrieval knowledge-graph ai-agents

Agentenbasiertes Abrufen und ausreichender Kontext: Wenn RAG nicht genug weiß

Standard RAG antwortet oft zu früh. Aggressive Suchpläne durchsuchen, leiten Quellen zu, bewerten Beweise und suchen erneut, bis der Kontext wirklich ausreichend ist.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20269 Min. Lesezeit2114 Wörter

Quellen: When RAG Doesn’t Know Enough: Why Agentic Retrieval Needs Sufficient Context

Die Vektorsuche ist nicht das Hauptproblem, das die meisten RAG-Systeme zum Scheitern bringt. Das größere Problem in der Produktion ist ein Modell, das zwar antwortet, aber dennoch an Beweismitteln mangelt. Es handelt sich dabei nicht um einen Fall, in dem nichts gefunden wird: Das System liefert in der Regel etwas, die Ausschnitte scheinen zum Thema zu passen, und die Antwort ist fließend und selbstsicher. Dennoch ist sie unvollständig, da die benötigten Fakten in mehreren Dokumenten, Systemen, Tabellen, Tickets, Handbüchern, Protokollen oder grafischen Beziehungen zu finden sind.

Das klassische Muster besteht aus einem einzigen Durchlauf:

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

Das ist in Ordnung für einfache Fragen, doch Unternehmensfragen sind selten einfach. Eine Richtlinie befindet sich in einem Dokument, ihre Ausnahmen in einem anderen. Ein Ticket beschreibt den Vorfall, eine Veröffentlichungsnotiz erklärt ein geändertes Verhalten, eine Datenbankzeile enthält den aktuellen Status, eine Kantenverbindung in einem Graphen zeigt eine Abhängigkeit an, eine Tabelle in einem PDF enthält die tatsächlichen Zahlen und ein früheres Gespräch protokolliert, was der Benutzer bereits versucht hat. Wenn nur die ersten wenigen ähnlichen Abschnitte abgerufen werden, antwortet das Modell zu früh. RAG ist nicht tot – es muss erkennen, wenn es nicht genug Informationen hat.

Frühzeitige Antworten

Viele RAG-Systeme versagen leise. Sie geben nie an, dass es nicht genügend Beweise gibt. Sie liefern eine Antwort – fließend, strukturiert und meist plausibel –, die jedoch falsch ist.

Stellen Sie sich einen internen Support-Mitarbeiter vor, der gefragt wird, warum die Exportfunktion von Acme nach einer Arbeitsplatzmigration nicht mehr funktionierte. Ein einfacher Automatisierungsprozess findet eine Fehlerbehebungseite zum Export und behauptet, es fehlten Berechtigungen. Das mag teilweise zutreffen. Eine vollständige Antwort berücksichtigt Acmes Migrationsprotokoll, eine Mitteilung zu Änderungen bei den Exportberechtigungen, das Ticket von letzter Woche, einen internen Bericht zum Vorfall, die Feature-Flags des Kontos sowie ein Abhängigkeitsdiagramm, das den betroffenen Exportdienst auflistet. Ein einzelnes Dokument kann niemals all das enthalten, daher muss die Informationsbeschaffung eher wie die eines Mitarbeiters ablaufen.

Was ausreichender Kontext bedeutet

Ein ausreichender Kontext bedeutet, dass die vorhandenen Beweise eine zuverlässige Antwort ermöglichen. Unzusammenhängende Teile, eine hohe Ähnlichkeitsrate oder fünf zurückgegebene Dokumente zählen nicht. Vor der Erstellung sollte das System überprüfen, ob es die Richtlinien, Ausnahmen, den aktuellen Zustand, die autoritativen Aufzeichnungen, die Verbindungen zwischen Entitäten sowie genügend Informationen besitzt, um die Ursache und nicht nur das Symptom zu erklären, sowie einen Weg zur Zitierung des Ergebnisses. Falls etwas fehlt, sollte es zurückgehen und erneut suchen. Das ist der Übergang vom klassischen RAG zur agierenden Informationsbeschaffung.

Von top-k zur Beweissuche

Standardmäßiges RAG betrachtet die Informationsbeschaffung als einzigen Schritt: einmal suchen und antworten. Agierende Informationsbeschaffung behandelt sie hingegen als Arbeitsablauf:

Retrieve once → answer

Plan → retrieve → inspect → judge evidence → retrieve again → answer

Nichts zwingt das Modell dazu, auf das erste zurückgegebene Ergebnis zu antworten. Es verhält sich eher wie ein Forschungsanalyst, der sucht, Dokumente öffnet, sie vergleicht, Zusammenhänge verfolgt, überprüft und erst dann antwortet, wenn der Kontext ausreichend ist.

Warum Agenten die Herausforderungen erhöhen

Ein Chatbot beantwortet eine Frage. Ein Agent trifft Entscheidungen: Er wählt Werkzeuge aus, ruft APIs auf, aktualisiert Datensätze, erstellt Tickets, empfiehlt Handlungen, bittet um Genehmigung oder führt mehrere Schritte durch. Ein unvollständiger Kontext breitet sich dann weiter aus:

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

Ein Produktionsagent sollte nicht einfach nur ein ähnliches Dokument melden. Er sollte in der Lage sein zu erklären, dass er die Police, die Ausnahme, den Status des Live-Kontos sowie das damit verbundene Incident gefunden hat, und dass diese Beweise die Frage klären. Das erfordert eine andere Architektur.

Wohin die agentenbasierte Suche entwickelt wird

Jüngste Arbeiten zu RAG und Wissensgraphen deuten auf eine Suche hin, die von Agenten gesteuert wird, graphenbewusst ist, anhand von Beweisen bewertet wird und durch Speicherfunktionen unterstützt wird. Nicht jedes System benötigt eine riesige Wissensgraph, doch die Suchschicht braucht mehr Intelligenz als nur das Einbetten einer Abfrage und das Zurückgeben der Top-k-Ergebnisse. Mehrere Entwicklungsrichtungen sind relevant.

Zwischenkorporale Suche

Unternehmenswissen befindet sich nicht in einer einzigen, ordentlichen Vektordatenbank. Es ist über Google Drive, Confluence, Notion, Slack, Jira, GitHub, Lagerbestände, Support-Tickets, Dashboards, interne APIs, Produktdokumente sowie PDF-Anleitungen verteilt. Ein gutes System muss entscheiden, wo zuerst gesucht werden soll. Ein Abrufplaner kann die Frage als Richtlinie, Produktverhalten, kundenbezogen, Incident, finanzielle Kennzahl oder technische Abhängigkeit klassifizieren und sie entsprechend weiterleiten. Das Durchsuchen aller Quellen ist kostspielig – und das Suchen am falschen Ort ist noch schlimmer.

Abruf als Werkzeuge

Ein nützliches Muster stellt den Abruf als eine kontrollierte Sammlung von Werkzeugen statt als festes Ergebnis dar:

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

Das spiegelt die menschliche Untersuchung wider: Suche, Öffnen vielversprechender Ergebnisse, Prüfung von Abschnitten, Verfeinerung der Abfrage und Vergleich von Beweisen. Das Reasoning-Modell steuert den Prozess, jedoch nur innerhalb eines begrenzten Werkzeugsatzes, was Flexibilität ohne unbegrenzten Zugriff bietet.

Wissensgraphen-Abfrage

Die Vektorsuche findet semantisch ähnlichen Text, während viele praktische Fragen auf Beziehungen beruhen. Welche Kunden werden von diesem Service betroffen? Welche Produkte sind von dieser API abhängig? Welche Richtlinie gilt in dieser Region? Welche Bereitstellung hat zu diesem Vorfall geführt? Das sind Fragen im Kontext der Verbindungen, nicht solche der Ähnlichkeit. Ein Graph kann die Entitäten direkt miteinander verknüpfen:

Customer → Workspace → Feature Flag → Service → Incident → Release Note

Ein Agent kann diesen Links folgen, anstatt zu hoffen, dass der richtige Teil der Informationen in den oberen Ergebnissen erscheint. Das ist ein Beweis für Navigation statt nur für Informationsabruf. Verwenden Sie es dort, wo Beziehungen wichtig sind, und überspringen Sie es, wenn es nur nach Fortgeschrittenem klingt.

Bewertung der Beweisausreichendheit

Nach dem Informationsabruf sollte das System beurteilen, ob die Beweise ausreichen. Beantwortet es die Frage direkt? Fehlen Entitäten, Daten oder Quellen? Überschneiden sich die Quellen? Hat die Quelle tatsächlich Autorität? Kann die Antwort zitiert werden? Wenn die Beweise schwach sind, setzt das System die Suche fort:

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

Der Schleifenmechanismus verhindert vorzeitige Antworten und erleichtert das Debuggen, denn man kann erkennen, warum der Agent erneut gesucht hat.

Kontextgraphen und Agentenmemorien

RAG befasst sich in der Regel mit externem Wissen, doch Agenten benötigen auch eine Memorie: Was der Benutzer zuvor gefragt hat, was gesucht wurde, welche Beweise akzeptiert wurden, was entschieden wurde und welche Annahmen noch offen sind. Ein einfacher Konversationspuffer reicht nicht aus. Ein besseres Design verknüpft die Memorie mit Entitäten und Entscheidungen, sodass die eigene Schlussfolgerungskette zur Memorie wird:

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

Beim nächsten Auftreten eines ähnlichen Problems startet der Agent nicht von vorne, was für langlaufende Agenten von Bedeutung ist.

Multimodales und dokumentorientiertes RAG

Viel Unternehmenswissen besteht nicht aus reinem Text. Es befindet sich in PDFs, Tabellen, Screenshoten, Diagrammen, Formeln, Scans, Charts, Präsentationsfolien und Formularen. Herkömmliches Zerlegen zerstört die Struktur: Tabellen verwandeln sich in unübersichtlichen Text, Formeln verlieren ihren Kontext, Diagramme werden zu OCR-Ergebnissen, und Abschnitte werden von den Erklärungen getrennt. Ein dokumentorientierter Prozessverlauf versteht Texte, Tabellen, Abbildungen, die Layout-Struktur, Überschriftenhierarchien, Beschreibungen, Formularfelder sowie die Beziehung zwischen visuellen Elementen und Prosa. Insbesondere die Bereiche Finanzen, Gesundheitswesen, Fertigung, Recht, Versicherungen und technische Dokumentation sind stark davon abhängig.

Tools und Kontextbudgets

Tools verbrauchen ebenfalls Kontext. Wenn Dutzende von Abfrages-, Graphen-, Datenbank- und Suchtools sowie ihre Schemata verwendet werden, konkurrieren sie mit den Beweismitteln:

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

Agentic RAG benötigt daher einen budgetbewussten Laufzeitmechanismus, der entscheidet, welche Tools angezeigt werden sollen, wie viele Fragmente einbezogen werden müssen, ob die Ausgabe der Tools zusammengefasst werden soll und, was besonders wichtig ist, wann mit der Arbeit aufgehört werden muss. Ziel ist es, ausreichende Informationen zu erhalten – nicht endlos weiterzumachen.

Architektur in der Produktion

Insgesamt ähnelt ein Produktionsystem für agentic Retrieval eher einem Steuerungsplan als einem Pipelining-System:

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

Die praktische Botschaft ist einfacher: Lassen Sie RAG nicht antworten, bevor es ausreichende Beweise hat.

Der Acme-Fall, von Anfang bis Ende

Als gefragt wurde, warum eine Exportierung nach der Arbeitsplatzmigration fehlgeschlagen ist, holt das herkömmliche RAG den Export-Fehlerbehebungsführer sowie die FAQ zur Migration und antwortet, dass die Exportierung vermutlich aufgrund fehlender Berechtigungen fehlgeschlagen ist. Ein agiler System untersucht Folgendes:

Sucht in den Support-Dokumenten nach Fehlern bei Exportierungen.
Sucht in den Veröffentlichungsnachrichten nach Änderungen bei der Arbeitsplatzmigration.
Öffnet die Kontoeinstellungen des Kunden.
Prüft den Status der Feature-Flags.
Sucht im Incidents-Verlauf.
Folgt dem Abhängigkeitsgraphen vom Exportdienst bis zum Berechtigungsdienst.
Entscheidet, ob die Beweise nun ausreichen.
Schreibt die Antwort mit Quellen.

Die Antwort lautet: Acme wurde auf das neue Workspace-Modell migriert, während der Exportdienst weiterhin den herkömmlichen Berechtigungsweg überprüfte. Die Workspace-Flagge ist aktiviert, doch die Exportrichtlinie wurde nie aktualisiert, weshalb die Lösung darin besteht, diese Richtlinie für das Workspace-Modell zu aktualisieren. Ein stärkeres Modell war nicht der Faktor, der das Ergebnis veränderte – vielmehr eine bessere Erhebung von Beweismitteln.

Was zuerst entwickelt werden sollte

Bei einem bereits vorhandenen RAG-System muss nicht alles neu aufgebaut werden. Folgen Sie diesen Schritten in dieser Reihenfolge:

Fügen Sie eine Ausreichheitsprüfung hinzu. Bevor Inhalte generiert werden, prüfen Sie, ob die abgerufenen Beweismittel für diese spezifische Frage ausreichen. Falls nicht, führen Sie eine weitere Abfrage durch oder stellen Sie dem Benutzer eine klärende Frage.
Fügen Sie eine Quellroutierung hinzu. Jedes Mal jede Quelle durchsuchen, ist zeitaufwendig. Klassifizieren Sie die Anfrage zunächst: Politikfragen gehen zu den Politikedokumenten, Kundendienstprobleme zu Tickets zusammen mit dem Kontostatus, technische Fehler zu Dokumenten, Protokollen und dem Servicegraphen, und Metrikenfragen in die semantische Schicht.
Fügen Sie Abrufwerkzeuge wie search, open, find, summarize, follow_entity_relation und query_structured_record hinzu, damit der Abruf iterativ erfolgen kann.
Fügen Sie Graphenabfragen hinzu, bei denen die Antworten von Eigentumsverhältnissen, Abhängigkeiten, Abstammungslinien, Kausalitäten, Hierarchien, mehrstufigen Verbindungen oder Politikausnahmen abhängen.
Erhalten Sie die Dokumentstruktur bei. Für PDFs, Berichte, Präsentationsfolien, Tabellen und Diagramme verwenden Sie dokumentorientierte Parsing-Verfahren und speichern Sie die Struktur anstelle einfacher Teilung in Blöcke.
Erhalten Sie einen Nachweis über die durchsuchten Quellen, geöffneten Dokumente, akzeptierten Fakten, gefundenen Lücken sowie den Grund, warum das System entschied, dass es ausreicht. Genau diese Aufzeichnung schafft Vertrauen in agierende RAG-Systeme.

Was man nicht übermäßig entwickeln sollte

Das kann zu kompliziert werden, und nicht jede Technik eignet sich für jeden Anwendungsfall. Eine einfache FAQ-Suche benötigt vermutlich keinen Wissensgraphen, Dokumente im reinen Textformat brauchen keine multimodale Analyse, One-Shot-Fragen benötigen kein langfristiges Graphenmemory, und ein vollständig interner Bereich benötigt keine externe Suche. Die richtige Frage lautet, welche Art von Beweisen für diese Frage erforderlich sind. Für ein einziges sauberes Dokument reicht normales RAG aus. Wenn die Antwort Quellen, Beziehungen, das Memory sowie den aktuellen Zustand umfasst, dann rechtfertigt die agierende Informationsbeschaffung ihre Komplexität.

Der Wandel

Die aktuelle Entwicklung in RAG zielt nicht darauf ab, die Vektorsuche zu ersetzen. Stattdessen bietet sie mehr Kontrolle über den Datenauszug. Die Vektorsuche bleibt wichtig, genauso wie die Schlüsselwortsuche. Wissensgraphen sind relevant, wenn Beziehungen eine Rolle spielen, Dokumentanalyse, wenn Strukturen wichtig sind, und Speicher, wenn ein Agent über Zeit arbeitet. Die Aufgabe besteht darin, all diese Methoden miteinander zu kombinieren. Die nächste Generation wird weniger so aussehen:

Vector DB → top-k chunks → LLM

und so weiter:

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

RAG versagt nicht nur dann, wenn es fehlerhafte Datenblöcke abruft. Es versagt auch dann, wenn es teilweise nützliche Datenblöcke abruft und bereits vorzeitig antwortet. Bei einfachen Fragen kann top-k noch funktionieren. Für Unternehmensanwendungen, Forschung, Support, Betriebsabläufe sowie agenten mit vielen Dokumenten benötigt die Datenabrufung einen stärkeren Algorithmus:

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

Das ist der Übergang vom Standard-RAG zur agierenden Informationsabrufung. Es liegt nicht daran, dass RAG tot ist. Produktionsagenten müssen erkennen, wann sie nicht genug wissen.