Journaliser les requêtes et les réponses pour les Endpoint de service (hérité)

info

Essayez la nouvelle passerelle d'IA Unity

Une nouvelle expérience Unity AI Gateway est désormais disponible. Il s’agit du plan de contrôle d’entreprise pour gérer les Endpoint LLM et les agents de codage avec des fonctionnalités améliorées. Voir la gouvernance de l’IA avec Unity AI Gateway.

Cet article décrit les tables d'inférence activées par AI Gateway pour le monitoring des modèles servis. La table d'inférence capture automatiquement les requêtes entrantes et les réponses sortantes pour un endpoint et les logs en tant que table Delta de Unity Catalog. Vous pouvez utiliser les données de ce tableau pour surveiller, évaluer, comparer et affiner les modèles de machine learning.

Que sont les tables d'inférence compatibles avec AI Gateway ?

Les tables d'inférence activées par AI Gateway simplifient le monitoring et les diagnostics pour les modèles en enregistrant en continu les entrées et les réponses (prédictions) des requêtes de service à partir des endpoints de Model Serving et en les enregistrant dans une table Delta dans Unity Catalog. Vous pouvez ensuite utiliser toutes les fonctionnalités de la plateforme Databricks, telles que les queries Databricks SQL et les Notebooks pour monitoring, déboguer et optimiser vos modèles.

Vous pouvez activer les tables d'inférence sur un endpoint de service de modèle existant ou nouvellement créé, et les requêtes vers cet endpoint sont alors automatiquement consignées dans une table de Unity Catalog.

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

• Créez un corpus d'entraînement. En joignant les tables d'inférence avec les é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.
• Surveillez la qualité des données et des modèles. Vous pouvez surveiller en continu les performances de votre modèle et la drift des données en utilisant le profilage des données, qui 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 enregistrent les données telles que les codes d'état HTTP, le code JSON de requête et de réponse, les temps d'exécution du modèle et les sorties de traces pendant les temps d'exécution du modèle. 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.
• Surveiller les agents déployés. Les tables d’inférence peuvent également stocker les traces MLflow pour les agents, ce qui vous aide à déboguer les problèmes et à surveiller les performances.

Exigences

• Les tables d’inférence activées par Unity AI Gateway ne sont prises en charge que pour les endpoints qui diffusent l’un des éléments suivants :

  • Charges de travail avec throughput provisionné
  • Modèles de paiement par jeton
  • Modèles externes
  • Modèles personnalisés

• Un workspace Databricks dans une région où la diffusion de modèles est prise en charge. Voir la disponibilité des fonctionnalités de Model Serving.

• Le compute Serverless doit être activé dans le Workspace.

• Databricks vous recommande d’ activer l’optimisation prédictive pour des performances optimisées de vos tables d’inférence.

• 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.

• Le catalogue ne peut pas être un catalogue OpenSharing vers le métastore actuel.

remarque

La spécification d'une table existante n'est pas prise en charge. Databricks crée automatiquement une nouvelle table d'inférence lorsque vous créez un Endpoint ou mettez à jour la configuration de la passerelle Unity AI avec la configuration de la table d'inférence activée.

attention

La table d'inférence pourrait cesser d'enregistrer des données ou être corrompue 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.

Activer et désactiver 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 de Serving. Le propriétaire des tables d'inférence est l'utilisateur qui a activé la table d'inférence. 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.

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. Dans la section AI Gateway, sélectionnez Activer les tables d'inférence .

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. Dans la section AI Gateway, cliquez sur **Edit AI Gateway**.
2. Sélectionnez **Activer les tables d'inférence**.

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

1. Accédez à votre page Endpoint.
2. Cliquez sur Modifier la passerelle IA .
3. Cliquez sur Activer la table d'inférence pour désactiver la case à cocher.
4. Une fois que les spécifications de la passerelle d'IA Unity vous conviennent, cliquez sur Mettre à jour .

