HDI Global baut sich eigene generative KI – Hintergund-Interview mit Willi Weber, Head of Data Analytics

Mehrwert schaffen durch künstliche Intelligenz (KI) liegt derzeit voll im Trend. Die HDI nutzt KI schon seit langen – jetzt aber geht das Unternehmen einen Schritt weiter: Mit einer eigenen hauseigenen KI. Per generativer KI-Lösung HDI-GPT gewinnt die HDI Informationen aus unstrukturierten Daten in Text- oder Bildform. 

Per HDI-GPT hat das Unternehmen die Möglichkeit geschaffen, in Echtzeit Erkenntnisse aus unstrukturierten Daten in Text- oder Bildform zu gewinnen, um den HDI-Global-Mitarbeitern unterstützend zur Seite zu stehen. Schon jetzt würden sich deutliche Vorteile für Kunden und Mitarbeiter abzeichnen, so HDI Global (Website). Besonders falle die Zeitersparnis durch optimierte Prozesse unter Beachtung geltender Datenschutz- und Compliance-Vorgaben auf. Doch das sei erst der Anfang. Um das volle Potenzial der Technologie systematisch zu erkunden und nachhaltig einzuführen, hat der Industrieversicherer eine Transformationsstrategie entwickelt.

Mit HDI-GPT setzen wir erstmals auf generative KI zur Transformation der Kernversicherungsprozesse und zur Optimierung von Workflows. Für uns ist elementar, dass es um Optimierungen, nicht aber um Automatisierungen geht. Der „Human in the Loop“ ist beim verantwortungsvollen Umgang mit generativer KI und unserem Anspruch, Kunden maßgeschneiderte Lösungen zu bieten, nicht wegzudenken. Ziel ist, die Technologie perspektivisch dort als Co-Pilot einzusetzen, wo sie sich als zielführend zur Verbesserung und Beschleunigung von datenbasierten Prozessen erweist und eine effizientere Steuerung des Geschäfts ermöglicht.“

Dr. Thomas Kuhnt, Chief Operating Officer der HDI Global SE

Willi Weber, Head of Data Analytics bei HDI Global, hat uns ein wenig tiefer in den KI-Kaninchenbau mitgenommen:

Herr Weber, wenn Sie von GPT sprechen – meinen Sie damit die neuen GPTs, die in ChatGPT bereitgestellt werden? 

Wir meinen damit einen eigenen ChatBot mit ähnlichem Funktionsumfang wie ChatGPT. Bereitgestellt in einer sicheren und datenschutz- und sicherheits-konformen Umgebung. Das Verwendete Modell ist GPT.

Oder nutzen Sie etwas anderes? Ein anderes LLM?

Nein, nicht als Foundational Modell und ausführendes LLM – GPT. Für individuelle Cases kommen andere Modelle und natürlich auch andere Embedding-Modelle zum Tragen.

Wie ist es angebunden – und an welche Systeme?

Dies ist abhängig vom UseCase. Der konventionelle ChatBot ist losgelöst von zusätzlichen Datenquellen und bietet lediglich einen Zugriff auf das reine Sprachmodel. Dies ist quasi für einen general day-to-day purpose installiert.

Individuelle Use Cases verwenden eine aufwändigere Infrastruktur, welche auf unterschiedliche Datenquellen Zugriff hat. Das können Policen-Texte, Schadensbeschreibungen, Arbeitsanweisungen oder generelle Informationen über versicherungsspezifische Deckungen sein.

Diese werden dann für die individuellen Cases entsprechend mit RAG-Technologien (Parser, Embeddings und Vektordatenbanken) verarbeitet und mit dem Sprachmodell kombiniert. Diese Bots sind oftmals keine ChatBots, sondern Engines die einzelne Prompts ohne Conversational Interaktion verarbeiten. Diese sind als APIs in umliegende Prozesse integriert und augmentieren so die Workflows der Nutzer. Beispielsweise durch Informationen über bestimmte Arbeitsanweisungen oder eine gedraftete E-Mail mit passenden Antworten zu Fragen zu bestimmten Deckungen.

Woher kommen die HDI-Daten? Haben Sie die extra aufbereitet?

Sowohl aus internen Datenquellen als auch für die Anreicherungen aus externen Datenquellen.

