Protokoll #12709

{
    "event": "PreToolUse",
    "tool_name": "Read",
    "tool_input": {
        "file_path": "\/var\/www\/docs\/pipeline\/ausgabeprozess.md"
    }
}

{
    "tool_response": {
        "type": "text",
        "file": {
            "filePath": "\/var\/www\/docs\/pipeline\/ausgabeprozess.md",
            "content": "# Abfrage- und Ausgabeprozess  \n## Präzise Phasenfolge für RAG-basierte Wissensabfragen  \n## Konsistent mit semantischer Infrastruktur und Graph-Zielbild\n\n---\n\n## Vorbemerkung\n\nDer Abfrageprozess ist **kein Spiegel** der Importpipeline.  \nEr ist ein **konsumierender Prozess**, der ausschließlich auf bereits validierten, versionierten Zuständen arbeitet.\n\nGrundsatz:\n\n- Die Abfrage **erzeugt kein Wissen**\n- Sie **kombiniert**, **filtert** und **formuliert** vorhandene Information\n- Der Graph wird **nicht verändert**\n- Die SQL-Datenbank bleibt **kanonisch**\n- Die Vektordatenbank wird **nur zur Vorselektion** genutzt\n\n---\n\n## Phase A0: Anfrage-Eingang und Kontextdefinition\n\n### Ziel  \nEindeutige Definition dessen, *was* gefragt wird und *in welchem Rahmen*.\n\n### Ablauf\n\n1. Eine Anfrage wird vom Nutzer über eine Anwendung initiiert:\n   - KI-Chat  \n   - Content Studio  \n\n2. Die Anfrage besteht aus:\n   - Primärfrage oder Briefing  \n   - Anwendungs-Kontext  \n   - optionalen Parametern  \n\n3. Kontextparameter sind explizit:\n   - Ziel-Collection(s)  \n   - gewünschte Kontext-Tiefe (top_k)  \n   - Modellwahl  \n   - Token-Limits  \n\n4. Die Anfrage wird als **Abfrageobjekt** behandelt, nicht als Textfragment.\n\n### Ergebnisartefakte\n\n- Anfrage-ID  \n- Roh-Anfragetext  \n- Abfragekonfiguration  \n\n### Supervisionskriterium\n\n- Die Anfrage ist vollständig parametriert, bevor irgendein Retrieval beginnt.\n\n---\n\n## Phase A1: Anfrage-Einbettung\n\n### Ziel  \nÜberführung der Anfrage in einen Suchvektor für Ähnlichkeitsretrieval.\n\n### Ablauf\n\n1. Der Anfragetext wird technisch normalisiert.  \n2. Die Anfrage wird mit **demselben Embedding-Modell** eingebettet wie die Chunks.  \n3. Es entsteht genau **ein Query-Vektor**.\n\n### Abgrenzung\n\n- Keine semantische Analyse  \n- Keine Interpretation  \n- Keine Graph-Abfrage  \n\n### Ergebnisartefakte\n\n- Query-Vektor  \n- Referenz auf verwendetes Embedding-Modell  \n\n### Supervisionskriterium\n\n- Modellidentität zwischen Indexierung und Anfrage ist geprüft.\n\n---\n\n## Phase A2: Vektorbasierte Vorselektion\n\n### Ziel  \nReduktion des Suchraums auf potenziell relevante Chunks.\n\n### Ablauf\n\n1. Der Query-Vektor wird gegen die definierte Collection gesucht.  \n2. Die Vektordatenbank liefert:\n   - Chunk-Referenzen  \n   - Relevanz-Scores  \n\n3. Es werden ausschließlich **Chunk-IDs und Payload-Metadaten** verwendet.\n\n### Abgrenzung\n\n- Scores sind **keine Wahrheitsmaße**  \n- Reihenfolge ist **heuristisch**, nicht semantisch  \n\n### Ergebnisartefakte\n\n- Kandidatenliste von Chunk-IDs mit Scores  \n\n### Supervisionskriterium\n\n- Kein Chunk ohne SQL-Referenz gelangt weiter.\n\n---\n\n## Phase A3: Kanonisches Nachladen aus SQL\n\n### Ziel  \nRückführung der vorselektierten Chunks in den kanonischen Datenbestand.\n\n### Ablauf\n\n1. Für jede Chunk-ID werden aus der SQL-Datenbank geladen:\n   - Chunk-Text  \n   - Dokumenten-Referenz  \n   - Abschnitts-Referenz  \n   - Provenienzinformationen  \n\n2. Die Vektordatenbank spielt **keine Rolle mehr**.\n\n### Abgrenzung\n\n- Kein Vertrauen in Payload-Content  \n- SQL ist alleinige Quelle der Wahrheit  \n\n### Ergebnisartefakte\n\n- Vollständige Chunk-Datensätze  \n\n### Supervisionskriterium\n\n- Jeder verwendete Text ist aus SQL rekonstruierbar.\n\n---\n\n## Phase A4: Kontext-Selektion und Priorisierung\n\n### Ziel  \nZusammenstellung eines sinnvollen, begrenzten Arbeitskontextes.\n\n### Ablauf\n\n1. Chunks werden nach:\n   - Relevanz-Score  \n   - Dokumentenvielfalt  \n   - Redundanzfreiheit  \n\n2. Auswahl erfolgt bis zum:\n   - Token-Limit  \n   - Kontext-Limit  \n\n3. Reihenfolge wird festgelegt und stabilisiert.\n\n### Abgrenzung\n\n- Noch keine Textgenerierung  \n- Keine semantische Umformung  \n\n### Ergebnisartefakte\n\n- Geordnete Chunk-Liste für Kontext  \n\n### Supervisionskriterium\n\n- Kontextaufbau ist deterministisch nachvollziehbar.\n\n---\n\n## Phase A5: Kontext-Formalisierung\n\n### Ziel  \nÜbersetzung der ausgewählten Chunks in ein LLM-verwertbares Kontextformat.\n\n### Ablauf\n\n1. Jeder Chunk wird versehen mit:\n   - Quellenkennzeichnung  \n   - Dokumentenreferenz  \n\n2. Trennmarker werden eingefügt.  \n3. Token-Limits werden technisch geprüft.\n\n### Ergebnisartefakte\n\n- Formatierter Kontextblock  \n- Quellenliste  \n\n### Supervisionskriterium\n\n- Jede Kontextpassage ist eindeutig einer Quelle zugeordnet.\n\n---\n\n## Phase A6: Prompt-Komposition\n\n### Ziel  \nZusammenführung von Kontext, Anfrage und Steuerinformationen.\n\n### Ablauf\n\n1. System-Prompt definiert:\n   - Rolle  \n   - Regeln  \n   - Antwortgrenzen  \n\n2. User-Prompt enthält:\n   - Originalfrage oder Briefing  \n\n3. Kontext wird **nicht verändert**, sondern eingebettet.\n\n### Abgrenzung\n\n- Keine inhaltliche Erweiterung  \n- Keine semantische Anreicherung  \n\n### Ergebnisartefakte\n\n- Vollständiger Prompt  \n\n### Supervisionskriterium\n\n- Prompt ist vollständig rekonstruierbar.\n\n---\n\n## Phase A7: LLM-Generierung\n\n### Ziel  \nErzeugung einer Antwort auf Basis des bereitgestellten Kontextes.\n\n### Ablauf\n\n1. Prompt wird an das gewählte LLM übergeben.  \n2. LLM generiert Text innerhalb:\n   - Token-Limit  \n   - Temperature  \n   - Systemregeln  \n\n3. Ausgabe wird nicht verändert.\n\n### Abgrenzung\n\n- LLM erzeugt Text, kein Wissen  \n- Wahrheit liegt weiterhin im System, nicht im Output  \n\n### Ergebnisartefakte\n\n- Roh-Antworttext  \n- Tokenverbrauch  \n\n### Supervisionskriterium\n\n- LLM hat ausschließlich den bereitgestellten Kontext genutzt.\n\n---\n\n## Phase A8: Ausgabe, Speicherung und Transparenz\n\n### Ziel  \nNachvollziehbare Übergabe der Antwort an den Nutzer.\n\n### Ablauf\n\n1. Antwort wird angezeigt.  \n2. Verwendete Quellen werden explizit ausgewiesen.  \n3. Bei Chat:\n   - Speicherung in Session  \n4. Bei Content Studio:\n   - Versionierung des Inhalts  \n\n### Ergebnisartefakte\n\n- Antwort  \n- Quellenverweise  \n- Sitzungs oder Versionsdatensatz  \n\n### Supervisionskriterium\n\n- Jede Antwort ist auf ihre Quellen rückführbar.\n\n---\n\n## Zusammenfassung Abfrageprozess\n\n1. Retrieval ist **zweistufig**: Vektor → SQL  \n2. Kontext ist **selektiert**, nicht geraten  \n3. Der Graph bleibt **unangetastet**  \n4. Das LLM ist **reiner Formulierer**  \n5. Transparenz ist kein UI-Feature, sondern Prozessbestandteil\n",
            "numLines": 299,
            "startLine": 1,
            "totalLines": 299
        }
    }
}