Tables d'inférence d'agent : Logs de requêtes et d'évaluation (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 d’agent, la configuration du serveur et le workflow de déploiement. Consultez 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 d’obsolescence** : À compter du 4 décembre 2025, Databricks ne remplit plus automatiquement les payload_request_logs payload_assessment_logs tables et. Ces tables ont été dépréciées.
- Agents nouvellement déployés via agents.deploy(). ne générera plus les tables request_logs ou assessment_logs.
- Les tables request_logs et assessment_logs d'anciennes générations ne sont plus renseignées. Vous pouvez créer votre propre table de remplacement en utilisant des vues matérialisées. Consultez les solutions alternatives pour MLflow 2.
- L’ API expérimentale héritée pour la journalisation 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 Assessments MLflow 3.
**Action requise** :
- Recommandé : Passez à MLflow 3 pour activer le traçage en temps réel, ce 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 commentaires des utilisateurs.
Table d'inférence | Exemple de nom de table Databricks | Table des matières |
|---|---|---|
Charge utile |
| Charges utiles brutes de requêtes et de réponses JSON |
Logs de requêtes de charge utile |
| Requêtes et réponses formatées. Traces MLflow. Dérivée de la table de charge utile brute. |
Logs d'évaluation de la charge utile. |
| Commentaires formatés, tels que fournis dans l'application de révision, pour chaque demande Dérivée de la 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 requête 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 remplit plus automatiquement les tables payload_request_logs et payload_assessment_logs.
Ce qui fonctionne toujours : la table brute payload continue de recevoir des données provenant de 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 heure et plus | <10s |
Organisation des données | Les traces et les retours d’utilisateurs (évaluations) sont extraits dans des tables distinctes du Unity Catalog ( | Toutes vos données liées à l'observabilité, telles que les traces, les retours et les évaluations, sont facilement accessibles dans la même expérimentation. |
Collecte de commentaires | Mal pris en charge. Utilise l'API de feedback expérimental, qui place les données dans la table d'inférence des charges utiles. | MLflow 3 fournit des APIs simplifiées pour l'exécution de l'évaluation, l'étiquetage humain et la gestion des datasets d'évaluation. |
Surveillance | Mal pris en charge. Le support est limité au monitoring hérité, désormais déprécié, qui était limité aux juges intégrés hérités et au juge de lignes directrices, et n'a pas de support de métriques personnalisées. Le monitoring hérité s'exécute sur les Logs de requêtes de charge utile, ce qui signifie que les réponses de votre agent prendront plus d'une heure à être évaluées. | Le Monitoring est intégré en mode natif à MLflow 3, prenant en charge tout Scorer :
Comprend des capacités de remplissage historique de métriques pour appliquer rétroactivement de nouvelles métriques aux traces historiques. Les traces sont lues à partir de MLflow pour l'évaluation, diminuant la latence du monitoring à de 15 à 30 minutes. |
MLflow 3 joint des évaluations aux traces, puis enregistre les traces sur le serveur de traçage MLflow avec tous les logs de charge utile, de réponse et d'étapes intermédiaires. Voir Étiquette pendant le développement et Concepts et modèle de données.
Étapes de migration
- Mettre à 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éploierez 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()
- Enregistrez votre agent : Enregistrez l'agent comme vous le feriez normalement, en vous assurant qu'il nécessite 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. Facultativement, définissez votre expérimentation MLflow avant le déploiement pour contrôler 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 d'avoir besoin de limites plus élevées, contactez votre équipe de compte Databricks.
Voir Suivi des agents 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 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 de renseigner la table brute payload. Cependant, Databricks ne traite plus ces données dans les tables payload_requests_logs et payload_assessment_logs.
Databricks génère plutôt 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 : Utiliser 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 nécessaire.
Vous pouvez, en option, renommer 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) compute 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éer des vues matérialisées pour les Logs d'inférence d'agent
Questions fréquemment posées
Que devient la donnée dans mes logs de requêtes et de évaluations existants ?
Les données existantes dans vos tables d'inférences resteront accessibles. Cependant, après le 4 décembre 2025, aucune nouvelle donnée ne sera renseignée dans les tables request_logs et assessment_logs.
Mon déploiement d’agent échoue-t-il ?
Non, vos anciens déploiements d'agents continuent de fonctionner, et vos tables d'inférence de charges utiles continuent d'être renseignées. Cependant, après les dates de dépréciation, vous ne recevrez plus de données dans les tables request_logs et assessment_logs. Utilisez les vues fournies ou migrez vers MLflow 3 pour maintenir des fonctionnalités équivalentes.
Si vous avez besoin d'aide pour la migration, contactez votre équipe d'assistance Databricks.