Comment décidez-vous entre un scoring en batch et une inférence en temps réel pour un modèle ?

Décidez à partir de la fraîcheur et de la forme de la requête. Si les caractéristiques et la population sont connues à l'avance et que les prédictions restent valables des heures, précalculez en batch et servez depuis une table de correspondance, ce qui est plus simple, moins cher et bien plus fiable. Passez au temps réel quand les caractéristiques dépendent de la requête en cours, quand l'ensemble d'entités est non borné, ou quand la péremption nuit réellement à la décision.

Je pars de deux questions : quelle péremption la prédiction supporte-t-elle, et est-ce que je sais à l'avance qui je score. Pour quelque chose comme un score d'attrition hebdomadaire sur une base de clients existante, les deux réponses vont vers le batch. Je lance un job de nuit, j'écris les scores dans une table, et le service devient une lecture par clé primaire qui ne peut pratiquement pas échouer. Pas d'accélérateur sur le chemin de la requête, pas de démarrage à froid, et si le job casse j'ai encore les scores d'hier, ce qui est un échec bien plus doux qu'un dépassement de délai. Le temps réel gagne sa place quand les caractéristiques viennent de la requête elle-même, comme ce que l'utilisateur vient de taper ou ce qu'il a dans son panier à l'instant, ou quand l'entité peut ne pas exister encore, comme une toute nouvelle session. La plupart des systèmes que j'ai construits ont fini hybrides : des agrégats lourds calculés en batch et mis en cache, joints au moment de la requête à une poignée de signaux en direct, puis scorés. Ça garde le chemin en ligne bon marché tout en réagissant à ce qui vient de se passer. L'erreur que j'essaie d'éviter, c'est de choisir le temps réel pour un plus joli schéma d'architecture alors que rien en aval ne consomme réellement cette fraîcheur.