Phase 2 · Checkpoint
Phase-2-Checkpoint
Prüfen, ob aus dem Mini-Use-Case ein belastbarer GraphRAG Practice Brief geworden ist.
Was du mitnimmst
Phase 2 ist abgeschlossen, wenn du einen kleinen GraphRAG-Fall so vorbereitet hast, dass Phase 3 ihn als Systementwurf spezifizieren und prüfen kann.
Review-Gate
Worum es hier geht
Dieser Checkpoint ist die Arbeitsprobe für Phase 2: Du prüfst, ob dein Praxisfall klein, nachvollziehbar und testbar genug ist, um daraus später eine Architektur oder einen Prototyp abzuleiten.
Du legst ein Arbeitsartefakt auf den Tisch. Es zeigt, wie du den Weg von Frage zu Quelle, von Quelle zu Kontext, von Kontext zu Graph und von Graph zu Evaluation nachvollziehbar schneidest.
Der Checkpoint verbindet drei Ziele. Erstens: Du kannst deinen Use Case fachlich erklären. Zweitens: Du kannst zeigen, welche Quellen, Chunks, belegten Aussagen, Entitäten und Beziehungen nötig sind. Drittens: Du hast Testfragen mit Erwartung, mit denen du später einen echten Stack prüfen kannst.
Wenn das gelingt, ist Phase 2 abgeschlossen. Phase 3 kann dann konkret werden: Toolwahl, Architekturvariante, Ingestion, Vector Store, Graph Store, Query Orchestration und Prototyp.
Offene Punkte zeigen dir, welcher Teil des Praxisfalls noch geschärft werden sollte: Quellen, Modellierung oder Evaluation.
Abschlussartefakt
GraphRAG Practice Brief
Der Practice Brief fasst die acht Praxis-Steps zusammen. Er beginnt mit einer klaren Frageklasse und einem Quelleninventar. Danach beschreibst du, wie Inhalte vorbereitet werden, welche Aussagen belegt werden müssen, welche Entitäten und Beziehungen erwartet werden, wie Identität und Zeit stabil bleiben, wann RAG genügt und welche Testfragen den Fall später prüfen.
phase-2-practice-brief.jsonjson
{
"question_class": "Welche Projekte und Systeme sind von einer Richtlinie oder einem Risiko betroffen?",
"source_inventory": "source-inventory.json",
"chunk_requirements": "chunk-requirements.json",
"statements_with_provenance": "statement-with-provenance.json",
"graph_fragment": "graph-fragment.json",
"identity_resolution": "entity-resolution.json",
"retrieval_comparison": "retrieval-comparison.json",
"evaluation_questions": "evaluation-question.json",
"ready_for_phase_3": true
}Schlüssel kurz erklärt
question_classbeschreibt die geprüfte Frageklasse.source_inventory,chunk_requirements,statements_with_provenance,graph_fragment,identity_resolution,retrieval_comparisonundevaluation_questionsverweisen auf die Artefakte aus den acht Praxis-Steps.ready_for_phase_3zeigt, ob der Fall technisch weitergeführt werden kann.
Prüfen
Selbstdiagnose
Du bist auf einem guten Stand, wenn du deinen Mini-Use-Case als prüfbaren Lernfall erklären kannst.
Prüfe dich an fünf Fragen:
1. Welche Frageklasse soll der Fall beantworten? 2. Welche Quellen tragen die Antwort fachlich? 3. Welche Entitäten und Beziehungen müssen erkennbar sein? 4. Wann reicht eine RAG-Antwort aus Textstellen, und wann hilft Graphkontext? 5. Woran erkennst du eine schwache Antwort: falsche Quelle, schwacher Chunk, fehlender Herkunftsbeleg, instabile Entität oder fehlender Graphpfad?
Wenn du bei einer dieser Fragen unsicher bist, gehe vor Phase 3 zum passenden Praxis-Step zurück.
Ein gutes Zeichen ist, wenn du über Fehler konkret sprechen kannst: "Der Chunk war zu schwach", "der Herkunftsbeleg fehlt", "die Entität ist unklar" oder "der Graphpfad fehlt im Kontextpaket".
Üben
Mini-Aufgabe
Nutze diesen isolierten Fall:
Ein Compliance-Team fragt: "Welche Projekte sind betroffen, wenn die Richtlinie für kritische Kundensysteme geändert wird?"
Erstelle eine knappe Practice-Brief-Skizze. Nenne die Frageklasse, zwei tragende Quellen, drei erwartete Entitäten, zwei Beziehungen, eine Identitätsregel, eine Retrieval-Entscheidung und eine Testfrage mit Erwartung.
Musterlösung
Frageklasse
Betroffenheitsfrage über Richtlinie, System und Projekt. Die Antwort soll zeigen, welche Projekte von einer geänderten Regel berührt werden.
Tragende Quellen
Richtlinie für kritische Kundensysteme, Systemkatalog, Projektliste und Verantwortlichkeitsnotiz.
Erwartete Entitäten
Richtlinie, System, Projekt, Team und verantwortliche Rolle.
Wichtige Beziehungen
Richtlinie gilt für Systemklasse. System gehört zu Projekt. Team verantwortet System.
Identitätsregel
"CRM" und "Customer Relationship Management" werden zusammengeführt, wenn dieselbe System-ID vorliegt. "Kundensystem" bleibt als allgemeiner Begriff markiert, bis eine konkrete Systemklasse bestätigt ist.
Retrieval-Entscheidung
Direkte Pflichtfragen laufen über RAG. Betroffenheitsfragen nutzen zusätzlich den Pfad Richtlinie -> System -> Projekt -> Team.
Testfrage mit Erwartung
"Welche Projekte sind betroffen, wenn CRM jährlich geprüft werden muss?" Erwartet werden Projekt Alpha, Richtlinie Abschnitt 4.2, System CRM und der Pfad zur Projektliste.
Übergang
Bereit für Phase 3
Du bist bereit für Phase 3, wenn du mit dem Practice Brief startest. Die Toolwahl kommt, sobald klar ist, welche Quellen, Beziehungen, Pfade und Tests das System tragen müssen.
Phase 3 wird dadurch zielgerichteter. Die Aufgabe heißt dann: Diese Frageklasse mit diesen Quellen, diesen Entitäten, diesen Pfaden und diesen Testfragen als Systementwurf durchdenken und spezifizieren.
Kernaussage
Phase 2 ist abgeschlossen, wenn du einen kleinen GraphRAG-Fall so vorbereitet hast, dass Phase 3 ihn als Systementwurf spezifizieren und prüfen kann.