Aller au contenu principal
Dernière mise à jour le

Configurer le monitoring de la production

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

Le monitoring de production vous permet d'exécuter automatiquement des scorers MLflow 3 sur les traces de vos agents afin d'évaluer en continu la qualité. Vous planifiez des scorers par rapport à une expérimentation MLflow, et le service de monitoring évalue un échantillon configurable de traces entrantes. Les résultats sont joints sous forme de feedback à chaque trace évaluée.

Le monitoring de production comprend les éléments suivants :

  • Évaluation automatisée de la qualité à l’aide d’évaluateurs intégrés ou personnalisés, y compris les juges multivoies pour l’évaluation de conversations entières.
  • Taux d'échantillonnage configurables afin que vous puissiez contrôler le compromis entre la couverture et le coût du calcul.
  • Utilisez les mêmes évaluateurs en développement et en production pour garantir une évaluation cohérente.
  • Évaluation continue de la qualité avec un monitoring en arrière-plan.
remarque

Le monitoring de la production MLflow 3 est compatible avec les traces enregistrées depuis MLflow 2.

Prérequis​

Avant de configurer le monitoring de production, assurez-vous d'avoir :

  • Expérimentation MLflow : Une expérimentation MLflow où les traces sont journalisées. Si aucune expérience n'est spécifiée, l'expérience active est utilisée.

  • Application de production instrumentée : votre agent doit consigner les traces à l'aide de MLflow Tracing. Consultez le guide de traçage de production.

  • Évaluateurs définis : Évaluateurs testés qui fonctionnent avec le format de trace de votre application. Si vous avez utilisé votre application de production comme predict_fn dans mlflow.genai.evaluate() pendant le développement, vos évaluateurs sont probablement déjà compatibles.

  • Politique budgétaire Serverless : Si votre Workspace n'autorise pas la politique budgétaire Serverless par default, définissez une politique sur l'Experimentation MLflow avant d'enregistrer les évaluateurs. Consultez Configurer une politique budgétaire Serverless pour une Experimentation MLflow.

  • Identifiant du SQL Warehouse (pour les traces Unity Catalog) : si vos traces sont stockées dans Unity Catalog, vous devez configurer un identifiant de SQL Warehouse pour que le monitoring fonctionne. Voir Configurer un SQL Warehouse pour les traces Unity Catalog.

Configurez un SQL Warehouse pour les traces Unity Catalog​

Si vos traces sont stockées dans Unity Catalog, le job de monitoring exécute des requêtes d'évaluation sur les tables Unity Catalog via un SQL warehouse. Configurez un ID de warehouse sur l'Experimentation avant d'enregistrer les évaluateurs, sous peine de voir les Jobs de monitoring échouer avec une erreur indiquant que le tag mlflow.monitoring.sqlWarehouseId est manquant.

Définissez l’ID du SQL Warehouse à l’aide de set_databricks_monitoring_sql_warehouse_id(). Cet assistant stocke l’ID dans le tag d’Experimentation mlflow.monitoring.sqlWarehouseId, à partir duquel le Job de monitoring le lit :

Python
from mlflow.tracing import set_databricks_monitoring_sql_warehouse_id

# Set the SQL warehouse ID for monitoring
set_databricks_monitoring_sql_warehouse_id(
    sql_warehouse_id="<SQL_WAREHOUSE_ID>",
    experiment_id="<EXPERIMENT_ID>"  # Optional, uses active experiment if not specified
)
remarque

La définition de la variable d’environnement MLFLOW_TRACING_SQL_WAREHOUSE_ID dans votre notebook ou votre application ne constitue pas un substitut. Il s’applique uniquement au processus où vous l’avez défini. Le job de monitoring s’exécute séparément et lit l’ID du warehouse à partir du tag de l’Experimentation. Utilisez set_databricks_monitoring_sql_warehouse_id() afin que l’ID du warehouse persiste sur l’Experimentation.

La configuration du monitoring pour les traces Unity Catalog nécessite les autorisations au niveau du workspace suivantes :

  • CAN USE sur le SQL Warehouse.
  • CAN EDIT sur l’expérimentation MLflow.
  • Autorisation sur le job de monitoring (accordée automatiquement lorsque vous enregistrez le premier évaluateur).

Le job de monitoring s’exécute sous l’identité de l’utilisateur qui a enregistré en premier un évaluateur sur l’expérimentation. Les autorisations de cet utilisateur déterminent ce que le job de monitoring peut consulter.

Get start​

Le monitoring commence dès que vous start un évaluateur. Enregistrez un évaluateur auprès de votre expérimentation, puis start it avec une configuration d’échantillonnage utilisant le modèle .register() et .start() :

Python
from mlflow.genai.scorers import Safety, ScorerSamplingConfig

# Register and start a built-in judge
safety_judge = Safety().register(name="safety")
safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.7))

Ce même schéma en deux étapes fonctionne pour tout type d’évaluateur : juges intégrés, juges personnalisés, évaluateurs basés sur du code et juges à tours multiples.

Pour connaître les types d’évaluateurs et de juges disponibles, consultez Scorers and judges.

remarque

À tout moment, au maximum 20 évaluateurs peuvent être associés à une expérimentation pour un monitoring continu de la qualité.

