Tables d'inférence pour le monitoring et le debugging des modèles

important

Cette documentation a été retirée et pourrait ne pas être mise à jour. Les produits, services ou technologies mentionnés dans ce contenu ne sont plus pris en charge.

Databricks recommande les tables d’inférence compatibles avec AI Gateway pour leur disponibilité sur les endpoints de service de modèle personnalisé, de modèle de fondation et d’agent. Pour obtenir des instructions sur la migration vers les tables d’inférence compatibles avec AI Gateway, consultez la page Migration vers les tables d’inférence AI Gateway.

Cet article décrit les tables d'inférence pour le monitoring des modèles servis. Le diagramme suivant montre un flux de travail typique avec les tables d'inférence. La table d'inférence capture automatiquement les requêtes entrantes et les réponses sortantes pour un endpoint de service de modèle et les enregistre en tant que table Delta de Unity Catalog. Vous pouvez utiliser les données de ce tableau pour surveiller, déboguer et améliorer les modèles ML.

Que sont les tables d'inférence ?

Le monitoring de la performance des modèles dans les workflows de production est un aspect important du cycle de vie des modèles d'IA et de ML. Les tables d'inférence simplifient le monitoring et les diagnostics des modèles en enregistrant en continu les entrées et les réponses (prédictions) des requêtes de service provenant des Endpoint de Model Serving et en les sauvegardant dans une table Delta dans Unity Catalog. Vous pouvez ensuite utiliser toutes les capacités de la plateforme Databricks, telles que les requêtes Databricks SQL, les notebooks et le profilage des données pour surveiller, déboguer et optimiser vos modèles.

Vous pouvez activer les tables d'inférence sur n'importe quel Endpoint de service de modèle existant ou nouvellement créé, et les requêtes vers cet Endpoint sont alors automatiquement enregistrées dans une table d'UC.

Voici quelques applications courantes pour les tables d’inférences :

• Surveillez la qualité des données et des modèles. Vous pouvez surveiller en continu les performances de votre modèle et le drift des données à l'aide du profilage des données. Le profilage des données génère automatiquement des tableaux de bord de qualité des données et des modèles que vous pouvez partager avec les parties prenantes. De plus, vous pouvez activer des alertes pour savoir quand vous devez réentraîner votre modèle en fonction des changements dans les données entrantes ou des réductions des performances du modèle.
• Déboguer les problèmes de production. Les tables d'inférence Logs de données telles que les codes de statut HTTP, les temps d'exécution des modèles et le code JSON de requête et de réponse. Vous pouvez utiliser ces données de performance à des fins de debugging. Vous pouvez également utiliser les données historiques des tables d'inférence pour comparer les performances du modèle sur les requêtes historiques.
• Créez un corpus d'entraînement. En joignant les tables d'inférence avec des étiquettes de vérité terrain, vous pouvez créer un corpus d'entraînement que vous pouvez utiliser pour ré-entraîner ou affiner et améliorer votre modèle. En utilisant Lakeflow Jobs, vous pouvez mettre en place une boucle de rétroaction continue et automatiser le ré-entraînement.

Exigences

• Votre workspace doit être compatible avec Unity Catalog.
• Le créateur de l'endpoint et le modificateur doivent tous deux disposer de l'autorisation **Peut gérer** sur l'endpoint. Consultez les listes de contrôle d'accès.
• Le créateur de l'endpoint et le modificateur doivent disposer des autorisations suivantes dans Unity Catalog :
  • USE CATALOG les autorisations sur le catalogue spécifié.
  • USE SCHEMA autorisations sur le schéma spécifié.
  • CREATE TABLE autorisations dans le schéma.

Activez et désactivez les tables d'inférence

Cette section vous explique comment activer ou désactiver les tables d'inférence à l'aide de l'interface utilisateur Databricks. Vous pouvez également utiliser l'API ; voir Activer les tables d'inférence sur les endpoints de service de modèle à l'aide de l'API pour obtenir des instructions.

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

attention

Le tableau d'inférence pourrait être corrompu si vous effectuez l'une des opérations suivantes :

