Echtzeit-Betrugserkennung mit Feature Views

Die Echtzeit-Betrugserkennung hängt von drei Arten von Merkmalen ab: was ein Kunde vor Sekunden getan hat, wie er normalerweise ausgibt und wie sich die aktuelle Zahlung im Vergleich dazu verhält. Diese Merkmale müssen für das Modelltraining und das Live-Scoring exakt gleich berechnet werden — andernfalls untergraben Data Leakage und Training-Serving-Skew schleichend die Modellqualität. Feature Views, ein Bestandteil von Databricks Feature Store, lösen dieses Problem. Sie definieren jedes Merkmal einmal, und diese Definition liefert sowohl zeitpunktkorrekte Trainingsdaten als auch die verwalteten Pipelines für die Online-Inferenz.

Eine Zahlung von 900 $ mag für einen Kunden Routine und für einen anderen ungewöhnlich sein. Wenn sie eingeht, hat ein Betrugsmodell nur einen Moment Zeit, um zu entscheiden, ob sie normal aussieht, geprüft werden muss oder blockiert werden sollte. Die Genehmigung einer betrügerischen Transaktion kann den Kunden Geld kosten. Das Blockieren einer legitimen Transaktion stört das Zahlungserlebnis und untergräbt das Vertrauen in die Plattform.

Die Transaktion allein erzählt nicht die ganze Geschichte. Das Modell muss auch wissen, wie dieser Kunde normalerweise Transaktionen durchführt und was er vor Sekunden, Minuten, Tagen oder Wochen getan haben. Während des Trainings dürfen Merkmale nur Informationen verwenden, die zum Zeitpunkt der jeweiligen Zahlung verfügbar waren. Beim Live-Scoring müssen sie aktuelle Transaktionen schnell genug widerspiegeln, um verdächtige Aktivitäten zu erkennen. Wenn die beiden Pfade die Logik getrennt voneinander implementieren, schleichen sich kleine Unterschiede zwischen ihnen ein.

Diese Schritt-für-Schritt-Anleitung verfolgt diese 900-$-Zahlung von einem Kafka-Stream bis zu einem von Model Serving bereitgestellten Betrugs-Score, inklusive Code für jeden Schritt. Der Kern gedanke ist, dass eine einzige Merkmalsdefinition, die sowohl Training als auch Serving steuert, Ihnen zeitpunktkorrekte Trainingsdaten und konsistente Online-Merkmale liefert. Sie müssen für jeden Pfad keine separate Pipeline erstellen.

Was ist eine Feature View?

Eine Feature View ist eine Definition im Databricks Feature Store, die die Quelle, Entity Keys, Zeitsemantik und Transformation eines Merkmals festlegt. Dieselbe Definition berechnet historische Werte für das Training und steuert die verwalteten Pipelines, die Merkmale für das Serving aktuell halten. Eine einzige API deckt Batch-, Streaming- und On-Demand-Merkmale ab. Unity Catalog steuert deren Definitionen, Berechtigungen und Herkunft.

Zwei Fehlerursachen motivieren dieses Design:

• Training-Serving-Skew tritt auf, wenn ein Merkmal im Training auf die eine und in der Produktion auf eine andere Weise berechnet wird. Zum Zeitpunkt der Inferenz sieht das Modell dann Eingaben, die nicht mit dem übereinstimmen, woraus es gelernt hat.
• Data Leakage tritt auf, wenn Trainingsdaten Informationen enthalten, die zum Zeitpunkt der Vorhersage noch nicht verfügbar waren. Zeitpunktkorrekte Merkmale verhindern dies, indem sie nur Ereignisse verwenden, die vor dem vorhergesagten Zeitpunkt stattgefunden haben.

Feature Views bringen die Streaming-Merkmalsberechnung in denselben Data-Science-Workflow wie das historische Training und das Live-Scoring. Sie können Merkmale anhand vergangener Transaktionen bewerten und dann dieselben Definitionen verwenden, um den Kundenkontext für Live-Entcheidungen aktuell zu halten.

