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

Article
03/26/2024

Important

Cette fonctionnalité est disponible en préversion publique.

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.

Flux de travail des tables d’inférence

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 le monitoring et les diagnostics des modèles en journalisant continuellement les entrées de requêtes de mise en service et les réponses (prédictions) à partir de points de terminaison de mise en service de modèles Databricks et en les enregistrant dans une table Delta d’Unity Catalog. Vous pouvez ensuite utiliser toutes les fonctionnalités de la plateforme Databricks, comme les requêtes DBSQL, 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. L’utilisation des workflows Databricks vous permet de configurer une boucle continue de commentaires et d’automatiser la réentraînement.

Exigences

Votre espace de travail doit être activé pour Unity Catalog.
Pour activer les tables d’inférence sur un point de terminaison, le créateur du point de terminaison et le modificateur ont besoin des autorisations suivantes :
- L’autorisation PEUT GÉRER sur le point de terminaison.
- 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.

Avertissement

La table d’inférence peut être altérée si vous effectuez l’une des actions suivantes :

Modifiez le schéma de la table.
Modifiez le nom de la table.
Supprimez la table.
Perdez les autorisations sur le catalogue ou le schéma Unity Catalog.

Dans ce cas, le auto_capture_config de l’état du point de terminaison affiche un état FAILED pour la table de charge utile. Si cela se produit, vous devez créer un point de terminaison pour continuer à utiliser des tables d’inférence.

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

Cliquez sur Service dans l’interface utilisateur Databricks Machine Learning.
Cliquez sur Créer un point de terminaison de mise en service.
Sélectionnez Activer des tables d’inférence.
Dans les menus déroulants, sélectionnez le catalogue et le schéma souhaités pour l’emplacement souhaité de la table.
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é.
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 :

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

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

Important

Lorsque vous désactivez des tables d’inférence sur un point de terminaison, vous ne pouvez pas les réactiver. Pour continuer à utiliser des tables d’inférence, vous devez créer un point de terminaison et y activer des tables d’inférence.

Rendez-vous sur la page de votre point de terminaison.
Cliquez sur Modifier la configuration.
Cliquez sur Activer la table d’inférence pour supprimer la coche.
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 :

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.
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.
(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.
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. Vous pouvez exécuter le notebook à la demande ou selon une planification périodique à l’aide de workflows 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. Vous pouvez exécuter le notebook à la demande ou selon une planification périodique à l’aide de workflows 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.

lien vers le nom de la table d’inférence sur la page du point de terminaison

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 les 10 minutes 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 :

Remarque

Si vous appelez le point de terminaison avec un lot d’entrées, le lot entier est enregistré sous forme d’une ligne.

Nom de colonne	Description	Type
`databricks_request_id`	Identificateur de requête généré par Azure Databricks attaché à toutes les requêtes de mise en service de modèle.	STRING
`client_request_id`	Identificateur de requête généré par un client facultatif qui peut être spécifié dans le corps de la requête de mise en service de modèle. Pour plus d’informations, consultez Spécifier `client_request_id`.	STRING
`date`	Date UTC de réception de la requête de mise en service de modèle.	DATE
`timestamp_ms`	Timestamp en millisecondes Epoch de l’heure de réception de la requête de mise en service du modèle.	LONG
`status_code`	Code d’état HTTP retourné par le modèle.	INT
`sampling_fraction`	Fraction d’échantillonnage utilisée dans l’événement où la requête a été échantillonnée. Cette valeur est comprise entre 0 et 1, où 1 indique que 100 % des requêtes entrantes ont été incluses.	DOUBLE
`execution_time_ms`	Durée d’exécution en millisecondes pour laquelle le modèle a réalisé l’inférence. Cela n’inclut pas les latences réseau de surcharge et représente uniquement le temps nécessaire pour que le modèle génère des prédictions.	LONG
`request`	Corps JSON de la requête brute qui a été envoyée au point de terminaison de mise en service de modèle.	STRING
`response`	Corps JSON de réponse brute retourné par le point de terminaison de mise en service de modèle.	STRING
`request_metadata`	Mappage des métadonnées liées au point de terminaison de mise en service de modèle associé à la requête. Ce mappage contient le nom du point de terminaison, le nom du modèle et la version du modèle utilisées pour votre point de terminaison.	MAP<STRING, STRING>

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é.
- Les tables d’inférence sur les points de terminaison de débit approvisionné ne prennent pas en charge la journalisation des requêtes de streaming.
Les tables d’inférence ne sont pas prises en charge sur les points de terminaison qui hébergent des modèles externes.
Le Pare-feu Azure n’est pas pris en charge et peut entraîner des échecs de création de la table Delta Unity Catalog.
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>.

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.