• Modifiez le schéma de la table.
• Modifier le nom de la table.
• Supprimer la table.
• Perdre les autorisations sur le catalogue Unity Catalog ou le schéma.

Dans ce cas, le auto_capture_config du statut de l'endpoint indique un état FAILED pour la table de charge utile. Si cela se produit, vous devez créer un nouvel endpoint pour continuer à utiliser les tables d'inférence.

Pour activer les tables d'inférence lors de la création d'Endpoint, suivez les étapes suivantes :

1. Cliquez sur **Serving** dans l'interface utilisateur de Databricks.

2. Cliquez sur Créer un Endpoint de service .

3. Sélectionnez **Activer les tables d'inférence**.

4. Dans les menus déroulants, sélectionnez le catalogue et le schéma souhaités où vous souhaitez que la table soit située.

   

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

6. Cliquez sur Créer un Endpoint de service .

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

1. Accédez à votre page Endpoint.
2. Cliquez sur Modifier la configuration .
3. Suivez les instructions précédentes, à partir de l'étape 3.
4. Lorsque vous avez terminé, cliquez sur Mettre à jour l'endpoint de service .

Suivez ces instructions pour désactiver les tables d'inférences :

1. Accédez à votre page Endpoint.
2. Cliquez sur Modifier la configuration .
3. Cliquez sur Activer la table d'inférence pour désactiver la case à cocher.
4. Une fois que vous êtes satisfait des spécifications de l'Endpoint, cliquez sur Mettre à jour .

Migration vers les tables d’inférence AI Gateway

important

Une fois qu'un Endpoint a migré pour utiliser une table d'inférence AI Gateway, il ne peut plus revenir à la table héritée.

remarque

Les tables d'inférence AI Gateway ont des schémas différents par rapport aux anciennes tables d'inférence.

Pour obtenir des informations sur les Tarifs, consultez la page de Tarifs d'AI Gateway.

Cette section explique comment migrer des tables d'inférence héritées vers les tables d'inférence AI Gateway.

Il y a deux étapes principales pour mettre à jour la configuration :

1. Mettez à jour le endpoint de service pour désactiver la table d'inférence héritée.
2. Mettre à jour l'endpoint de service pour activer la table d'inférence de l'AI Gateway.

Utilisez l'interface utilisateur pour migrer la configuration de la table d'inférence

Pour un petit nombre d'endpoints de service, modifiez la configuration de l'endpoint dans l'interface utilisateur :

1. Cliquez sur Serving dans l’interface Databricks, puis accédez à la page de votre endpoint.

2. Cliquez sur Modifier la configuration .

3. Cliquez sur Activer les tables d'inférence pour décocher la case.

4. Cliquez sur Update et attendez que l'tat de l'Endpoint devienne Ready .

   

Suivez ces instructions pour activer la table d'inférence AI Gateway :

1. Cliquez sur Serving dans l’interface Databricks, puis accédez à la page de votre endpoint.

2. Cliquez sur Modifier la passerelle IA .

3. Cliquez sur **Activer les tables d'inférence**.

4. Dans le menu déroulant, sélectionnez le catalogue et le schéma souhaités où vous souhaitez que la table soit située.

5. Le nom de table par default est <catalog>.<schema>.<endpoint-name>_payload. Éventuellement, saisissez un préfixe de table personnalisé.

6. Cliquez sur Mettre à jour .

   

Utilisez le Notebook pour migrer la configuration des tables d'inférence

Pour de nombreux endpoints, vous pouvez utiliser l'API pour automatiser le processus de migration. Databricks fournit un notebook d'exemple qui migre les endpoints de service par batch et des exemples sur la façon de migrer les données existantes des tables d'inférence héritées vers les tables d'inférence AI Gateway.

Migrez vers le notebook des tables d'inférence AI Gateway

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

Flux de travail : Surveiller les performances du modèle à l'aide de tables d'inférence

Pour surveiller les performances du modèle à l'aide de tables d'inférence, suivez les étapes suivantes :