Welche Merkmale benötigt ein Echtzeit-Betrugsmodell?

Das Ziel ist es, verdächtige Zahlungen beim Eingehen zu kennzeichnen, ohne falsche Alarme bei legitimen Zahlungen auszulösen. Für sich genommen mag die Zahlung von 900 $ harmlos aussehen. Wenn es jedoch die zehnte Zahlung innerhalb von fünf Minuten ist, könnte sie Teil eines verdächtigen Bursts sein. Jede Verzögerung bei der Erkennung dieses Bursts gibt jemandem mit Zugriff auf ein kompromittiertes Konto mehr Zeit, weitere Zahlungen zu tätigen.

Eine mit Databricks Apps erstellte Betrugserkennungsanwendung verarbeitet einen Strom von Finanztransaktionen. Jedes Ereignis umfasst eine Kunden-ID, den Betrag, die Zahlungsart, den Zeitstempel sowie Herkunfts- und Zielländer. Die Anwendung sendet jede Transaktion an einen Model-Serving-Endpunkt. Anschließend zeigt sie den Risikowert der Transaktion zusammen mit dem Live-Transaktionsvolumen, markierten Transaktionen und den Strömen zwischen Ländern an.
 

Das Modell kombiniert drei Arten von Kontext:

• Aktuelle Aktivität: eine Transaktionsanzahl über fünf Minuten und ein Gesamtbetrag über 10 Minuten, berechnet mit RollingWindow, erfassen, wie oft der Kunde zahlt und wie viel er ausgibt.
• Ausgabenbasislinie: ein 30-Tage-Durchschnitt und eine Standardabweichung, verwaltet mit SawtoothWindow, beschreiben den typischen Zahlungsbetrag des Kunden und dessen Schwankungsbreite.
• Transaktionsdetails: der Betrag der aktuellen Zahlung, die Zahlungsart sowie Herkunfts- und Zielländer liefern den Kontext für die Entscheidung.

Die Architektur verfügt über einen historischen Pfad für das Training und einen Online-Pfad für die Inferenz. Beide beginnen mit denselben Merkmalsdefinitionen im Unity Catalog. Der historische Pfad liest die Ingestion-Tabelle des Streams, um zeitpunktkorrekte Trainingssätze zu erstellen. Der Online-Pfad materialisiert Aggregate in den Online Feature Store, wo Model Serving sie zum Zeitpunkt der Anfrage liest.

So definieren Sie Streaming-Merkmale aus Kafka

Bevor Sie entscheiden, welche Merkmale bereitgestellt werden sollen, können Sie Alternativen anhand historischer Transaktionen testen. Liefert eine Transaktionsanzahl über fünf Minuten ein stärkeres Signal als eine über 15 Minuten? Hilft der Vergleich des aktuellen Betrags mit der Ausgabenschwankung des Kunden mehr als die alleinige Verwendung seines Durchschnitts?

In diesem Beispiel kommen Kundentransaktionsereignisse als Kafka-Streams an. Ein registrierter Stream hält die Verbindung, das Schema und die Ingestion-Einstellungen, und eine StreamSource verweist darauf, um Echtzeit-Merkmale zu berechnen. Kafka-Topics behalten nicht genügend Historie für das Modelltraining bei. Databricks verwaltet daher eine Offline-Kopie des Streams in einer Ingestion-Tabelle. Für das Training oder das Backfilling eines Online Stores berechnet Databricks historische Werte aus der Ingestion-Tabelle und verwendet den Live-Kafka-Feed für die aktuellsten Daten.

Beim Ingest bringt transformation_sql verschachtelte Felder aus der Kafka- value-Nutzlast in das Schema, das die Merkmale benötigen. Die Projektion wird Teil der Quelldefinition, sodass Sie keine separate Vorverarbeitungspipeline bereitstellen müssen. Für unsere Zahlung enthält die Kafka- value-Nutzlast:

Die Demo verwendet demo_user_id zusammen mit customer_id, um die Kundenhistorien verschiedener App-Benutzer getrennt zu halten.

