Phase 4 · Operational Step 4 von 9
Observability und Trace-Diagnose definieren
Traces zeigen den Entstehungsweg einer Antwort und machen sichtbar, wo das Team zuerst prüfen sollte.
Was du mitnimmst
Eine GraphRAG-Erprobung braucht Traces, damit auffällige Antworten gezielt verbessert werden können.
Betriebsziel
Welche Betriebsfähigkeit du herstellst
Du machst Antworten erklärbar: Welche Route wurde genommen, welche Quellen wurden genutzt, welcher Graphpfad war beteiligt und an welcher Stelle muss das Team bei Fehlern zuerst prüfen?
Input
Ausgangsartefakt aus Entwerfen
Der Prototyp aus Entwerfen hat eine Testfrage mit Erwartung und einen Demo-Trace. Absichern macht daraus ein Betriebsformat, das für jeden Lauf der Erprobung wiederholbar gespeichert werden kann.
Prinzip
Betriebsprinzip
Ein Trace muss die Route, die verwendeten Artefakte und die Fehlerklasse sichtbar machen.
Das Prinzip ist einfach: Zu jeder Antwort gehört ein kurzer Laufzettel. Er hält fest, welche Frage gestellt wurde, welche Route das System gewählt hat, welche Quellen und Entitäten im Spiel waren, welcher Graphpfad genutzt wurde und welche Prüfung gegriffen hat. Wenn das Ergebnis später auffällig ist, muss niemand raten, an welcher Stelle die Diagnose beginnt.
Für GraphRAG ist besonders wichtig, dass der Trace bei der Frageeinordnung startet und über Entitätserkennung, Texttreffer, Graphpfad, Policy-Prüfung und Antwortstatus führt. So wird Observability zu einer Betriebsfähigkeit: Das Team kann aus dem Trace eine konkrete nächste Korrektur ableiten.
Operational Artefact
Betriebsartefakt
| Bereich | Leitfrage |
|---|---|
| Route | Welcher Suchweg wurde gewählt? |
| Artefakte | Welche Quellen, Chunks, Entitäten und Graphpfade wurden genutzt? |
| Prüfungen | Welche Evidence- und Policy-Checks wurden ausgeführt? |
| Status | Wurde die Antwort akzeptiert, zurückgewiesen oder zur Prüfung markiert? |
| Diagnose | Welcher Systemschritt ist bei einer auffälligen Antwort zuerst zu prüfen? |
Dieses Artefakt ist kein vollständiges Logschema. Es ist die Mindeststruktur für eine Erprobung: Jede gespeicherte Antwort muss so viel Kontext enthalten, dass ein Mensch den nächsten Prüfpunkt erkennt. Technische Felder können später ergänzt werden, aber Route, Artefakte, Prüfungen, Status und Diagnose gehören von Anfang an zusammen.
Control
Kontrollfrage
Diese Frage muss beantwortbar sein
Kann das Team nach einer auffälligen Antwort sagen, welcher Systemschritt zuerst geprüft werden muss?
Risk
Betriebsrisiko
Worauf du achten musst
Das System speichert Antworttexte ohne Entstehungsweg. Dann sieht das Team den Fehler, aber nicht den nächsten sinnvollen Prüfpunkt.
Prüfen
Woran du es erkennst
Prüfpunkt
Observability ist ausreichend, wenn ein Trace die Route, die Evidence, den Graphpfad, die Policy-Prüfung, den Antwortstatus und den nächsten Diagnosehinweis enthält.
Üben
Mini-Aufgabe
Formuliere drei Trace-Felder, die für einfache Quellenfragen optional wären, für GraphRAG aber wichtig sind.
Musterlösung
Wichtige Trace-Felder zeigen erkannte Entitäten, genutzte Graphpfade und den Policy Check. Dadurch wird sichtbar, welche Entitäten erkannt wurden, welcher Beziehungspfad genutzt wurde und ob dieser Pfad für die Rolle freigegeben war.
Reflektieren
Prüffragen
1.Was unterscheidet einen Trace von der Antwort?
Die Antwort zeigt das Ergebnis. Der Trace zeigt den Entstehungsweg: Route, Quellen, erkannte Entitäten, Graphpfad, Policy-Prüfung und Antwortstatus.
2.Welche Trace-Felder braucht GraphRAG zusätzlich zu klassischem RAG?
Erkannte Entitäten, genutzte Graphpfade, Evidence Checks und den Policy Check.
3.Woran erkennst du ausreichende Observability?
Wenn ein Trace Route, Evidence, Graphpfad, Policy-Prüfung, Antwortstatus und Diagnosehinweis enthält.
Kernaussage
Eine GraphRAG-Erprobung braucht Traces, damit auffällige Antworten gezielt verbessert werden können.