Tables d'inférence d'agents : logs de requêtes et d'évaluations (obsolètes)
Pour les nouveaux cas d'utilisation, Databricks recommande de déployer des agents sur Databricks Apps pour un contrôle total sur le code de l'agent, la configuration du serveur et le flux de travail de déploiement. Voir Créer un agent IA et le déployer sur Databricks Apps. Pour migrer un agent existant, consultez Migrer un agent de Model Serving vers Databricks Apps.
Avis de dépréciation : À compter du 4 décembre 2025, Databricks ne remplit plus automatiquement les tables payload_request_logs et payload_assessment_logs. Ces tables ont été dépréciées.
- Agents nouvellement déployés via agents.deploy() ne générera plus de tables request_logs ou assessment_logs.
- Les tables de `request_logs` et `assessment_logs` héritées ne sont plus remplies. Vous pouvez créer votre propre table de remplacement à l'aide de vues matérialisées. Consultez les solutions alternatives pour MLflow 2.
- L' API expérimentale héritée pour la consignation des retours ne sera plus prise en charge pour les agents déployés avec la dernière version de databricks-agents. Utilisez plutôt l' API d'évaluation de MLflow 3.
Action requise :
- **Recommandé** : Passez à MLflow 3 pour utiliser le traçage en temps réel, qui offre une journalisation unifiée avec de meilleures performances.
- **Alternative** : si vous devez continuer à utiliser MLflow 2, consultez les solutions alternatives pour maintenir l'accès à vos données.
Lorsque vous déployez un agent d'IA, Databricks crée trois tables d'inférence qui capturent automatiquement les requêtes et les réponses vers et depuis votre agent. Ces tables vous aident à surveiller les performances, à déboguer les problèmes et à analyser les retours d'utilisateurs.
Table d’inférence | Exemple de nom de table Databricks. | Contenu du tableau |
|---|---|---|
Charge utile |
| Charges utiles JSON brutes des requêtes et des réponses |
Logs de requête de charge utile |
| Requêtes et réponses formatées. Traces MLflow. Dérivé d’une table de charge utile brute. |
Logs d'évaluation de la charge utile |
| Commentaires formatés, tels que fournis dans l'application d'évaluation, pour chaque demande Dérivé d’une table de charge utile brute. |
- Les données JSON brutes entrent dans la table de charge utile dans l'heure qui suit la réception d'une demande par votre agent.
- Les tables des logs de requêtes et des logs d'évaluation traitent et formatent les données de la table de charge utile. Cela prend du temps supplémentaire.
- Vous pouvez extraire et traiter manuellement les données de la table de charge utile si nécessaire.
- Les modifications apportées à la table de charge utile (suppressions ou mises à jour) ne sont pas automatiquement synchronisées avec les tables dérivées.
Qu'est-ce qui change ?
Databricks ne peuple plus automatiquement les tables payload_request_logs et payload_assessment_logs.
Ce qui fonctionne encore : La table brute payload continue de recevoir des données des nouvelles requêtes.
Migrez vers MLflow 3 et utilisez le traçage en temps réel pour unifier les logs d'agent
Databricks recommande fortement de migrer les endpoints d'agent vers MLflow 3. Le traçage en temps réel de MLflow 3 élimine le besoin de tables request_logs et assessment_logs distinctes en unifiant tous vos journaux d'agent en un seul emplacement de trace.
Observabilité héritée | Observabilité MLflow 3 | |
|---|---|---|
Latence de la collecte de données | 1+ heures | <10s |
Organisation des données | Les traces et les commentaires des utilisateurs (évaluations) sont extraits dans des tables Unity Catalog distinctes ( | Toutes vos données liées à l'observabilité, telles que les traces, les commentaires et les évaluations, sont facilement accessibles dans la même expérimentation. |
Collecte des commentaires | Pas bien pris en charge. Utilise l'API de feedback expérimental, qui place les données dans la table d'inférence de charge utile. | MLflow 3 offre des APIs simplifiées pour l'exécution d'évaluations, l'étiquetage humain et la gestion des jeux de données d'évaluation. |
Surveillance | Pas bien pris en charge. Le support est limité au monitoring hérité, maintenant déprécié, qui était limité aux juges intégrés hérités et au juge de lignes directrices, et ne prend pas en charge les métriques personnalisées. Le monitoring hérité s'exécute au-dessus des logs de requêtes de charge utile, ce qui signifie que les réponses de votre agent prendront au moins 1 heure pour être évaluées. | Le monitoring est intégré en mode natif à MLflow 3, prenant en charge tout Scorer :
Intègre des capacités de remplissage historique des métriques pour appliquer rétroactivement de nouvelles métriques aux traces historiques. Les traces sont lues depuis MLflow pour l'évaluation, ce qui réduit la latence du monitoring à 15–30 minutes. |
MLflow 3 associe des évaluations aux traces, puis enregistre les traces sur le serveur de tracing MLflow avec tous les logs de charge utile, de réponse et d’étape intermédiaire. Consultez Label during development et Concepts & data model.
Étapes de migration
- Mise à niveau vers MLflow 3 : assurez-vous que votre agent utilise MLflow 3.1.3 ou supérieur. Le traçage sera automatiquement activé lorsque vous déployez des agents avec MLflow 3.
# Install prerequisites
%pip install mlflow>=3.1.3
# Restart Python to make sure the new packages are picked up
dbutils.library.restartPython()
- Consignez votre agent : consignez l'agent comme vous le feriez normalement, en vous assurant qu'il requiert MLflow 3.1.3 ou supérieur. Ensuite, enregistrez le modèle dans UC.
# Log your agent
with mlflow.start_run():
logged_agent_info = mlflow.pyfunc.log_model(
name="my_agent",
pip_requirements=[
"mlflow>=3.1.3",
],
...
)
# Register your model to UC
uc_registered_model_info = mlflow.register_model(
model_uri=logged_agent_info.model_uri, name=UC_MODEL_NAME
)
- Déployez votre agent : Déployez l'agent comme vous le feriez normalement. Optionnellement, définissez votre experimentation MLflow avant le déploiement pour contrôler l'endroit où les traces sont enregistrées. Si vous ne le faites pas, les traces seront enregistrées dans l'Experimentation MLflow actuellement active.
import mlflow
from databricks import agents
# Set experiment for trace logging
mlflow.set_experiment("/path/to/your/experiment")
# Deploy with automatic tracing
deployment = agents.deploy(uc_model_name, uc_model_info.version)
# Retrieve the query endpoint URL for making API requests
deployment.query_endpoint
MLflow 3 prend actuellement en charge jusqu'à 100 000 traces par endpoint de service. Si vous prévoyez avoir besoin de limites plus élevées, contactez votre équipe de compte Databricks.
Voir Agents de trace déployés sur Databricks pour plus d'informations.
Options alternatives pour continuer à utiliser MLflow 2
Les méthodes alternatives de MLflow 2 ne prennent pas en charge les Endpoint avec le monitoring d'agent activé. Si vous utilisez le monitoring, vous devez migrer vers MLflow 3 et recréer vos moniteurs en tant que scorers MLflow 3.
Si vous ne pouvez pas passer à MLflow 3, Databricks continue d'alimenter la table brute payload. Cependant, Databricks ne traite plus ces données dans les tables payload_requests_logs et payload_assessment_logs.
Au lieu de cela, Databricks génère des vues sur vos tables de charge utile qui fournissent les mêmes données formatées. Vous avez deux options pour accéder à ces données. Utilisez les vues fournies ou créez des vues matérialisées.
Option 1 : Utilisez les vues fournies
La méthode la plus simple consiste à utiliser les vues générées payload_request_logs_view et payload_assessment_logs_view à la place des tables obsolètes.
Ces vues interrogent la table de charge utile pour fournir les mêmes données formatées, et elles fonctionnent immédiatement sans aucune configuration requise.
Optionnellement, renommez les vues pour qu'elles correspondent à vos noms de table d'origine afin de minimiser les modifications de code.
Option 2 : créer des vues matérialisées
Les vues fournies (payload_request_logs_view et payload_assessment_logs_view) calculent les données en temps réel en interrogeant la table de charge utile. Pour les scénarios qui nécessitent des tables Delta physiques, comme le monitoring en temps réel, créez plutôt des vues matérialisées.
Exécutez le Notebook suivant pour convertir vos vues en vues matérialisées :
Créez des vues matérialisées pour les logs d'inférence d'agent.
Questions fréquemment posées
Que deviennent les données de mes logs de requête et logs d'évaluation existants ?
Les données existantes dans vos tables d'inférence continueront d'être accessibles. Cependant, après le 4 décembre 2025, aucune nouvelle donnée ne sera ajoutée dans les tables request_logs et assessment_logs.
Mon déploiement d'agent est-il interrompu ?
Non, vos anciens déploiements d'agents continuent de fonctionner, et vos tables d'inférence de charge utile continuent d'être renseignées. Cependant, après les dates d'obsolescence, vous ne recevrez pas de données dans les tables request_logs et assessment_logs. Utilisez les vues fournies ou migrez vers MLflow 3 pour maintenir une fonctionnalité équivalente.
Si vous avez besoin d'aide pour la migration, veuillez contacter votre équipe de support Databricks.