Checkpoint
Phase-3-Checkpoint
Prüfen, ob aus dem Practice Brief ein umsetzbarer GraphRAG-Systemdesign-Entwurf geworden ist.
Was du mitnimmst
Der Abschnitt ist abgeschlossen, wenn du einen GraphRAG-Entwurf begründen und in den Betriebsteil überführen kannst.
Review-Gate
Worum es hier geht
Dieser Checkpoint ist die Arbeitsprobe zwischen Entwurf und Betrieb. Du prüfst, ob dein Entwurf technisch nachvollziehbar genug ist, um Governance, Evaluation, Kosten und Betriebsfähigkeit zu diskutieren.
Der Checkpoint führt die bisherigen Entscheidungen zusammen: Systementwurf, Komponenten, Ingestion-Pipeline, Speicherarchitektur, Graphschema, Anfrageweg, Toolklassen und Prototyp-Ausschnitt.
Das Ziel ist ein nachvollziehbarer, umsetzbarer Entwurf. Er darf offene Punkte enthalten. Er zeigt, was das System leisten soll, welche Komponente welche Aufgabe übernimmt und welche Betriebsfragen danach geklärt werden.
Der Checkpoint verbindet drei Ziele. Erstens: Der Systementwurf ist klar. Zweitens: Komponenten, Pipeline, Speicherarchitektur, Graphschema und Anfrageweg sind als technische Systembeschreibung sichtbar. Drittens: Der Prototyp-Ausschnitt zeigt, welche Architekturannahme geprüft wird.
Für den Mini-Use-Case heißt das konkret: Du kannst erklären, warum Projektbetroffenheit Beziehungskontext braucht. Du kannst zeigen, welche Komponente welche Information erzeugt. Du kannst sagen, wo Chunks, belegte Aussagen, Entitäten, Kanten, Belege und Anfrageprotokolle liegen. Und du kannst beschreiben, welche Testfrage mit Erwartung der Prototyp prüft.
Abschlussartefakt
GraphRAG-Systemdesign
Der Systemdesign-Entwurf fasst die bisherigen Entscheidungen als umsetzbare Architekturentscheidungen zusammen.
| Entwurfsbereich | Was geklärt ist |
|---|---|
| Systementwurf | gewünschtes Ergebnis, benötigte Systemfähigkeiten und Architekturbereiche sind sichtbar |
| Komponenten | Parser, Chunker, Graph Builder, Orchestrator und Anfrageprotokoll-Logger haben klare Verantwortung |
| Ingestion-Pipeline | Quellen werden in Chunks, Embeddings, Entitäten, Beziehungen und Herkunftsbelege überführt |
| Speicherarchitektur | Text, Graphdaten, Belege und Anfrageprotokolle haben klare technische Ablagen |
| Graphschema | Labels, Beziehungstypen, Pflichtfelder, Belegreferenzen und Eindeutigkeitsregeln sind spezifiziert |
| Anfrageweg | die Testfrage läuft über Textsuche, Entity Linking, Graphpfad und Kontextpaket |
| Toolklassen | Werkzeuge werden nach Aufgabe eingeordnet, bevor Produkte gewählt werden |
| Prototyp-Ausschnitt | ein kleiner Systemlauf prüft Frage, Quelle, Pfad, Ergebnis und Anfrageprotokoll |
Der Entwurf ist die zusammenhängende Sicht auf das System, das später betrieben und kontrolliert werden soll.
Prüfen
Selbstdiagnose
Du bist auf einem guten Stand, wenn du erklären kannst, wie dein Entwurf die Frageklasse technisch beantwortet und welchen Teil der Prototyp prüft.
Prüfe dich an fünf Fragen:
1. Welcher Systementwurf entsteht aus dem vorbereiteten GraphRAG-Fall? 2. Welche Komponente erzeugt, speichert oder nutzt welche Information? 3. Wie erzeugt die Pipeline Chunks, Vektoren, Graphdaten und Herkunftsbelege? 4. Wie läuft die Testfrage mit Erwartung durch den Anfrageweg? 5. Welche Betriebsfragen gehören in den Betriebsteil?
Unsicherheit bei Komponenten zeigt meist einen zu groben Schnitt. Unsicherheit bei der Speicherarchitektur zeigt unklare Ablageaufgaben. Unsicherheit beim Anfrageweg zeigt eine noch zu abstrakte Orchestration. Unsicherheit bei späteren Themen zeigt einen zu großen Prototyp.
Ein guter Entwurf liest sich wie eine umsetzbare Systembeschreibung: dieser Systementwurf, diese Komponenten, diese Pipeline, diese Speicherarchitektur, dieses Graphschema, dieser Anfrageweg, dieses Tool-Mapping und dieser Prototyp-Ausschnitt.
Üben
Mini-Aufgabe
Nutze diesen isolierten Fall:
Ein Team will prüfen, welche Projekte betroffen sind, wenn ein als kritisch klassifiziertes System jährlich geprüft werden muss.
Skizziere den Entwurf in sieben Punkten: Systementwurf, wichtigste Komponenten, Pipeline, Speicherarchitektur, Graphschema, Anfrageweg und Prototyp-Ausschnitt. Markiere außerdem zwei Betriebsfragen für den Betriebsteil.
Musterlösung
Systementwurf
Das System soll zeigen, welche Projekte betroffen sind, wenn ein kritisches Kundensystem jährlich geprüft werden muss. Dafür braucht es Richtlinientext, Beziehungspfad, Quellenbeleg und Anfrageprotokoll. Daraus entstehen die Entwurfsbereiche Komponenten, Pipeline, Speicherarchitektur, Graphschema, Anfrageweg, Tool-Mapping und Prototyp-Ausschnitt.
Wichtigste Komponenten
Ingestion bereitet Quellen vor. Extractor erzeugt belegte Aussagen, Entitäten und Beziehungen. Retriever holt Texttreffer und Graphpfade. Das LLM formuliert das Ergebnis mit Quellenbezug.
Pipeline
Richtlinie, Systemkatalog und Projektliste werden gelesen, in Chunks und Metadaten überführt, mit Embeddings versehen, über Entity Resolution stabilisiert und mit geprüften Beziehungen in den Graph Store geschrieben.
Speicherarchitektur
Chunks und Embeddings liegen im Vector Store. Entitäten, Beziehungen und Pfade liegen im Graph Store. Belege liegen als Belegablage oder Metadaten an Kanten. Anfrageabläufe liegen im Anfrageprotokoll oder Log.
Graphschema
Projekt, System, Team, Richtlinie und Pflicht sind technische Labels. Beziehungen wie "nutzt", "verantwortet" und "definiert Pflicht" haben stabile Typen, Pflichtfelder und Belegreferenzen.
Anfrageweg
Die Frage startet mit Textsuche nach der Prüfpflicht. Entity Linking erkennt CRM. Graph Traversal ergänzt den Pfad Richtlinie -> System -> Projekt -> Team. Das Kontextpaket verbindet Textbeleg, Pfad und Herkunft.
Prototyp-Ausschnitt
Der Prototyp prüft genau eine Frageklasse mit zwei Quellen, einem kritischen Kundensystem, einem Projekt und einer Testfrage mit Erwartung.
Betriebsfragen
Governance-Regeln für erlaubte Pfade und Betriebsmetriken für Qualität, Kosten und Fehler.
Übergang
Bereit für Phase 4
Du bist bereit für den Betriebsteil, wenn du zeigen kannst, welches System der Entwurf beschreibt, welche Annahme der Prototyp prüft und welche Betriebsrisiken noch offen sind.
Zusätzliche Arbeit lohnt sich, wenn der Entwurf vor allem aus Toolnamen besteht, Komponentenaufgaben unscharf bleiben, der Graph keine klare Aufgabe hat oder der Prototyp keine überprüfbare Testfrage mit Erwartung besitzt.
Kernaussage
Der Abschnitt ist abgeschlossen, wenn du einen GraphRAG-Entwurf begründen und in den Betriebsteil überführen kannst.