Es ist der dritte Tag der Zusammenarbeit mit einem mittelständischen Versicherungsmakler, und die Leitung der Schadenabteilung wünscht sich ein Chat-Tool, das Schadenregulierer schnell unterstützen kann. Das Tool soll aktuelle Versicherungsrichtlinien zitieren, Ausnahmen erläutern und auf die genaue Seite im entsprechenden Handbuch verweisen. In derselben Besprechung fügt die Rechtsabteilung eine weitere Vorgabe hinzu: Das Tool darf unter keinen Umständen Inhalte aus einem Kundenvertrag anzeigen, sofern der jeweilige Schadenregulierer nicht diesem Kundenkonto zugeordnet ist.
Genau hier kommt kundenspezifische Retrieval-Augmented Generation (RAG) bei FDE-Einsätzen (Forward Deployed Engineering) ins Spiel. Bei kundenspezifischem RAG generiert das KI-System Antworten, indem es zunächst Fakten aus den eigenen Quellen des Kunden abruft und diese anschließend zur Formulierung der Antwort nutzt. Das Verfahren ist kundenspezifisch, da sich die Quellen im Laufe der Zeit ändern und der Kunde – nicht wir – festlegt, was als akzeptable Antwort gilt.
In der Praxis liefern wir keinen generischen Chatbot aus, sondern einen Antwort-Workflow, der fest mit echten Dokumenten, Berechtigungen und Geschäftsprozessen verknüpft ist. Für den Makler bedeutet „korrekt“, dass die Antwort der aktuellen Handbuchversion entspricht, diese zitiert und Zugriffsregeln auf Kontoebene einhält – selbst wenn die Frage mehrdeutig ist.
Der entscheidende FDE-Ansatz besteht darin, RAG als End-to-End-System und nicht bloß als einzelne Funktion zu betrachten. Konzentriert man sich nur auf Modell-Prompts, vernachlässigt man jene Aspekte, die das System im Produktivbetrieb sicher und zuverlässig machen. Die weiteren Ausführungen dieser Lektion beziehen sich weiterhin auf das Beispiel des Versicherungsmaklers, da jede Entscheidung direkte Auswirkungen darauf hat, welche Informationen dem Schadenregulierer im Moment der Bedarfsdeckung angezeigt werden.
Fehler bei RAG-Systemen im Produktivbetrieb verlaufen selten spektakulär. Sie sind meist unauffällig, wirken plausibel und verursachen hohe Kosten. Der Schadenregulierer erhält eine Antwort, die korrekt klingt, handelt entsprechend, und erst später fällt auf, dass der Schadenfall auf der Grundlage einer veralteten oder falschen Regel bearbeitet wurde.
Stellen Sie sich folgendes Szenario vor: Der Makler lädt am Montag ein neues Rundschreiben zum Thema „Ausnahmen bei Wasserschäden“ hoch. Am Mittwoch greift das Chat-Tool immer noch auf das Handbuch des Vormonats zurück, da die Content-Pipeline die neue Datei nicht neu eingelesen hat. Es treten keine Fehlermeldungen auf, und das System nennt womöglich sogar eine korrekte Seitenzahl – nur eben die falsche für das aktuell gültige Regelwerk.
Eine weitere häufige Fehlerquelle liegt bei den Zugriffsbeschränkungen. Kann der Abrufprozess (Retrieval) auf ein Dokument zugreifen, besteht die Gefahr, dass das KI-System dessen Inhalt zusammenfasst – selbst wenn der Endnutzer eigentlich keinen Zugriff darauf haben sollte. Aus diesem Grund sind Berechtigungen bei RAG-Systemen weit mehr als nur ein Detail der Benutzeroberfläche. Sie sind Bestandteil des Retrieval-Designs und müssen durchgesetzt werden, bevor Text an das Modell übergeben wird.
Ein weiteres kritisches Problem sind unbemerkte Fehlzugriffe („Silent Misses“). Eine Frage wie „Können wir auf die Inspektion verzichten, wenn der Schaden unter 2.000 liegt?“ erfordert möglicherweise eine spezifische Ausnahmeregelung. Findet der Retrieval-Prozess diese nicht, versucht das Modell oft dennoch, hilfreich zu sein, und füllt die Lücke mit einer allgemein klingenden Regel. Ohne entsprechende Messungen bemerken Sie diese Abweichung erst, wenn sich der Fachbereich beschwert.
Untersuchen Sie, wie sich diese Fehler auf die geschäftlichen Auswirkungen auswirken.
Von Drift ausgehen, Qualität nachweisen Wenn Sie die Qualität nicht im Zeitverlauf überwachen, verändert sie sich bereits, ohne dass Sie es schon bemerken.
Diese Fehlerszenarien führen zur eigentlichen FDE-Fragestellung: Welche Entscheidungen müssen wir in welcher Reihenfolge treffen, damit das System auch bei Änderungen von Dokumenten, Benutzern und Regeln korrekt bleibt?
Kundenspezifische RAG-Projekte (Retrieval-Augmented Generation) sind eine Kette von Entscheidungen, bei denen jedes Glied beeinflusst, was im nächsten Schritt sicher umgesetzt werden kann. Springt man direkt zu Themen wie Embeddings oder Chunk-Größen, muss das System später oft umgeschrieben werden – etwa wenn eine Geschäftsregel auftaucht, die eigentlich von Anfang an als zentrale Anforderung hätte berücksichtigt werden müssen.
Beginnen Sie mit Anforderungen, die präzise genug für Tests sind. Für den Versicherungsmakler formulieren wir Abnahmekriterien wie „muss den genauen Abschnitt im Handbuch zitieren“ und „muss die Antwort verweigern, wenn der Benutzer keine Zugriffsberechtigung hat“. Dies sind keine vagen Ziele, sondern klare Prüfkriterien (Bestanden/Nicht bestanden), die sich in ein Evaluierungs-Set überführen lassen.
Als Nächstes folgen die Daten. Wir erfassen die Quellen, die das Retrieval speisen, und deren Veränderungsmuster: Handbücher in SharePoint, Mitteilungen per E-Mail, Kundenverträge aus CRM-Exporten. Zudem legen wir fest, wer welche Inhalte sehen darf, da dieses Berechtigungsmodell sowohl die Indizierung als auch die Filterung zum Zeitpunkt der Abfrage bestimmt.
Dann folgt das Design des Retrieval-Prozesses. Beim Retrieval wählt das System aus, welche Dokumentenausschnitte dem Modell präsentiert werden. Eine entscheidende Frage ist, ob Berechtigungsfilter erst bei der Abfrage angewendet werden können oder ob für verschiedene Segmente separate Indizes erforderlich sind, um Informationsabflüsse (Leakage) zu verhindern. Im Fall des Versicherungsmaklers führen Kundenverträge oft zu der Notwendigkeit strenger Filterung, da bereits ein einziger Fehler einen schwerwiegenden Vorfall darstellen kann.
Unter „Grounding“ versteht man Maßnahmen, die sicherstellen, dass sich das Modell eng an den abgerufenen Text hält. Dazu gehören meist Regeln wie „Antwort nur auf Basis des bereitgestellten Kontexts“ und „Angabe von Quellen“. Ebenso wird festgelegt, wie das System reagieren soll, wenn Kontext fehlt – etwa durch eine Rückfrage oder die Antwort: „Ich kann dazu in den aktuellen Richtliniendokumenten nichts finden.“
Die Evaluierung macht die Zuverlässigkeit messbar. Sie besteht aus einem wiederholbaren Set von Testfragen und erwarteten Verhaltensweisen, die vor und nach Änderungen durchlaufen werden. Für den Versicherungsmakler sind dabei die Genauigkeit der Quellenangaben, die korrekte Verweigerung bei eingeschränkt zugänglichen Dokumenten sowie die Abdeckung von Schadensfällen mit hohem Risiko von Bedeutung.
Entscheidungen zur Bereitstellung (Deployment) machen aus all dem ein produktives System. Wir legen fest, wie die Datenaufnahme (Ingestion) abläuft, wie oft Indizes aktualisiert werden, wie Anfragen sicher protokolliert werden und wie Updates ausgerollt werden. Die Iteration erfolgt dann in einem Prozess mit definierten Leitplanken: Melden Sachbearbeiter einen Fehler, analysieren wir, ob eine Lücke bei den Daten, beim Retrieval oder bei den Anweisungen vorlag, und korrigieren die entsprechende Ebene.
Betrachten Sie die Phasen als ein zusammenhängendes System von Entscheidungen.