Tables d’inférence pour la surveillance et le débogage des modèles

L’article présente les tables d’inférence pour le monitoring de modèles servis. Le diagramme suivant montre un workflow typique avec des tables d’inférence. La table d’inférence capture automatiquement les requêtes entrantes et les réponses sortantes pour un point de terminaison de mise en service de modèle et les enregistre sous forme de table Delta Unity Catalog. Vous pouvez utiliser les données de cette table pour monitorer, déboguer et améliorer des modèles ML.

Pour les points de terminaison de service de modèle qui hébergent des modèles externes, vous ne pouvez activer que les tables d’inférence à l’aide de la passerelle IA.

Que sont les tables d’inférence ?

Le monitoring des performances des modèles dans des workflows de production est un aspect important du cycle de vie de modèles ML et IA. Les tables d’inférence simplifient la supervision et le diagnostic des modèles en journalisant continuellement les entrées des requêtes de mise en service et les réponses (prédictions) à partir des points de terminaison de service de modèle Mosaic AI, puis en les enregistrant dans une table Delta dans Unity Catalog. Vous pouvez ensuite utiliser toutes les capacités de la plateforme Databricks, comme les requêtes Databricks SQL, les notebooks et Lakehouse Monitoring pour surveiller, déboguer et optimiser vos modèles.

Vous pouvez activer des tables d’inférence sur tout point de terminaison de mise en service de modèles existant ou nouvelle créé pour que toutes les requêtes à ce point de terminaison soient automatiquement journalisées vers une table d’Unity Catalog.

Certaines applications courantes pour les tables d’inférence sont les suivantes :

• Monitorer des données et qualité du modèle. Vous pouvez continuellement monitorer les performances de votre modèle et la dérive de données en utilisant Lakehouse Monitoring. Lakehouse Monitoring génère automatiquement des tableaux de bord de qualité des modèles et des données que vous pouvez partager avec des parties prenantes. En outre, vous pouvez activer des alertes pour savoir quand vous devez réentraîner votre modèle en fonction de changements dans les données entrantes ou de baisses en matière de performances des modèles.
• Déboguer des problèmes de production. Les tables d’inférence journalisent des données telles que des codes d’état HTTP, des délais d’exécution de modèles et du code JSON de requête et de réponse. Vous pouvez utiliser ces données de performances à des fins de débogage. Vous pouvez également utiliser les données historiques dans les tables d’inférence pour comparer les performances d’un modèle sur l’historique des requêtes.
• Créez un corpus d’apprentissage. En rejoignant les tables d’inférence avec des étiquettes de vérité de terrain, vous pouvez créer un corpus d’apprentissage que vous pouvez utiliser pour réentraîner ou ajuster et améliorer votre modèle. En utilisant des travaux Databricks, vous pouvez configurer une boucle de feedback continue et automatiser le réentraînement.

Exigences

• Votre espace de travail doit être activé pour Unity Catalog.
• Le créateur ou la créatrice du point de terminaison et le modificateur doivent avoir Peut gérer autorisation sur le point de terminaison. Consultez Listes de contrôle d’accès.
• Le créateur ou la créatrice du point de terminaison et le modificateur doivent avoir les autorisations suivantes dans Unity Catalog :
  • Autorisations USE CATALOG sur le catalogue spécifié.
  • Autorisations USE SCHEMA sur le schéma spécifié.
  • Autorisations CREATE TABLE dans le schéma.

Activer désactiver les tables d’inférence

La section vous présente comment activer ou désactiver les tables d’inférence en tirant parti de l’interface utilisateur Databricks. Vous pouvez également utilisez l’API ; voir Activer des tables d’inférence sur des points de terminaison de mise en service de modèles en utilisant l’API pour découvrir des instructions.

Le propriétaire des tables d’inférence est l’utilisateur ayant créé le point de terminaison. Toutes les listes de contrôle d’accès (ACL) de la table suivent les autorisations standard du catalogue Unity et peuvent être modifiées par le propriétaire de la table.

Pour activer les tables d’inférence lors de la création du point de terminaison, procédez comme suit :

1. Cliquez sur Service dans l’interface utilisateur de Databricks Mosaic AI.

2. Cliquez sur Créer un point de terminaison de mise en service.

3. Sélectionnez Activer des tables d’inférence.

4. Dans les menus déroulants, sélectionnez le catalogue et le schéma souhaités pour l’emplacement souhaité de la table.

   

5. Le nom de table par défaut est <catalog>.<schema>.<endpoint-name>_payload. Si vous le souhaitez, vous pouvez entrer un préfixe de table personnalisé.

6. Cliquez sur Créer un point de terminaison de mise en service.

Vous pouvez également activer les tables d’inférence sur un point de terminaison existant. Pour modifier une configuration de point de terminaison existante, procédez comme suit :

1. Rendez-vous sur la page de votre point de terminaison.
2. Cliquez sur Modifier la configuration.
3. Suivez les instructions précédentes, à partir de l’étape 3.
4. Une fois terminé, cliquez sur Mettre à jour le point de terminaison de service.

Suivez ces instructions pour désactiver des tables d’inférence :

1. Rendez-vous sur la page de votre point de terminaison.
2. Cliquez sur Modifier la configuration.
3. Cliquez sur Activer la table d’inférence pour supprimer la coche.
4. Lorsque les spécifications des points de terminaison vous conviennent, cliquez sur Mettre à jour.

Workflow : monitorer les performances d’un modèle en utilisant des tables d’inférence

Pour monitorer les performances d’un modèle en utilisant des tables d’inférence, suivez ces étapes :

