Bases de caractéristiques : Feast et Tecton

Les équipes réimplémentent sans cesse les mêmes caractéristiques, et les chaînes de traitement d'entraînement les calculent différemment du code de mise à disposition. Un magasin de caractéristiques centralise les définitions, la réutilisation et la mise à disposition des caractéristiques, éliminant le travail en double et le décalage entre l'entraînement et la mise à disposition.

Deux magasins de caractéristiques de premier plan :

• Feast : libre, léger, avec une infrastructure que vous fournissez
• Tecton : commercial et géré, avec des chaînes de traitement de caractéristiques en continu et une gouvernance supplémentaires

Tous deux partagent les concepts fondamentaux d'entités, de caractéristiques et de magasins hors ligne et en ligne.

Une entité est l'élément décrit par les caractéristiques (un utilisateur, un produit). Une vue de caractéristiques regroupe les caractéristiques associées à une entité et pointe vers une source de données. Ces définitions résident dans le code et sont versionnées comme n'importe quel autre artefact.

feast apply enregistre vos définitions d'entités et de vues de caractéristiques dans le registre du magasin de caractéristiques. C'est ainsi que le magasin découvre quelles caractéristiques existent et d'où proviennent leurs données.

Les caractéristiques doivent être chargées dans le magasin en ligne avant la mise à disposition. La matérialisation calcule les valeurs de caractéristiques jusqu'à un instant donné et les écrit dans le magasin en ligne (par exemple Redis), afin qu'elles soient prêtes à être lues avec une faible latence.

feast materialize prend une date de début et une date de fin, puis charge dans le magasin en ligne les valeurs de caractéristiques correspondant à cette période. Vous l'exécutez selon une planification afin de conserver des caractéristiques en ligne récentes.

Lors de l'inférence, vous récupérez les caractéristiques les plus récentes pour certaines entités avec get_online_features, en transmettant des entity_rows qui indiquent les entités à rechercher. La commande renvoie les valeurs les plus récentes en quelques millisecondes.

Pour l'entraînement, vous associez les valeurs de caractéristiques aux étiquettes historiques. Le magasin de caractéristiques lit les données du magasin hors ligne et renvoie un jeu de données aligné sur l'horodatage de chaque étiquette, afin que les données d'entrée de l'entraînement correspondent à celles que la mise à disposition fournira.

La garantie essentielle du magasin de caractéristiques est la jointure à un instant donné : pour chaque étiquette d'entraînement, il récupère uniquement les valeurs de caractéristiques qui étaient connues à cet instant ou avant. Cela empêche d'utiliser des informations futures.

Sans exactitude temporelle lors des jointures à un instant donné, vous risquez une fuite de données : entraîner le modèle sur des valeurs de caractéristiques calculées après l'événement associé à l'étiquette, ce qui gonfle les métriques hors ligne mais s'effondre en production. Le magasin de caractéristiques garantit automatiquement l'exactitude temporelle.

Le cycle de vie du magasin de caractéristiques relie tous ces éléments :

• feast apply enregistre les définitions
• feast materialize charge le magasin en ligne
• l'entraînement utilise des jointures à un instant donné depuis le magasin hors ligne
• la mise à disposition lit les valeurs récentes via get_online_features

Vérifiez vos connaissances sur les magasins de caractéristiques.

Vous avez découvert les magasins de caractéristiques avec Feast et Tecton :

• feast apply enregistre les entités et les vues de caractéristiques
• feast materialize charge le magasin en ligne pour les dates indiquées
• get_online_features fournit des valeurs récentes pour entity_rows
• Les jointures à un instant donné construisent des données d'entraînement exemptes de fuites