Quel problème un feature store résout-il qu'un bon pipeline de données ne résout pas ?

Il résout la cohérence entre entraînement et service. La même caractéristique doit être calculée depuis l'historique en batch pour l'entraînement et depuis des données fraîches à faible latence pour le service, et quand ce sont deux implémentations séparées elles divergent. Un feature store définit une caractéristique une seule fois, la matérialise dans un magasin hors ligne pour des données d'entraînement correctes dans le temps et dans un magasin en ligne pour des lectures en millisecondes, et fournit des jointures correctes à la date.

Le problème, c'est que la même caractéristique a deux vies. Pour l'entraînement il me faut sa valeur à un horodatage historique donné, jointe sans inclure par accident quoi que ce soit survenu après. Pour le service il me la faut maintenant, en moins de dix millisecondes, indexée par entité. Si ce sont deux bases de code, et ce sont toujours deux bases de code au départ, elles divergent. Quelqu'un change une fenêtre de trente à vingt-huit jours dans le job d'entraînement, personne ne touche au chemin de service, et voilà le modèle qui score sur des caractéristiques sur lesquelles il n'a jamais été entraîné. Cette dérive est silencieuse, et c'est ce qui la rend coûteuse. Un feature store vous donne une définition unique qui se matérialise à la fois en table hors ligne pour l'entraînement et en magasin clé-valeur en ligne pour le service, plus des jointures correctes à la date pour que la requête historique ne puisse pas laisser fuiter le futur. Cela dit, je n'en monterais pas un pour une équipe avec deux modèles. Le surcoût est réel, et vous obtenez l'essentiel du bénéfice avec une bibliothèque de transformations partagée plus un job planifié qui écrit dans un cache. Je passerais à un feature store géré une fois que plusieurs équipes partagent des caractéristiques, parce que c'est là que les définitions dupliquées se multiplient.