Comment Lakehouse AI améliore la précision des modèles grâce à des calculs en temps réel

La qualité prédictive d’un modèle d’apprentissage automatique reflète directement la qualité des données utilisées pour entraîner et servir le modèle. Habituellement, les caractéristiques, ou les données d’entrée du modèle, sont calculées à l’avance, enregistrées, puis recherchées et transmises au modèle à des fins d’inférence. Le défi se pose lorsque ces caractéristiques ne peuvent pas être précalculées, car les performances du modèle sont souvent directement corrélées à la fraîcheur des données utilisées pour le calcul des caractéristiques. Pour simplifier le défi lié à la fourniture de cette classe de fonctionnalités, nous sommes ravis d’annoncer le calcul des fonctionnalités à la demande.

Les cas d’utilisation tels que les recommandations, les systèmes de sécurité et la détection des fraudes nécessitent que les fonctionnalités soient calculées à la demande au moment de l’évaluation de ces modèles. Les scénarios incluent :

1. Lorsque les données d’entrée pour les entités ne sont disponibles qu’au moment de la diffusion du modèle. Par exemple, distance_from_restaurant nécessite le dernier emplacement connu d’un utilisateur déterminé par un appareil mobile.
2. Situations où la valeur d’une fonctionnalité varie en fonction du contexte dans lequel elle est utilisée. Les mesures d’engagement doivent être interprétées très différemment lorsque device_type est mobilepar opposition à ordinateur de bureau.
3. Cas où il est prohibitif de précalculer, de stocker et d’actualiser les fonctionnalités. Un service de streaming vidéo peut compter des millions d’utilisateurs et des dizaines de milliers de films, ce qui rend prohibitif le précalcul d’une fonctionnalité telle que avg_rating_of_similar_movies.

Afin de prendre en charge ces cas d’utilisation, les fonctionnalités doivent être calculées au moment de l’inférence. Cependant, le calcul des fonctionnalités pour la formation des modèles est généralement effectué à l’aide de frameworks rentables et optimisés en termes de débit comme Apache Spark(™). Cela pose deux problèmes majeurs lorsque ces fonctionnalités sont requises pour un scoring en temps réel :

1. Effort humain, retards et biais de formation/service : L’architecture nécessite trop souvent de réécrire les calculs des fonctionnalités dans des langages côté serveur optimisés en termes de latence, comme Java ou C++. Cela introduit non seulement la possibilité d’un biais de formation et de diffusion car les fonctionnalités sont créées dans deux langues différentes, mais nécessite également que les ingénieurs en apprentissage automatique maintiennent et synchronisent la logique de calcul des fonctionnalités entre les systèmes hors ligne et en ligne.
2. Complexité architecturale pour calculer et fournir des fonctionnalités aux modèles. Ces systèmes de pipelines d’ingénierie de fonctionnalités doivent être déployés et mis à jour en tandem avec les modèles servis. Lorsque de nouvelles versions de modèle sont déployées, elles nécessitent de nouvelles définitions de fonctionnalités. De telles architectures ajoutent également des retards de déploiement inutiles. Les ingénieurs en machine learning doivent s’assurer que les pipelines et les points de terminaison de calcul des nouvelles fonctionnalités sont indépendants des systèmes en production afin d’éviter de se heurter aux limites de débit, aux contraintes de ressources et aux bandes passantes du réseau.

Dans l’architecture ci-dessus, la mise à jour d’une définition de fonctionnalité peut être une entreprise majeure. Un pipeline de caractérisation mis à jour doit être développé et déployé en tandem avec l’original, qui continue de prendre en charge la formation et l’inférence par lots avec l’ancienne définition de fonctionnalités. Le modèle doit être recyclé et validé à l’aide de la définition de fonctionnalité mise à jour. Une fois le déploiement autorisé, les ingénieurs doivent d’abord réécrire la logique de calcul des fonctionnalités dans le serveur de fonctionnalités et déployer une version indépendante du serveur de fonctionnalités afin de ne pas affecter le trafic de production. Après le déploiement, de nombreux tests doivent être exécutés pour garantir que les performances du modèle mis à jour sont les mêmes que celles observées lors du développement. L’orchestrateur de modèles doit être mis à jour pour diriger le trafic vers le nouveau modèle. Enfin, après un certain temps de préparation, l’ancien modèle et l’ancien serveur de fonctionnalités peuvent être supprimés.

Pour simplifier cette architecture, améliorer la vitesse d’ingénierie et augmenter la disponibilité, Databricks lance la prise en charge du calcul de fonctionnalités à la demande. La fonctionnalité est intégrée directement dans Unity Catalog, simplifiant ainsi le parcours utilisateur de bout en bout pour créer et déployer des modèles.

Les fonctionnalités à la demande ont contribué à réduire considérablement la complexité de nos pipelines d’ingénierie de fonctionnalités. Grâce aux fonctionnalités à la demande, nous pouvons éviter de gérer des transformations compliquées et propres à chacun de nos clients. Au lieu de cela, nous pouvons simplement commencer avec notre ensemble de fonctionnalités de base et les transformer, par client, à la demande pendant la formation et l’inférence. En réalité, les fonctionnalités à la demande ont permis de libérer notre capacité à créer notre prochaine génération de modèles. – Chris Messier, ingénieur senior en apprentissage automatique chez MissionWired

