Zum Inhalt springen
GraphRAG Compass
  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Lernpfad
  • Simulation
  • Landkarte
GraphRAG Compass

Öffentlicher Field Guide für GraphRAG, Knowledge Graphs, AI-Architekturen und bessere Entscheidungen in komplexen Wissenssystemen.

Erkunden

  • Grundlagen
  • Architekturen
  • Praxis
  • Business Cases
  • Simulation
  • Landkarte

Lernen

  • Lernpfad
  • Mini-Use-Case
  • GraphRAG Poster
  • Glossar

Über

  • About
  • LinkedIn

Discovery

  • llms.txt
  • llms-full.txt
  • sitemap.xml

Rechtliches

  • Impressum
  • Datenschutz

© 2026 Meierhoff Systems · GraphRAG Compass

Orientierung für Entscheidungen in Wissenssystemen

Zurück zu Context Graphs

Deep Dive · Context Graphs

Context Graphs als strukturierter Arbeitszustand

Ein Context Graph macht den laufenden Kontext einer Aufgabe explizit: Ziele, Quellen, Annahmen, Entscheidungen, offene Fragen, Tool-Aufrufe und Zwischenergebnisse werden als abfragbarer Zustand modelliert.

Arbeitszustand
Quellen
Entscheidungen
Agentenläufe

Kuratierter erster Schnitt · Stand Mai 2026

Die Grundidee

Kontext ist in Agentensystemen oft nur Prompt-Text: lang, flüchtig und schwer zu prüfen. Ein Context Graph behandelt Kontext als Arbeitszustand. Er hält fest, was das Ziel ist, welche Quellen genutzt wurden, welche Annahmen offen sind und welche Entscheidungen bereits getroffen wurden.

Dadurch kann ein Agent gezielter fragen: Was ist belegt? Was ist offen? Welche Tool-Ergebnisse gehören zu welcher Entscheidung? Und welche Teile dieses Zustands sind noch aktuell?

Orientierungsfrage

Context Graphs verbinden Agent Memory, Reasoning Traces und Domänenwissen zu einer kohärenten Kontextschicht.

Motion Map

Context Graph

Ziel
Quellen
Claims
Zustand
Agent
Entscheid

Context Graphs machen den laufenden Zustand abfragbar.

Was im Context Graph liegt

Ein guter Context Graph startet mit wenigen Knotentypen. Wichtig ist, dass Quellen, Claims und Entscheidungen getrennt bleiben.

Ziel

Beschreibt, was die aktuelle Aufgabe erreichen soll und woran ein brauchbares Ergebnis erkennbar ist.

Aufgabe

Hält konkrete Arbeitsschritte, Teilfragen, Verantwortlichkeiten oder Agentenaufträge fest.

Quelle

Verweist auf Dokumente, Daten, Tool-Ergebnisse oder Gespräche, die als Evidenz dienen.

Annahme

Macht sichtbar, wo der Agent oder Nutzer noch nicht sicher weiß, ob eine Aussage stimmt.

Entscheidung

Dokumentiert, was im Lauf der Arbeit entschieden wurde und auf welcher Grundlage.

Tool-Aufruf

Verknüpft Aktionen, Parameter, Ergebnisse und Fehler mit dem Arbeitskontext.

Antwortspur

Verbindet Frage, Antwort, verwendete Fakten, Quellen und Feedback zu einer prüfbaren Spur.

Lebenszyklus

Context Graphs sind dynamisch. Sie wachsen während der Aufgabe, werden verdichtet und am Ende teilweise abgeschlossen oder in längerfristige Erinnerung überführt.

01

Initialisieren

Ziel, Scope, Rollen und erste Quellen werden angelegt. Der Graph startet klein.

02

Erweitern

Neue Quellen, Claims, offene Fragen und Tool-Ergebnisse werden als Knoten und Kanten ergänzt.

03

Verdichten

Zwischenstände werden zusammengeführt, Duplikate entfernt und relevante Pfade hervorgehoben.

04

Prüfen

Unsichere Annahmen, widersprüchliche Quellen und offene Fragen werden markiert.

05

Abschließen