Wir definieren die Fünf-Minuten-Anzahl mit RollingWindow. Das Begleit-Notebook enthält Importe, Konfigurationen und die vollständige Quellprojektion.

Sie können die historischen Werte in einem Notebook mit compute_features(features=[recent_transaction_count]) überprüfen. Die 10-Minuten-Summe verwendet dieselbe Quelle und dieselben Schlüssel, mit Sum über ein 10-minütiges RollingWindow.

Ein Sawtooth Window ist eine Aggregation mit langer Rückschauzeit, deren älteste Grenze in täglichen Schritten voranschreitet. Es kombiniert batch-berechnete Historie mit Streaming-Updates für aktuelle Aktivitäten. Für unsere 900-$-Zahlung fügt SawtoothWindow den kurzen gleitenden Fenstern eine 30-tägige Ausgabenbasislinie hinzu. Beide Fensterarten halten die aktuellen Aktivitäten frisch. Da sich die älteste Grenze des Sawtooth Window täglich statt kontinuierlich bewegt, ist die effektive Rückschauzeit etwas länger als 30 Tage. Die Basislinie verwendet die integrierten Aggregationen Avg, StddevPop und Count für Zahlungsbeträge über dasselbe Sawtooth Window.

Databricks startet eine verwaltete Ingestion-Pipeline, wenn ein Stream erstellt wird, und speichert eingehende Ereignisse in seiner Ingestion-Tabelle. Wenn Sie auch Ereignisse aus der Zeit vor der Existenz des Streams benötigen, können Sie mit StreamBackfillSource Ihre eigene Historie während der Stream-Einrichtung bereitstellen. Sobald die Tabelle den gesamten Rückschauzeitraum abdeckt, kann ein neues Sawtooth-Merkmal diese sofort verwenden, anstatt 30 Tage auf die Ansammlung von Ereignissen zu warten.

So vergleichst du eine Live-Zahlung mit der Baseline eines Kunden

Ein On-Demand-Feature wird zum Zeitpunkt der Anfrage berechnet, indem Werte aus der Scoring-Anfrage mit gespeicherten Features kombiniert werden. Der Vergleich einer Live-Transaktion mit der historischen Baseline eines Kunden ist eine gängige Methode, um abnormales Verhalten zu erkennen. In Feature Views werden Informationen zum Zeitpunkt der Inferenz durch ein RequestSource dargestellt – hier durch transaction_amount aus der Anfrage der Anwendung.

Zwei Kunden können beide im Schnitt 300 $ pro Zahlung ausgeben, sich aber im Ausgabeverhalten stark unterscheiden. Bei Standardabweichungen von 100 $ und 600 $ liegt dieselbe Zahlung von 900 $ sechs Standardabweichungen über dem Durchschnitt des einen Kunden und nur eine über dem des anderen. Das Modell kombiniert diesen Vergleich mit der jüngsten Aktivität und Zahlungsdetails, um das Betrugsrisiko einzuschätzen.

Die Sawtooth-Aggregationen halten den 30-Tage-Durchschnitt und die Standardabweichung vor. Das On-Demand-Feature kombiniert diese mit dem aktuellen Betrag, um (current_amount - average) / standard_deviation zu berechnen. Wir implementieren diese Berechnung als Python UDF, die in Unity Catalog registriert ist:

Die Feature-Definition verwendet registrierte Upstream-Feature-Objekte. FeatureViewSource führt den aktuellen Betrag und die drei 30-Tage-Statistiken zusammen, und CustomUDF ruft die Funktion auf:

Wenn nicht genügend verwertbare Historie vorhanden ist, gibt die Funktion als Fallback null zurück. Ein separater Indikator ermöglicht es dem Modell, diesen Fallback von einer echten Null zu unterscheiden, was bedeutet, dass die Zahlung dem Kundendurchschnitt entspricht. Dasselbe abgeleitete Feature wird beim Training gegen historische Eingaben und bei der Inferenz gegen die aktuelle Anfrage plus abgerufene Statistiken evaluiert.

So testest du Feature-Kandidaten vor der Bereitstellung

