🥇Entwicklung eines automatischen Systems zur Bekämpfung von Betrügern auf der Website

In den letzten etwa sechs Monaten habe ich an der Entwicklung eines Systems zur Bekämpfung von Betrug (betrügerische Aktivitäten, Betrug usw.) ohne jegliche Ausgangsinfrastruktur gearbeitet. Die heutigen Ideen, die wir gefunden und in unserem System implementiert haben, helfen uns, eine Vielzahl von betrügerischen Aktivitäten zu erkennen und zu analysieren. In diesem Artikel möchte ich die Prinzipien vorstellen, denen wir gefolgt sind, und erläutern, was wir getan haben, um den aktuellen Stand unseres Systems zu erreichen, ohne tiefer in die technische Materie einzutauchen.

Die Prinzipien unseres Systems

Wenn Sie Begriffe wie "automatic" und "fraud" hören, denken Sie wahrscheinlich an maschinelles Lernen, Apache Spark, Hadoop, Python, Airflow und andere Technologien aus dem Apache Foundation-Ökosystem sowie im Bereich Data Science. Ich glaube, es gibt einen Aspekt bei der Nutzung dieser Tools, der oft nicht erwähnt wird: Sie benötigen bestimmte Voraussetzungen in Ihrem Unternehmenssystem, bevor Sie mit deren Einsatz beginnen können. Kurz gesagt, Sie benötigen eine Unternehmensdatenplattform, die ein Data Lake und ein Data Warehouse umfasst. Aber was, wenn Sie eine solche Plattform nicht haben und dennoch diese Praxis entwickeln müssen? Die folgenden Prinzipien, die ich unten beschreibe, haben uns geholfen, einen Punkt zu erreichen, an dem wir uns auf die Verbesserung unserer Ideen konzentrieren können, anstatt nach einer funktionierenden Lösung zu suchen. Dennoch ist dies kein „Plateau“ des Projekts. Aus technologischer und produktmäßiger Sicht gibt es noch viele Dinge zu erledigen.

Prinzip 1: Geschäftswert zuerst

Im Mittelpunkt all unserer Bemühungen steht der „Wert für das Geschäft“. Im Allgemeinen gehört jedes automatisierte Analysesystem zu einer Gruppe komplexer Systeme mit hohem Automatisierungsgrad und technischer Raffinesse. Die Entwicklung 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äftswert an erste Stelle zu setzen und die technologische Vollständigkeit an zweite Stelle. Im realen Leben bedeutet das, dass wir fortschrittliche Technologien nicht als Dogma akzeptieren. Wir wählen die Technologie, die derzeit am besten für uns funktioniert. Im Laufe der Zeit kann es notwendig erscheinen, einige Module erneut zu implementieren. Dies ist der Kompromiss, den wir eingegangen sind.

Prinzip 2: Erweiterten menschlichen Intelligenz (augmented intelligence)

Ich wette, die meisten Menschen, die nicht tief in die Entwicklung von maschinellen Lernlösungen involviert sind, könnten denken, dass das Ersetzen von Menschen das Ziel ist. In Wirklichkeit sind maschinelle Lernlösungen weit entfernt von Perfektion, und ein Ersatz ist nur in bestimmten Bereichen möglich. Von dieser Idee haben wir von Anfang an aus mehreren Gründen Abstand genommen: unausgewogene Daten über betrügerische Aktivitäten und die Unmöglichkeit, eine umfassende Liste von Funktionen für maschinelle Lernmodelle bereitzustellen. Im Gegensatz dazu haben wir uns für eine erweiterte Intelligenz entschieden. Dies ist ein alternatives Konzept der Künstlichen Intelligenz, das sich auf die unterstützende Rolle von KI konzentriert und betont, dass kognitive Technologien dazu gedacht sind, menschliche Intelligenz zu verbessern, nicht sie zu ersetzen. [1]

Angesichts dessen hätte die Entwicklung einer vollständigen Maschine-Learning-Lösung von Grund auf erhebliche Anstrengungen erfordert, was die Schaffung von Mehrwert für unser Geschäft verzögert hätte. Wir beschlossen, ein System mit einem iterativ wachsenden Aspekt des maschinellen Lernens unter der Anleitung unserer Fachexperten zu entwickeln. Der komplizierte Teil der Entwicklung eines solchen Systems besteht darin, dass es unseren Analysten Fälle präsentieren muss, die nicht nur in Bezug auf potenzielles Betrugsverhalten überprüft werden können. Im Allgemeinen wird jede Anomalie im Kundenverhalten als verdächtiger Fall angesehen, den die Spezialisten untersuchen und auf den sie reagieren müssen. Nur ein Teil dieser festgestellten Fälle kann tatsächlich als Betrug kategorisiert werden.

