Zum Inhalt springen
SwankyForge
SwankyForge
Alle Fallstudien
ML-SystemeMLOpsMonitoring5 Monate

Betrugserkennungs-Pipeline + Monitoring

Analysten verbrachten ihren Tag mit Fehlalarmen. Die Prüf-Queue ist jetzt ein Drittel so groß.

False-Positive-Rate

1,6 %

Kostenkalibriertes Modell, gleicher Recall

Vorher

4,1 %

Statische Regeln beim Ziel-Recall

In einfachen Worten

Worum es geht.

In diesem Abschnitt kein Fachjargon. Die technische Beschreibung folgt weiter unten.

Was schieflief

Ein fester Regelsatz erkannte den Betrug, den er schon kannte, und sonst nichts. Analysten kämpften sich den ganzen Tag durch Fehlalarme, während wirklich neue Angriffsmuster wochenlang unbemerkt blieben.

Was wir gebaut haben

Wir haben ein Echtzeit-Scoring gebaut, das die tatsächlichen Kosten jeder Fehlerart abwägt, ein Monitoring ergänzt, das anschlägt, wenn sich Verhalten verschiebt, und es schrittweise neben den bestehenden Regeln ausgerollt, statt sie über Nacht zu ersetzen.

Was sich geändert hat

Bei gleicher Menge erkannten Betrugs fielen die Fehlalarme von 4,1 % auf 1,6 % – die Prüf-Queue schrumpfte um fast zwei Drittel. Neue Muster tauchen jetzt innerhalb von Tagen auf, und jede abgelehnte Transaktion kommt mit einer Begründung.

Architektur

Wie alles zusammenpasst.

Scrollen Sie durch die Phasen. Alles, was als hinzugefügt markiert ist, ist eine Komponente, die es vor diesem Projekt nicht gab.

FEATURESPRÜFUNGLOGTransaktionECHTZEITFeature StoreONLINEGBDT-Scorer241 FEATURESKostenmatrixSCHWELLENWERTEAnalysten-QueueERKLÄRTDrift-MonitorPSI + KS
  1. Transaktion

    Echtzeit

    speist
    Feature StoreFeatures
  2. Feature Store

    online

    Das haben wir hinzugefügt
    erhält von
    TransaktionFeatures
    speist
    GBDT-Scorer
  3. GBDT-Scorer

    241 Features

    Das haben wir hinzugefügt
    erhält von
    Feature Store
    speist
    Kostenmatrix · Drift-MonitorLog
  4. Kostenmatrix

    Schwellenwerte

    Das haben wir hinzugefügt
    erhält von
    GBDT-Scorer
    speist
    Analysten-QueuePrüfung
  5. Analysten-Queue

    erklärt

    erhält von
    KostenmatrixPrüfung
  6. Drift-Monitor

    PSI + KS

    Das haben wir hinzugefügt
    erhält von
    GBDT-ScorerLog
Die Beschreibung

Wie es gebaut würde.

Datensatz, Vorgehen, Zielmetriken und der Stack. Geschrieben für die Person, die es prüfen muss.

ML-SystemeMLOpsMonitoring5 Monate

Betrugserkennungs-Pipeline + Monitoring

Echtzeit-Scoring mit Feature-Pipelines, Monitoring und kontrollierten Rollouts.

Problem

Ein statischer Regelsatz erkannte bekannte Betrugsmuster und sonst nichts. Analysten gingen in False Positives unter, während neue Angriffsmuster wochenlang unentdeckt blieben.

Datensatz

Zeilen
186 Mio. Transaktionen
Features
241
Quellen
Zahlungen, Geräte, Verhalten
Zeitraum
28 Monate

Vorgehen

  1. 01Einen Echtzeit-Feature-Store mit strikter Offline/Online-Parität gebaut
  2. 02Ein Gradient-Boosting-Modell mit gezielter Behandlung starker Klassenungleichgewichte trainiert
  3. 03Schwellenwerte aus einer expliziten Kostenmatrix statt aus dem F1 abgeleitet
  4. 04Drift-Monitoring und eine Champion/Challenger-Retraining-Schleife ergänzt

Metriken

0,79
PR-AUC
+0,34
-61 %
False Positives
bei gleichem Recall
28 ms
Scoring p95
inline
0,041
Drift-PSI
überwacht

Evidenz

Quelle
Referenzdesign
Zahlen
Illustrativ – typische Werte für dieses Design
Messung
Nicht gemessen. Typische Werte für ein Referenzdesign dieser Art, nicht auf einem Kundensystem beobachtet.
Referenz
Für dieses Projekt nicht verfügbar
zuletzt geprüft
2026-08-25

Geschäftlicher Effekt

  • Prüf-Queue der Analysten um fast zwei Drittel verkleinert
  • Neue Muster in Tagen statt Wochen erkannt
  • Jede Ablehnung mit Feature-Attributionen erklärbar

Tech-Stack

  • Python
  • Kafka
  • Flink
  • LightGBM
  • Feast
  • Prometheus
  • Grafana

Weiter

Brauchen Sie ein System wie dieses?

Beantworten Sie sechs Fragen, und wir sagen Ihnen, ob diese Form zu Ihrem Problem passt – auch wenn sie es nicht tut.