Das Ergebnis wird mit Quellen, Entscheidungen und offenen Restpunkten nachvollziehbar gemacht.

06

Überführen

Längerfristig relevante Entscheidungen oder Präferenzen können in Agent Memory übernommen werden.

Ein Beispiel: Rechercheauftrag

Der Context Graph trennt Aufgabe, Evidenz, Annahmen und Entscheidung. Das macht den Weg zum Ergebnis nachvollziehbar.

Auftrag

Bewerte, ob Hybrid Retrieval für Supportfragen im GraphRAG Compass als nächster Architekturpfad sinnvoll ist.

Der Context Graph zeigt, welche Quellen und Annahmen zur Entscheidung geführt haben, und hält den finalen Text nachvollziehbar.

Knoten

  • Goal: Entscheidungsgrundlage für Hybrid Retrieval
  • Source: Supportartikel, Release Notes, Produktmodule
  • Claim: Version und Modul verbessern Trefferqualität
  • Open Question: Reicht Metadatenfilterung oder braucht es Graphkontext?
  • Decision: Hybrid Retrieval zuerst als pragmatische Zwischenstufe prüfen
  • Answer: Empfehlung mit Quellenpfad und offenem Risiko
  • Feedback: Version als stärkeres Signal gewichten

Kanten

  • Goal -[:BRAUCHT]-> Open Question
  • Source -[:STÜTZT]-> Claim
  • Claim -[:BEGRÜNDET]-> Decision
  • Answer -[:NUTZT]-> Claim
  • Feedback -[:VERBESSERT]-> Retrieval Rule
  • Decision -[:ERZEUGT]-> Next Task

Nutzen für Agenten

Agenten profitieren, wenn Arbeitszustand explizit abgefragt und weitergegeben werden kann.

  • Der Agent kann eine längere Aufgabe unterbrechen und später am richtigen Zwischenstand fortsetzen.
  • Tool-Ergebnisse werden als strukturierter Zustand gespeichert und bleiben im Prompt nutzbar.
  • Offene Fragen bleiben sichtbar und gehen nicht zwischen Chat-Antworten verloren.
  • Quellen, Claims und Entscheidungen bleiben getrennt, sodass Antworten besser prüfbar sind.
  • Frage, Antwort, verwendete Fakten und Feedback können später für Audit und Verbesserung wiedergefunden werden.
  • Mehrere Agenten können denselben Arbeitszustand lesen, ergänzen und weitergeben.

Ein minimales Schema

Ein kleiner Context Graph reicht oft, wenn die Knoten und Kanten fachlich klar bleiben.

Code
nodes:
  - Goal
  - Task
  - Source
  - Claim
  - Decision
  - OpenQuestion
  - ToolResult
edges:
  - Task -> USES -> Source
  - Source -> SUPPORTS -> Claim
  - Claim -> INFORMS -> Decision
  - Decision -> CREATES -> Task
  - OpenQuestion -> BLOCKS -> Decision

Context Graph und Agent Memory

Die beiden Konzepte gehören zusammen, lösen aber unterschiedliche Probleme. Der Context Graph hält die laufende Aufgabe zusammen; Memory bewahrt ausgewählte Erkenntnisse für später.

Context Graph

modelliert den laufenden Zustand einer konkreten Aufgabe: Quellen, Claims, Tool-Aufrufe, offene Fragen und Zwischenentscheidungen.

Agent Memory

speichert länger nutzbare Erkenntnisse, Präferenzen, Entscheidungen oder Projektfakten über einzelne Aufgaben hinaus.

Übergang

Beim Abschluss können ausgewählte Entscheidungen, Präferenzen oder stabile Fakten aus dem Context Graph ins Memory übernommen werden.

Observation, Claim, Decision, OpenQuestion

Context Graphs werden nützlich, wenn sie strukturierte Arbeitszustände sammeln. Die Trennung dieser Knotentypen zeigt, was belegt ist, was interpretiert wird, was entschieden wurde und was noch offen bleibt.

Question

Die gestellte Frage mit Nutzerrolle, Zeitpunkt und erwarteter Antwortform.

Warum schlägt Login für Version 4.2 nach der Migration fehl?

Observation