Activer les tables d'inférence pour les agents

Vous pouvez également activer les tables d’inférence pour les agents déployés, ces tables d’inférence stockent les détails de la charge utile et de la requête, ainsi que les logs de trace MLflow.

Activer les tables d'inférence pour les agents en utilisant les méthodes suivantes :

• Les agents déployés à l'aide de l'API mlflow.deploy() ont des tables d'inférence automatiquement activées. Consultez Déployer un agent pour les applications d'IA (Model Serving).
• Pour les déploiements programmatiques, définissez la variable d'environnement ENABLE_MLFLOW_TRACING sur True dans la configuration de l'Endpoint. Voir Ajouter des variables d’environnement en texte brut.

Pour en savoir plus sur le traçage des agents MLflow, consultez MLflow Tracing - Observabilité de GenAI.

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, interroger la table depuis Databricks SQL ou un Notebook, ou interroger la table en utilisant 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 Databricks SQL ou un Databricks Notebook : Vous pouvez exécuter un code similaire à celui qui suit pour query la table d’inférence.

SQL

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

Pour joindre les données de votre table d'inférence avec les détails concernant le modèle de fondation sous-jacent servi sur votre Endpoint : Les détails du modèle de fondation sont capturés dans system.serving.served_entities table système.

SQL

SELECT * FROM <catalog>.<schema>.<payload_table> payload
JOIN system.serving.served_entities se on payload.served_entity_id = se.served_entity_id

Schéma de table d'inférence compatible Unity AI Gateway

Les tables d'inférence activées à l'aide de Unity AI Gateway ont le schéma suivant :

Nom de colonne	Description	Type
request_date	La date UTC à laquelle la requête de mise à disposition du modèle a été reçue.	Date
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	L'identifiant de demande fourni par l'utilisateur qui peut être spécifié dans le corps de la demande de service de modèles.	CHAÎNE
request_time	Timestamp auquel la requête est reçue.	Horodatage
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_duration_ms	Le temps 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.	BIGINT
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
served_entity_id	L’ID unique de l’entité servie.	CHAÎNE
logging_error_codes	Les erreurs survenues lorsque les données n'ont pas pu être consignées. Les codes d'erreur incluent MAX_REQUEST_SIZE_EXCEEDED et MAX_RESPONSE_SIZE_EXCEEDED.	TABLEAU
requester	L'ID de l'utilisateur ou du Service Principal dont les autorisations sont utilisées pour la requête d'invocation de l'Endpoint de service. Ce champ retourne NULL pour les Endpoint de modèle personnalisés optimisés pour l’itinéraire.	CHAÎNE

Nom de colonne	Description	Type
request_date	La date UTC à laquelle la requête de mise à disposition du modèle a été reçue.	Date
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	L'identifiant de demande fourni par l'utilisateur qui peut être spécifié dans le corps de la demande de service de modèles.	CHAÎNE
request_time	Timestamp auquel la requête est reçue.	Horodatage
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_duration_ms	Le temps 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.	BIGINT
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
served_entity_id	L’ID unique de l’entité servie.	CHAÎNE
logging_error_codes	Les erreurs survenues lorsque les données n'ont pas pu être consignées. Les codes d'erreur incluent MAX_REQUEST_SIZE_EXCEEDED et MAX_RESPONSE_SIZE_EXCEEDED.	TABLEAU
requester	L'ID de l'utilisateur ou du Service Principal dont les autorisations sont utilisées pour la requête d'invocation de l'Endpoint de service. Ce champ retourne NULL pour les Endpoint de modèle personnalisés optimisés pour l’itinéraire.	CHAÎNE

Schémas de table d'inférence de l'agent

attention

Les Logs de requête et les Logs d'évaluation sont obsolètes et seront supprimés dans une prochaine version. Consultez la dépréciation des Logs de requête et des Logs d’évaluation pour obtenir des conseils sur la migration.

