Logo UNIQA Insurance Group AG

UNIQA Insurance Group AG

Etablierte Firma
Alle Videos anzeigen

GenAI myUNIQA

Description

Aleksandar Kamenica von UNIQA zeigt in seinem devjobs.at TechTalk einen Anwendungsfall für AI innerhalb des Unternehmens und wie das Team zu der Lösung gekommen ist.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In GenAI myUNIQA zeigt Aleksandar Kamenica, wie UNIQA GenAI nutzt, um aus rechtlich bindenden Versicherungsdokumenten personalisierte, strukturierte Antworten in der myUNIQA‑App zu erzeugen und damit das zentrale Kundenproblem – das Verstehen von Leistungen, Deckungen und Selbstbehalt – zu lösen. Nach ersten RAG-/Chunking-Versuchen wechselte das Team auf Large‑Context‑LLMs, verankerte Antworten strikt in bereitgestellten Dokumenten und beseitigte Widersprüche über eine Hierarchie aus „Haupt-“ und „Zusatzdokumenten“; die KI liefert nachvollziehbare, mit Quellen versehene JSON-Antworten, die im UI als aufklappbare Abschnitte gerendert werden. Learnings: Public Cloud senkt Einstiegshürden, Prompts und Ausgabeformate iterativ entwickeln (Markdown → JSON) und die eigene Datenstruktur tief verstehen – Ansätze, die sich auf ähnliche Vertrags‑ und Policy‑Use‑Cases übertragen lassen.

Von juristischen PDFs zu personalisierten Antworten: GenAI myUNIQA in der Praxis

Kontext: Warum UNIQA GenAI in myUNIQA einsetzt

Bei „GenAI myUNIQA“ führte uns Aleksandar Kamenica (Product Owner Technology Exploration, UNIQA Insurance Group AG) durch eine sehr greifbare Use-Case-Story: Kundinnen und Kunden verstehen ihre Versicherungsverträge nicht. Das ist kein Bauchgefühl, sondern datenbasiert bestätigt. In Befragungen sah UNIQA konsistent „Verstehen“ als Kernproblem – ob es um Leistungen, Ausschlüsse, Selbstbehalte, Dokumente, Schadensmeldungen oder Zahlungsdetails geht. Besonders deutlich: Die rechtsverbindliche Wahrheit liegt ausschließlich in den Vertragsdokumenten, nicht in strukturierten Datenfeldern.

Die Herausforderung: Aus heterogenen, rechtlich bindenden Dokumenten (PDFs, Bausteine, Produkt- und Zusatzbedingungen) sollen individuelle, klar formulierte Antworten entstehen – präzise für die jeweilige Produktkonfiguration, ohne Widersprüche und ausschließlich auf Grundlage der Dokumente.

Kamenicas Zielbild: Von „Dokumentberge“ zu „sofort verständlichen, personalisierten Antworten“ in myUNIQA – visuell ansprechend, korrekt, vollständig und nachvollziehbar.

Das Team hinter dem Use Case

Die Lösung entstand im Technology Exploration Team – ein cross-funktionales Team mit zwei klaren Aufgaben:

  • Neue, bislang bei UNIQA nicht eingesetzte Technologien evaluieren und produktiv machen.
  • Technische Lösungen für besonders anspruchsvolle Businessprobleme finden.

Vorleistungen, die auch diesen GenAI-Case ermöglichten:

  • Migration von myUNIQA auf Public-Cloud-Infrastruktur (AWS) – laut Kamenica ein „wichtiger Puzzlestein“ für die AI-Journey.
  • Selektion und Etablierung eines Frontend-Framework-Stacks für kundenseitige Anwendungen.
  • Migration des Customer Identity & Access Management von On-Premises in die Cloud.

Diese Bewegungen in die Cloud senkten die Startbarrieren für GenAI deutlich – ein Learning, auf das Kamenica später ausdrücklich zurückkommt.

Problemdefinition: Personalisierte Antworten aus rechtsverbindlichen Dokumenten

UNIQA arbeitet „Customer First“ – nicht nur als KPI-getriebene Zufriedenheitsmessung, sondern als Datengrundlage für die Produktentwicklung. Die Analyse zeigte: Viele Kundinnen und Kunden verstehen relevante Vertragsinhalte nicht. Gleichzeitig sind rechtlich maßgebliche Informationen ausschließlich in den Dokumenten verankert. Es gibt also keinen bequemen Weg, Antworten aus einem bereits existierenden, sauberen Datenmodell zu ziehen.