Während der Feature-Entwicklung kannst du Feature-Definitionen in einem Notebook mit compute_features() inspizieren. Dies funktioniert für abgeleitete Features, deren Eingaben vollständig aus historischen Quelldaten stammen. Für anfrageabhängige Vergleiche wie amount_deviation verwendest du stattdessen create_training_set(), das die aktuellen Zahlungsfelder aus gelabelten Beispielen bereitstellt. Die Unity Catalog-Funktion muss existieren, aber Feature-Definitionen können unregistered bleiben, während du Kandidaten testest.

So kannst du prüfen, ob ein Feature die Offline-Leistung des Betrugsmodells verbessert, bevor du es für das Live-Scoring bereitstellst. Du kannst beispielsweise Modelle mit und ohne amount_deviation bei späteren Hold-out-Zahlungen vergleichen. Diese Experimente laufen auf Batch-Compute über die Transaktionshistorie, sodass du jeden Kandidaten evaluieren kannst, ohne Online-Materialisierung einrichten zu müssen. Sobald du die Features ausgewählt hast, registriere ihre Definitionen und materialisiere die gleitenden und Sawtooth-Aggregationen für das Serving.

So erstellst du zeitpunktkorrekte Trainingsdaten

Jedes historische Trainingsbeispiel benötigt Features, die zum Zeitstempel dieser Zahlung berechnet wurden. Für unsere Zahlung über 900 $ um 10:00 Uhr sollte der Fünf-Minuten-Zähler Transaktionen von 9:55 Uhr bis einschließlich 9:59 Uhr enthalten (ohne 10:00 Uhr). Ein um 10:03 Uhr abgerufener Zähler könnte eine Zahlung enthalten, die um 10:02 Uhr getätigt wurde und zum Zeitpunkt des Scorings der ursprünglichen Zahlung noch nicht verfügbar war. Das ist Data Leakage: Das Modell lernt aus zukünftigen Aktivitäten, und seine Offline-Leistung sieht besser aus, als sie tatsächlich ist. Feature Views verwenden die Kundenschlüssel und den Zeitstempel jedes Beispiels, um das korrekte historische Zeitfenster aus Ereignissen in der Ingestion-Tabelle des Stream zu berechnen.

Nach dem Registrieren der ausgewählten Features erstellt create_training_set() die Trainingsdaten des Modells. Das gelabelte DataFrame liefert die Kundenschlüssel, die Ereigniszeit, aktuelle Zahlungsfelder und is_fraud. Dieser Auszug wählt die registrierten Features der Anleitung aus, einschließlich der 30-Tage-Baseline, und verwendet Zeilen vor einem gewählten Stichtag für das Training:

Schlüssel und Zeitstempel wählen die Kundenhistorie aus, werden jedoch als Modelleingaben ausgeschlossen. Anfragetexte bzw. -felder speisen die Feature-Berechnungen; der Klassifikator verwendet die resultierenden benannten Features. Spätere Zeilen bilden einen Validierungssatz unter Verwendung derselben Definitionen.

Wir trainieren einen Random-Forest-Klassifikator und evaluieren die durchschnittliche Präzision sowie den ROC AUC auf letzterem. Anschließend protokollieren wir das Modell über den Feature Engineering Client. Die Übergabe von training_set=train_set zeichnet die Feature-Abhängigkeiten auf, die das Serving benötigt:

So stellst du Echtzeit-Features für die Online-Inferenz bereit

Um die oben genannten ausgewählten Features in das Live-Scoring zu übernehmen, sind Pipelines erforderlich, die Streaming-Aggregate pflegen, historische Daten verarbeiten und den Online Store aktuell halten. Das Erstellen und Betreiben dieser Pipelines erfordert monatelange Data-Engineering-Arbeit über die Entwicklung des Betrugsmodells hinaus. Mit Feature Views treiben die registrierten Feature-Definitionen diesen Prozess an: Ein Aufruf von materialize_features() erstellt verwaltete Pipelines, die die Aggregationen im Databricks Online Feature Store verfügbar machen, unterstützt durch Lakebase.