Utilisation de fonctions dans des modèles d’apprentissage automatique

Avec Ingénierie des fonctionnalités dans le catalogue Unity, les data scientists peuvent récupérer des fonctionnalités prématérialisées à partir de tables et calculer des fonctionnalités à la demande à l’aide de fonctions. Le calcul à la demande est exprimé sous forme de fonctions définies par l’utilisateur (UDF) Python, qui sont des entités gouvernées dans Unity Catalog. Les fonctions sont créées en SQL et peuvent ensuite être utilisées dans Lakehouse dans des requêtes SQL, des tableaux de bord, des blocs-notes et maintenant pour calculer des fonctionnalités dans des modèles en temps réel.

Le graphique de lignée UC enregistre les dépendances du modèle sur les données et les fonctions.

CREATE OR REPLACE FUNCTION main.on_demand_demo.avg_hover_time(blob STRING)
RETURNS FLOAT
LANGUAGE PYTHON
COMMENT "Extract hover time from JSON blob and computes average"
AS $$
import json

def calculate_average_hover_time(json_blob):
    # Parse the JSON blob
    data = json.loads(json_blob)

    # Ensure the 'hover_time' list exists and is not empty
    hover_time_list = data.get('hover_time')
    if not hover_time_list:
        raise ValueError("No hover_time list found or list is empty")

    # Sum the hover time durations and calculate the average
    total_duration = sum(hover_time_list)
    average_duration = total_duration / len(hover_time_list)

    return average_duration

return calculate_average_hover_time(blob)
$$

Pour utiliser une fonction dans un modèle, incluez-la dans l’appel à create_training_set.

from databricks.feature_store import FeatureStoreClient

fs = FeatureStoreClient()

features = [
    FeatureFunction(
        udf_name="main.on_demand_demo.avg_hover_time",
        output_name="on_demand_output",
        input_bindings={"blob": "json_blob"},
    ),
 ...
]

training_set = fs.create_training_set(
    raw_df, feature_lookups=features, label="label", exclude_columns=["id"]
)

La fonction est exécutée par Spark pour générer des données de formation pour votre modèle.

La fonction est également exécutée en temps réel à l’aide de Python et de pandas natifs. Bien que Spark ne soit pas impliqué dans le parcours en temps réel, le même calcul est garanti équivalent à celui utilisé au moment de la formation.

Une architecture simplifiée

Les modèles, les fonctions et les données coexistent tous dans Unity Catalog, permettant une gouvernance unifiée. Un catalogue partagé permet aux data scientists de réutiliser des caractéristiques et des fonctions pour la modélisation, garantissant ainsi la cohérence dans la façon dont les caractéristiques sont calculées au sein d’une organisation. Une fois servi, le lignage du modèle est utilisé pour déterminer les fonctions et les tables à utiliser comme entrée dans le modèle, éliminant ainsi la possibilité d’un biais de formation et de diffusion. Dans l’ensemble, cela se traduit par une architecture considérablement simplifiée.

Lakehouse AI automatise le déploiement des modèles : lorsqu’un modèle est déployé, Databricks Model Serving déploie automatiquement toutes les fonctions requises pour permettre le calcul en direct des fonctionnalités. Au moment de la demande, les fonctionnalités prématérialisées sont recherchées dans les magasins en ligne et les fonctionnalités à la demande sont calculées en exécutant le corps de leurs UDF Python.

Exemple simple – Temps de survol moyen

Dans cet exemple, une fonctionnalité à la demande analyse une chaîne JSON pour extraire une liste des temps de survol sur une page Web. Ces temps sont moyennés ensemble et la moyenne est transmise en tant que caractéristique à un modèle.

L’interrogation du modèle transmet un blob JSON contenant les temps de survol. Par exemple:

curl \
  -u token:$DATABRICKS_TOKEN \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "dataframe_records": [
      {"json_blob": "{\"hover_time\": [5.5, 2.3, 10.3]}"}
    ]
  }' \
  <host>/serving-endpoints/<endpoint_name>/invocations

Le modèle calculera le temps de survol moyen à la demande, puis évaluera le modèle en utilisant le temps de survol moyen comme fonctionnalité.

Démo simple

Exemple sophistiqué – Distance du restaurant

Dans cet exemple, un modèle de recommandation de restaurant prend une chaîne JSON contenant l’emplacement d’un utilisateur et un identifiant de restaurant. L’emplacement du restaurant est recherché à partir d’un tableau de caractéristiques prématérialisé publié dans une boutique en ligne, et une fonctionnalité à la demande calcule la distance entre l’utilisateur et le restaurant. Cette distance est transmise en entrée à un modèle.

Notez que cet exemple inclut une recherche de l’emplacement d’un restaurant, puis une transformation ultérieure pour calculer la distance entre ce restaurant et l’utilisateur.

Démo de recommandation de restaurant

Apprendre encore plus

Pour obtenir de la documentation sur l’API et des conseils supplémentaires, voir Fonctionnalités de calcul à la demande à l’aide des fonctions Python définies par l’utilisateur.

Vous avez un cas d’utilisation que vous aimeriez partager avec Databricks ? Contactez-nous à [email protected].