System-Step 4 von 9
Speicherarchitektur spezifizieren
Spezifizieren, wo Dokumente, Chunks, Vektoren, Graphdaten, Belege und Anfrageprotokolle technisch liegen.
Was du mitnimmst
Antworten werden nachvollziehbarer, wenn Suche, Graphpfad, Belege und Anfrageprotokolle als eigene Aufgaben im System sichtbar sind.
Systemziel
Was hier geklärt wird
Du erstellst eine Speicherarchitektur für den Mini-Use-Case.
Kontext
Die Architekturfrage
Die Architekturfrage lautet: Welche Daten müssen wo liegen, damit das System Text finden, Beziehungen abfragen, Quellen belegen und Antwortwege nachvollziehen kann?
Der Chunk aus Richtlinie A Abschnitt 4.2 muss semantisch gefunden werden. Die Aussage "kritische Kundensysteme müssen jährlich geprüft werden" muss belegbar bleiben. Die Entität CRM muss über Quellen hinweg eindeutig sein. Die Beziehung CRM zu Projekt Alpha muss abfragbar sein. Das Anfrageprotokoll muss zeigen, welcher Suchweg zur Antwort geführt hat.
Das sind unterschiedliche Aufgaben. Deshalb reicht die Frage "In welcher Datenbank speichern wir das?" noch nicht. Zuerst klärst du, ob ein Datenstück als Quelle, Suchtext, Beziehung, Beleg oder Anfrageprotokoll gebraucht wird.
Prinzip
Architekturprinzip
Für jedes Datenstück klärst du zuerst, wie es später genutzt wird. Textabschnitte werden gesucht. Beziehungen werden abgefragt. Quellen belegen Aussagen. Anfrageprotokolle helfen beim Prüfen und Debugging.
Daraus entsteht eine Speicherarchitektur. Sie benennt die Aufgaben hinter den technischen Ablagen: Dokumente ablegen, Textsuchindex aufbauen, Graphdaten speichern, Belege halten und Anfrageabläufe protokollieren. Eine technische Datenbank kann mehrere dieser Aufgaben übernehmen.
Systementwicklung
Systembaustein
| Speicheraufgabe | Typische Ablage | Wofür das System es nutzt |
|---|---|---|
| Originale erhalten | Dokumentstore | Quellen, Versionen und Wiederverarbeitung |
| Text auffindbar machen | Vector Store | semantische Suche über Chunks |
| Beziehungen abfragen | Graph Store | Entitäten, Kanten und Pfade |
| Aussagen belegen | Belegablage oder Metadaten an Kanten | Quelle, Abschnitt, Version und Gültigkeit |
| Antwortweg prüfen | Anfrageprotokoll oder Log | Suchschritte, Graphpfad und genutzter Kontext |
Der Systembaustein ist eine Speicherarchitektur. Sie zeigt, welche Aufgabe eine Ablage übernimmt. "Belegablage" und "Anfrageprotokoll" bedeuten dabei nicht automatisch eigene Datenbanken. Sie können auch als Metadaten, Tabellen oder Logs umgesetzt werden.
storage-map.jsonjson
{
"document_store": ["source_id", "version", "section_id", "raw_text"],
"vector_store": ["chunk_id", "embedding", "source_id", "section_id"],
"graph_store": ["nodes", "relationships", "path_queries"],
"evidence": ["statement_id", "source_ref", "valid_from"],
"query_log": ["question_id", "search_steps", "used_context"]
}Abwägen
Trade-off
Was wird einfacher, was schwieriger?
Die Entscheidung: Du kannst im Prototyp vieles in einem Produkt speichern. Oder du benennst die Speicheraufgaben getrennt und entscheidest danach, welche Produkte, Tabellen oder Logs sie technisch tragen.
Die erste Variante ist schneller aufzusetzen. Sie wird schwieriger, sobald du prüfen musst, warum eine Antwort entstanden ist: Quelle, Graphpfad, Beleg und Suchweg liegen dann leicht vermischt in Metadaten oder Suchtreffern.
Die zweite Variante braucht mehr Entwurfsarbeit am Anfang. Dafür siehst du später klarer, wo ein Fehler liegt: im Suchindex, im Graphen, im Beleg oder im Anfrageprotokoll.
Fehlerbild
Typischer Baufehler
Worauf du achten musst
Die typische Falle: Der erste Prototyp speichert Chunks, Metadaten, Pfadhinweise, Belege und Debug-Informationen im Vector Store, weil dort schon alles auffindbar wirkt.
Das rächt sich bei der ersten Prüfungsfrage: Die Antwort nennt ein Projekt, aber der Pfad zur Quelle, die Beziehung im Graphen und der genutzte Suchweg lassen sich nur mühsam rekonstruieren.
Benenne die Speicheraufgaben sauber. Danach kannst du entscheiden, ob ein Produkt mehrere Aufgaben trägt oder ob getrennte Ablagen sinnvoll sind.
Prüfen
Woran du es erkennst
Prüfpunkt
Du erkennst die nötige Ablage an der Aufgabe in der Antwort. Sobald eine Antwort einen Pfad, einen Beleg oder ihren Entstehungsweg erklären muss, reicht reine Textsuche nicht mehr aus.
Üben
Mini-Aufgabe
Nutze den Mini-Use-Case: Eine Antwort nennt eine Quelle, einen Graphpfad und den Suchweg, der zur Antwort geführt hat. Ordne diese drei Dinge den passenden Speicheraufgaben zu.
Musterlösung
- 1Die Quelle und ihre Version liegen im Dokumentstore.
- 2Der Graphpfad liegt im Graph Store.
- 3Der Suchweg gehört in ein Anfrageprotokoll oder Log.
Der Beleg verbindet die Aussage zusätzlich mit Quelle, Abschnitt, Version und Gültigkeit.
Reflektieren
Selbsttest
1.Warum trennt man Speicheraufgaben?
Weil Suche, Beziehungspfad, Beleg und Anfrageprotokoll unterschiedliche Aufgaben im System übernehmen.
2.Bedeutet die Speicherarchitektur automatisch mehrere Datenbanken?
Nein. Eine Datenbank kann mehrere Aufgaben tragen, solange die Aufgaben im Entwurf unterscheidbar bleiben.
3.Welche Rolle braucht ein Antwortpfad besonders?
Einen Graph Store für Beziehungen und eine Belegablage für die Quellen hinter den Aussagen.
Kernaussage
Antworten werden nachvollziehbarer, wenn Suche, Graphpfad, Belege und Anfrageprotokolle als eigene Aufgaben im System sichtbar sind.