Pour les agents, Databricks crée trois tables d'inférence pour chaque déploiement afin d'enregistrer les requêtes et les réponses vers et depuis l'endpoint de service de modèle :

Table d'inférence	Exemple de nom de table Databricks	Table des matières
Charge utile	{catalog_name}.{schema_name}.{model_name}_payload	Charges utiles brutes de requêtes et de réponses JSON
Logs de requêtes de charge utile	{catalog_name}.{schema_name}.{model_name}_payload_request_logs	Requêtes et réponses formatées, traces MLflow
Logs d'évaluation de la charge utile.	{catalog_name}.{schema_name}.{model_name}_payload_assessment_logs	Commentaires formatés, tels que fournis dans l'application de révision, pour chaque demande

Table d'inférence	Exemple de nom de table Databricks	Table des matières
Charge utile	{catalog_name}.{schema_name}.{model_name}_payload	Charges utiles brutes de requêtes et de réponses JSON
Logs de requêtes de charge utile	{catalog_name}.{schema_name}.{model_name}_payload_request_logs	Requêtes et réponses formatées, traces MLflow
Logs d'évaluation de la charge utile.	{catalog_name}.{schema_name}.{model_name}_payload_assessment_logs	Commentaires formatés, tels que fournis dans l'application de révision, pour chaque demande

Les utilisateurs peuvent s'attendre à ce que les données des tables de charge utile soient disponibles dans l'heure suivant l'interaction avec le serving Endpoint. Les logs de requêtes de charge utile et les logs d'évaluation peuvent prendre plus de temps à se remplir, et sont dérivés de la table de charge utile brute. Vous pouvez extraire vous-même les logs de requêtes et d'évaluation de la table de charge utile. Les suppressions et les mises à jour de la table de charge utile ne sont pas reflétées dans les logs de requêtes de charge utile ou les logs d'évaluation de charge utile.

Ce qui suit présente le schéma de la table des logs de requêtes de charge utile :

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.	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
timestamp	Timestamp de la requête.	Horodatage
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
conversation_id	L'ID de conversation extrait des logs de requête.	CHAÎNE
request	La dernière query de l'utilisateur à partir de la conversation de l'utilisateur.	CHAÎNE
response	La dernière réponse à l'utilisateur.	CHAÎNE
request_raw	La représentation sous forme de chaîne de la requête.	CHAÎNE
response_raw	Représentation sous forme de chaîne de la réponse.	CHAÎNE
trace	Représentation sous forme de chaîne de la trace extraite du databricks_options de la Struct de réponse.	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>
schema_version	La version du schéma.	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.	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
timestamp	Timestamp de la requête.	Horodatage
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
conversation_id	L'ID de conversation extrait des logs de requête.	CHAÎNE
request	La dernière query de l'utilisateur à partir de la conversation de l'utilisateur.	CHAÎNE
response	La dernière réponse à l'utilisateur.	CHAÎNE
request_raw	La représentation sous forme de chaîne de la requête.	CHAÎNE
response_raw	Représentation sous forme de chaîne de la réponse.	CHAÎNE
trace	Représentation sous forme de chaîne de la trace extraite du databricks_options de la Struct de réponse.	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>
schema_version	La version du schéma.	CHAÎNE

Voici le schéma de la table des Logs d'évaluation de la charge utile :

Nom de colonne	Description	Type
request_id	Un ID de demande Databricks.	CHAÎNE
step_id	L'ID de l'étape, dérivé de l'évaluation de la récupération.	CHAÎNE
source	Un champ de structure contenant les informations sur la personne qui a créé l'évaluation.	Structure
timestamp	Timestamp de la requête.	Horodatage
text_assessment	Les données pour tout commentaire sur les réponses de l'agent provenant de l'application d'évaluation.	CHAÎNE
retrieval_assessment	Les données relatives à tout feedback sur les documents récupérés pour une réponse.	CHAÎNE