Das Wunschbild: Nutzerinnen und Nutzer öffnen in myUNIQA den konkreten Vertrag (zum Beispiel Haushalt) und sehen vordefinierte Fragen mit personalisierten Antworten – abhängig von Produkt, Add-ons und individueller Kombination dieser Bausteine. Kamenica nutzt dafür das „Lego“-Bild: Ein Produkt besteht aus vielen Bausteinen; jeder kann eigene Anhänge und Klauseln mitbringen. Die Antwort muss die Gesamtkonfiguration korrekt widerspiegeln.

Produktvision und die bewusst gewählte Phase 1

Die Vision auf der rechten Seite des Zielbilds: Ein direkter AI-Dialog, der alle versicherungsbezogenen Fragen in Echtzeit beantwortet – basierend auf UNIQA-Wissen. Doch für Phase 1 setzte das Team auf „indirekte AI-Beteiligung“:

  • Einheitliche, vordefinierte Fragen pro Produktbereich.
  • Antworten personalisiert, aber nicht live generiert.
  • Die AI erzeugt Antworten vorab auf Basis der jeweiligen Dokumentenkombinationen.
  • Diese Antworten werden in einer Datenbank gespeichert und in der App angezeigt.

Warum kein CMS? Weil die Antworten aus juristischen Quellen abgeleitet werden und alle möglichen Produktkombinationen abdecken müssen. Eine händische Pflege wäre unpraktikabel und riskant – die AI erstellt Inhalte, aber Kundinnen und Kunden interagieren in Phase 1 noch nicht direkt mit dem Modell.

Erste Implementierungsidee: RAG mit Chunking – und die Realität

Der klassische Einstieg: Retrieval-Augmented Generation (RAG) mit Dokumentensplit in Chunks plus Overlap. In der Theorie gut, in der Praxis schwierig:

  • Relevante Inhalte verteilen sich häufig über mehrere Seiten.
  • Unterschiedliche Dokumentstrukturen (Artikel, fett/italic Überschriften, uneinheitliche Gliederungen) erschweren sinnvolles, semantisches Chunking.
  • Fixe Chunk-Größen führten zu Teilantworten – gut für Prototypen, nicht für produktionsreife, vollständige Antworten.

RAG blieb also hinter dem Qualitätsziel zurück. Kamenica betont, dass es nicht am Konzept scheiterte, sondern am Aufwand-Nutzen-Verhältnis im konkreten Dokumentenkontext.

Der Wendepunkt: Große Kontextfenster statt komplexes Chunking

Während des Projekts kamen Modelle mit deutlich größeren Kontextfenstern auf den Markt (Kamenica nennt 128.000 Tokens). Damit konnte das Team im Worst Case alle relevanten Dokumente für eine Frage in einen Prompt legen – ohne Chunking. Ergebnis: Komplettantworten auf Basis der gesamten, kontextrelevanten Primärquellen.

Technisch war damit die Grundlage gelegt. Doch es blieb die fachliche Härteprobe: Antworten müssen „wahr“ sein, nur aus den gelieferten Dokumenten gespeist, und sie dürfen sich nicht widersprechen.

Der Knackpunkt: Widersprüche auflösen (Beispiel „Terrorismus“)

Kamenica nennt als realen Stolperstein die „Terrorismus“-Klausel: Ein höherstufiges Dokument (z. B. allgemeine Bedingungen) enthält einen Ausschluss, während produktnahe Dokumente die Deckung nicht ausschließen. Was gilt für die konkrete Konfiguration?

Die Lösung: Dokumente logisch trennen und priorisieren.

  • „Hauptdokumente“: die produktnächsten, speziellsten Unterlagen der konkreten Konfiguration.
  • „Zusatzdokumente“: höherstufige, allgemeinere Dokumente.

Die Prompt-Logik: Zuerst aus Hauptdokumenten antworten; nur bei Widerspruch oder fehlender Information Zusatzdokumente heranziehen. In der Folge war die Terrorismus-Deckung korrekt aufgelöst, ohne den allgemeinen Ausschluss unreflektiert zu übernehmen.

Dieser Schritt war nicht trivial. Wie Kamenica betont, war „Verständnis der Daten“ entscheidend – also das Wissen um Produktarchitektur und Dokumentebenen, um der AI das richtige „Entscheidungsgerüst“ in den Prompt zu geben.

