Ruling in the world of ML

Die Frage nach der Nutzung des ein oder anderen Modelles ist hochgradig abhängig vom Use Case und von den verschiedenen Faktoren dessen, die bei der Entscheidungsfindung mit einbezogen werden müssen.

Rule Based Engines bieten sich für Problemstellungen mit für den Menschen klar nachvollziehbaren Entscheidungen an, die durch eindeutige Regeln gegeben sind. Hier trägt auch der Vorteil, dass solche Modelle keine Trainingsdaten benötigen und eine hohe Präzision haben. Präzision bezeichnet in diesem statistischen Kontext, dass die von den als Versicherungsbeitrag klassifizierten Transaktionen tatsächlich auch viele tatsächlich Versicherungsbeiträge sind – und eben keine Netflix-Gebühren.

Machine Learning Lösungen hingegen eignen sich für komplexe Probleme ohne eindeutig definierte Regeln und bietet dabei einen hohen Recall. Recall bezeichnet in diesem statistischen Kontext, wie viele der tatsächlichen Versicherungsbeiträge vom Algorithmus auch identifiziert wurden. Je nachdem wohin gehend der Use Case also optimiert werden sollte, sollte die Auswahl entsprechend getroffen werden.

Im Beispiel von Anti-Money-Laundy (AML) Use Cases muss sich die Bank entscheiden, was ihr wichtiger ist: Jeden AML Fall zu erkennen und dabei Gefahr laufen Kunden zu Unrecht zu beschuldigen und eventuell zu verlieren (hoher recall) – oder soll das Modell möglichst nur echte Betrugsfälle markieren, mit der Gefahr tatsächliche Fälle zu übersehen (hohe Präzision).

Der Tradeoff zwischen Präzision und Recall ist aber nicht die einzige Entscheidungsdimension. Zusätzlich gilt es, die Frequenz und Intensität von Data Drift zu beleuchten. Je schneller und stärker sich die Daten verändern, desto mehr kontinuierlichen Anpassungsbedarf bringen RBEs mit sich. Die fortlaufende Analyse und Anpassung der Regelwerke kann unserer Erfahrung nach bei ~5.000 Regeln auch schnell 1-2 FTE beschäftigen. Je nach gehobenen Effizienzen und Prozesskosten kann sich das lohnen, muss aber berücksichtigt werden. Der Vorteil von ML-Modellen ist, dass sie deutlich besser mit verfügbaren AI-umgebungen wie Vertex AI automatisiert werden können und sich selbst auf Basis von Data Drifts optimieren. Herausforderung daran ist aber natürlich, dass dafür deutlich mehr Erfahrung im Setup von ML Ops nötig wird und entsprechende Experten häufig nur begrenzt zur Verfügung stehen. Zusätzlich kann ein ML-Modell nur begrenzt mit extremen Veränderungen der Daten umgehen, sondern zeigt seine Stärke vor allem in kontinuierlichen Data Drifts. Welchem Ausmaß an Data Drift ein Use Case unterliegt sowie die strategische Abwägung der Betriebsherausforderungen sollte daher also auch in der Modellwahl eine Rolle spielen.

Zusätzlich ist noch entscheidender Faktor, ob überhaupt genügend Trainingsdaten vorhanden sind. ML-Modelle benötigen eine große Menge an Trainingsdaten, die für die Modellerstellung verwendet werden. Die Produktion entsprechender, validierter Trainingsdaten ist ein zeitaufwendiger Prozess, der in der Entscheidung berücksichtigt werden muss.

Zuletzt können sich die Anforderungen an das Modell auch mit der Zeit ändern, sodass ein Wechsel sinnvoll werden kann. In einem Kunden Use Case wurde ursprünglich eine RBE eingesetzt zur Klassifikation von Transaktionen. Damit konnte bereits ein F1-Score von 91% erreicht werden. Mit geänderten Anforderungen aus dem Management (>95% Anspruch) war eine RBE nicht mehr das Mittel der Wahl und auf Basis eines ML-Modells mit BERT konnte der F1-Score auf 96% gesteigert werden.

In der Praxis ist es schwer vermittelbar und noch schwieriger, aus dem Senior Management eine Entscheidung für die ein- oder andere Richtung zu erhalten. Standardmäßig wird sowohl eine hohe Präzision wie auch ein hoher Recall gefordert. Nun stellt sich also die Frage, wie man sich dieser Forderung annähert.

Eine Möglichkeit ist ein doppelter Aufbau: Zuerst läuft ein ML Modell, welches die Ergebnisse vorsortiert. Anschließend wendet eine RBE die Businesslogik an und überstimmt das ML-Modell, um die Präzision zu erhöhen.

Wurde sich ursprünglich für eine RBE entschieden, besteht die Gefahr, dass mit der Zeit höhere Erkennungsraten angestrebt werden und immer mehr Edge Case mit Regeln abgebildet werden müssten. Das Problem ist, dass die Anzahl notwendiger Regeln exponentiell zunimmt. Deutlich wird dies am Beispiel eines Merchant Taggers, den wir für einen Kunden entwickelt haben. Dieser erkannte auf Basis der Counterparty die dahinter liegende Firma. In einem MVP Use Case konnten wir mit ungefähr 730 Regeln ca. 2/3 der Transaktionen einem Merchant zuordnen. Für jedes weitere Prozent hätten wir exponentiell wachsend mehr Regeln benötigen, um auch die kleinen Firmen abzudecken.

In diesem Fall wurde vom Kunden auf Empfehlung hin entschieden, eine Modellkaskade aufzusetzen. Alle Fälle, die nicht vom RBE identifiziert wurden, sind durch ein zusätzliches ML Modell gelaufen, welches auch zusätzliche Daten wie Geo- und Brancheninformationen mitverwertet hat. So konnte die Abdeckung von etwa 66% auf 80% gesteigert werden. Solche Modellkaskaden sind aber natürlich deutlich Intensiver im Aufbau und der Instandhaltung und es ist immer fallabhängig zu entscheiden, ob ein solcher zusätzlicher Aufklärungsanteil die Investition rechtfertigt.

Auch unter Berücksichtigung sich ändernder Anforderungen ist doch unser Fazit aus vielen erfolgreich umgesetzten Use Cases, dass RBEs häufig eine sehr gute Lösung sind. Natürlich sind fallspezifisch andere Faktoren zugunsten von ML-Modellen höher zu gewichten, ML-Modelle sind aber nicht blind der Best-in-Class Ansatz für Automatisierungen.