Wichtigste Erkenntnisse

  • Als weltweit größte Kryptobörse ist es für uns von entscheidender Bedeutung, über ein Risikoerkennungssystem zu verfügen, das schnell ist, jedoch keine Kompromisse bei der Genauigkeit eingeht.

  • Die Herausforderung bestand für uns darin, sicherzustellen, dass unsere Modelle immer aktuelle Informationen verwendeten, insbesondere beim Erkennen verdächtiger Kontoaktivitäten in Echtzeit.

  • Um eine stärkere Funktionskonsistenz und höhere Produktionsgeschwindigkeit zu erreichen, treffen wir jetzt vernünftige Annahmen über unsere Daten und kombinieren unsere Batch- und Streaming-Pipelines.

Entdecken Sie, wie unsere Feature-Engineering-Pipeline leistungsstarke, konsistente Funktionen zum Erkennen betrügerischer Abhebungen auf der Binance-Plattform erstellt.

Innerhalb unserer Pipeline für maschinelles Lernen (ML) – über die Sie in einem früheren Artikel mehr erfahren können – haben wir vor Kurzem eine automatisierte Feature-Engineering-Pipeline erstellt, die Rohdaten in wiederverwendbare Online-Features umwandelt, die für alle risikobezogenen Modelle gemeinsam genutzt werden können.

Beim Erstellen und Testen dieser Pipeline stießen unsere Datenwissenschaftler auf ein interessantes Problem hinsichtlich der Merkmalskonsistenz: Wie erstellen wir genaue Sätze von Online-Funktionen, die sich im Laufe der Zeit dynamisch ändern?

Betrachten Sie dieses reale Szenario: Eine Kryptobörse – in diesem Fall Binance – versucht, betrügerische Abhebungen zu erkennen, bevor Geld die Plattform verlässt. Eine mögliche Lösung besteht darin, Ihrem Modell eine Funktion hinzuzufügen, die die seit der letzten bestimmten Aktion des Benutzers (z. B. Anmelden oder Mobilgerätebindung) verstrichene Zeit erkennt. Das würde ungefähr so ​​aussehen:

Benutzer-ID|letzte_Bindung_Google_Zeitdifferenz_in_Tagen|...

1|3,52|...

Die Herausforderung der Umsetzung

Die Anzahl der Schlüssel, die zum Berechnen und Aktualisieren von Features in einem Online-Feature-Store erforderlich ist, ist unpraktisch. Die Verwendung einer Streaming-Pipeline wie Flink wäre unmöglich, da diese nur Benutzer mit Datensätzen berechnen kann, die im aktuellen Moment in Kafka eingehen.

Als Kompromiss könnten wir eine Batch-Pipeline verwenden und eine gewisse Verzögerung in Kauf nehmen. Nehmen wir an, ein Modell kann Features aus einem Online-Feature-Store abrufen und in etwa einer Stunde Echtzeit-Inferenzen durchführen. Wenn es gleichzeitig eine Stunde dauert, bis ein Feature-Store die Berechnung und Aufnahme der Daten abgeschlossen hat, würde die Batch-Pipeline das Problem – theoretisch – lösen.

Leider gibt es ein eklatantes Problem: Die Verwendung einer solchen Batch-Pipeline ist sehr zeitaufwändig. Dies macht es unmöglich, innerhalb einer Stunde fertig zu werden, wenn man die weltweit größte Kryptobörse mit ungefähr hundert Millionen Benutzern und einem TPS-Limit für Schreibvorgänge ist.

Wir haben festgestellt, dass es sich am besten eignet, Annahmen über unsere Nutzer zu treffen und so die Datenmenge zu reduzieren, die in unseren Feature Store gelangt.

Das Problem durch praktische Annahmen lindern

Online-Funktionen werden in Echtzeit aufgenommen und ändern sich ständig, da sie die aktuellste Version einer Umgebung darstellen. Bei aktiven Binance-Benutzern können wir es uns nicht leisten, Modelle mit veralteten Funktionen zu verwenden.

Es ist zwingend erforderlich, dass unser System verdächtige Abhebungen so schnell wie möglich kennzeichnet. Jede zusätzliche Verzögerung, selbst um ein paar Minuten, bedeutet mehr Zeit für einen böswilligen Akteur, um mit seinen Verbrechen davonzukommen.

Aus Effizienzgründen gehen wir davon aus, dass aktuelle Anmeldungen ein relativ höheres Risiko bergen:

  • Wir stellen fest, dass (250 Tage + 0,125 [3/24 Verzögerung] Tag) relativ kleinere Fehler erzeugt als (1 Tag + 0,125 [3/24 Verzögerung] Tag).

  • Die meisten Vorgänge überschreiten einen bestimmten Grenzwert nicht, beispielsweise 365 Tage. Um Zeit und Rechenressourcen zu sparen, lassen wir Benutzer aus, die sich seit über einem Jahr nicht angemeldet haben.

Unsere Lösung

Wir verwenden eine Lambda-Architektur, die einen Prozess beinhaltet, bei dem wir Batch- und Streaming-Pipelines kombinieren, um eine stärkere Funktionskonsistenz zu erreichen.

Wie sieht die Lösung konzeptionell aus?

  • Batch-Pipeline: Führt Feature-Engineering für eine riesige Benutzerbasis durch.

  • Streaming-Pipeline: Behebt Verzögerungen in der Batch-Pipeline für aktuelle Anmeldungen.

Was passiert, wenn ein Datensatz während der Verzögerungszeit bei der Stapelaufnahme in den Online-Feature-Store aufgenommen wird?

Unsere Funktionen behalten auch dann eine hohe Konsistenz bei, wenn Datensätze während der einstündigen Verzögerungszeit für die Stapelverarbeitung aufgenommen werden. Dies liegt daran, dass der Online-Feature-Store, den wir bei Binance verwenden, den neuesten Wert basierend auf der von Ihnen beim Abrufen des Werts angegebenen Ereigniszeit zurückgibt.

Trete unserem Team bei!

Sie möchten maschinelles Lernen nutzen, um das weltweit größte Krypto-Ökosystem und seine Benutzer zu schützen? Schauen Sie auf unserer Karriereseite nach Stellenangeboten im Bereich Binance Engineering/AI.

Weitere Informationen finden Sie in den folgenden hilfreichen Artikeln:

  • (Blog) Verwenden von MLOps zum Erstellen einer End-to-End-Pipeline für maschinelles Lernen in Echtzeit

  • (Blog) Ein genauerer Blick auf unseren Machine Learning Feature Store