Ich habe in den letzten etwa sechs Monaten ein System zur Betrugsbekämpfung (betrügerische Aktivitäten, Betrug usw.) erstellt, ohne dass hierfür eine anfängliche Infrastruktur vorhanden war. Die heutigen Ideen, die wir gefunden und in unserem System implementiert haben, helfen uns, viele betrügerische Aktivitäten zu erkennen und zu analysieren. In diesem Artikel möchte ich über die Prinzipien sprechen, denen wir gefolgt sind, und darüber, was wir getan haben, um den aktuellen Stand unseres Systems zu erreichen, ohne auf den technischen Teil einzugehen.
Prinzipien unseres Systems
Wenn Sie Begriffe wie „automatisch“ und „Betrug“ hören, denken Sie höchstwahrscheinlich an maschinelles Lernen, Apache Spark, Hadoop, Python, Airflow und andere Technologien aus dem Apache Foundation-Ökosystem und dem Bereich Data Science. Ich denke, es gibt einen Aspekt bei der Verwendung dieser Tools, der normalerweise nicht erwähnt wird: Sie erfordern bestimmte Voraussetzungen in Ihrem Unternehmenssystem, bevor Sie sie verwenden können. Kurz gesagt, Sie benötigen eine Unternehmensdatenplattform, die einen Data Lake und ein Warehouse umfasst. Aber was ist, wenn Sie nicht über eine solche Plattform verfügen und diese Praxis dennoch weiterentwickeln müssen? Die folgenden Prinzipien, die ich weiter unten teile, haben uns geholfen, einen Punkt zu erreichen, an dem wir uns auf die Verbesserung unserer Ideen konzentrieren können, anstatt eine zu finden, die funktioniert. Dies ist jedoch kein Projektplateau. Aus technologischer und produkttechnischer Sicht ist noch einiges auf dem Plan.
Prinzip 1: Geschäftswert zuerst
Bei all unseren Bemühungen steht der „Geschäftswert“ im Vordergrund. Generell gehört jedes automatische Analysesystem zur Gruppe der komplexen Systeme mit hohem Automatisierungsgrad und technischer Komplexität. Die Erstellung einer vollständigen Lösung wird viel Zeit in Anspruch nehmen, wenn Sie sie von Grund auf neu erstellen. Wir haben uns entschieden, den geschäftlichen Nutzen an erster Stelle und die technologische Vollständigkeit an zweiter Stelle zu setzen. Im wirklichen Leben bedeutet dies, dass wir fortschrittliche Technologie nicht als Dogma akzeptieren. Wir wählen die Technologie, die für uns im Moment am besten funktioniert. Im Laufe der Zeit könnte es so aussehen, als müssten wir einige Module neu implementieren. Dies ist der Kompromiss, den wir akzeptiert haben.
Prinzip 2: Erweiterte Intelligenz
Ich wette, die meisten Leute, die sich nicht intensiv mit der Entwicklung von Lösungen für maschinelles Lernen beschäftigen, denken vielleicht, dass das Ziel darin besteht, den Menschen zu ersetzen. Tatsächlich sind Lösungen für maschinelles Lernen noch lange nicht perfekt und nur in bestimmten Bereichen ist ein Ersatz möglich. Wir haben diese Idee aus mehreren Gründen von Anfang an abgelehnt: unausgewogene Daten zu betrügerischen Aktivitäten und die Unfähigkeit, eine umfassende Liste von Funktionen für Modelle für maschinelles Lernen bereitzustellen. Im Gegensatz dazu haben wir uns für die Option „Enhanced Intelligence“ entschieden. Hierbei handelt es sich um ein alternatives Konzept der künstlichen Intelligenz, das sich auf die unterstützende Rolle der KI konzentriert und die Tatsache betont, dass kognitive Technologien die menschliche Intelligenz verbessern und nicht ersetzen sollen. [1]
Vor diesem Hintergrund wäre die Entwicklung einer vollständigen Lösung für maschinelles Lernen von Anfang an mit einem enormen Aufwand verbunden, der die Wertschöpfung für unser Unternehmen verzögern würde. Wir haben uns entschieden, unter Anleitung unserer Fachexperten ein System mit einem iterativ wachsenden Aspekt des maschinellen Lernens aufzubauen. Die Herausforderung bei der Entwicklung eines solchen Systems besteht darin, dass es unseren Analysten nicht nur Fälle im Hinblick darauf liefern muss, ob es sich um betrügerische Aktivitäten handelt oder nicht. Im Allgemeinen ist jede Anomalie im Kundenverhalten ein Verdachtsfall, den Spezialisten untersuchen und irgendwie reagieren müssen. Nur ein Bruchteil dieser gemeldeten Fälle kann tatsächlich als Betrug eingestuft werden.
Prinzip 3: Rich Analytics Platform
Der anspruchsvollste Teil unseres Systems ist die End-to-End-Überprüfung des Systemworkflows. Analysten und Entwickler sollten problemlos historische Datensätze mit allen für die Analyse verwendeten Metriken erhalten. Darüber hinaus sollte die Datenplattform eine einfache Möglichkeit bieten, einen bestehenden Satz von Metriken durch neue zu ergänzen. Die von uns erstellten Prozesse, und dabei handelt es sich nicht nur um Softwareprozesse, sollten es uns ermöglichen, frühere Zeiträume einfach neu zu berechnen, neue Metriken hinzuzufügen und die Datenprognose zu ändern. Dies könnten wir erreichen, indem wir alle Daten sammeln, die unser Produktionssystem generiert. In diesem Fall würden die Daten nach und nach zu einem Ärgernis werden. Wir müssten eine wachsende Menge an Daten, die wir nicht nutzen, speichern und schützen. In einem solchen Szenario werden Daten im Laufe der Zeit immer irrelevanter, erfordern aber dennoch unsere Bemühungen, sie zu verwalten. Für uns machte das Horten von Daten keinen Sinn, also haben wir uns für einen anderen Ansatz entschieden. Wir haben beschlossen, Echtzeit-Datenspeicher rund um die Zielentitäten zu organisieren, die wir klassifizieren möchten, und nur die Daten zu speichern, die es uns ermöglichen, die aktuellsten und relevantesten Zeiträume zu überprüfen. Die Herausforderung bei diesem Vorhaben besteht darin, dass unser System heterogen ist und über mehrere Datenspeicher und Softwaremodule verfügt, die eine sorgfältige Planung erfordern, um konsistent zu funktionieren.
Designkonzepte unseres Systems
Wir haben vier Hauptkomponenten in unserem System: Erfassungssystem, Berechnungssystem, BI-Analyse und Tracking-System. Sie dienen bestimmten, isolierten Zwecken, und wir halten sie isoliert, indem wir bestimmte Designansätze verfolgen.
Vertragsbasiertes Design
Zunächst haben wir uns darauf geeinigt, dass Komponenten nur auf bestimmte Datenstrukturen (Verträge) angewiesen sein sollten, die zwischen ihnen weitergegeben werden. Dies erleichtert die Integration zwischen ihnen und erfordert keine bestimmte Zusammensetzung (und Reihenfolge) der Komponenten. In einigen Fällen ist es uns beispielsweise möglich, das Einlasssystem direkt in das Alarmverfolgungssystem zu integrieren. Dies erfolgt in einem solchen Fall nach Maßgabe des vereinbarten Alarmierungsvertrages. Das bedeutet, dass beide Komponenten über einen Vertrag integriert werden, den jede andere Komponente nutzen kann. Wir werden keinen zusätzlichen Vertrag hinzufügen, um vom Eingabesystem aus Warnungen zum Tracking-System hinzuzufügen. Dieser Ansatz erfordert die Verwendung einer vorgegebenen Mindestanzahl von Verträgen und vereinfacht das System und die Kommunikation. Im Wesentlichen verfolgen wir einen Ansatz namens „Contract First Design“ und wenden ihn auf Streaming-Verträge an. [2]
Überall streamen
Das Speichern und Verwalten des Zustands in einem System führt unweigerlich zu Komplikationen bei seiner Implementierung. Im Allgemeinen sollte der Zustand von jeder Komponente aus zugänglich sein, er sollte konsistent sein und über alle Komponenten hinweg den aktuellsten Wert liefern und er sollte mit den richtigen Werten zuverlässig sein. Darüber hinaus erhöhen Aufrufe an persistenten Speicher zum Abrufen des neuesten Status die Anzahl der E/A-Vorgänge und die Komplexität der in unseren Echtzeit-Pipelines verwendeten Algorithmen. Aus diesem Grund haben wir uns entschieden, die Zustandsspeicherung möglichst vollständig aus unserem System zu entfernen. Dieser Ansatz erfordert, dass alle notwendigen Daten im übertragenen Datenblock (Nachricht) enthalten sind. Wenn wir beispielsweise die Gesamtzahl einiger Beobachtungen (die Anzahl der Operationen oder Fälle mit bestimmten Merkmalen) berechnen müssen, berechnen wir sie im Speicher und generieren einen Strom solcher Werte. Abhängige Module verwenden Partitionierung und Stapelverarbeitung, um den Stream in Einheiten aufzuteilen und mit den neuesten Werten zu arbeiten. Dieser Ansatz machte einen dauerhaften Festplattenspeicher für solche Daten überflüssig. Unser System verwendet Kafka als Nachrichtenbroker und kann mit KSQL als Datenbank verwendet werden. [3] Aber die Verwendung hätte unsere Lösung stark an Kafka gebunden, und wir haben uns entschieden, es nicht zu verwenden. Der von uns gewählte Ansatz ermöglicht es uns, Kafka ohne größere interne Änderungen am System durch einen anderen Nachrichtenbroker zu ersetzen.
Dieses Konzept bedeutet nicht, dass wir keine Festplattenspeicher und Datenbanken verwenden. Um die Systemleistung zu testen und zu analysieren, müssen wir eine erhebliche Datenmenge auf der Festplatte speichern, die verschiedene Metriken und Zustände darstellt. Der wichtige Punkt hierbei ist, dass Echtzeitalgorithmen nicht auf solche Daten angewiesen sind. In den meisten Fällen verwenden wir die gespeicherten Daten zur Offline-Analyse, Fehlerbehebung und Verfolgung spezifischer Fälle und Ergebnisse, die das System erzeugt.
Probleme unseres Systems
Es gibt bestimmte Probleme, die wir bis zu einem gewissen Grad gelöst haben, aber sie erfordern durchdachtere Lösungen. Jetzt möchte ich sie hier nur erwähnen, denn jeder Punkt ist einen eigenen Artikel wert.
- Wir müssen noch Prozesse und Richtlinien definieren, die die Sammlung aussagekräftiger und relevanter Daten für unsere automatisierte Datenanalyse, -ermittlung und -exploration unterstützen.
- Einbeziehung menschlicher Analyseergebnisse in den Prozess der automatischen Einrichtung des Systems, um es mit den neuesten Daten zu aktualisieren. Dadurch aktualisieren wir nicht nur unser Modell, sondern aktualisieren auch unsere Prozesse und verbessern unser Verständnis unserer Daten.
- Finden eines Gleichgewichts zwischen dem deterministischen Ansatz von IF-ELSE und ML. Jemand sagte: „ML ist ein Werkzeug für Verzweifelte.“ Das bedeutet, dass Sie ML nutzen möchten, wenn Sie nicht mehr wissen, wie Sie Ihre Algorithmen optimieren und verbessern können. Andererseits ermöglicht der deterministische Ansatz nicht die Erkennung von Anomalien, die nicht vorhergesehen wurden.
- Wir brauchen eine einfache Möglichkeit, unsere Hypothesen oder Korrelationen zwischen Metriken in den Daten zu testen.
- Das System muss mehrere Ebenen wirklich positiver Ergebnisse aufweisen. Betrugsfälle machen nur einen Bruchteil aller Fälle aus, die als positiv für das System gewertet werden können. Analysten möchten beispielsweise alle verdächtigen Fälle zur Überprüfung erhalten, und nur ein kleiner Teil davon ist Betrug. Das System muss den Analysten alle Fälle effizient präsentieren, unabhängig davon, ob es sich um tatsächlichen Betrug oder nur um verdächtiges Verhalten handelt.
- Die Datenplattform sollte in der Lage sein, historische Datensätze mit im laufenden Betrieb generierten und berechneten Berechnungen abzurufen.
- Stellen Sie beliebige Systemkomponenten einfach und automatisch in mindestens drei verschiedenen Umgebungen bereit: Produktion, experimentell (Beta) und für Entwickler.
- Zuguterletzt. Wir müssen eine umfassende Leistungstestplattform aufbauen, auf der wir unsere Modelle analysieren können. [4]
Referenzen
Source: habr.com