Eine beobachtete Quelle oder ein Tool-Ergebnis: etwas wurde gesehen, gelesen oder gemessen.

Release Notes nennen OAuth-Änderung in Version 4.2.

Claim

Eine interpretierte Aussage, die durch Quellen gestützt oder widerlegt werden kann.

Die OAuth-Änderung ist wahrscheinlich Ursache für Loginfehler.

Decision

Eine getroffene Auswahl, die Arbeit steuert und später nachvollziehbar sein muss.

Hybrid Retrieval wird als nächster Architekturpfad getestet.

Answer

Die erzeugte Antwort mit Verweis auf verwendete Quellen, Claims oder Graphpfade.

Antwort nutzt Release Notes 4.2, Incident 381 und den Pfad Service -> Reporting API.

OpenQuestion

Eine noch ungeklärte Frage, die weitere Recherche oder Entscheidung blockiert.

Reichen Metadatenfilter oder braucht es Graphkontext?

Feedback

Nutzer- oder Review-Signal, das spätere Retrieval-Regeln, Reranking oder Schreibregeln verbessern kann.

Supportartikel war richtig, aber veraltete Anleitung wurde zu hoch gerankt.

Typische Risiken

Ein Context Graph verbessert Nachvollziehbarkeit nur, wenn er bewusst begrenzt und geprüft wird.

Unkontrolliertes Wachstum

Jeder Zwischenschritt wird gespeichert, bis der Graph unübersichtlich und teuer wird.

Falsche Kanten

Eine Quelle stützt einen Claim nicht wirklich, wird aber als Evidenz verknüpft.

Unklare Aktualität

Alte Zwischenergebnisse wirken aktiv, obwohl sich Ziel, Quelle oder Entscheidung geändert haben.

Zu viel Zwischenzustand

Der Graph enthält Reasoning-Rauschen, aber keine belastbaren Claims, Entscheidungen oder offenen Fragen.

Keine Ownership

Unklar bleibt, wer Knoten korrigieren, abschließen oder ins Memory übernehmen darf.

Wie Context Graphs andere Konzepte berühren

Context Graphs sind die operative Arbeitsfläche zwischen Graphmodell, Agentenprotokollen und Memory.

übernimmt stabile Erkenntnisse aus abgeschlossenen oder laufenden Context Graphs.

können Context Graphs als kontrollierte Kontextquelle für Tools und mehrere Agenten verfügbar machen.

liefern das allgemeine Graphmodell; Context Graphs fokussieren den temporären Arbeitszustand.

definiert, welche Knoten, Kanten und Aktionen in einem fachlichen Kontext erlaubt und sinnvoll sind.

Klein beginnen

Der beste Start ist ein enger, sichtbarer Arbeitsgraph für einen konkreten Agentenlauf. Erst wenn das Modell beim Wiederaufnehmen und Prüfen hilft, lohnt mehr Detail.

Schritt 1

Mit einem einzelnen Workflow starten, zum Beispiel Recherche oder Analyseauftrag.

Schritt 2

Nur wenige Knotentypen erlauben: Ziel, Quelle, Claim, Entscheidung, offene Frage, Tool-Ergebnis.

Schritt 3

Kanten semantisch eng halten: nutzt, stützt, widerspricht, blockiert, erzeugt.

Schritt 4

Nach jedem Agentenschritt aktualisieren: Was ist neu, was ist belegt, was ist offen?

Schritt 5

Am Ende entscheiden, welche Knoten ins Agent Memory übernommen werden.

Praxisentscheidung

Wenn Aufgaben lange laufen

Nutze Context Graphs, wenn Quellen, Tool-Aufrufe und Zwischenentscheidungen über mehrere Schritte erhalten bleiben müssen.

Wenn Nachvollziehbarkeit zählt

Trenne Quelle, Claim und Entscheidung. Dann lässt sich später prüfen, warum ein Ergebnis entstanden ist.

Wenn Kontext wiederverwendbar wird

Überführe nur stabile Entscheidungen, Präferenzen oder Fakten ins Memory. Nicht jeder Zwischenzustand gehört dauerhaft gespeichert.

Nächste Schritte

Nächstes Konzept: MCP & A2AMCP und A2A vertiefen