Kanonisches SQL-Nachladen (Phase A3)
Ziel
Rückführung der vorselektierten Chunks in den kanonischen Datenbestand. Ab dieser Phase spielt die Vektordatenbank keine Rolle mehr.
Grundprinzip
Kein Vertrauen in Payload-Content. Die Vektordatenbank liefert nur IDs. Der tatsächliche Content wird ausschließlich aus der SQL-Datenbank geladen.
Ablauf
- Für jede Chunk-ID werden aus der SQL-Datenbank geladen:
- Chunk-Text (vollständig)
- Dokumenten-Referenz
- Abschnitts-Referenz
- Provenienzinformationen
- Die Vektordatenbank spielt keine Rolle mehr
- SQL ist alleinige Quelle der Wahrheit
SQL-Abfrage
SELECT
c.id, c.content, c.heading_path, c.token_count,
d.id AS document_id, d.filename, d.source_path,
dp.page_number
FROM chunks c
JOIN documents d ON c.document_id = d.id
LEFT JOIN document_pages dp ON c.page_id = dp.id
WHERE c.id IN (?, ?, ?, ...)
Warum nicht direkt aus Qdrant-Payload?
| Qdrant-Payload | SQL-Datenbank |
|---|---|
| Kann veraltet sein | Ist kanonisch und aktuell |
| Keine Versionierung | Versioniert und nachvollziehbar |
| Keine Provenienz | Vollständige Quellenreferenz |
| Optimiert für Suche | Optimiert für Wahrheit |
Ergebnisartefakte
- Vollständige Chunk-Datensätze
- Dokumenten-Metadaten
- Provenienz-Informationen
Beteiligte Komponenten
| Komponente | Pfad | Funktion |
|---|---|---|
| ChunkRepository | src/Infrastructure/ | SQL-Abfrage |
| chunks-Tabelle | ki_content.chunks | Chunk-Speicher |
| documents-Tabelle | ki_content.documents | Dokument-Metadaten |
Prüfbedingungen für Supervision
- Jeder verwendete Text ist aus SQL rekonstruierbar
- Kein Content aus Qdrant-Payload wird direkt verwendet
- Alle Chunks haben valide Dokumenten-Referenzen
- Fehlende Chunks in SQL führen zum Ausschluss (nicht zur Nutzung von Payload)