diff --git a/RAG_SYSTEM_OVERVIEW.md b/RAG_SYSTEM_OVERVIEW.md index 08d8e39..65100f1 100644 --- a/RAG_SYSTEM_OVERVIEW.md +++ b/RAG_SYSTEM_OVERVIEW.md @@ -1,140 +1,686 @@ -# RAG-System - Wie funktioniert das System? +# RAG_SYSTEM_OVERVIEW.md + +# RetrieX – Systemüberblick + +> Hinweis: Die Datei heißt weiterhin `RAG_SYSTEM_OVERVIEW.md`, das System selbst wird fachlich jedoch als **RetrieX** bezeichnet. ## Grundidee -Dieses System ist ein sogenanntes **RAG-System** (Retrieval Augmented Generation). +RetrieX ist ein dokumentenbasiertes Assistenzsystem mit **Retrieval-Augmented Generation**. Das bedeutet: -> Die KI antwortet nicht frei oder kreativ, -> sondern ausschließlich auf Basis der hier hinterlegten Wissensdokumente. +- Antworten sollen nicht frei erfunden werden +- Wissen stammt primär aus den aktivierten Dokumenten im System +- die KI formuliert auf Basis von abgerufenem Kontext +- bei Produktanfragen können zusätzlich Live-Shopdaten einbezogen werden -Oder einfacher gesagt: +RetrieX ist damit **kein frei antwortender Chatbot**, sondern ein kontrolliertes System aus: -Die KI „weiß“ nur das, was Sie ihr hier als Dokumente geben. +- versionierten Wissensdokumenten +- deterministischem Ingest +- hybridem Retrieval +- optionaler Commerce-Erweiterung +- LLM-basierter Formulierung der Antwort --- -# Die drei Ebenen des Systems +# Die Hauptbausteine des Systems -## 1. Dokumente (Ihre Wissensquelle) +## 1. Dokumente als Wissensbasis -Sie laden Dokumente hoch (z. B. PDF, DOCX, Markdown, TXT). +Die Wissensbasis besteht aus hochgeladenen Dokumenten, zum Beispiel: -Diese Dokumente sind: +- PDF +- DOCX +- Markdown +- TXT -- versioniert -- unveränderlich gespeichert -- die einzige Wissensgrundlage des Systems +Diese Dokumente werden nicht direkt „gelesen“, sondern in einen verarbeitbaren Wissensindex überführt. -Wichtig: -Dokumente werden nicht direkt beantwortet, sondern technisch vorbereitet. +Wichtige Eigenschaften: + +- Dokumente sind versioniert +- pro Dokument gibt es fachlich genau eine aktive Version +- nur aktive Inhalte fließen in den Wissensindex ein +- Chunks sind abgeleitete Artefakte, keine manuell gepflegte Primärquelle + +Die eigentliche Wissensquelle sind also die **aktiven Dokumentversionen**, nicht frei bearbeitete Textfragmente. --- -## 2. Ingest & Indexierung (technische Aufbereitung) +## 2. Ingest und Indexierung -Sobald ein Dokument aktiviert wird: +Sobald eine Dokumentversion ingestiert oder aktiviert wird, läuft ein technischer Verarbeitungsprozess. -1. Es wird in kleinere Textabschnitte („Chunks“) zerlegt -2. Diese Chunks werden strukturiert gespeichert (NDJSON) -3. Der Vektorindex wird vollständig neu aufgebaut +Dabei passiert im Kern: -Nur aktive Dokumentversionen werden berücksichtigt. +1. Dokumentinhalt wird extrahiert +2. Inhalt wird in Chunks zerlegt +3. Chunk-Datensätze werden in `index.ndjson` geschrieben +4. der Vektorindex wird vollständig neu aufgebaut +5. Laufzeit-Metadaten werden aktualisiert -Das System arbeitet deterministisch und reproduzierbar. +Der Ingest ist bewusst **deterministisch** aufgebaut. +Das heißt: derselbe Datenstand soll immer wieder denselben Indexzustand erzeugen. --- -## 3. Anfrage & Antwort +## 3. Retrieval zur Laufzeit -Wenn ein Nutzer im Frontend eine Frage stellt: +Wenn ein Nutzer eine Anfrage stellt, durchsucht RetrieX nicht „das ganze Dokument direkt“, sondern den vorbereiteten Wissensbestand. -1. Das System durchsucht den Index nach passenden Inhalten -2. Relevante Textstellen werden ausgewählt -3. Diese werden an das KI-Modell übergeben -4. Die KI formuliert daraus eine Antwort +Das Retrieval ist im aktuellen Stand **hybrid und routingfähig**: -Die KI erfindet keine Inhalte. -Sie formuliert ausschließlich das, was in Ihren Dokumenten steht. +- Vektor-Retrieval über FAISS +- zusätzliches Tag-Routing zur Vorselektion möglicher Dokumente +- Score-basierte Auswahl relevanter Chunks +- Sonderroute für Katalog-/Listenanfragen +- optionale Ergänzung durch Live-Shopdaten bei Commerce-Intent + +Das System liefert also nicht einfach „irgendwelche Treffer“, sondern baut einen gezielten Kontextblock für das Modell. --- -# Steuerungsmöglichkeiten im Adminbereich +## 4. Antwortgenerierung -Im Adminbereich können zentrale Parameter gesteuert werden. -Diese beeinflussen, wie das System antwortet und wie es Inhalte verarbeitet. +Aus den ermittelten Informationen wird ein finaler Prompt aufgebaut. -## Modell- & Antwortparameter +Dieser Prompt kann aus mehreren Blöcken bestehen: -| Parameter | Bedeutung | Wirkung | -|------------|------------|----------| -| **Modell** | Auswahl des KI-Modells | Bestimmt Stil, Qualität und Sprachverhalten | -| **Temperatur** | Kreativitätsgrad der Antwort | Niedrig = sachlich & stabil, Hoch = freier formuliert | -| **Top K (LLM)** | Token-Auswahlbreite | Steuert Varianz bei der Wortauswahl | -| **Top P** | Wahrscheinlichkeitsfilter | Begrenzt unplausible Wortkombinationen | -| **Streaming** | Antwort wird live ausgegeben | Verbessert UX im Frontend | +- aktiver System-Prompt +- Gesprächskontext des Nutzers +- Live-Shop-Ergebnisse +- abgerufene Wissens-Chunks +- optional extrahierter Inhalt einer URL aus der Nutzeranfrage +- aktuelle Nutzerfrage + +Erst danach erzeugt das Sprachmodell die eigentliche Antwort. + +Die KI ist damit die **Formulierungsinstanz**, nicht die eigentliche Wissensquelle. --- -## Retrieval- & Wissensparameter +# Architektur in vier Ebenen -| Parameter | Bedeutung | Wirkung | -|------------|------------|----------| -| **vectorTopK** | Anzahl gefundener Chunks | Mehr = breiter Kontext, weniger = fokussierter | -| **maxChunks** | Maximale Übergabe an das Modell | Begrenzt Kontextgröße | -| **Tag-Routing aktiv** | Aktiviert Tag-Vorselektion | Präzisere Themenfilterung | -| **Scoring-Version** | Bewertungslogik | Steuert Priorisierung relevanter Inhalte | +## 1. Primärquellen + +Primärquellen sind die fachlichen Eingaben des Systems: + +- Dokumente +- Dokumentversionen +- aktive System-Prompts +- Modellkonfiguration +- optional externe Shopdaten + +Diese Ebene bestimmt, **welches Wissen und welche Regeln** überhaupt verwendet werden dürfen. --- -## Ingest- & Indexparameter +## 2. Index- und Retrieval-Ebene -| Parameter | Bedeutung | Wirkung | -|------------|------------|----------| -| **Chunk-Größe** | Länge eines Textabschnitts | Klein = präziser, Groß = mehr Kontext | -| **Chunk-Overlap** | Überlappung zwischen Chunks | Verhindert Kontextverlust | -| **Embedding-Modell** | Modell für Vektorisierung | Bestimmt Suchqualität | -| **Global Reindex** | Vollständiger Neuaufbau | Erzwingt saubere Reproduzierbarkeit | +Diese Ebene erzeugt und verwaltet den Suchraum: + +- `index.ndjson` als Chunk-Quelle +- `index_meta.json` als Struktur- und Governance-Metadaten +- `index_runtime.json` als Laufzeitstatus +- `vector.index` als FAISS-Index +- `tags.ndjson` und `vector_tags.index` für Tag-Routing + +Diese Ebene ist für Suche, Relevanz und Reproduzierbarkeit zuständig. --- -# Was bedeutet das für Sie als Admin? +## 3. Orchestrierungsebene -Sie steuern: +Diese Ebene verbindet alle Teile des Systems: -- Welche Dokumente aktiv sind -- Welche Versionen gültig sind -- Wie Inhalte indexiert werden -- Wie stark gefiltert wird -- Wie das Modell antwortet +- Anfrageannahme +- URL-Auswertung +- Retrieval +- Intent-Erkennung +- Shop-Suche +- Prompt-Aufbau +- Streaming der Modellantwort +- Historienpersistenz -Die Qualität der Antworten hängt direkt ab von: - -- der Dokumentstruktur -- der Chunk-Logik -- der Retrieval-Konfiguration -- der Modellkonfiguration +Zentrale Klasse für die Laufzeit ist hier insbesondere der `AgentRunner`. --- -# Grundprinzip des Systems +## 4. Ausgabe- und UI-Ebene -> „Wir nutzen KI nicht, um kreativ zu raten, -> sondern um verlässlich auf Basis Ihres Wissens zu antworten.“ +Die Antwort wird per **Server-Sent Events (SSE)** gestreamt. -Das System ist: +Dadurch erhält das Frontend die Ausgabe schrittweise, statt auf eine vollständige Blockantwort zu warten. -- deterministisch -- versioniert -- governance-stabil -- reproduzierbar +Der aktuelle Projektstand setzt für Browser-Streaming bevorzugt auf SSE. + +--- + +# Wissensspeicher und Indexdateien + +## index.ndjson + +`index.ndjson` ist die zentrale Chunk-Datei des Systems. + +Eigenschaften: + +- NDJSON statt großes JSON-Array +- streamingfähig +- append-/rewrite-fähig +- geeignet für größere Bestände +- dient als operative Grundlage für den Vector-Rebuild + +Jede Zeile repräsentiert einen Chunk-Datensatz. + +--- + +## index_meta.json + +`index_meta.json` beschreibt den strukturellen Zustand des Index. + +Beispielhafte Inhalte: + +- `index_version` +- `embedding_model` +- `embedding_dimension` +- `chunk_size` +- `chunk_overlap` +- `scoring_version` +- `index_format` +- `vector_backend` + +Diese Datei ist wichtig für Guardrails. +Wenn sich die Strukturparameter ändern, darf lokaler Ingest nicht einfach weiterlaufen. + +--- + +## index_runtime.json + +`index_runtime.json` enthält laufzeitbezogene Informationen zum aktuellen Indexzustand, zum Beispiel aktualisierte Chunk-Zählungen. + +Diese Datei dient nicht als Primärquelle, sondern als technische Betriebsmetadatei. + +--- + +## vector.index + +`vector.index` ist der FAISS-Vektorindex des Systems. + +Er wird nicht manuell gepflegt, sondern aus `index.ndjson` neu erzeugt. + +--- + +## tags.ndjson und vector_tags.index + +Neben dem Hauptindex existiert eine Tag-Ebene: + +- `tags.ndjson` +- `vector_tags.index` + +Diese wird für Tag-Routing bzw. thematische Vorselektion verwendet. + +Sie ist eine ergänzende Routing-Schicht, kein Ersatz für das Hauptretrieval. + +--- + +# Dokument-Lifecycle + +## 1. Dokument anlegen + +Ein Dokument wird als fachliche Einheit gespeichert. + +## 2. Versionen verwalten + +Dokumente besitzen Versionen. +Diese Versionen sind der eigentliche inhaltliche Träger. + +## 3. Aktivierung + +Wird eine Version aktiviert, wird nicht einfach nur „ein Text ausgetauscht“, sondern ein definierter Prozess ausgelöst. + +## 4. IngestJob + +Die Aktivierung führt in die Ingest-Orchestrierung. + +## 5. Chunk-Erzeugung + +Aus der aktiven Version werden Chunk-Records erzeugt. + +## 6. NDJSON-Update + +Bestehende Chunks des betroffenen Dokuments werden entfernt und durch neue ersetzt. + +## 7. Vollständiger Vector-Rebuild + +Anschließend wird der gesamte FAISS-Index aus dem aktuellen NDJSON-Bestand neu gebaut. + +--- + +# Ingest-Logik im aktuellen Stand + +Der Ingest ist in mehrere spezialisierte Services getrennt. + +## GuardrailValidator + +Prüft, ob der aktuelle Indexzustand mit der erwarteten Struktur kompatibel ist. + +Wenn nicht, wird lokaler Ingest blockiert. + +--- + +## ChunkWriteService + +Kapselt die Schreibvorgänge auf der Chunk-Ebene, insbesondere: + +- Chunks zählen +- Chunks für ein Dokument entfernen +- neue Chunks anhängen +- gesamten NDJSON-Bestand neu schreiben + +--- + +## VectorRebuildService + +Verantwortet den vollständigen Rebuild des Vektorindex und die Aktualisierung der Runtime-Metadaten. + +--- + +## IngestFlow + +Der `IngestFlow` orchestriert den Gesamtprozess. + +Für Dokument-Ingest bedeutet das insbesondere: + +- Guardrail prüfen +- Status auf laufend setzen +- alte Dokument-Chunks entfernen +- neue Chunks streamingfähig anhängen +- Chunk-Limits überwachen +- Vector-Rebuild auslösen +- finalen Status setzen + +--- + +# Guardrails und Reproduzierbarkeit + +RetrieX schützt sich bewusst gegen strukturellen Drift. + +Wenn sich zentrale Indexparameter ändern, etwa: + +- Embedding-Modell +- Embedding-Dimension +- Chunk-Größe +- Chunk-Overlap +- Scoring-Version +- Indexformat + +dann darf ein lokaler Ingest nicht stillschweigend in einen inkompatiblen Index hineinschreiben. + +Stattdessen wird ein **Global Reindex** erforderlich. + +Das verhindert inkonsistente Mischzustände. + +--- + +# Global Reindex + +Ein Global Reindex unterscheidet sich bewusst vom lokalen Dokument-Ingest. + +Dabei passiert: + +- alle aktiven Dokumente werden neu verarbeitet +- `index.ndjson` wird vollständig neu geschrieben +- der Vektorindex wird komplett neu gebaut +- die `index_version` wird erhöht + +Der Global Reindex ist damit der kontrollierte Weg, strukturelle Änderungen sauber auf den gesamten Wissensbestand anzuwenden. + +--- + +# Retrieval zur Anfragezeit + +## Hybrid-Retrieval + +Das aktuelle System verwendet kein rein lineares Suchmodell, sondern kombiniert mehrere Schritte: + +- Query-Cleaning +- Query-Enrichment +- Intent-Erkennung +- Tag-Routing +- globale Vektorsuche +- optional gescopte Vektorsuche auf Kandidatendokumente +- Fusion und Auswahl relevanter Chunks + +Das Ziel ist nicht einfach „mehr Treffer“, sondern **passendere, stabilere Kontexterzeugung**. + +--- + +## Tag-Routing + +Vor der eigentlichen Chunk-Auswahl kann das System thematisch passende Dokumente über Tags eingrenzen. + +Das reduziert die Suchfläche und erhöht die Wahrscheinlichkeit, dass relevante Dokumente bevorzugt werden. + +--- + +## Katalog-/Listenroute + +Für bestimmte Anfragen erkennt das System, dass keine klassische Chunk-Antwort, sondern eher eine Listen- oder Katalogausgabe sinnvoll ist. + +Dann kann statt normaler Chunk-Selektion ein Katalogblock erzeugt werden. + +--- + +## Ergebnisbegrenzung + +Die Zahl der zurückgegebenen Wissens-Chunks ist konfigurationsgetrieben. + +Wichtige Steuergrößen sind: + +- `retrievalMaxChunks` +- `retrievalVectorTopK` + +Diese Werte stammen aus der aktiven Modell-/Generierungskonfiguration. + +--- + +# Commerce-Erweiterung und Shop-Suche + +Ein zentrales Merkmal des aktuellen Systemstands ist die **optionale Shopware-Store-API-Anbindung**. + +Diese wird nicht immer verwendet, sondern nur dann, wenn die Anfrage nach Commerce-Logik aussieht. + +## CommerceIntentLite + +Die Anfrage wird heuristisch auf Commerce-Signale geprüft, zum Beispiel: + +- Produktsuche +- Preisbezug +- Größen-/Farbhinweise +- SKU-ähnliche Nummern +- typische Produkt- oder Empfehlungsfragen + +Das Ergebnis ist einer von drei Zuständen: + +- `none` +- `product_search` +- `advisory_product_search` + +--- + +## CommerceQueryParser + +Wenn Commerce erkannt wird, wird die Nutzeranfrage deterministisch aufbereitet. + +Dabei werden strukturierte Suchinformationen abgeleitet, etwa: + +- Suchkern +- Preis +- Größe +- Farbe +- weitere Suchsignale + +--- + +## ShopSearchService + +Der `ShopSearchService` baut daraus eine Shopware-Store-API-Anfrage und mappt die Ergebnisse in ein internes, schlankes Produktformat. + +Typische Produktinformationen sind dann: + +- Name +- Produktnummer +- Hersteller +- Preis +- Verfügbarkeit +- URL +- Beschreibung +- Bild +- ausgewählte Zusatzinformationen + +--- + +## Rolle der Shopdaten + +Shopdaten werden im Prompt ausdrücklich als **authoritative for products** behandelt. + +Das bedeutet: + +- für reale Produktdaten sind Live-Shopdaten führend +- Wissens-Chunks bleiben unterstützend +- das System trennt damit Produktwahrheit und Dokumentwissen bewusst voneinander + +--- + +## Balance zwischen Shop und Wissen + +Wenn Commerce aktiv ist, wird die Zahl der Wissens-Chunks reduziert: + +- bei `product_search` stärker +- bei `advisory_product_search` moderat + +So soll verhindert werden, dass Shopdaten im finalen Prompt von allgemeinen Wissens-Chunks verdrängt werden. + +--- + +# URL-Auswertung + +Wenn die Nutzeranfrage eine URL enthält, kann RetrieX den Inhalt dieser URL zusätzlich extrahieren. + +Dazu wird: + +- die erste URL im Prompt erkannt +- der Inhalt geladen +- über Readability verarbeitet +- HTML entfernt +- Text normalisiert +- auf eine maximale Länge begrenzt + +Der extrahierte Inhalt wird anschließend als zusätzlicher unterstützender Wissensblock in den Prompt aufgenommen. + +Das ist hilfreich, wenn ein Nutzer auf eine konkrete externe Quelle verweist. + +--- + +# Prompt-Aufbau + +Der finale Prompt wird systematisch zusammengesetzt. + +## 1. Systemblock + +Der aktive System-Prompt wird aus der Datenbank geladen. + +Er ist die führende Regel- und Verhaltensbasis des Modells. + +--- + +## 2. Gesprächskontext + +Frühere Nachrichten des Nutzers werden als autoritativer Konversationskontext eingebunden. + +So bleibt der Dialog über mehrere Turns konsistent. + +--- + +## 3. Live-Shop-Block + +Wenn Shop-Ergebnisse vorliegen, werden diese als eigener Block eingebaut. + +Sie sind für Produktfragen führend. + +--- + +## 4. Retrieved Knowledge + +Die ausgewählten Wissens-Chunks werden als unterstützender Wissensblock eingefügt. + +--- + +## 5. URL-Content + +Optional kommt zusätzlich extrahierter Webinhalt hinzu. + +--- + +## 6. Nutzerfrage + +Am Ende steht die aktuelle Benutzerfrage. + +--- + +# Antwort-Streaming + +Die Antwort wird nicht gesammelt und dann komplett ausgeliefert, sondern als Stream übertragen. + +## AskSseController + +Der `AskSseController` stellt den SSE-Endpunkt bereit. + +Dabei werden: + +- Buffer geleert +- Cookies weitergereicht +- SSE-Header gesetzt +- Daten als `data:`-Zeilen gesendet +- am Ende ein `done`-Event ausgeliefert + +## Vorteil + +Das Frontend kann Antworten live darstellen und laufend erweitern. + +Das verbessert die Benutzererfahrung deutlich, besonders bei längeren Antworten. + +--- + +# Conversation Context und Historie + +RetrieX verwaltet Nutzerkontext über eine eigene Context-Schicht. + +Dazu gehören insbesondere: + +- Aufbau eines nutzerspezifischen Gesprächskontexts +- Einbindung früherer Turns in den Prompt +- Persistierung der finalen Antworthistorie + +So kann das System nicht nur auf Einzelfragen, sondern auf fortlaufende Dialoge reagieren. + +--- + +# Modell- und Antwortsteuerung + +Ein Teil des Systemverhaltens wird über Modellkonfigurationen gesteuert. + +Dazu gehören fachlich und technisch insbesondere: + +- welches Modell verwendet wird +- wie Retrieval parametriert ist +- wie viele Chunks eingebunden werden +- wie breit die Vektorsuche sucht +- wie stark die Antwort durch System-Prompt und Kontext geprägt wird + +Diese Konfiguration ist bewusst nicht „wild überschreibbar“, sondern an die aktiven Systemobjekte gebunden. + +--- + +# Was Admins fachlich steuern + +Aus Admin-Sicht wird nicht nur „die KI“ gesteuert, sondern ein ganzes Wissens- und Antwortsystem. + +Steuerbar sind unter anderem: + +- welche Dokumente im System existieren +- welche Version aktiv ist +- welche Ingest-Profile gelten +- wann Reindexing ausgelöst wird +- welcher System-Prompt aktiv ist +- welche Modellkonfiguration aktiv ist +- ob und wie Commerce integriert ist + +--- + +# Was die Antwortqualität tatsächlich beeinflusst + +Die Qualität der Antworten hängt direkt von mehreren Ebenen ab: + +## 1. Dokumentqualität + +Schlecht strukturierte oder inhaltlich schwache Dokumente führen zu schwachen Antworten. + +## 2. Aktivierungslogik + +Nur aktive Versionen zählen. +Falsche Aktivierung bedeutet falscher Wissensstand. + +## 3. Chunking + +Chunk-Größe und Overlap beeinflussen, wie gut relevante Informationen später gefunden werden. + +## 4. Retrieval-Konfiguration + +Top-K, Auswahlgrenzen und Routing beeinflussen, welche Informationen überhaupt im Prompt landen. + +## 5. System-Prompt + +Der System-Prompt bestimmt Stil, Regelverhalten und Prioritäten der Ausgabe. + +## 6. Commerce-Daten + +Bei Produktfragen entscheidet die Qualität der Live-Shopdaten über die Produktwahrheit der Antwort. + +--- + +# Grundprinzipien des Systems + +RetrieX folgt im aktuellen Stand diesen Grundprinzipien: + +- dokumentenzentriert statt modellzentriert +- deterministisch statt zufällig orchestriert +- reproduzierbar statt implizit +- governance-fähig statt unkontrolliert +- hybrid im Retrieval +- erweiterbar durch Shopdaten +- streamingfähig in der Ausgabe + +--- + +# Was RetrieX ausdrücklich nicht ist + +RetrieX ist im aktuellen Design: + +- kein rein freier LLM-Chat +- kein ausschließlich kreatives Generierungssystem +- kein manuell gepflegter Chunk-Editor +- kein Produktkatalog ohne Wissenslogik +- kein rein vektorbasierter Blackbox-Sucher + +Es ist ein **kontrolliertes Antwortsystem**, das Wissen, Routing, Produktdaten und Modellformulierung zusammenführt. --- # Kurz zusammengefasst -Dokumente → werden aufbereitet → indexiert → gezielt durchsucht → KI formuliert Antwort. +RetrieX arbeitet im Kern so: -Sie kontrollieren das Wissen. -Die KI formuliert es. \ No newline at end of file +1. Dokumente und Versionen definieren den Wissensstand +2. Ingest erzeugt daraus NDJSON-Chunks +3. daraus wird der FAISS-Index vollständig neu aufgebaut +4. bei einer Anfrage laufen Retrieval, Routing und optional Commerce-Suche +5. PromptBuilder kombiniert Systemregeln, Kontext, Wissenschunks, URL-Inhalte und Shopdaten +6. das Modell formuliert daraus die Antwort +7. die Ausgabe wird per SSE ins Frontend gestreamt + +Kurzform: + +**Dokumente → Ingest → NDJSON → Vector Index → Retrieval → Prompt-Aufbau → LLM-Antwort → SSE-Streaming** + +--- + +# Merksatz + +> Sie steuern in RetrieX nicht einfach nur ein Modell. +> Sie steuern die zugelassene Wissensbasis, die Suchlogik, die Antwortregeln und – bei Produktfragen – die produktbezogene Live-Datenquelle. + +Die KI formuliert. +RetrieX bestimmt, worauf sie sich dabei stützen darf. \ No newline at end of file