- Data analytics
Vom Lab zur Factory: Was Betreiber von KI-Ökosystemen beachten sollten
- •
- Kristina Schreiber
– ABSTRACT
KI-Factories agieren als Betriebsplattformen
Wie exotisch sind KI-Ökosysteme im Banken- und Versicherungsumfeld tatsächlich?
Thomas Löchte: Viele Banken und Versicherungen haben bereits Use Cases mit Künstlicher Intelligenz umgesetzt – etwa bei Schadenregulierung, Customer Analytics oder zur Verbesserung der Dunkelverarbeitung. Es entstanden Algorithmen für neue Geschäftsmodelle. Allerdings ist vieles im Experimentierstadium, dem „Lab“, hängengeblieben und wurde noch nicht produktiv in die „Factory“ eingebracht (siehe Grafik).
Womit steht und fällt der Erfolg einer KI-Factory bzw. einer Plattform, die mehrere KI betreibt?
Ali Rahimi: Sie benötigen Use Cases, die strategische Ziele anpeilen, etwa den Planungsstand einer KI-Initiative in den nächsten fünf Jahren. Und Sie müssen Ihre Datenlage überblicken: Welche Informationen befinden sich bereits in den Datenbeständen? Welche Zielvariablen helfen, Marketing- oder Risikofragen zu beantworten? Wie lässt sich Wissen schöpfen? Im Lab erproben wir, ob ein Use Case funktioniert. Wir experimentieren mit Technologien und Daten und leiten einen Business-Case ab.
Löchte: Ist der Business Case positiv, wird die produktive Nutzung in einer Factory eingeleitet: In der Factory betreiben Sie Lösungen, monitoren Prognosemodelle, deren Performance und Kennzahlen.
Rahimi: Zwischen Lab und Factory sehe ich die laufende Entwicklung sogar als Zwischenstufe: Künstliche Intelligenz weist im Anfangsstadium Laborcharakter auf. Datenmodelle ändern sich kontinuierlich und müssen immer wieder an die Realität angepasst werden. Laufen die Modelle über Docker oder Kubernetes erst einmal produktiv, kommt es nicht nur zu millionenfachen Requests und durch Integrationen zu massenhaften Datenzulieferungen. Die Modelle lassen sich vor allem nur noch aufwändig retrainieren. Wie bei jeder „lebenden“ Software helfen im kontinuierlichen Verbesserungs-Prozess Machine-Learning-Operations-Ansätze – MLOps – wie MLFlow oder Kubeflow. *
Löchte: Ob ich im Labor oder in der Factory optimiere, darüber streiten sich die Experten bis heute. Ich unterscheide einerseits gern zwischen der Laborsituation, die – übrigens schnell – mit neuen Themen experimentieren kann, und der „IT- Fabrikhalle“ andererseits: In der Factory arbeiten im Idealfall unterschiedliche KI im sicheren und skalierbaren Betrieb.
Die Herausforderungen sind mit Sicherheit mannigfaltig ...
Löchte: Genau. Wer den Change begleitet, muss diese Modelle nicht nur technisch einbinden, sondern den Change auch bei der Nutzung begleiten. Nur so lassen sich Customer-Analytics-Daten, die ansonsten in Fachabteilungen zu versanden drohen, auch übergreifend einsetzen. Spartenübergreifende Kaufwahrscheinlichkeiten sind intensiver nutzbar und valide Daten tragen zu mehr Effizienz im Sales-Bereich bei.
Stephan Roth: Mit SAP Hana sind – etwa für die Vertriebssteuerung auf In- und Exkasso-Daten – Realtime-Auswertungen möglich, die zuvor nur aufwändig zu berechnen waren. Chancen liegen jedenfalls darin, Produkte auf Basis von Wissen innovativer zu gestalten. Bezogen auf die Kernsysteme von Versicherungen lassen sich hierzu SAP-Tools und -Produkte sinnvoll ergänzen
Welche Anforderungen, Dos und Don’ts kommen Data-Analytics-seitig auf Banken und Versicherungen zu?
Apropos Veränderungen ...
Rahimi: Das Fahrverhalten etwa ändert sich über die Jahre, die Modelle müssen also an diese Veränderungen angepasst werden, um dauerhaft richtige Ergebnisse zu liefern.
Löchte: Fatal ist, dass sich Fehler oft langsam und fast unbemerkt festsetzen und Modelle schleichend degenerieren können.
Stichwort Lernen als wichtige KI-Aufgabe. Welche Rolle spielt hier Transfer Learning? Und wie weit ist der Markt?
Der Proof of Concept markiert die Nahtstelle vom Lab zur Factory:
Ein Prototyp wird innerhalb einer übergreifenden KI-Lösung entwickelt, produktiv gesetzt und im Idealfall immer wieder geprüft.
Wenn mehr solcher Use Cases entstehen: Was empfehlen Sie beim Verwalten unterschiedlicher KI-Lösungen innerhalb einer Factory?
Löchte: Ich rate erstens zu einem Use-Case-Management, das bereits im Labor Ideen bewertet. Es untersucht, inwieweit sich aus Daten verwertbares Wissen im Sinne der Unternehmensstrategie und der Ableitung von Handlungsfeldern generieren lässt. Zweitens müssen Sie den Bereich und die Expertise von Data Science inhouse aufbauen. Drittens sollte der Datenzugriff zum Sammeln und Aufbereiten von Informationen einfach gestaltet sein – etwa durch Datalake-Lösungen –, die Rohdaten zur Verfügung stellen.
Rahimi: Zwar sitzen Versicherungen auf enormen Datenschätzen. Dennoch und viertens kommen auch sie nicht umhin, externe Datentöpfe in ihre Berechnungen einfließen zu lassen: etwa statistische Informationen zu Sterblichkeit, Geburten, Wetter und Entwicklung an den Finanzmärkten. Außerdem Daten zu Regionalität, Bebauungsstrukturen, Gartenanteil und viele Datenpunkte mehr. Ganzheitliche Integrationsplattformen, die neben Bestandsinformationen auch Social-Media-Daten, Geoinformationen und weitere externe Daten in ihrer Factory nahezu in Echtzeit verfüg- und verarbeitbar machen, sind ein weiterer Erfolgsfaktor.
Roth: In- und externe Daten helfen einzukreisen, wo Konsumenten mit Kundenpotenzial wohnen, wo Versicherer mit Stürmen und erhöhten Gefahren durch Umweltkatastrophen rechnen müssen und wo besondere Produkte aufgrund aktueller Gegebenheiten möglich sind. Außenstände im Zahlungsverkehr lassen sich gut visualisieren; Institute bleiben handlungsfähig. Richtig interessant wird es, wenn Banken und Versicherer prognostizieren, welche individuellen Bedürfnisse bei der Behandlung von Außenständen notwendig sind.
Welchen Lösungsansätze helfen dabei, KI-Anwendungen in einer Factory zu betreiben?
Und im zweiten Schritt?
Löchte: Alle Banken und Versicherer wollen ihre KI-Herausforderungen für ihre spezifischen Anforderungen skalieren. KI-Lösungen auf Legacy-Systemen aufzusetzen, ist jedoch aufwändiger.
Roth: Zudem können Sie keine Echtzeitdaten mit einem alten Host verarbeiten, der Batch-basiert ist. Befinden sich obendrein mehrere Systeme im Haus, bremst eine Stapelverarbeitung die Arbeitssteuerung weiter aus.
Löchte: Der Markt bietet verschiedene Ansätze, um erprobte Datenmodelle etwa als Workflow- oder Container-basierte Plattformen (siehe Tabelle) zu betreiben: Die Programmierung in Python oder R wird zum Beispiel auf einer KI-Plattform in Container gepackt und produktiv gesetzt. Wir arbeiten aber auch gern mit Lösungen, die grafische Oberflächen bereitstellen, etwa Microsoft ML Studio oder DataIku. Sie können damit auf Plattformen in Echtzeit viele KI-Modelle abbilden und, etwa im Inkassoprozess, immer den „Next best Action“ anzeigen. Die Zukunftschancen dieser Ansätze sind enorm. Es gilt, die für das Unternehmen passenden Use Cases zu finden und diejenigen Technologien einzusetzen, welche die Mitarbeiter beherrschen. So kann immer mehr Business-Potenzial genutzt werden.
Lösungen | Vorteile | Nachteile |
Stand-alone-Lösungen suchen nach dem besten Algorithmus bzw. Prognosemodell: | Gut für Modellauswahl und Optimierung einsetzbar | Unterstützt Datenaufbereitung und Feature Engineering nur rudimentär |
Einfacher Zugang auch durch Cloud-Lösungen | Reine Prognosemodelle für Supervised ML, keine Apps etc. | |
Code und UI kann genutzt werden | Hält Marketingversprechen nicht ein: Data Scientists werden weiterhin benötigt | |
Workflow-basierte Plattformen bieten den Anwendern neben der Möglichkeit zur Programmierung auch grafische Oberflächen – etwa um Prozesse zu modellieren. So adressieren sie eine größere Anwenderbandbreite: | Gute Unterstützung des gesamten Entwicklungs-Workflow | Vendor-Lock-in bei manchen Plattform-Angeboten |
Grafische Entwicklung möglich, Programmierkenntnisse nicht zwingend erforderlich | Akzeptanz bei programmiernahen Data Scientists gering | |
Containerisierung und Anbindung an Computercluster möglich (teilweise) | Spezielle Anforderungen nicht immer umsetzbar | |
Gute Kollaboration zwischen den Beteiligten | ||
Container-basierte Lösungen bieten meist klassische Code-Entwicklungsansätze mit Cloud-Fokus. Produktivsetzungen erfolgen über Git oder andere Versionsverwaltungen und Container-Bildung zum Übertrag in die entsprechenden Systemumgebungen. Ursprünglich stammt dieser Ansatz aus der klassischen Software-Entwicklung. Das zergliederte Verpacken einer KI-Anwendung in mehrere Container (Modularisierung bis auf Modellebene) hilft den Betrieb für die IT zu erleichtern: | Hohe Flexibilität durch maßgeschneiderten Tool Stack | Eigenleistungen (evtl. Software-Entwicklung) für Plattformaufbau notwendig (kein SaaS) |
Gute Integration in bestehende Infrastruktur | Heterogenität erfordert mehr Expertenwissen für Infrastruktur und Lösungen | |
Lose Kopplung der Komponenten vermindert Technologie-Risiken | Wartung der Lösungen kann umfangreicher ausfallen (aufgrund der Heterogenität) | |
Gute Integration mit bestehenden CI-/CD- und Change-Prozessen |
Fußnoten
- Machine-Learning-Operations-Ansätze: https://github.com/mlflow/mlflow bzw. https://github.com/kubeflow
- Vortrainierte KI: kostenlos etwa bei https://huggingface.co/models oder kostenpflichtig u.a. bei Azure (https://azure.microsoft.com/en-us/services/cognitive-services/#features) oder AWS Marketplace (https://aws.amazon.com/marketplace/solutions/machine-learning/pre-trained-models)
So funktioniert der Betrieb von KI-Ökosystemen. Das Interview und die Tabelle können Sie hier als PDF downloaden. Die Inhalte sind als Gastbeitrag im Sapport Magazin 06/21 erschienen.
Ansprechpartner
Ali Rahimi
Chief Product Owner
Dock Finsure Integration
info-finsure@ikor.one
+49 40 8199442-0
Thomas Löchte
Geschäftsführer
Informationsfabrik GmbH
communications@ikor.one
+49 251 9199790
Stephan Roth
Chief Product Owner
Dock Assurance
assurance@ikor.one
+49 40 8199442-0
Kristina Schreiber
Communications Manager
Anchor Circle Governance
communications@ikor.one
+49 40 8199442-0