1. Activez les tables d'inférence sur votre Endpoint, soit lors de la création de l'Endpoint, soit en le mettant à jour par la suite.
2. Planifiez un flux de travail pour traiter les charges utiles JSON dans la table d'inférence en les décompressant selon le schéma de l'endpoint.
3. (Facultatif) Joignez les requêtes et les réponses décompressées aux étiquettes de vérité terrain pour permettre le calcul des métriques de qualité du modèle.
4. Créez un moniteur sur la table Delta résultante et refresh les métriques.

Les Notebooks de démarrage implémentent ce workflow.

Notebook de démarrage pour le monitoring d'une table d'inférence

Le Notebook suivant implémente les étapes décrites ci-dessus pour décompresser les requêtes d’une table d’inférence de profilage des données. Le Notebook peut être exécuté à la demande ou selon un calendrier récurrent à l'aide des Lakeflow Jobs.

Notebook de démarrage pour le profilage des données de la table d'inférence

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

Notebook de démarrage pour le monitoring de la qualité du texte à partir des Endpoint servant les LLM

Le Notebook suivant décompresse les requêtes d'une table d'inférence, calcule un ensemble de métriques d'évaluation de texte (telles que la lisibilité et la toxicité) et active le monitoring de ces métriques. Le Notebook peut être exécuté à la demande ou selon un calendrier récurrent à l'aide des Lakeflow Jobs.

Notebook de démarrage de profilage des données de table d'inférence LLM

Ouvrir le notebook dans un nouvel ongletOuvrir dans Databricks

query et analysez les résultats dans le tableau d'inférences

Une fois vos modèles servis prêts, toutes les requêtes faites à vos modèles sont automatiquement enregistrées dans la table d'inférence, avec les réponses. Vous pouvez afficher la table dans l'interface utilisateur, query la table à partir de DBSQL ou d'un Notebook, ou query la table à l'aide de l'API REST.

Pour afficher la table dans l'interface utilisateur : Sur la page de l'Endpoint, cliquez sur le nom de la table d'inférence pour ouvrir la table dans Catalog Explorer.

Pour query la table depuis DBSQL ou un Notebook Databricks : Vous pouvez exécuter du code similaire au suivant pour query la table d'inférence.

SQL

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

Si vous avez activé les tables d'inférence à l'aide de l'interface utilisateur, payload_table est le nom de table que vous avez attribué lors de la création de l'Endpoint. Si vous avez activé les tables d'inférence à l'aide de l'API, payload_table est signalé dans la section state de la réponse auto_capture_config. Pour un exemple, consultez Activer les tables d'inférence sur les Endpoint de service de modèles à l'aide de l'API.

Note de performance

Après avoir invoqué l'endpoint, vous pouvez voir l'invocation enregistrée dans votre table d'inférence dans l'heure suivant l'envoi d'une requête de scoring. De plus, Databricks garantit que la livraison des logs a lieu au moins une fois, il est donc possible, bien que peu probable, que des logs en double soient envoyés.

Schéma de la table d'inférence Unity Catalog

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

remarque

Si vous invoquez l'Endpoint avec un batch d'entrées, le batch entier est consigné comme une seule ligne.

Nom de colonne	Description	Type
databricks_request_id	Un identifiant de requête généré par Databricks attaché à toutes les requêtes de diffusion de modèle.	CHAÎNE
client_request_id	Un identifiant de requête facultatif généré par le client qui peut être spécifié dans le corps de la requête de service de modèle. Consultez Spécifier client_request_id pour plus d'informations.	CHAÎNE
date	La date UTC à laquelle la requête de mise à disposition du modèle a été reçue.	Date
timestamp_ms	Le Timestamp en millisecondes d'époque auquel la requête de service de modèle a été reçue.	LONG
status_code	Le code de statut HTTP qui a été renvoyé par le modèle.	INT
sampling_fraction	La fraction d'échantillonnage utilisée dans le cas où la requête a été sous-échantillonnée. Cette valeur est comprise entre 0 et 1, où 1 représente l'inclusion de 100 % des requêtes entrantes.	Double
execution_time_ms	Le temps d'exécution en millisecondes pendant lequel le modèle a effectué l'inférence. Cela n'inclut pas les latences réseau supplémentaires et représente uniquement le temps qu'il a fallu au modèle pour générer des prédictions.	LONG
request	Le corps JSON de la requête brute qui a été envoyé à l'endpoint de service de modèle.	CHAÎNE
response	Le corps JSON de la réponse brute qui a été renvoyé par l'endpoint de mise en service de modèle.	CHAÎNE
request_metadata	Une carte des métadonnées liées à l'Endpoint de service de modèle associé à la requête. Cette carte contient le nom d'Endpoint, le nom du modèle et la version du modèle utilisés pour votre Endpoint.	MAP<CHAÎNE, CHAÎNE>