Nom de colonne	Description	Type
request_id	Un ID de demande Databricks.	CHAÎNE
step_id	L'ID de l'étape, dérivé de l'évaluation de la récupération.	CHAÎNE
source	Un champ de structure contenant les informations sur la personne qui a créé l'évaluation.	Structure
timestamp	Timestamp de la requête.	Horodatage
text_assessment	Les données pour tout commentaire sur les réponses de l'agent provenant de l'application d'évaluation.	CHAÎNE
retrieval_assessment	Les données relatives à tout feedback sur les documents récupérés pour une réponse.	CHAÎNE

Échantillonnage

remarque

L'échantillonnage s'applique aux tables d'inférence sur les Endpoints de service de modèle CPU, où les charges utiles sont livrées via la télémétrie des Endpoint. Les Endpoint qui servent un throughput provisionné, des modèles externes, des charges de travail d'API de modèle de fondation ou des agents suivent le comportement de livraison dans Limitations.

Pour les Endpoint de service de modèles CPU, vous pouvez configurer la fraction des requêtes qui sont consignées dans la table d'inférence. L'échantillonnage réduit le volume de journalisation et le coût de stockage sur les endpoints à haut throughput tout en conservant un échantillon représentatif du trafic.

• default : 100 %. Toutes les requêtes sont enregistrées, sauf si vous définissez un taux inférieur.
• Plage : 0 % à 100 %, stocké en tant que sampling_fraction entre 0 et 1.
• Chaque ligne journalisée enregistre le taux appliqué dans sa colonne sampling_fraction.

Pour définir le taux dans l'interface utilisateur, saisissez un **Taux d'échantillonnage (%)** lorsque vous activez les tables d'inférence dans la section AI Gateway. Pour le définir par programmation, spécifiez sampling_fraction dans la configuration de télémétrie de l'Endpoint.

Volume de point de contrôle interne

Pour prendre en charge les tables d'inférence compatibles avec Unity AI Gateway, Databricks crée un volume interne dans le schéma de la table d'inférence. Le volume possède un nom généré par le système sous la forme <catalog>.<schema>.<payload table ID>_checkpoints. La suppression de ce volume peut laisser les tables d'inférence mal formées. Databricks supprime automatiquement le volume lorsque vous supprimez le Endpoint correspondant.

Limitations

• La livraison des Logs de table d'inférence pour les Endpoint de diffusion de modèles qui servent des modèles personnalisés prend environ 2 heures.

• La livraison des Logs des tables d'inférence pour les Endpoint de service de modèle qui servent les charges de travail de l'API de modèle de fondation, les modèles externes ou les agents est actuellement fournie au mieux de nos efforts. Vous pouvez vous attendre à ce que les logs soient disponibles dans l'heure suivant une requête. Contactez votre équipe de compte Databricks pour plus d'informations.

• La taille maximale de requête, de réponse et de trace journalisée est de 1 MiB (1 048 576 octets). Les charges utiles qui dépassent cette valeur sont journalisées en tant que null et logging_error_codes sont remplies avec MAX_REQUEST_SIZE_EXCEEDED ou MAX_RESPONSE_SIZE_EXCEEDED.

• Les tables d'inférence pour les endpoints de service de modèle optimisés pour l'itinéraire sont en aperçu public.

• Les logs de la table d'inférence ne sont pas garantis d'être renseignés si l'endpoint de service de modèle renvoie une erreur.

  • Pour les Endpoints de modèle personnalisés, les Logs peuvent ne pas être enregistrés pour les erreurs 4xx ou 5xx.
  • Pour les autres endpoints, les Logs peuvent ne pas être enregistrés pour les erreurs 401, 403, 429 ou 500.

Pour les limitations spécifiques à Unity AI Gateway, voir Limitations. Pour les limitations générales des Endpoint de Model Serving, consultez Limites et régions de Model Serving.