Prompt-Evolution: Vom Markdown-Text zur strukturierten JSON-Antwort

Die Entwicklung begann in einem Jupyter Notebook. Der Ablauf: LLM-Verbindung initialisieren (z. B. GPT-4 mit großem Kontext), Dokumente laden, Prompts iterieren, Ausgabe prüfen – und später in produktionsreife Serverless-Funktionen überführen.

Wichtige Meilensteine der Prompt-Evolution:

  1. Grounding und Wahrheitskriterium:
  • Antworten nur auf Basis der bereitgestellten Informationen.
  • Wenn Information fehlt: „false“ zurückgeben, nicht halluzinieren.
  • Ziel: Modelle sollen Trainingswissen nicht einbringen, sondern strikt auf die Dokumente „geerdet“ bleiben.
  1. Formatierung in Markdown:
  • Zweck: Antworten im Browser schnell prüfbar und visuell ansprechend machen.
  • Ergänzend: Quellenangaben hinzufügen; keine juristischen Verweisschemata („Artikel 1, 2, 3“) in der Antwort; keine einleitenden Texte.
  1. Haupt- vs. Zusatzdokumente:
  • Logik in den Prompt aufnehmen, um Widersprüche gezielt aufzulösen.
  • Das erwies sich als Durchbruch für knifflige Klauseln.
  1. Sprachwahl:
  • Tests in Englisch und Deutsch; Entscheidung für Deutsch, da die Dokumente deutschsprachig sind und die Qualität gefühlt besser passte.
  1. Von Markdown zu JSON:
  • Ziel: Antworten app-seitig strukturiert rendern – nicht Markdown parsen.
  • Vorgehen: Ein Beispiel-JSON vorgeben (Titel, Sections, Subsections, Bullets, „positive/negative“-Flags, Quellen). Das Modell sollte exakt diese Struktur ausfüllen.
  • Wichtige Constraint: „Keine neuen Attribute erfinden.“ Modelle neigen zur Kreativität – die wurde anfangs als Inspiration genutzt, später aber bewusst unterbunden für deterministischere Ausgaben.

Das Ergebnis: Eine robuste JSON-Antwort, die myUNIQA in UI-Komponenten (z. B. Akkordeons, Bulletlisten, Icons) sauber umsetzen kann. Zusätzlich sorgt das „positive/negative“-Flag dafür, dass UI-Signale (Häkchen, Hinweise) konsistent gesetzt werden.

Datenpipeline: Fragenkatalog, Dokumentkombinationen, Antwortgenerierung

Für die Generierung aggregierte das Team die relevanten Kombinationen in einer CSV: Spalten wie Hauptdokumente, Zusatzdokumente, Frage. Die Pipeline:

  • Dokumente laden und in Textform dem Prompt zuführen.
  • Pro Zeile (Frage + Dokumentset) eine Antwort generieren.
  • Antwort validieren und anschließend in eine Datenbank schreiben.

Ein wichtiger operativer Punkt: Latenz. Kamenica nennt 2–3 Minuten pro Antwort – für Live-Chats zu lang, aber für das Offline-Vorberechnen (indirekte AI) tragbar. Genau deshalb ist die Phase-1-Entscheidung (Pre-Compute und Ausliefern) so konsequent.

UI-Rendering: Von JSON zu nutzerfreundlichen Antworten

Die Demo zeigte eine Haushaltsversicherung mit vordefinierten Fragen, z. B. „Welche Risiken sind versichert?“. Die Antwort bestand aus klar gegliederten Sektionen, etwa „Feuer“ oder „Explosion“, jeweils mit Definitionen, Klarstellungen und Beispielen.

Bemerkenswert:

  • Die „positive/negative“-Kennzeichnung steuert die ikonografische Darstellung (z. B. Häkchen bei versicherten Risiken).
  • Akkordeons sorgen für Übersicht bei langen Antworten.
  • Quellen sind ausgewiesen; die Inhalte lassen sich in den Dokumenten nachprüfen.
  • Mehrere Produkte (z. B. Haushalt, Haftpflicht) in einem Bündel werden getrennt navigierbar gemacht – auf jeder Ebene die passenden, personalisierten Antworten.

Die Darstellung ist „visuell ansprechend“ – und bleibt rechtlich sicher, da sie ausschließlich die bereitgestellten Dokumente verdichtet.