Prinzip 3: Plattform für umfassende Analytik

Der herausforderndste Teil unseres Systems ist die durchgehende Überprüfung des Arbeitsablaufs. Analysten und Entwickler müssen problemlos Datensätze aus vergangenen Zeiträumen mit allen Metriken abrufen können, die für die Analyse verwendet wurden. Darüber hinaus sollte die Datenplattform eine einfache Möglichkeit bieten, den bestehenden Kennzahlenbestand um neue Metriken zu ergänzen. Die Prozesse, die wir erstellen – und das sind nicht nur Softwareprozesse – sollten eine unkomplizierte Berechnung vorheriger Zeiträume, das Hinzufügen neuer Metriken und das Ändern von Datenprognosen ermöglichen. Wir könnten dies erreichen, indem wir alle Daten sammeln, die unser Produktionssystem generiert. In einem solchen Fall würden die Daten allmählich zur Belastung werden. Wir müssten eine wachsende Menge an Daten speichern, die wir nicht verwenden, und sie schützen. In einem solchen Szenario werden die Daten im Laufe der Zeit immer irrelevanter, erfordern jedoch weiterhin unsere Arbeit zu deren Verwaltung. Für uns machte das Ansammeln von Daten (data hoarding) keinen Sinn, und wir entschieden uns für einen anderen Ansatz. Wir beschlossen, Echtzeit-Datenspeicher um die Zielentitäten zu organisieren, die wir klassifizieren wollen, und nur die Daten zu speichern, die die Überprüfung der letzten und aktuellsten Zeiträume ermöglichen. Die Komplexität dieser Bemühungen besteht darin, dass unser System heterogen ist, mit mehreren Datenspeichern und Softwaremodulen, die eine sorgfältige Planung für ein konsistentes Funktionieren erfordern.

Konstruktive Konzepte unseres Systems

Unser System besteht aus vier Hauptkomponenten: ein Aufnahmesystem (ingestion system), ein Berechnungssystem (computational), eine Analyse (BI-Analyse) und ein Tracking-System (tracking system). Sie dienen spezifischen isolierten Zwecken, und wir halten sie isoliert, indem wir bestimmten Entwicklungsansätzen folgen.

Vertragsbasiertes Design

Zunächst einmal haben wir uns darauf geeinigt, dass die Komponenten ausschließlich auf bestimmte Datenstrukturen (Verträge) angewiesen sein sollten, die zwischen ihnen ausgetauscht werden. Dies ermöglicht eine einfache Integration und zwingt nicht zu einer bestimmten Komposition (und Reihenfolge) der Komponenten. In einigen Fällen erlaubt uns dies beispielsweise, das Empfangssystem direkt mit dem Warnverfolgungssystem zu integrieren. In solchen Fällen wird dies gemäß dem vereinbarten Benachrichtigungsvertrag erfolgen. Das bedeutet, dass beide Komponenten mit einem Vertrag integriert werden, der von jeder anderen Komponente verwendet werden kann. Wir werden keinen zusätzlichen Vertrag hinzufügen, um Warnmeldungen aus dem Eingabesystem in das Verfolgungssystem einzufügen. Dieser Ansatz erfordert die Verwendung einer vorab definierten minimalen Anzahl von Verträgen und vereinfacht sowohl das System als auch die Kommunikation. Im Wesentlichen verwenden wir einen Ansatz, der als „Contract First Design“ bezeichnet wird, und wenden ihn auf die Datenstreaming-Verträge an. [2]

Streaming überall