1. Activez les tables d’inférence sur votre point de terminaison au moment de sa création ou lors d’une mise à jour ultérieure.
2. Planifiez un workflow pour traiter les charges utiles JSON dans la table d’inférence en les décompressant en fonction du schéma du point de terminaison.
3. (Facultatif) Joignez les demandes et réponses décompressées avec des étiquettes ground-truth pour permettre le calcul des métriques de qualité du modèle.
4. Créez un moniteur sur la table Delta résultante et actualisez les métriques.

Le notebook de démarrage implémente ce workflow.

Notebook de démarrage de surveillance d’une table d’inférence

Le notebook suivant implémente les étapes décrites ci-dessus pour décompresser des requêtes à partir d’une table d’inférence Lakehouse Monitoring. Le notebook peut être exécuté à la demande ou selon une planification périodique en utilisant des travaux Databricks.

Notebook de démarrage de surveillance d’une table d’inférence avec la surveillance de Lakehouse

Obtenir le notebook

Notebook de démarrage pour monitorer la qualité d’un texte à partir de points de terminaison servant de grands modèles de langage (LLM)

Le notebook suivant décompresse des requêtes à partir d’une table d’inférence, calcule un ensemble de mesures d’évaluation du texte (telles que la lisibilité et la toxicité) et permet le monitoring de ces mesures. Le notebook peut être exécuté à la demande ou selon une planification périodique en utilisant des travaux Databricks.

Notebook de démarrage Lakehouse Monitoring de table d’inférence de LLM

Obtenir le notebook

Interroger et analyser des résultats dans la table d’inférence

Une fois vos modèles servis prêts, toutes les requêtes adressées à vos modèles sont enregistrées automatiquement dans la table d’inférence, ainsi que les réponses. Vous pouvez afficher la table dans l’interface utilisateur, interroger la table à partir de DBSQL ou d’un notebook, ou interroger la table en utilisant l’API REST.

Pour afficher la table dans l’interface utilisateur : sur la page du point de terminaison, cliquez sur le nom de la table d’inférence pour ouvrir la table dans l’Explorateur de catalogues.

Pour interroger la table à partir de DBSQL ou d’un notebook Databricks : vous pouvez exécuter du code semblable à ce qui suit pour interroger la table d’inférence.

SELECT * FROM <catalog>.<schema>.<payload_table>

Si vous avez activé des tables d’inférence en utilisant l’interface utilisateur, payload_table est le nom de table que vous avez affecté lors de votre création du point de terminaison. Si vous avez activé des tables d’inférence en utilisant l’API, payload_table est signalé dans la section state de la réponse auto_capture_config. Pour obtenir un exemple, voir Activer des tables d’inférence sur des points de terminaison de mise en service de modèles en utilisant l’API.

Remarque sur les performances

Après avoir appelé le point de terminaison, vous pouvez voir l’appel enregistré dans votre table d’inférence dans l’heure après l’envoi d’une demande de scoring. De plus, Azure Databricks garantit que les journaux soient envoyés au moins une fois. Il est donc possible, bien que peu probable, que les journaux soient envoyés en double.

Schéma de table d’inférence Unity Catalog

Chaque requête et réponse journalisée dans une table d’inférence est écrite dans une table Delta avec le schéma suivant :

Spécifiez client_request_id

Le champ client_request_id est une valeur facultative que l’utilisateur peut fournir dans le corps de la demande de service du modèle. Il vous permet de fournir son propre identificateur pour une requête qui s’affiche dans la table d’inférence finale sous client_request_id et peut être utilisé pour joindre votre demande à d’autres tables qui utilisent client_request_id, comme la jonction d’étiquettes de vérité terrain. Pour spécifier client_request_id, incluez-le en tant que clé de niveau supérieur de la charge utile de la requête. Si client_request_id n’est pas spécifié, la valeur apparaît comme nulle dans la ligne correspondant à la demande.

{
  "client_request_id": "<user-provided-id>",
  "dataframe_records": [
    {
      "sepal length (cm)": 5.1,
      "sepal width (cm)": 3.5,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.9,
      "sepal width (cm)": 3,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.7,
      "sepal width (cm)": 3.2,
      "petal length (cm)": 1.3,
      "petal width (cm)": 0.2
    }
  ]
}

client_request_id peut être utilisé ultérieurement pour les jonctions d’étiquettes de vérité terrain s’il existe d’autres tables qui ont des étiquettes associées à client_request_id.

Limites

• Les clés gérées par le client ne sont pas prises en charge.
• Pour les points de terminaison qui hébergent des modèles de fondation, les tables d’inférence sont prises en charge seulement sur des charges de travail avec débit provisionné.
• Azure Firewall peut entraîner l’échec de la création de la table Unity Catalog Delta, qui n’est donc pas prise en charge par défaut. Contactez l’équipe de votre compte Databricks pour l’activer.
• Lorsque des tables d’inférence sont activées, la limite de concurrence maximale totale est de 128 pour tous les modèles servis dans un point de terminaison unique. Contactez l’équipe en charge de votre compte Azure Databricks pour demander une augmentation de cette limite.
• Si une table d’inférence contient plus de 500 000 fichiers, aucune donnée supplémentaire n’est enregistrée. Pour éviter de dépasser cette limite, exécutez OPTIMIZE ou configurez la rétention sur votre table en supprimant des données plus anciennes. Pour vérifier le nombre de fichiers de votre table, exécutez DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• La remise du journal des tables d’inférence est actuellement la meilleure solution. Toutefois, vous pouvez prévoir la disponibilité des journaux dans l’heure qui suit la demande. Contactez votre équipe de compte Databricks pour plus d’informations.

Pour connaître les limitations générales des points de terminaison de service de modèle, consultez limites et régions du service de modèle.