Phase 2 · Praxis-Step 1 von 9
Einen Praxisfall eingrenzen
Mit einer kleinen, wiederkehrenden Frageart starten und daraus einen prüfbaren Practice Brief ableiten.
Was du mitnimmst
Eine Frageklasse macht aus einem GraphRAG-Wunsch einen prüfbaren Arbeitsauftrag.
Praxisziel
Was du praktisch entscheidest
Du formulierst eine konkrete Frageklasse: eine wiederkehrende Art von Frage, die ein System zuverlässig beantworten soll. Damit legst du fest, welche Quellen gebraucht werden, welche Beziehungen wichtig sind und woran eine Antwort später gemessen wird.
Szenario
Ausgangslage im Mini-Use-Case
Ein Unternehmen möchte wissen, welche internen Richtlinien, Projekte und Systeme zusammenhängen. Es gibt kurze Richtliniendokumente, eine Projektliste und einzelne Verantwortlichkeitsnotizen. Einige Fragen lassen sich direkt aus Dokumenten beantworten. Andere brauchen Beziehungen: Welche Systeme sind betroffen? Welche Richtlinie erzeugt welche Prüfpflicht? Welches Projekt hängt an welchem Risiko?
Genau hier beginnt die Praxis: Welche Art von Frage soll später zuverlässig beantwortet werden? Die Frageklasse entscheidet, was vorbereitet wird: Quellen, Chunks, Entitäten, Beziehungen, Graphpfade und Testfragen mit Erwartung. Mit dieser Eingrenzung erkennst du, welche Systemfähigkeit der Praxisfall prüfen soll.
Der Mini-Use-Case ist bewusst klein. Er simuliert aber ein echtes Muster aus Unternehmensprojekten: Richtlinien erzeugen Pflichten, Systeme gehören zu Projekten, Teams tragen Verantwortung, Risiken entstehen über Abhängigkeiten. Das ist groß genug, um Graphkontext zu brauchen, aber klein genug, um Fehler noch sehen zu können.
Heuristik
Arbeitsprinzip
Grenze den Use Case kleiner ein, als es sich zuerst gut anfühlt. Eine gute Frageklasse wirkt wie eine Messlatte: Sie sagt, welche Quellen gefunden werden müssen, welche Objekte und Beziehungen im Graphen auftauchen sollten und wann eine Antwort fachlich trägt.
Eine gute Frageklasse ist die kleinste wiederkehrende Frageart mit Lernwert. "Was steht in Richtlinie A?" ist eine einfache Quellenfrage. "Welche Unternehmensrisiken gibt es?" ist zu breit. Tragfähiger ist eine Frage, die Quellen und Beziehungen gemeinsam braucht: "Welche Projekte sind betroffen, wenn ein kritisches Kundensystem einer Prüfpflicht unterliegt?"
Der praktische Nutzen ist früh sichtbar: Du kannst danach entscheiden, welche Dokumente relevant sind, welche Tabellen erhalten bleiben müssen, welche Kanten modelliert werden und welche Tests eine spätere Antwort bestehen soll.
Greifbar machen
Praxisartefakt
Der Practice Brief macht den Praxisfall auf einer Seite prüfbar. Er zeigt die zentralen Festlegungen, an denen du die nächsten Schritte ausrichtest.
Praxis-Hinweis: In echten Projekten entsteht daraus meist ein kurzer Practice Brief: drei bis fünf Beispielfragen, erwartete Quellen, erwartete Objekte, wichtige Beziehungen und klare Prüfkriterien. Das ist der fachliche Schnitt, mit dem später Ingestion, Graphschema und Evaluation ausgerichtet werden.
practice-brief.jsonjson
{
"question_class": "Welche Projekte und Teams sind betroffen, wenn ein kritisches Kundensystem einer Prüfpflicht unterliegt?",
"users": ["Compliance", "Architekturteam", "Projektleitung"],
"sources": ["policy-a", "project-list", "system-catalog", "responsibility-note"],
"expected_objects": ["Richtlinie", "Systemklasse", "System", "Projekt", "Team"],
"expected_relations": [
"defines_obligation_for",
"used_by",
"owned_by"
],
"answer_contract": {
"must_include": ["betroffene Objekte", "Beziehungspfad", "Quellenabschnitte"],
"weak_if": ["Systembeleg fehlt", "Projekt mit gleichem Namen vermischt"]
}
}Schlüssel kurz erklärt
question_classbeschreibt die wiederkehrende Frageart.usersbenennt die Zielgruppen.sourceslistet die erwarteten Quellen.expected_objectsundexpected_relationszeigen, welche Dinge und Beziehungen der Fall braucht.answer_contractbeschreibt, woran eine Antwort später geprüft wird.
Achten auf
Typischer Qualitätsfehler
Worauf du achten musst
Der Praxisfall wird als "Chat mit allen Dokumenten" beschrieben. Dann bleibt unklar, ob das System Quellen finden, Beziehungen erklären, Verantwortlichkeiten prüfen oder Zusammenfassungen erzeugen soll.
Ein zweiter Fehler ist die Demo-Frage. Sie funktioniert einmal, weil sie genau auf vorhandene Beispieltexte passt. Eine wiederholbare Frageklasse zeigt zusätzlich, welche Systemfähigkeit gerade bewiesen wird.
Prüfen
Woran du es erkennst
Signal
Du erkennst einen zu breiten Praxisfall daran, dass erwartete Quellen, Objekte oder Beziehungen unklar bleiben. Wenn jede Frage erlaubt ist, bleibt die Systemfähigkeit unscharf.
Ein weiteres Signal: Die Beispielfrage funktioniert nur einmal und lässt sich nicht als wiederkehrendes Muster formulieren. Dann fehlt die Frageklasse, an der Quellen, Beziehungen und Prüfkriterien ausgerichtet werden.
Üben
Mini-Aufgabe
Formuliere für den Mini-Use-Case eine eigene Frageklasse. Ergänze mindestens drei erwartete Objekte, zwei Beziehungstypen und ein Prüfkriterium.
Musterlösung
Frageklasse
Welche kritischen Kundensysteme müssen nach Richtlinie A jährlich geprüft werden und welches Team ist verantwortlich?
Erwartete Objekte
Richtlinie A, kritisches Kundensystem, Team und Prüfpflicht.
Erwartete Beziehungen
definiert Pflicht für, hat Klassifikation und verantwortet.
Prüfkriterium
Die Antwort belegt Systemklasse, Team und Quellenabschnitt der Prüfpflicht. Eine schwache Antwort nennt ein System und lässt den Beleg offen.
Diese Lösung ist stark, weil sie eine klare Grenze hat. Sie prüft eine konkrete Fähigkeit: Das System muss eine Regel finden, ein System klassifizieren, eine Verantwortung auflösen und alles belegen. Damit entsteht ein kleiner, aber echter GraphRAG-Testfall.
Reflektieren
Selbsttest
1.Was meint "Frageklasse" hier?
Eine Frageklasse ist eine wiederkehrende Art von Frage, zum Beispiel: "Welche Projekte sind betroffen, wenn ein System eine Pflicht erfüllt?" Es geht um ein Muster, das sich mehrfach prüfen lässt.
2.Warum soll ich eine Frageklasse formulieren?
Weil sie die spätere Arbeit ausrichtet: Du weißt, welche Quellen du brauchst, welche Beziehungen der Graph enthalten muss und woran du die Antwortqualität prüfst.
3.Was muss ein Practice Brief mindestens enthalten?
Er braucht eine Frageklasse, Nutzer, Quellen, erwartete Objekte, erwartete Beziehungen und ein Prüfkriterium für schwache Antworten.
4.Woran erkennst du einen zu breiten Praxisfall?
Du erkennst es daran, dass erwartete Quellen, Objekte oder Beziehungen unklar bleiben oder dass jede beliebige Frage erlaubt ist.
Kernaussage
Eine Frageklasse macht aus einem GraphRAG-Wunsch einen prüfbaren Arbeitsauftrag.