Berechnen Sie einen Score im Batch, wenn die Entscheidung Daten toleriert, die ein paar Stunden alt sind. Berechnen Sie ihn nur dann in Echtzeit, wenn die Antwort von der Anfrage selbst oder von Ereignissen der letzten Sekunden abhängt. Die meisten Finanzsysteme landen dazwischen: ein schwerer Basis-Score, über Nacht vorberechnet, zur Laufzeit der Anfrage gegen ein paar Live-Features aufgefrischt.
Der Fehler, den ich am häufigsten sehe, ist, “Echtzeit” als Standard zu behandeln, weil es modern klingt, und ihn dann in Latenzbudget und Serving-Kosten für Scores zu bezahlen, die innerhalb der nächsten Stunde niemand liest. Die Risikoklasse eines Kreditnehmers ändert sich nicht zwischen zwei Seitenaufrufen. Die Exposure-Stufe einer Gegenpartei ebenso wenig, und auch nicht die Zahlungskonditions-Empfehlung für einen Lieferanten. Was das Modell leisten kann, ist hier nebensächlich. Die Grenze ergibt sich aus der Aktualität, die die Entscheidung braucht, und wenn jeder Input eines Scores bereits vor Eintreffen der Anfrage abgeschlossen war, dann kauft Ihnen die Berechnung zur Laufzeit nur eine höhere Rechnung und einen schwieriger zu handhabenden Fehlermodus ein.
Was die Entscheidung tolerieren kann
Die nützliche Frage ist nicht, wie schnell das Modell ist. Sie lautet, wie alt die Inputs sein dürfen in dem Moment, in dem jemand auf Basis des Outputs handelt. Halten Sie das pro Anwendungsfall fest, bevor Sie die Serving-Architektur auch nur anfassen.
- Eine quartalsweise Kreditlinien-Prüfung liest einen Score, der einen Tag alt sein darf. Vorberechnen.
- Eine AML-Alert-Triage-Warteschlange wird über Nacht aus abgeschlossenen Transaktionen befüllt. Batch ist die natürliche Wahl, und Sie können die teure Anreicherung einmal pro Entität statt pro Analysten-Klick laufen lassen.
- Eine Zahlungsautorisierungs-Entscheidung hängt von Velocity-Counts der letzten sechzig Sekunden ab. Hier rettet Sie keine Vorberechnung; das Signal existierte nicht, als der Batch lief.
- Eine Checkout-Risikoprüfung liegt dazwischen. Die Historie des Kunden ist stabil und vorberechenbar; der aktuelle Warenkorb, das Gerät und die Session sind es nicht.
Sobald Sie es als Frage der Toleranz formulieren, ergibt sich die Aufteilung von selbst. Die Batch-Seite übernimmt alles, was aus bereits abgestimmten und abgeschlossenen Daten abgeleitet ist. Die Echtzeit-Seite übernimmt nur das, was die Anfrage neu einbringt. Die Grenze zwischen beiden ist der Ort, an dem der Großteil der Entwurfsarbeit anfällt, denn dort kollidieren Veralterung und Point-in-time-Korrektheit.
Der andere Input für die Entscheidung ist die Volumenform. Wenn Sie planmäßig Scores für jede Entität im Bestand benötigen, ist Batch das richtige Muster, unabhängig von der Latenz, und die niedrigeren Kosten sind ein Bonus. Zehn Millionen Konten eine HTTP-Anfrage nach der anderen zu scoren, ist eine operative Entscheidung, die Sie zum Quartalsende bereuen werden. Scoren Sie sie in einem einzigen Durchlauf, schreiben Sie die Ergebnisse in einen Store mit Entitäts-Key, und lassen Sie den Online-Pfad ein Lookup statt einer Inferenz durchführen.
Vorberechnen, dann nachschlagen
Das Batch-Muster ist leicht zu beschreiben und leicht falsch zu machen. Sie lassen das Modell über einen Snapshot der Features laufen, schreiben jedes Ergebnis mit Entitäts-Key und As-of-Zeitstempel in einen Low-Latency-Store, und zur Laufzeit der Anfrage holen Sie den gespeicherten Wert. Die Inferenzkosten wandern vollständig vom Hot Path weg. Der Online-Service führt einen Key-Value-Read statt eines Modellaufrufs aus, seine Latenz ist also durch den Store begrenzt und seine Kosten pro Anfrage brechen zusammen.
Drei Dinge müssen zutreffen, damit das trägt:
- Jeder gespeicherte Score trägt den Zeitstempel der Daten, aus denen er berechnet wurde. Ohne ihn können Sie die Frage “seit wann galt das” nicht beantworten und keine Entscheidung für einen Audit Trail oder ein Model-Risk-Review rekonstruieren. Ein gespeicherter Score ohne As-of-Zeitpunkt übersteht ein solches Review nicht; Sie verlangen von jemandem, einer Zahl ohne Herkunftsnachweis zu vertrauen.
- Der Batch-Job ist idempotent und reproduzierbar. Ein erneuter Lauf über denselben Snapshot erzeugt dieselben Scores. Wenn nicht, haben Sie verborgenen Nichtdeterminismus, und Ihre Lineage ist wertlos, sobald jemand zum ersten Mal fragt, warum sich eine Zahl geändert hat.
- Die Features, die den Batch speisen, sind Point-in-time-korrekt. Vorberechnung macht es leichter, Leakage einzuschleusen, denn es ist verführerisch, gegen das zu joinen, was das Warehouse jetzt gerade enthält, statt gegen das, was zum As-of-Stichtag bekannt war. Ein Batch-Score, der auf Lookahead-Daten aufbaut, sieht offline hervorragend aus und versagt in der Produktion still.
Die Aktualisierungsfrequenz ist der Stellhebel. Nächtlich ist üblich, weil es sich an den Settlement- und Reconciliation-Zyklen ausrichtet. Manche Scores rechtfertigen untertägige Neuläufe. Einige brauchen nicht mehr als wöchentlich. Wählen Sie die Frequenz danach, wie schnell sich das Signal bewegt, und bleiben Sie ehrlich, dass ein gespeicherter Score eine Aussage über die Vergangenheit ist, mit Zeitstempel versehen und ausgeliefert.
Der Hybridpfad, den die meisten Systeme brauchen
Reiner Batch ist zu veraltet für alles, was auf aktuelles Verhalten reagiert. Reine Echtzeit ist zu teuer und zu fragil für Scores, die sich meistens nicht ändern. Die übliche Form ist daher ein im Batch vorberechneter Basis-Score, der zur Laufzeit der Anfrage mit einer dünnen Schicht schnell veränderlicher Features kombiniert wird.
Konkret: Der nächtliche Job berechnet den schweren Teil, das Stück, das den vollständigen Feature-Satz und das teure Modell braucht. Dieses Ergebnis landet im Online-Store. Wenn eine Anfrage eintrifft, liest der Service den Basis-Score und mischt ihn mit ein paar Live-Signalen, dem aktuellen Transaktionsbetrag, einem Velocity-Count aus einem Streaming-Window, einem Device-Fingerprint, der vor dreißig Sekunden gesehen wurde. Die Berechnung zur Anfragezeit bleibt klein, das Latenzbudget bleibt also intakt, und Sie reagieren trotzdem auf das gerade Geschehene.
Hier versteckt sich Train/Serve-Skew. Das Feature, das Sie zur Laufzeit in einem Streaming-Window berechnen, muss zu dem Feature passen, das Ihre Batch-Pipeline im Training Point-in-time rekonstruiert. Werden der Streaming-Zähler und der Trainings-Zähler von unterschiedlichem Code gebaut, driften sie auseinander, und Ihre Offline-Metriken beginnen, Sie anzulügen. Dasselbe Feature, eine Definition, von beiden Pfaden ausgeführt. Diese Disziplin ist der Grund, warum sich ein Feature Store in dieser Architektur bezahlt macht.
Eine Sache noch, die klar ausgesprochen gehört: Die Aufteilung ist genauso ein Kosten- wie ein Latenzhebel. Inferenz in den Batch zu verlagern heißt, dass Sie das Modell nach Ihrem Zeitplan laufen lassen, auf Hardware, die Sie auf Durchsatz dimensionieren können, abseits des Anfragepfads, wo ein Traffic-Spike sonst Ihre Inferenzrechnung genau dann vervielfachen würde, wenn Sie sich die Last am wenigsten leisten können. Dafür geben Sie Aktualität auf. Entscheiden Sie den Kompromiss pro Score, bewusst, und dokumentieren Sie, was Sie entschieden haben.
Häufige Fragen
Wie entscheide ich, ob ein Score in den Batch- oder in den Echtzeit-Pfad gehört?
Fragen Sie sich, wovon der Score zum Entscheidungszeitpunkt abhängt. Hängt er nur von Daten ab, die bereits vor Stunden abgeschlossen wurden, berechnen Sie ihn im Batch vor und liefern den gespeicherten Wert aus. Hängt er von der aktuellen Anfrage oder von Ereignissen der letzten Sekunden ab, muss er zum Zeitpunkt der Anfrage berechnet werden.
Veraltet ein vorberechneter Score nicht?
Ja, und genau das ist der Kompromiss, den Sie eingehen. Ein nächtlicher Score spiegelt die Welt zum Stichtag der letzten Nacht wider. Für eine Kreditlinien-Prüfung ist das in Ordnung, für Autorisierungs-Betrugsprüfung inakzeptabel. Passen Sie die Aktualisierungsfrequenz daran an, wie schnell sich das zugrunde liegende Signal tatsächlich bewegt, und versehen Sie jeden gespeicherten Score mit dem As-of-Zeitpunkt, zu dem er berechnet wurde.
Wo liegt in der Praxis üblicherweise die Aktualitätsgrenze?
Die meisten Systeme landen bei einem Hybrid. Ein stabiler Basis-Score wird im Batch vorberechnet, und ein kleiner Satz schnell veränderlicher Features wird zum Zeitpunkt der Anfrage damit kombiniert. Diese Aufteilung hält die teuren Modellläufe vom Hot Path fern und erlaubt es Ihnen dennoch, auf das gerade Geschehene zu reagieren.