Ja, die Daten müssen in der Regel aufwändig für einen effektiven Einsatz aufbereitet werden. Besonders Dateiformate wie PDFs sind aufwändig vorzubereiten, da diese unstrukturierten Daten halten. In der Regel sammelt man die Informationen, bringt sie in ein flaches Textformat und lässt dann sogenannte Embeddings (Vektor-Repräsentation der semantischen Inhalte einzelner Dokumente oder Teile/Chunks dieser) durch ein weiteres Embedding-Sprachmodell generieren, die dann in dafür spezialisierten Datenbanken (Vektordatenbanken) gespeichert werden.

Dies ist einer der Prozessschritte, der am aufwändigsten bei der Implementierung solcher individuellen UseCases ist.

Mit RAG ist man dann aber in der Lage, einen Prompt, der ebenfalls embedded, wurde semantisch mit einzelnen Daten-Embeddings abzugleichen und so relevante Informationen zu identifizieren, die dann durch das LLM verarbeitet werden können.

Wie stellen Sie sicher, dass die Informationen vom KI-Dienstleister compliant behandelt werden?

Die Gesamten UseCases und auch der proprietäre ChatBot laufen in privaten Cloud-Instanzen, die allen regulatorischen und sicherheitsrelevanten Voraussetzungen und Standards entsprechen. Entsprechende Agreements und vertragliche Vereinbarungen stellen dies sicher. Der Cloud-Anbieter hat keinen Zugriff auf die internen Daten, und das verwendete Sprachmodel wird direkt verwendet ohne vorgelagerten externen Chatbot, wie es beispielsweise bei ChatGPT der Fall ist.

Was für Hardware setzen Sie dafür ein?

Private Cloud-Instanzen.

Wie äußern sich die Ergebnisse in der Praxis? Was bekommen die Angestellten mit? Wie nutzen die es?

Die UseCases sind transparent, dem User ist bewusst, das dieser mit einem Sprachmodell interagiert oder Teile seines Prozesses durch Erkenntnisse eines Sprachmodells generiert und augmentiert wird. Wir setzen auf starke Awareness für das Thema, um den Mitarbeitern auch die Limitierungen bewusst zu machen und gute Methodiken an die Hand zu geben, effektiv mit dem Chatbot zu interagieren. Bei den UseCases mit internen Daten setzten wir auf das Konzept „Human in the Loop“, was bedeutet das die Ergebnisse nur Mitarbeitern bereitgestellt werden, die die Ergebnisse auch qualitativ evaluieren können. Es gib die goldene Regel, wonach mit derartigem System nichts gemacht werden sollte, was man nicht selbst mit ausstreichend Kapazitäten erledigen könnte.

Wie schafft man es, einer KI die aktuellen Prozesse beizubringen, um Verbesserungsvorschläge herauszubekommen?

Die UseCases werden, bevor sie in den Piloten für größere Anwendergruppen gehen, ausgiebig mit unterschiedlichen Stakeholdern verprobt und getestet. Unterschiedliche Evaluierungsstrategien kommen dabei zum Tragen. Beispielsweise der Abgleich mit Referenzantworten oder automatisierte wiederholte Requests, bei denen dann die unterschiedlichen Ergebnisse auf semantische Ähnlichkeit geprüft werden.

Der Testaufwand für LLM Cases ist weit höher und aufwändiger als bei prädikativer KI oder generell analytischen UseCases, da das Modell eben nicht deterministisch reagiert.

Halluzination ist seit GPT4.0 wesentlich unkritischer geworden, da das Model dahingehend verändert wurde, weniger Kreativität zuzulassen und früher zu retournieren, wenn keine qualitativ gesicherten Antworten generiert werden können.

Bei den internen Cases wird viel durch die Implementierung der RAG-Systeme geregelt. Findet man beispielsweise keine ausreichend passenden Informationen in den internen Daten, die semantisch zum User-Prompt passen, wird das mitgeteilt. Das Sprachmodell wird dann gar nicht angefragt.

Die UseCases sind sehr unterschiedlich und in der Regel mit umfangreicher Businesslogik versehen, die das Modell steuert, im Zweifell unterschiedliche und mehrere Request an das Modell tätigt und die RAG-Zugriffe verschiedener Methodiken verwendet, um passende Informationen zu extrahieren, um dann an das Modell zu übergeben.

Herr Weber – vielen herzlichen Dank für den Einblick.aj