Wie entscheidest du zwischen Batch-Scoring und Echtzeit-Inferenz für ein Modell?

Entscheide anhand von Frische und der Form des Requests. Wenn Features und Population im Voraus bekannt sind und Vorhersagen stundenlang gültig bleiben, rechne im Batch vor und serviere aus einer Lookup-Tabelle, das ist einfacher, billiger und weit zuverlässiger. Geh in Echtzeit, wenn Features vom aktuellen Request abhängen, die Entity-Menge unbegrenzt ist oder Veraltung die Entscheidung spürbar verschlechtert.

Ich starte mit zwei Fragen: wie alt darf die Vorhersage sein, und weiß ich im Voraus, wen ich score. Bei so etwas wie einem wöchentlichen Churn-Score über einen bestehenden Kundenstamm sprechen beide Antworten für Batch. Ich lasse einen nächtlichen Job laufen, schreibe die Scores in eine Tabelle, und Serving wird zu einem Primary-Key-Lookup, der im Grunde nicht kaputtgehen kann. Kein Beschleuniger im Request-Pfad, keine Cold Starts, und wenn der Job bricht, habe ich immer noch die Scores von gestern, was ein viel sanfterer Fehlerfall ist als ein Timeout. Echtzeit verdient sich ihren Platz, wenn die Features aus dem Request selbst kommen, etwa was der User gerade getippt hat oder was jetzt in seinem Warenkorb liegt, oder wenn die Entity noch gar nicht existiert, etwa eine brandneue Session. Die meisten Systeme, die ich gebaut habe, sind hybrid geworden: schwere Aggregate im Batch berechnet und gecacht, zur Request-Zeit mit einer Handvoll Live-Signale gejoint und dann gescort. Das hält den Online-Pfad billig und reagiert trotzdem auf das, was gerade passiert ist. Der Fehler, den ich zu vermeiden versuche, ist Echtzeit für ein hübscheres Architekturdiagramm zu wählen, wenn downstream niemand die Frische überhaupt nutzt.