Architekturpfad: Notebook zu Serverless – und Cloud als Ermöglicher

Die Entwicklungsreise ging von Jupyter zu produktionsähnlicher Infrastruktur:

  • Prompt- und Evaluationsexperimente in Python/Jupyter.
  • Übergang zu Serverless-Funktionen für reproduzierbare, skalierbare Generierung.
  • Speicherung der Ergebnisse mit Referenzen auf die jeweilige Dokumentkombination.

Kamenica betont die Rolle der Public Cloud (AWS): „Das hat unsere Leben viel einfacher gemacht.“ Ohne aufwändige Vorabfreigaben konnten Services schnell ausprobiert und parallel zur finalen Architektur evaluiert werden.

Qualitätskriterien: Wahrheitsgehalt, Vollständigkeit, Quellen, Konsistenz

Die Lösung adressiert vier zentrale Qualitätsziele:

  • Wahrheitsgehalt: Kein Wissen außerhalb der Dokumente verwenden.
  • Vollständigkeit: Dank großem Kontextfenster alle relevanten Passagen berücksichtigen; keine „Teilantworten“.
  • Quellen: Jede Aussage auf Dokumentquellen zurückführen; Quellen explizit im JSON ausweisen.
  • Konsistenz: Widersprüche zwischen Dokumentebenen deterministisch auflösen (Haupt- vor Zusatzdokumente, definierte Ausnahmen).

Dass diese Kriterien erfüllt werden, war das eigentliche „Produkt“ der Prompt-Evolution – inklusive Formatwechsel zu JSON und feinkörniger Output-Guidelines.

Lessons Learned: Drei prägnante Einsichten

Kamenica fasst die Learnings klar zusammen:

„Running in the public cloud makes it easier to start with general AI.“

  • Die Cloud-Situation (AWS) erleichterte den Start signifikant – Services waren schnell verfügbar, Experimente sofort möglich.

„GenAI is moving really fast. Be open to changes in the approach.“

  • Vom RAG-Ansatz zum Kontextfenster-Paradigma in wenigen Monaten: Das Team passte den Kurs an, als neue Modellfähigkeiten (128k Tokens) verfügbar wurden.

„Understanding your data is crucial.“

  • Ohne tiefes Verständnis der Dokumentarchitektur (Haupt- vs. Zusatzdokumente) wäre das Auflösen von Widersprüchen nicht gelungen.

Was wir als Engineering-Community mitnehmen können

  • Datenverständnis ist nicht optional: Die besten Modelle lösen keine Domänenlogik, wenn sie nicht explizit in den Prompt gegossen wird.
  • Output-Format lohnt sich früh zu durchdenken: Markdown hilft beim schnellen Validieren; für Produktreife ist ein stabiles JSON-Schema mit strikten Constraints überlegen.
  • „Indirekte AI“ ist ein starker erster Schritt: Precompute nimmt Latenzdruck und vereinfacht Qualitätssicherung im regulierten Kontext.
  • Architektur offen halten: Vom Notebook zur Serverless-Pipeline ist ein natürlicher Pfad – besonders, wenn die Cloud-Foundation steht.
  • Modellfähigkeiten aktiv beobachten: Große Kontextfenster können komplexes Retrieval sparen – gerade bei variablen, unstrukturierten Rechtsdokumenten.

Fazit: Ein sauberer, iterativer Pfad zu vertrauenswürdigen Antworten

„GenAI myUNIQA“ zeigt, wie man mit klaren Zielen, datenbasierten Entscheidungen und pragmatischer Architektur echte Kundenschmerzen adressiert. Aleksandar Kamenica und das Technology Exploration Team haben sich von RAG-Experimenten hin zu einer robusten, dokumentwahren JSON-Antwort-Pipeline entwickelt – mit Priorisierungslogik für Dokumentebenen, Quellenangaben, strukturierter Darstellung und produktionsnaher Infrastruktur.

Das Ergebnis sind präzise, personalisierte Antworten in myUNIQA, die juristische Genauigkeit mit Nutzerfreundlichkeit verbinden – und die Basis dafür legen, in weiteren Phasen in Richtung direkter AI-Interaktion zu gehen. Die Story unterstreicht eindrücklich: Geschwindigkeit in der Modellentwicklung ist real – wer Datendomäne und Promptführung im Griff hat, kann sie produktiv für echte Kundenprobleme nutzen.

Weitere Tech Lead Stories

Weitere Dev Stories