System-Step 7 von 9
Toolklassen für die Umsetzung spezifizieren
Werkzeuge nach Aufgabe einordnen: Graph Store, Vector Store, Anfrageablauf, Evaluation und Anfrageprotokoll.
Was du mitnimmst
Toolklassen machen sichtbar, welche Art von Werkzeug für welche Aufgabe im GraphRAG-System gebraucht wird.
Systemziel
Was hier geklärt wird
Du erstellst ein Tool-Mapping: Welche Art von Werkzeug brauchst du für Graphspeicher, Textsuche, Anfrageablauf, Evaluation und Logs?
Kontext
Die Architekturfrage
Die Architekturfrage lautet: Welche Art von Werkzeug wird für welche technische Aufgabe gebraucht?
Für den Mini-Use-Case brauchst du mindestens drei feste Aufgaben: einen Ort für semantische Chunks, einen Ort für Beziehungspfade und eine Logik, die beide kombiniert. Evaluation und Logs können im Prototyp leichtgewichtig sein, müssen aber als eigene Aufgaben sichtbar bleiben.
Das Tool-Mapping hängt an Fragen wie: Müssen Pfade tief abgefragt werden? Brauchen wir starke Metadatenfilter? Soll der Anfrageweg als eigener Service gebaut werden? Wie wichtig sind Anfrageprotokolle für jede einzelne Antwort?
Prinzip
Architekturprinzip
Toolwahl folgt Aufgabe. Ein Werkzeug ist passend, wenn es die benötigte Aufgabe sauber erfüllt und die späteren Betriebsfragen sichtbar lässt.
Produktnamen kommen nach der Aufgabenklärung. So bleibt die Architektur verständlich, auch wenn ein Werkzeug später ausgetauscht wird.
Systementwicklung
Systembaustein
| Aufgabe im System | Toolklasse | Beispiele | Prüfpunkt |
|---|---|---|---|
| Graph Store | Property Graph oder RDF Graph | Neo4j, Memgraph, Neptune, GraphDB | Pfade und fachliche Beziehungen sind zentral |
| Vector Store | Vector Database oder SQL Extension | Qdrant, Weaviate, Pinecone, pgvector | Embedding-Suche und Metadatenfilter sind zentral |
| Anfrageablauf | Framework oder eigener Service | LlamaIndex, LangChain, eigene API | Suchwege, Tools und Fallbacks müssen gesteuert werden |
| Evaluation und Logs | Eval- und Observability-Werkzeuge | LangSmith, Ragas, eigene Testläufe | Qualität und Anfrageprotokolle müssen wiederholbar prüfbar sein |
Der Systembaustein ist ein Tool-Mapping. Es verbindet technische Aufgaben mit Werkzeugklassen und Beispielprodukten.
Abwägen
Trade-off
Was wird einfacher, was schwieriger?
Die Entscheidung: Du wählst Werkzeuge nach Aufgabe: Graph Store, Vector Store, Anfrageablauf, Evaluation und Anfrageprotokoll.
Die Konsequenz: Ein Framework kann den Start stark beschleunigen, weil es Retriever anbindet, Tools koordiniert, Prompts strukturiert und Traces erzeugt. Ein eigener Service kostet mehr Bauzeit, gibt dir aber mehr Kontrolle über fachliche Grenzen und Austauschbarkeit.
Der Trade-off hilft dir beim Grundverständnis: Fertige Frameworks bringen Tempo. Eigene Services bringen Kontrolle. Die Toolklasse sagt dir, an welcher Stelle diese Entscheidung wirklich entsteht.
Fehlerbild
Typischer Baufehler
Worauf du achten musst
Die typische Falle: Ein Framework übernimmt unbemerkt fachliche Entscheidungen. Dann entscheidet die Default-Konfiguration, welche Treffer gerankt werden, wann ein Graphpfad genutzt wird oder wie ein unsicheres Ergebnis markiert wird.
Das wird kritisch, wenn die Antwort falsch ist. Dann lässt sich schwer sagen, ob der Fehler aus der Textsuche, der Graphabfrage, dem Prompt, dem Framework-Routing oder dem fehlenden Trace kommt.
Lege deshalb fest, welche Entscheidung im eigenen Code, in der Tool-Konfiguration oder in einem Review-Gate liegt. So bleibt das System erklärbar, auch wenn du Frameworks und Libraries nutzt.
Prüfen
Woran du es erkennst
Prüfpunkt
Du erkennst ein gutes Tool-Mapping daran, dass jedes Werkzeug eine klare Aufgabe hat: speichern, suchen, Pfad abfragen, Anfrageweg steuern, Qualität messen oder Ablauf protokollieren.
Üben
Mini-Aufgabe
Wähle für einen kleinen Prototypen je eine Toolklasse für Graph Store, Vector Store und Anfrageablauf. Nenne ein Beispiel und eine Alternative.
Musterlösung
- 1Graph Store: Property Graph, zum Beispiel Neo4j; Alternative Memgraph.
- 2Vector Store: Vector Database oder SQL Extension, zum Beispiel Qdrant oder pgvector.
- 3Anfrageablauf: eigener Service oder LlamaIndex, abhängig davon, wie fachlich die Entscheidung über Textsuche, Graphpfad und Fallback ist.
Wichtig ist, dass Graph Store, Vector Store und Anfrageablauf getrennte Aufgaben bleiben.
Reflektieren
Selbsttest
1.Warum startet Toolwahl mit Aufgaben?
Weil erst die Aufgabe zeigt, welches Werkzeug im System wirklich gebraucht wird.
2.Was ist der Unterschied zwischen Toolklasse und Produkt?
Die Toolklasse beschreibt eine Art von Werkzeug. Das Produkt ist eine konkrete Ausprägung dieser Klasse.
3.Was zeigt eine gute Toolklassen-Matrix?
Sie verbindet Aufgabe, Werkzeugkategorie, Beispiele und Prüfpunkt.
Kernaussage
Toolklassen machen sichtbar, welche Art von Werkzeug für welche Aufgabe im GraphRAG-System gebraucht wird.