System-Step 3 von 9
Ingestion-Pipeline spezifizieren
Spezifizieren, wie Quellen technisch wiederholbar verarbeitet werden: Parsing, Chunking, Metadaten, Embeddings, Entitäten, Beziehungen, Review-Gates und Schreibpfade.
Was du mitnimmst
Ingestion ist die technische Pipeline, mit der aus vorbereiteten Quellen nutzbare Systemartefakte werden.
Systemziel
Was hier geklärt wird
Du spezifizierst Verarbeitungsschritte, Parameter, Review-Gates und Schreibpfade vor dem ersten Retrieval.
Kontext
Die Architekturfrage
Die Architekturfrage lautet: Wie verarbeitet das System Quellen so, dass Suche, Graph und Herkunftsprüfung zuverlässige Artefakte bekommen?
Für den Mini-Use-Case gibt es drei Quellen. Die Richtlinie enthält die Prüfpflicht und ihre Gültigkeit. Der Systemkatalog benennt Systeme und ihre wichtigsten Stammdaten, zum Beispiel System-ID und zuständiges Team. Die Projektliste zeigt, welches System zu welchem Projekt gehört.
Eine gute Pipeline-Spezifikation respektiert diese Unterschiede. Sie hält fest, wie jede Quelle gelesen wird, welche Version sie hat, welche Chunks entstehen, welche Entitäten erkannt werden und an welcher Stelle Beziehungen geprüft werden.
Prinzip
Architekturprinzip
Aus Quellen werden erst prüfbare Zwischenstände, dann Schreibaufträge.
In der Praxis übernehmen Libraries und Frameworks viele Teilschritte: Parser lesen Dokumente, Chunking-Libraries teilen Text, Embedding-Modelle erzeugen Vektoren und Graph-Tools schreiben Knoten und Kanten. Architekturseitig spezifizierst du, welche Zwischenstände sichtbar sein müssen, welche Parameter gelten, wo geprüft wird und welche technischen Ablagen beschrieben werden.
Systementwicklung
Systembaustein
| Pipeline-Schritt | Was dabei geklärt wird | Ergebnis oder Schreibziel |
|---|---|---|
| Quellen lesen | Welche Abschnitte, Tabellenzeilen und Metadaten nutzbar sind | Rohtext, Tabellen, Metadaten |
| Chunks bilden | Welche Textstücke später auffindbar sein müssen | Chunks mit Quelle, Abschnitt und Version |
| Embeddings erzeugen | Welche Chunks über semantische Suche erreichbar sind | Vector Store |
| Entitäten auflösen | Welche Namen dasselbe System, Projekt oder Team meinen | eindeutige Entitäten |
| Beziehungen prüfen | Welche Kanten fachlich belastbar sind | Review-Gate mit Herkunft |
| Schreibaufträge erzeugen | Welche geprüften Artefakte in welche technische Ablage gehen | Vector Store, Graph Store, Belegablage |
| Trace vorbereiten | Welche Parameter und Prüfschritte später sichtbar bleiben | Ingestion-Trace |
Der Systembaustein ist eine Pipeline-Spezifikation. Er ergänzt die Komponentenkarte aus dem vorherigen Schritt: Dort ging es um Rollen, hier geht es um den konkreten Herstellungsweg der Artefakte.
Abwägen
Trade-off
Was wird einfacher, was schwieriger?
Die Entscheidung: Du startest mit einem festen Importlauf. Ein Quellenstand wird vollständig verarbeitet und danach geprüft.
Die Konsequenz: Live-Updates, Löschung, Reprocessing und konkurrierende Versionen bleiben zunächst draußen. Dafür siehst du sauber, welche Artefakte entstehen: Chunks, Embeddings, Entitäten, Beziehungen, Herkunft und Trace.
Der Trade-off hilft dir beim Grundverständnis: Ein fester Importlauf macht den Herstellungsweg verständlich. Laufende Updates bringen das System näher an den Betrieb und verlangen zusätzliche Regeln für Versionierung, Löschung und Wiederverarbeitung.
Fehlerbild
Typischer Baufehler
Worauf du achten musst
Die typische Falle: Parsing, Chunking, Extraktion und Graph-Schreiben laufen in einem Durchgang und schreiben alles direkt in die Ablagen. Das wirkt produktiv, bis eine falsche Beziehung in der Antwort auftaucht.
Dann beginnt die Fehlersuche rückwärts: Wurde der Abschnitt falsch gelesen, der Chunk ungünstig geschnitten, "CRM" falsch aufgelöst oder eine unsichere Aussage als feste Kante gespeichert?
Plane die Pipeline mit sichtbaren Zwischenständen: Rohtext, Chunks, Metadaten, Entitäten, Beziehungen, Herkunft und Review-Gate.
Prüfen
Woran du es erkennst
Prüfpunkt
Du erkennst eine zu grobe Pipeline, wenn eine falsche Kante nur durch kompletten Neuimport korrigiert werden kann. Dann fehlen Zwischenstände, Review-Gate oder Versionierungsmodell.
Üben
Mini-Aufgabe
Nutze den Mini-Use-Case: Richtlinie A wurde aktualisiert, aber die Antwort verweist weiterhin auf die alte Fassung. Markiere zwei Stellen in der Pipeline, an denen du Versionierung oder Prüfung brauchst.
Musterlösung
- 1Quellen lesen: Die neue Richtlinienversion bekommt eine eigene Versions- und Gültigkeitsinformation.
- 2Schreiben in Suche und Graph: Alte Chunks, Beziehungen und Herkunftsbelege werden aktualisiert, deaktiviert oder als veraltet markiert.
So bleibt nachvollziehbar, welche Antwort auf welchem Quellenstand beruht.
Reflektieren
Selbsttest
1.Warum ist Ingestion mehr als Datei-Upload?
Weil aus Quellen mehrere Systembausteine entstehen: Chunks, Embeddings, Entitäten, Beziehungen, Herkunftsbelege und Schreibaufträge.
2.Wo entstehen viele GraphRAG-Fehler besonders früh?
Beim Lesen, Schneiden, Extrahieren, Zusammenführen und Versionieren der Quellen.
3.Was prüft ein Review-Gate?
Es prüft, ob ein erzeugtes Artefakt stabil genug ist, um in Suche, Graph oder Antwortlogik genutzt zu werden.
Kernaussage
Ingestion ist die technische Pipeline, mit der aus vorbereiteten Quellen nutzbare Systemartefakte werden.