Nom de colonne	Description	Type
databricks_request_id	Un identifiant de requête généré par Databricks attaché à toutes les requêtes de diffusion de modèle.	CHAÎNE
client_request_id	Un identifiant de requête facultatif généré par le client qui peut être spécifié dans le corps de la requête de service de modèle. Consultez Spécifier client_request_id pour plus d'informations.	CHAÎNE
date	La date UTC à laquelle la requête de mise à disposition du modèle a été reçue.	Date
timestamp_ms	Le Timestamp en millisecondes d'époque auquel la requête de service de modèle a été reçue.	LONG
status_code	Le code de statut HTTP qui a été renvoyé par le modèle.	INT
sampling_fraction	La fraction d'échantillonnage utilisée dans le cas où la requête a été sous-échantillonnée. Cette valeur est comprise entre 0 et 1, où 1 représente l'inclusion de 100 % des requêtes entrantes.	Double
execution_time_ms	Le temps d'exécution en millisecondes pendant lequel le modèle a effectué l'inférence. Cela n'inclut pas les latences réseau supplémentaires et représente uniquement le temps qu'il a fallu au modèle pour générer des prédictions.	LONG
request	Le corps JSON de la requête brute qui a été envoyé à l'endpoint de service de modèle.	CHAÎNE
response	Le corps JSON de la réponse brute qui a été renvoyé par l'endpoint de mise en service de modèle.	CHAÎNE
request_metadata	Une carte des métadonnées liées à l'Endpoint de service de modèle associé à la requête. Cette carte contient le nom d'Endpoint, le nom du modèle et la version du modèle utilisés pour votre Endpoint.	MAP<CHAÎNE, CHAÎNE>

Spécifier 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 de modèle. Ceci permet à l'utilisateur de fournir son propre identifiant pour une requête qui apparaît dans la table d'inférence finale sous le client_request_id et qui peut être utilisée pour joindre votre requête à d'autres tables qui utilisent le client_request_id, comme la jointure d'étiquettes de vérité terrain. Pour spécifier un client_request_id, incluez-le en tant que clé de premier niveau de la charge utile de la requête. Si aucun client_request_id n'est spécifié, la valeur apparaît comme nulle dans la ligne correspondant à la demande.

JSON

{
  "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
    }
  ]
}

Le client_request_id peut ensuite être utilisé pour les jointures d'étiquettes de vérité terrain s'il existe d'autres tables associées au client_request_id.

Limitations

• Les clés gérées par le client ne sont pas prises en charge.
• Pour les endpoints qui hébergent des modèles de fondation, les tables d'inférence sont uniquement prises en charge sur les charges de travail de throughput provisionné.
• AWS PrivateLink n'est pas pris en charge par default. Contactez l'équipe de votre compte Databricks pour l'activer.
• Lorsque les tables d'inférence sont activées, la limite de la concurrence maximale totale pour tous les modèles servis dans un seul endpoint est de 128. Veuillez contacter l'équipe de votre compte Databricks pour demander une augmentation de cette limite.
• Si une table d'inférence contient plus de 500 K fichiers, aucune donnée supplémentaire n'est journalisée. Pour éviter de dépasser cette limite, exécutez OPTIMIZE ou configurez la rétention sur votre table en supprimant les données plus anciennes. Pour vérifier le nombre de fichiers dans votre table, exécutez DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• La livraison des logs des tables d'inférence se fait actuellement au mieux, mais vous pouvez vous attendre à ce que les logs soient disponibles dans l'heure suivant une requête. Contactez l'équipe de votre compte Databricks pour plus d'informations.

Pour les limitations générales des Endpoint Model Serving, consultez Limites et régions de Model Serving.