Afficher les résultats​

Après la planification des scorers, prévoyez 15 à 20 minutes pour le traitement initial. Ensuite :

  1. Accédez à votre expérience MLflow.
  2. Ouvrez l'onglet Traces pour voir les évaluations jointes aux traces.
  3. Utilisez les tableaux de bord de monitoring pour suivre les tendances de qualité.

Pour les juges multi-tours, les évaluations sont attachées à la première trace de chaque session. Consultez Comment les évaluations sont stockées pour plus de détails.

Bonnes pratiques​

Stratégie d’échantillonnage​

  • Pour les évaluateurs critiques tels que les vérifications de sûreté et de sécurité, utilisez sample_rate=1.0.

  • Pour les évaluateurs coûteux, tels que les juges LLM complexes, utilisez des taux d'échantillonnage plus faibles (0,05-0,2).

  • Pour une amélioration itérative pendant le développement, utilisez des taux modérés (0,3-0,5).

  • Équilibrez la couverture et le coût, comme le montrent les exemples suivants :

    Python
    # High-priority scorers: higher sampling
    safety_judge = Safety().register(name="safety")
    safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=1.0))  # 100% coverage for critical safety

    # Expensive scorers: lower sampling
    complex_scorer = ComplexCustomScorer().register(name="complex_analysis")
    complex_scorer = complex_scorer.start(sampling_config=ScorerSamplingConfig(sample_rate=0.05))  # 5% for expensive operations

Filtrer les traces​

Utilisez le paramètre filter_string dans ScorerSamplingConfig pour contrôler les traces qu'un évaluateur évalue. Ceci utilise la même syntaxe de filtre que mlflow.search_traces().

Python
from mlflow.genai.scorers import Safety, ScorerSamplingConfig

# Only evaluate traces that completed successfully
safety_judge = Safety().register(name="safety")
safety_judge = safety_judge.start(
    sampling_config=ScorerSamplingConfig(
        sample_rate=1.0,
        filter_string="attributes.status = 'OK'"
    ),
)

Vous pouvez combiner plusieurs conditions :

Python
import time

# Evaluate successful traces from the last 24 hours
one_day_ago = int((time.time() - 86400) * 1000)
safety_judge = safety_judge.start(
    sampling_config=ScorerSamplingConfig(
        sample_rate=0.5,
        filter_string=f"attributes.status = 'OK' AND attributes.timestamp_ms > {one_day_ago}"
    ),
)

Conception d'évaluateur personnalisé​

Maintenez les évaluateurs personnalisés autonomes, comme le montre l'exemple suivant :

Python
@scorer
def well_designed_scorer(inputs, outputs):
    # All imports inside the function
    import re
    import json

    # Handle missing data gracefully
    response = outputs.get("response", "")
    if not response:
        return 0.0

    # Return consistent types
    return float(len(response) > 100)

Dépannage​

Évaluateurs non exécutés​

Si les évaluateurs ne s'exécutent pas, vérifiez les points suivants :

  1. Vérifier l'expérimentation : Assurez-vous que les traces sont enregistrées dans l'expérimentation, et non dans des exécutions individuelles.
  2. Taux d'échantillonnage : Avec des taux d'échantillonnage faibles, l'affichage des résultats peut prendre du temps.
  3. Vérifiez la chaîne de filtre : assurez-vous que votre filter_string correspond aux traces réelles.

Problèmes de sérialisation​

Les évaluateurs personnalisés pour le monitoring de production sont sérialisés afin qu'ils puissent être exécutés à distance par le service de monitoring. Ceci impose plusieurs contraintes :

  • Prérequis du Notebook : Les fonctions @scorer personnalisées doivent être définies et enregistrées depuis un Notebook Databricks. Le mécanisme de sérialisation repose sur l'environnement du notebook.
  • Fonctions autonomes : toutes les importations doivent être intégrées dans le corps de la fonction. Les références à des variables, modules ou objets externes définis en dehors de la fonction ne sont pas capturées pendant la sérialisation.
  • Pas de scorers basés sur des classes : seuls les scorers basés sur le décorateur @scorer peuvent être enregistrés. Les sous-classes basées sur des classes Scorer ne peuvent pas être sérialisées pour une exécution à distance.
  • Aucune indication de type nécessitant des importations : Les indications de type dans la signature de fonction qui nécessitent des instructions d'importation (par exemple, List de typing) provoquent des échecs de sérialisation.

Lorsque vous créez un évaluateur personnalisé, incluez les importations dans la définition de la fonction.

Python
# Avoid external dependencies
import external_library  # Outside function

@scorer
def bad_scorer(outputs):
    return external_library.process(outputs)

# Include imports in the function definition
@scorer
def good_scorer(outputs):
    import json  # Inside function
    return len(json.dumps(outputs))

# Avoid using type hints in scorer function signature that requires imports
from typing import List

@scorer
def scorer_with_bad_types(outputs: List[str]):
    return False

# Class-based scorers are not supported for production monitoring
class MyScorer(Scorer):
    name: str = "my_scorer"
    def __call__(self, outputs):
        return len(outputs) > 10

Étape suivante : Gérer les scoreurs de production

Ressources supplémentaires​

Guides de référence​

Sur cette page