Der Streaming-Pfad verwendet Spark Real-Time Mode (RTM), um eingehende Ereignisse kontinuierlich zu verarbeiten und gleitende Aggregate beim Eintreffen zu aktualisieren.

Wir materialisieren die gleitenden und Sawtooth-Aggregationen. Für die 30-Tage-Sawtooth-Baseline verwaltet Databricks den historischen Teil mit Batch-Berechnung und die jüngste Aktivität mit Streaming. Die beiden werden beim Lesen zu einem einzigen Feature zusammengeführt, und StreamingMode() verwaltet diesen hybriden Pfad ohne separaten Batch-Aufruf. Überprüfe vor dem Serving beide Materialisierungspfade im Catalog Explorer. Die Sawtooth-Anleitung empfiehlt, vor der Verwendung in der Produktion zwei volle Tage zu warten.

RequestSource liefert Werte von jeder Scoring-Anfrage, und abgeleitete Features werden bei Bedarf berechnet. Sobald das Modell bereitgestellt ist, sendet die Anwendung die Kundenschlüssel und aktuellen Zahlungsfelder an ihren Endpunkt. Model Serving ruft die neuesten Kunden-Features ab, wertet die On-Demand-Abweichung aus und leitet die Eingaben dann an das Betrugsmodell weiter. Hier ist unsere Zahlung von 900 $ im Anfrageformat der App, unter Verwendung des SDK-Aufrufs des Scorers:

Die App sendet event_time in dieser Anfrage, aber das Online-Lookup verwendet die neuesten verfügbaren Kunden-Features und keinen historischen Snapshot, der von diesem Zeitstempel ausgewählt wurde. In dieser Demo bewertet die App jede Zahlung, bevor sie an Kafka veröffentlicht wird. Dadurch bleibt die aktuelle Zahlung von ihrer eigenen Historie ausgeschlossen, was dem Ausschluss dieser Zahlung im Trainingsfenster entspricht. Feature-Updates und Scoring laufen weiterhin asynchron, sodass beim Scoring der nächsten Zahlung möglicherweise andere Ereignisse ausstehen.

Der Endpunkt gibt eine Wahrscheinlichkeit in fraud_probability und ein Flag in fraud_prediction zurück. Die Anwendung speichert bewertete Transaktionen zur Anzeige im Dashboard in Lakebase.

So verwalten Sie ML-Features in Unity Catalog

Betrugsmodelle in der Produktion werfen Governance-Fragen auf: Welche Modelle verwenden ein Feature, woher stammt es und wer kann es lesen. Unity Catalog führt Feature-Definitionen, Berechtigungen und Lineage zusammen, um diese Fragen zu beantworten. MLflow zeichnet auf, welche Features jedes Modell verwendet, und Model Serving nutzt diese Abhängigkeiten bei der Bearbeitung einer Inferenzanfrage.

Feature-Berechtigungen steuern den Lebenszyklus:

• CREATE FEATURE steuert die Registrierung.
• READ FEATURE gewährt Zugriff auf Feature-Metadaten.
• MANAGE autorisiert Vorgänge wie die Materialisierung.

Feature-Berechtigungen ersetzen nicht die SELECT Berechtigungen, die für Quell- oder materialisierte Tabellen für Training und Serving erforderlich sind.

Im Catalog Explorer werden Feature Views unter Funktionen angezeigt – zusammen mit ihren Definitionen, Quell-Links, materialisierten Tabellen und ihrem Status. Streaming-Materialisierungen verlinken zur Überprüfung auf ihre vom System verwalteten Lakeflow-Pipelines. Materialisierungs-Tags ermöglichen es Teams, Pipeline- oder Job-Compute-Kosten einem bestimmten Team oder Projekt zuzuordnen.

Wichtigste Erkenntnisse für die Betrugserkennung in Echtzeit

Unsere Zahlung von 900 $ hat jetzt Kontext: aktuelle Aktivitäten, eine längerfristige Baseline und die aktuelle Anfrage. Drei Vorgehensweisen haben dies ermöglicht:

