System-Step 2 von 9
Komponenten und Verantwortlichkeiten spezifizieren
Die Systemteile als konkrete Verantwortlichkeiten beschreiben: Parser, Chunker, Entity Resolver, Graph Builder, Retriever, Orchestrator, Answer Composer und Trace Logger.
Was du mitnimmst
Eine Komponentenkarte zeigt, wo Informationen entstehen, genutzt werden und wo Fehler sichtbar werden.
Systemziel
Was hier geklärt wird
Du legst fest, welche Komponente welche Information erzeugt, speichert, abruft, prüft oder protokolliert.
Kontext
Die Architekturfrage
Eine Architektur mit Graphkontext braucht klare Verantwortlichkeiten. Die Frage ist: Welche Systemkomponente erzeugt, speichert, nutzt oder prüft welche Information?
Für den Mini-Use-Case bedeutet das: Die Richtlinie muss sauber gelesen werden. Die Projektliste muss als strukturierte Zuordnung nutzbar werden. Die Team-Zuordnung muss Customer Core mit Projekt Alpha verbinden. Der Orchestrator muss erkennen, ob eine Frage eine Textstelle, einen Beziehungspfad oder beides braucht. Das LLM formuliert daraus ein Ergebnis mit Quellenbezug.
Die Kernfrage lautet: Welche Komponente ist für welchen Teil des Systems zuständig?
Prinzip
Architekturprinzip
Komponenten werden nach ihrer Aufgabe benannt. Eine technische Umsetzung kann mehrere Aufgaben bündeln, aber das Systemdesign muss die Grenzen trotzdem sichtbar halten.
Klare Grenzen helfen dir später beim Debugging: Wenn ein Pfad fehlt, schaust du auf Graph Builder und Graph Store. Wenn die Quelle fehlt, schaust du auf Parser, Chunker und Herkunftsbelege. Wenn der Suchweg falsch ist, schaust du auf den Orchestrator. Wenn das Ergebnis unklar formuliert ist oder Quellenbezug fehlt, schaust du auf LLM und Composer.
Systementwicklung
Systembaustein
| Komponente | Aufgabe | Liefert | Typisches Fehlersignal |
|---|---|---|---|
| Parser | Quellenstruktur lesen | Abschnitte, Tabellen, Metadaten | wichtige Struktur fehlt |
| Chunker | Text in nutzbare Abschnitte teilen | Chunks mit Quelle und Abschnitt | Kontext bricht ab |
| Graph Builder | Entitäten und Beziehungen erzeugen | kleine Graphfragmente | Beziehung fehlt oder ist falsch |
| Query Orchestrator | Suchweg pro Frage wählen | Kontextpaket aus Text und Pfad | unpassender Retrieval-Weg |
| LLM / Composer | Ergebnis aus Kontext formulieren | Ergebnis mit Quellenbezug | Quelle, Pfad oder Einschränkung fehlt |
| Trace Logger | Ablauf sichtbar machen | Trace der Anfrage | Fehler ist nicht nachvollziehbar |
Die Komponentenkarte zeigt für jeden Systemteil: Welche Aufgabe hat er, was liefert er und woran erkennst du dort ein Problem?
Abwägen
Trade-off
Was wird einfacher, was schwieriger?
Die Entscheidung: Du schneidest die Komponenten so fein, dass jede wichtige Aufgabe ein eigenes Ergebnis und ein Fehlersignal hat.
Die Konsequenz: Die Karte wird etwas größer. Dafür erkennst du später gezielt, ob CRM falsch erkannt wurde, ob eine Beziehung fehlt, ob der Orchestrator den Graphpfad ausgelassen hat oder ob das LLM den Quellenbezug verloren hat.
Der Trade-off hilft dir beim Grundverständnis: Eine grobe Karte erklärt den Ablauf schneller, eine präzisere Karte macht Fehler suchbar. Für den Lernpfad reichen die wichtigsten Rollen: Quellen lesen, Chunks bilden, Beziehungen bauen, Suchweg wählen, Ergebnis formulieren und Trace speichern.
Fehlerbild
Typischer Baufehler
Worauf du achten musst
Die typische Falle: Mehrere Aufgaben verschwinden in einem großen Block. Dann heißt es schnell: "Die Pipeline macht das" oder "der Backend-Service kümmert sich darum".
Das wird kritisch, sobald eine falsche Antwort auftritt: Es bleibt unklar, ob die Quelle falsch gelesen wurde, die Beziehung fehlt, der Orchestrator den falschen Suchweg gewählt hat, das LLM den Kontext unsauber formuliert hat oder der Trace zu wenig zeigt.
Benenne die Systemrollen so, dass jede wichtige Aufgabe ein eigenes Ergebnis und ein Fehlersignal hat.
Prüfen
Woran du es erkennst
Prüfpunkt
Du erkennst zu grobe Komponentengrenzen, wenn eine falsche Antwort niemandem im System zugeordnet werden kann. Dann brauchst du klarere Rollen für Parser, Chunker, Graph Builder, Orchestrator, LLM und Trace.
Üben
Mini-Aufgabe
Nutze den Mini-Use-Case: Eine Antwort nennt Projekt Alpha nicht, obwohl CRM in der Projektliste mit Projekt Alpha verbunden ist. Markiere drei Komponenten, die du prüfen würdest.
Musterlösung
- 1Parser: Hat die Projektliste die CRM-Zeile korrekt gelesen?
- 2Graph Builder: Wurde aus der Zuordnung die Beziehung CRM -> Projekt Alpha erzeugt?
- 3Query Orchestrator: Hat die Frage einen Graphpfad angefordert oder nur Textsuche genutzt?
Der Fehler lässt sich gezielt eingrenzen, weil jede Komponente eine eigene Verantwortung hat.
Reflektieren
Selbsttest
1.Warum reichen Produktnamen für den Komponentenschnitt nicht aus?
Weil ein Produkt mehrere Rollen tragen kann. Die Architektur muss trotzdem wissen, welche Verantwortung gerade gemeint ist.
2.Welche Frage beantwortet eine gute Komponentenkarte?
Sie zeigt, welche Komponente welche Information erzeugt, nutzt, speichert, prüft oder protokolliert.
3.Was ist ein Warnsignal für einen zu groben Schnitt?
Eine falsche Antwort lässt sich keiner verantwortlichen Komponente zuordnen.
Kernaussage
Eine Komponentenkarte zeigt, wo Informationen entstehen, genutzt werden und wo Fehler sichtbar werden.