Die Speicherung und Verwaltung des Zustands in einem System führt unvermeidlich zu Komplikationen bei seiner Implementierung. Im Allgemeinen sollte der Zustand von allen Komponenten zugänglich sein, er sollte konsistent sein und den aktuellsten Wert für alle Komponenten bereitstellen, und er sollte verlässlich mit den korrekten Werten sein. Darüber hinaus führt die Notwendigkeit von Aufrufen an einen persistenten Speicher, um den letzten Zustand abzurufen, zu einer erhöhten Anzahl von Ein-/Ausgabeoperationen und zur Komplexität der Algorithmen, die in unseren Echtzeit-Pipelines verwendet werden. Aus diesem Grund haben wir beschlossen, die Zustandsverwaltung, wo immer möglich, vollständig aus unserem System zu entfernen. Dieser Ansatz erfordert, dass alle notwendigen Daten im übermittelten Datenblock (Nachricht) enthalten sind. Beispielsweise, wenn wir die Gesamtzahl bestimmter Beobachtungen (Anzahl der Operationen oder Fälle mit bestimmten Eigenschaften) berechnen müssen, berechnen wir sie im Speicher und generieren einen Stream solcher Werte. Abhängige Module werden Partitionierung und Batch-Verarbeitung verwenden, um den Stream nach Entitäten zu zerlegen und mit den letzten Werten zu arbeiten. Dieser Ansatz hat die Notwendigkeit beseitigt, einen permanenten Datenspeicher für solche Daten zu haben. Unser System verwendet Kafka als Nachrichtenbrocker, und es kann als Datenbank mit KSQL verwendet werden. [3] Aber seine Verwendung würde unsere Lösung stark an Kafka binden, und wir haben beschlossen, es nicht zu verwenden. Unser gewählter Ansatz ermöglicht es uns, Kafka durch einen anderen Nachrichtenbroker zu ersetzen, ohne erhebliche interne Änderungen am System vorzunehmen.

Dieses Konzept bedeutet nicht, dass wir keine Datenträger und Datenbanken verwenden. Um die Systemleistung zu überprüfen und zu analysieren, müssen wir einen erheblichen Teil der Daten, die verschiedene Kennzahlen und Zustände repräsentieren, auf der Festplatte speichern. Ein wichtiger Punkt ist, dass die Echtzeitalgorithmen nicht von solchen Daten abhängen. In den meisten Fällen nutzen wir gespeicherte Daten für die Offline-Analyse, das Debugging und das Nachverfolgen spezifischer Fälle und Ergebnisse, die das System liefert.

Probleme unseres Systems

Es gibt bestimmte Probleme, die wir bis zu einem bestimmten Punkt gelöst haben, aber sie erfordern durchdachtere Lösungen. Ich möchte sie nur hier erwähnen, da jeder Punkt eine eigene Artikel wert ist.

Wir müssen weiterhin Prozesse und Richtlinien definieren, die zur Ansammlung bedeutungsvoller und relevanter Daten für unsere automatische Analyse, Datenentdeckung und -untersuchung beitragen.
Die Integration menschlicher Analyseergebnisse in den automatischen Systemanpassungsprozess zur Aktualisierung mit den neuesten Daten. Dies ist nicht nur eine Aktualisierung unseres Modells, sondern auch eine Verbesserung der Prozesse und des Verständnisses unserer Daten.
Das Finden eines Gleichgewichts zwischen einem deterministischen IF-ELSE-Ansatz und maschinellem Lernen (ML). Jemand sagte: "ML ist ein Werkzeug für die Verzweifelten." Das bedeutet, dass Sie ML nutzen möchten, wenn Sie nicht mehr verstehen, wie Sie Ihre Algorithmen optimieren und verbessern können. Andererseits lässt der deterministische Ansatz keine Anomalien entdecken, die nicht vorhergesehen wurden.
Wir brauchen eine einfache Möglichkeit, um unsere Hypothesen oder Korrelationen zwischen Metriken in den Daten zu überprüfen.
Das System sollte mehrere Ebenen von echten positiven (True Positive) Ergebnissen haben. Betrugsfälle sind nur ein Teil aller Fälle, die als positiv für das System betrachtet werden können. Zum Beispiel möchten Analytiker alle verdächtigen Fälle zur Überprüfung erhalten, und nur ein kleiner Teil davon sind Betrugsfälle. Das System sollte Analytikern effizient alle Fälle zur Verfügung stellen, unabhängig davon, ob es sich um echten Betrug oder nur um verdächtiges Verhalten handelt.
Die Datenplattform sollte die Möglichkeit bieten, Datensätze aus früheren Zeiträumen mit Berechnungen abzurufen, die in Echtzeit erstellt und berechnet wurden.
Einfache und automatisierte Bereitstellung eines jeden Komponenten des Systems in mindestens drei verschiedenen Umgebungen: Produktions-, experimenteller (Beta) und Entwicklerumgebung.
Und schließlich, aber nicht weniger wichtig. Wir müssen eine umfangreiche Plattform zur Leistungsüberprüfung schaffen, auf der wir unsere Modelle analysieren können. [4]