• Einmal definieren, zweimal verwenden. Gemeinsame Feature-Definitionen für Training und Serving reduzieren den Trainings-Serving-Skew, der durch getrennte Implementierungen entsteht.
• Zeitpunkt berechnen. Trainingsfenster, die zukünftige Ereignisse ausschließen, verhindern Datenlecks und halten Offline-Metriken aussagekräftig.
• Die Plattform die Pipelines ausführen lassen. Materialisierung und Online-Lookup werden verwaltet, sodass Sie sich ganz auf die Auswahl besserer Betrugssignale konzentrieren können.

Dies lässt sich auch über diese Anleitung hinaus anwenden. LastN speichert Sequenzen wie die Zielländer der zehn letzten Zahlungen eines Kunden, was Modellen hilft, Änderungen bei den Zahlungsrouten zu erkennen. Batch-Features können auch Aggregationen über die gesamte Lebensdauer verwenden, um die vollständige Historie einer Entität zusammenzufassen.

Einen genauen Blick auf die Infrastruktur hinter Streaming-Aktualität im Subsekundenbereich erhalten Sie im Artikel Wie der Databricks Feature Store Features mit Aktualität im Subsekundenbereich bereitstellt. Implementierungsdetails finden Sie in der Dokumentation zur Feature Views API, zu Materialisierungen und zum Durchsuchen von Feature Views in Unity Catalog.

Häufig gestellte Fragen

Was sind Databricks Feature Views?

Feature Views sind eine Funktion des Databricks Feature Store, mit der ML-Features einmal definiert und sowohl für das Training als auch für die Produktion verwendet werden können. Jede Definition gibt eine Quelle, Entitätsschlüssel, Zeitsemantik und eine Transformation an. Dieselbe API deckt Batch-, Streaming- und On-Demand-Features ab, und Unity Catalog verwaltet sie.

Wie verhindern Feature Views Datenlecks beim Trainieren eines Betrugsmodells?

Feature Views berechnen die Features für jedes Trainingsbeispiel zum Zeitpunkt dieses Beispiels. Bei einer Zahlung um 10:00 Uhr umfasst eine Transaktionsanzahl von fünf Minuten Zahlungen von 9:55 Uhr bis einschließlich 9:59:59 Uhr (ohne 10:00 Uhr). Dadurch bleiben zukünftige Aktivitäten aus den Trainingsdaten ausgeschlossen, sodass die Offline-Leistung nicht verfälscht wird.

Was ist ein Trainings-Serving-Skew und wie reduzieren Feature Views diesen?

Ein Trainings-Serving-Skew tritt auf, wenn Features für das Training auf die eine und für Live-Inferenzen auf eine andere Weise berechnet werden. Feature Views reduzieren diesen Versatz, indem sie eine einzige registrierte Definition sowohl für die historische Berechnung als auch für die Online-Materialisierung verwenden. Teams müssen die Feature-Logik nicht für die Produktion neu implementieren.

Können Feature Views Features aus Kafka-Streams berechnen?

Ja. Ein registrierter Stream enthält die Kafka-Verbindung, das Schema und die Ingestion-Einstellungen, und ein StreamSource verweist darauf in Feature-Definitionen. Databricks speichert eine Offline-Kopie des Streams in einer Ingestion-Tabelle für Training und Backfills. Der Echtzeitmodus aktualisiert Streaming-Aggregationen, sobald neue Ereignisse eintreffen.

Wie werden Echtzeit-Features für ein Betrugsmodell in der Produktion bereitgestellt?

Durch den Aufruf von materialize_features() werden verwaltete Pipelines erstellt, die Aggregate im Online Feature Store (unterstützt durch Lakebase) aktuell halten. Wenn das Modell mit log_model() protokolliert und für Model Serving bereitgestellt wird, ruft der Endpunkt die neuesten Kunden-Features ab und berechnet On-Demand-Features aus der Anfrage. Anschließend wird eine Betrugswahrscheinlichkeit ausgegeben.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag