{
"event": "PreToolUse",
"tool_name": "WebFetch",
"tool_input": {
"url": "https:\/\/dev.campus.systemische-tools.de\/docs\/prozesse\/rag-prozess",
"prompt": "Extrahiere den vollständigen Inhalt dieser RAG-Prozess Dokumentation. Gib alle Schritte, Komponenten, Anforderungen und technischen Details zurück."
}
}
{
"tool_response": {
"bytes": 121250,
"code": 200,
"codeText": "OK",
"result": "# RAG-Prozess Dokumentation - Übersicht\n\n## Kernarchitektur\n\nDas System trennt strikt zwischen **Offline-Pipeline** (Wissensaufbau) und **Online-Pipeline** (Wissenskonsum). Die \"Drei-Säulen-Architektur\" besteht aus SQL-Datenbank als kanonischer Quelle, Vektordatenbank für Ähnlichkeitssuche und Graph als Wissensmodell.\n\n## Offline-Pipeline (12 Phasen)\n\n**Phase 0-1: Dokumentimport**\n- Eindeutige Identifikation via source_path\n- SHA256-Hash zur Änderungserkennung\n- Originaldatei archiviert und unverändert erhalten\n\n**Phase 2-3: Chunking**\n- Semantische Zerlegung nach Struktur\n- Parameter: 500-800 Token pro Chunk, 50-100 Token Überlappung\n- Maximale Zeichengrenze: 800 für Embedding\n\n**Phase 4: Vektorspeicherung**\n- Embedding-Modell: mxbai-embed-large (1536 Dimensionen)\n- Qdrant-Collections für Documents und System-Docs\n- Payload enthält nur: chunk_id, document_id, language, type\n\n**Phase 5-6: Semantische Extraktion und Normalisierung**\n- Entitätsextraktion (Named Entity Recognition)\n- Relationsextraktion aus Text\n- Konsolidierung und Deduplizierung mit canonical_name\n\n**Phase 7: Aussagebildung**\n- Explizite SPO-Tripel (Subject-Predicate-Object)\n- Aussagetypen: Definition, Faktische Behauptung, Regel, Beschreibung, Beispiel\n- Modalität dokumentiert: behauptend, hypothetisch, normativ, zitierend\n\n**Phase 8-9: Ontologie und Taxonomie**\n- Ontologie-Klassen definieren begriffliches Weltmodell\n- Taxonomie ordnet Klassen hierarchisch (ist-ein, Teil-von, gehört-zu)\n- Versioniert und änderbar nur manuell\n\n**Phase 10-12: Provenienz, Persistenz und Stabilisierung**\n- Vollständige Quellenrückverfolgung für jede Entität\n- Graph als versioniertes Wissensmodell\n- Übergang in stabilen, supervisionstauglichen Zustand\n\n## Online-Pipeline (8 Phasen)\n\n**Phase A0-A1: Anfrage-Eingang und Embedding**\n- Query wird mit identischem Modell wie Chunks eingebettet\n- Keine semantische Interpretation zu diesem Zeitpunkt\n\n**Phase A2: Vektorselektion**\n- Cosine-Similarity gegen Qdrant-Collections\n- Top-k Ergebnisse: standardmäßig top 5-10\n- Reine Vorselektion, nicht Wahrheitsfindung\n\n**Phase A3: SQL-Nachladen**\n- Chunk-Volltext nur aus SQL-Datenbank laden\n- Vektordatenbank liefert nur IDs und Payloads\n- Keine direktere Nutzung von Qdrant-Content\n\n**Phase A4-A5: Kontext-Aufbau**\n- Priorisierung nach Relevanz-Score und Dokumentenvielfalt\n- Formatierung mit Quellenangaben\n- Token-Limit respektieren (default 4096)\n\n**Phase A6: Prompt-Komposition**\n- System-Prompt + Kontext + User-Question\n- Keine inhaltliche Erweiterung oder Anreicherung\n- Kontext bleibt unverändert eingebettet\n\n**Phase A7: LLM-Generierung**\n- Claude-Modelle (Sonnet 4, Opus 4.5) oder Ollama lokal\n- Temperature und maxTokens konfigurierbar\n- Modellversion wird protokolliert\n\n**Phase A8: Response mit Quellennachweis**\n- Antwort mit vollständiger Quellenliste\n- Chat-Session persistiert\n- Sources zeigen: Dokument, Seite, Relevanz-Score\n\n## Kritische Governance-Regeln\n\n**ID-Stabilität:**\n- Dokument-ID stabil via source_path (UNIQUE)\n- Entity-ID stabil via canonical_name\n- Chunks und Qdrant-IDs: instabil, regenerierbar\n\n**Versionierungsformat:** [inhaltlich].[strukturell].[pipeline]\n\n**Status-Lebenszyklen implementiert:**\n- Chunks: created → embedding → embedded \/ error \/ deprecated\n- Entities: extracted → normalized → validated \/ deprecated \/ merged\n- Dokumente: pending → processing → done \/ error\n\n**Löschregeln:**\n- Wissen wird **nie gelöscht**, nur deprecated\n- Derivate (Chunks, Embeddings) dürfen gelöscht werden\n- DSGVO-Löschung nur für personenbezogene Daten explizit\n\n## Implementierungsstatus (Stand 2025-12-24)\n\n**Bereits implementiert:**\n- Chunk-Status ENUM (5 Zustände)\n- Entity-Status ENUM (5 Zustände)\n- Prompt-Versionierung mit IDs\n- Aussagen-Tabelle (statements) mit SPO-Tripeln\n- Provenienz-Tabelle\n- Entity-Synonyme (75 Einträge aktiv)\n- Audit-Service für kritische Operationen\n- Scoring-Service mit Gewichtung (0.7×similarity + 0.1×recency + 0.2×authority)\n- Document-Sections für Hierarchie\n\n**Komponenten:**\n- Pipeline-Orchestrierung: pipeline.py (scan, process, embed, all, file, status)\n- Python-Services: detect.py, extract.py, chunk.py, embed.py, analyze.py, vision.py, enrich.py\n- PHP-Services: ChatController, ChatService, QdrantService, OllamaService, ClaudeService\n\n## Fundamentale Abgrenzungen\n\n| System | Funktion | NICHT |\n|--------|----------|-------|\n| **SQL-DB** | Kanonische Wahrheit | Ähnlichkeitssuche |\n| **Vektoren** | Ähnlichkeitspreselektion | Semantische Autorität |\n| **Graph** | Strukturelles Wissensmodell | Datenhaltung (materialisiert aus SQL) |\n\n**Essenziell:** Vektorähnlichkeit ≠ Relevanz ≠ Wahrheit. Der LLM ist Formulierer, nicht Wissensproduzent.",
"durationMs": 18317,
"url": "https:\/\/dev.campus.systemische-tools.de\/docs\/prozesse\/rag-prozess"
}
}