Überwachen von GenAI-Apps in der Produktion

Von Bedeutung

Dieses Feature befindet sich in der Betaversion. Arbeitsbereichsadministratoren können den Zugriff auf dieses Feature über die Vorschauseite steuern. Siehe Manage Azure Databricks Previews.

Mit der Produktionsüberwachung können Sie MLflow 3 Scorer automatisch auf Protokolle Ihrer GenAI-Apps anwenden, um die Qualität kontinuierlich zu bewerten. Sie planen Bewertungen im Rahmen eines MLflow-Experiments, und der Überwachungsdienst wertet eine konfigurierbare Stichprobe eingehender Spuren aus. Die Ergebnisse werden als Feedback an jede ausgewertete Ablaufverfolgung angefügt.

Die Produktionsüberwachung umfasst Folgendes:

Automatisierte Qualitätsbewertung mit integrierten oder benutzerdefinierten Scorern, einschließlich Multi-Turn-Prüfern für die Bewertung ganzer Unterhaltungen.
Konfigurierbare Samplingraten, damit Sie den Kompromiss zwischen Abdeckung und Rechenkosten steuern können.
Verwenden Sie die gleichen Scorer in der Entwicklung und Produktion, um eine konsistente Bewertung sicherzustellen.
Kontinuierliche Qualitätsbewertung mit laufender Überwachung im Hintergrund.

Hinweis

Die MLflow 3 Produktionsüberwachung ist kompatibel mit Traces, die von MLflow 2 protokolliert werden.

Voraussetzungen

Stellen Sie vor dem Einrichten der Produktionsüberwachung folgendes sicher:

MLflow-Experiment: Ein MLflow-Experiment, in dem Traces protokolliert werden. Wenn kein Experiment angegeben ist, wird das aktive Experiment verwendet.
Instrumentierte Produktionsanwendung: Ihre GenAI-App muss Traces mithilfe von MLflow Tracing erfassen. Weitere Informationen finden Sie im Produktionsablaufverfolgungshandbuch.
Definierte Scorer: Getestete Scorer, die mit dem Trace-Format Ihrer Anwendung arbeiten. Wenn Sie Ihre Produktions-App als predict_fn in mlflow.genai.evaluate() während der Entwicklung verwendet haben, sind Ihre Scorer wahrscheinlich bereits kompatibel.

SQL Warehouse ID (für Unity Catalog-Ablaufverfolgungen):Wenn Ihre Ablaufverfolgungen im Unity-Katalog gespeichert sind, müssen Sie eine SQL Warehouse-ID konfigurieren, damit die Überwachung funktioniert. Siehe Aktivieren der Produktionsüberwachung.

Erste Schritte

Um die Produktionsüberwachung einzurichten, registrieren Sie einen Scorer bei Ihrem MLflow-Experiment und starten sie dann mit einer Samplingkonfiguration. Dieses zweistufige Muster (.register() dann .start()) gilt für alle Scorertypen.

Hinweis

Zu einem bestimmten Zeitpunkt können höchstens 20 Scorer mit einem Experiment zur kontinuierlichen Qualitätsüberwachung verknüpft werden.

Weitere Informationen zu Scorern finden Sie in den folgenden Themen:

In den folgenden Abschnitten wird beschrieben, wie sie die verschiedenen Arten von Richtern verwenden und wie sie kombiniert werden. Erweitern Sie einen Abschnitt, um mehr zu erfahren.

LLM-Juroren mithilfe der Benutzeroberfläche erstellen und planen

Erstellen und Planen von LLM-Richtern mithilfe der Benutzeroberfläche

Sie können die Benutzeroberfläche von MLflow Experiment verwenden, um Scorer basierend auf LLM-Bewertungen zu erstellen und zu testen.

So erstellen Sie einen neuen LLM-Richter:

Navigieren Sie zur Registerkarte "Richter " in der Benutzeroberfläche des MLflow-Experiments.
Klicken Sie auf "Neuer LLM-Richter".
Geben Sie an, was das Bewertungssystem auswerten soll, indem Sie "Ablaufverfolgungen" oder "Sitzungen" auswählen.
Geben Sie einen Namen für den Richter ein.
Klicken Sie wie dargestellt auf den Pfeil, um den Abschnitt "Bewertungskriterien " anzuzeigen.
Wählen Sie im Dropdownmenü den Typ des Richters aus. Bei einigen Richtertypen können Sie benutzerdefinierte Anweisungen einschließlich Variablen eingeben.
Klicken Sie wie dargestellt auf den Pfeil, um den Abschnitt " Automatische Auswertung" anzuzeigen.
Stellen Sie den Schalter "Für alle zukünftigen Ablaufverfolgungen ausführen" nach Wunsch ein.
(Optional) Passen Sie unter Erweiterte Einstellungen die Abtastrate und den Filter an, um zu steuern, welche Traces ausgewertet werden.
(Optional) Zum Testen der neuen Bewertungskomponente mit einer bestehenden Sammlung von Traces:
1. Klicken Sie im linken Bereich auf " Ablaufverfolgungen auswählen ". Ein Popupfenster wird eingeblendet.
2. Wählen Sie die Ablaufverfolgungen aus, die Sie ausführen möchten, und klicken Sie auf Select (n).
3. Klicken Sie auf „Judge ausführen“. Die Ablaufverfolgungen werden ausgewertet, und die Ergebnisse werden angezeigt.
4. Überprüfen Sie die Ergebnisse. Verwenden Sie die Schaltflächen "Weiter" und "Zurück", um die Ergebnisse für jede ausgewählte Ablaufverfolgung zu durchlaufen.
5. Bearbeiten Sie bei Bedarf den Richter, und iterieren Sie ihn, bis Sie mit der Leistung des Richters zufrieden sind.
Klicken Sie zum Erstellen des Richters auf "Richter erstellen".

Sie können keinen benutzerdefinierten Code-Bewertungssystem mithilfe der Benutzeroberfläche erstellen. Gehen Sie wie folgt vor, um Vorlagencode anzuzeigen, den Sie nach Bedarf in Ihr Notizbuch kopieren und bearbeiten können:

Klicken Sie auf den Dropdownpfeil neben der Schaltfläche " Neuer LLM-Richter ", und wählen Sie "Benutzerdefinierter Coderichter" aus.
Ein Pop-up wird mit Anweisungen sowie Vorlagencode angezeigt, der zeigt, wie der benutzerdefinierte Coderichter definiert und ausgeführt wird.

Verwenden integrierter LLM-Richter

Verwenden Sie die integrierten LLM-Richter

MLflow bietet mehrere integrierte LLM-Richter, die Sie direkt verwenden können.

from mlflow.genai.scorers import Safety, ScorerSamplingConfig

# Register the scorer with a name and start monitoring
safety_judge = Safety().register(name="my_safety_judge")  # name must be unique to experiment
safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.7))

Standardmäßig verwendet jeder Richter ein vom Databricks gehostetes LLM, das zur Durchführung von GenAI-Qualitätsbewertungen entwickelt wurde. Sie können das Bewertungsmodell stattdessen so ändern, dass ein Databricks-Modell verwendet wird, das den Endpunkt bedient, indem Sie das model Argument in der Scorerdefinition verwenden. Das Modell muss im Format databricks:/<databricks-serving-endpoint-name>angegeben werden.

safety_judge = Safety(model="databricks:/databricks-gpt-oss-20b").register(name="my_custom_safety_judge")

Richtlinien für LLM-Richter verwenden

Richtlinien LLM-Richter bewerten Eingaben und Ausgaben mithilfe von Pass-/Fail-Kriterien für natürliche Sprache.

from mlflow.genai.scorers import Guidelines

# Create and register the guidelines scorer
english_judge = Guidelines(
  name="english",
  guidelines=["The response must be in English"]
).register(name="is_english")  # name must be unique to experiment

# Start monitoring with the specified sample rate
english_judge = english_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.7))

Wie integrierte Richter können Sie das Richtermodell so ändern, dass stattdessen ein Databricks-Modell verwendet wird, das den Endpunkt bedient.

english_judge = Guidelines(
  name="english",
  guidelines=["The response must be in English"],
  model="databricks:/databricks-gpt-oss-20b",
).register(name="custom_is_english")

Verwenden von LLM-Richtern mit benutzerdefinierten Eingabeaufforderungen

Verwenden Sie LLM-Richter mit benutzerdefinierten Prompts

Für mehr Flexibilität als Richtlinienrichter verwenden Sie LLM-Richter mit benutzerdefinierten Eingabeaufforderungen , die eine mehrstufige Qualitätsbewertung mit anpassbaren Auswahlkategorien ermöglichen.

from typing import Literal
from mlflow.genai import make_judge
from mlflow.genai.scorers import ScorerSamplingConfig

# Create a custom judge using make_judge
formality_judge = make_judge(
    name="formality",
    instructions="""You will look at the response and determine the formality of the response.

Request: {{ inputs }}
Response: {{ outputs }}

Evaluate whether the response is formal, somewhat formal, or not formal.
A response is somewhat formal if it mentions friendship, etc.""",
    feedback_value_type=Literal["formal", "semi_formal", "not_formal"],
    model="databricks:/databricks-gpt-oss-20b",  # optional
)

# Register the custom judge and start monitoring
registered_judge = formality_judge.register(name="my_formality_judge")  # name must be unique to experiment
registered_judge = registered_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.1))

Verwenden von benutzerdefinierten Scorerfunktionen

Um maximale Flexibilität zu erzielen, definieren und verwenden Sie eine benutzerdefinierte Scorerfunktion.

`:::important Anforderungen an benutzerdefinierte Scorer für die Produktionsüberwachung`

Nur @scorer Dekorator-basierte Scorer werden unterstützt. Klassenbasierte Scorer Unterklassen können nicht für die Produktionsüberwachung registriert werden. Wenn Sie einen klassenbasierten Scorer benötigen, sollten Sie ihn umgestalten, um stattdessen den @scorer Dekorateur zu verwenden.
Scorer müssen in einem Databricks-Notizbuch definiert und registriert werden. Der Überwachungsdienst serialisiert den Bewertungsfunktionscode für die Remoteausführung, und diese Serialisierung erfordert die Notebook-Umgebung. Scorer, die in eigenständigen Python Dateien oder lokalen IDE-Umgebungen definiert sind, können nicht für die Produktionsüberwachung serialisiert werden.
Scorer müssen eigenständig sein. Da Scorerfunktionen als Code für die Remoteausführung serialisiert werden, müssen alle Importe inline innerhalb des Funktionskörpers erfolgen. Die Funktion kann nicht auf Variablen, Objekte oder Module verweisen, die außerhalb davon definiert sind.

:::

Verwenden Sie beim Definieren von benutzerdefinierten Scorern keine Typhinweise, die in die Funktionssignatur importiert werden müssen. Wenn der Funktionskörper der Scorer-Funktion Pakete verwendet, die importiert werden müssen, importieren Sie diese Pakete in Zeile innerhalb der Funktion, um die ordnungsgemäße Serialisierung sicherzustellen.

Einige Pakete sind standardmäßig verfügbar, ohne dass ein Inlineimport erforderlich ist. Dazu gehören databricks-agents, , mlflow-skinny, openaiund alle Pakete, die in Der Serverless-Umgebung, Version 2 enthalten sind.

from mlflow.genai.scorers import scorer, ScorerSamplingConfig


# Custom metric: Check if response mentions Databricks
@scorer
def mentions_databricks(outputs):
    """Check if the response mentions Databricks"""
    return "databricks" in str(outputs.get("response", "")).lower()

# Register and start monitoring
databricks_scorer = mentions_databricks.register(name="databricks_mentions")
databricks_scorer = databricks_scorer.start(sampling_config=ScorerSamplingConfig(sample_rate=0.5))

Weitere beispiele für benutzerdefinierte Scorer finden Sie unter Erstellen benutzerdefinierter codebasierter Scorer.

Multi-Turn-Judges verwenden

Multi-Turn-Entscheider verwenden

Die Produktionsüberwachung unterstützt Multi-Turn-Analysen, die ganze Unterhaltungen statt einzelner Nachverfolgungen auswerten. Diese Richter bewerten Qualitätsmuster über mehrere Interaktionen hinweg, z. B. Frustration des Benutzers und Vollständigkeit der Unterhaltungen. Multi-Turn-Richter werden registriert und auf die gleiche Weise gestartet wie Einzelrichter.

Der Überwachungs-Job gruppiert Traces automatisch basierend auf mlflow.trace.session-Tag in Unterhaltungen. Mehrstufige Richter werden gestartet, nachdem eine Unterhaltung als beendet betrachtet wird – standardmäßig ist eine Unterhaltung abgeschlossen, wenn keine neuen Protokolle mit dieser Sitzungs-ID für 5 Minuten aufgenommen werden. Um diesen Puffer zu konfigurieren, legen Sie die MLFLOW_ONLINE_SCORING_DEFAULT_SESSION_COMPLETION_BUFFER_SECONDS Umgebungsvariable für den Überwachungsauftrag fest.

Die vollständige Liste der verfügbaren Mehrfachrichter finden Sie unter Multi-Turn-Richter. Ausführliche Informationen zur Unterhaltungsauswertung finden Sie unter "Auswerten von Unterhaltungen".

Hinweis

Um mehrfache Bewertungsdurchläufe zu verwenden, müssen Ihre Agenten Sitzungs-IDs für Traces festlegen. Details finden Sie unter "Nachverfolgen von Benutzern und Sitzungen ".

from mlflow.genai.scorers import (
    ConversationCompleteness,
    UserFrustration,
    ScorerSamplingConfig,
)

# Register and start multi-turn judges just like single-turn judges
completeness_scorer = ConversationCompleteness().register(name="conversation_completeness")
completeness_scorer = completeness_scorer.start(
    sampling_config=ScorerSamplingConfig(sample_rate=1.0),
)

frustration_scorer = UserFrustration().register(name="user_frustration")
frustration_scorer = frustration_scorer.start(
    sampling_config=ScorerSamplingConfig(sample_rate=1.0),
)

Kombinieren von Richtern

Sie können Einzel-Schritt-Richter und Mehrfach-Schritt-Richter im selben Experiment kombinieren. Registrieren und starten Sie jeden Scorer einzeln.

from mlflow.genai.scorers import Safety, Guidelines, UserFrustration, ScorerSamplingConfig

# Single-turn judges
safety_judge = Safety().register(name="safety")
safety_judge = safety_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=1.0))

english_judge = Guidelines(
    name="english",
    guidelines=["The response must be in English"]
).register(name="is_english")
english_judge = english_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.5))

# Multi-turn judge
frustration_judge = UserFrustration().register(name="frustration")
frustration_judge = frustration_judge.start(sampling_config=ScorerSamplingConfig(sample_rate=0.3))

Anzeigen der Ergebnisse

Nach der Planung von Scorern können Sie 15-20 Minuten für die anfängliche Verarbeitung zulassen. Führen Sie dann folgende Schritte aus:

Navigieren Sie zu Ihrem MLflow-Experiment.
Öffnen Sie die Registerkarte " Ablaufverfolgungen ", um Bewertungen anzuzeigen, die an Ablaufverfolgungen angefügt sind.
Verwenden Sie die Überwachungsdashboards, um Qualitätstrends nachzuverfolgen.

Bei mehrphasigen Bewertungen werden die Beurteilungen an das erste Protokoll in jeder Sitzung angehängt. Weitere Informationen finden Sie unter " Gespeicherte Bewertungen ".

Bewährte Methoden

Samplingstrategie

Verwenden Sie sample_rate=1.0 bei kritischen Prüfern wie Sicherheits- und Schutzprüfungen.
Bei teuren Scorern wie komplexen LLM-Richtern verwenden Sie niedrigere Stichprobenraten (0,05-0,2).
Für iterative Verbesserung während der Entwicklung verwenden Sie moderate Raten (0,3-0,5).

Stimmen Sie die Abdeckung mit den Kosten ab, wie in den folgenden Beispielen erläutert.

# 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

Filtern von Ablaufverfolgungen

Verwenden Sie den Parameter filter_string in ScorerSamplingConfig, um zu steuern, welche Spuren ein Scorer bewertet. Dies verwendet dieselbe Filtersyntax wie mlflow.search_traces().

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'"
    ),
)

Sie können mehrere Bedingungen kombinieren:

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}"
    ),
)

Benutzerdefiniertes Scorerdesign

Halten Sie benutzerdefinierte Scorer autark, wie im folgenden Beispiel gezeigt:

@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)

Problembehandlung

Scorer werden nicht ausgeführt

Wenn Scorer nicht ausgeführt werden, überprüfen Sie Folgendes:

Überprüfen Sie das Experiment: Stellen Sie sicher, dass Ablaufverfolgungen beim Experiment protokolliert werden, nicht bei einzelnen Läufen.
Samplingrate: Bei niedrigen Stichprobenraten kann es Zeit dauern, um Ergebnisse anzuzeigen.
Überprüfen Sie die Filterzeichenfolge: Stellen Sie sicher, dass Ihre filter_string mit den tatsächlichen Prozedurabläufen übereinstimmt.

Serialisierungsprobleme

Benutzerdefinierte Scorer für die Produktionsüberwachung werden serialisiert, sodass sie vom Überwachungsdienst remote ausgeführt werden können. Dies führt zu mehreren Einschränkungen:

Notizbuchanforderung: Benutzerdefinierte @scorer Funktionen müssen in einem Databricks-Notizbuch definiert und registriert werden. Der Serialisierungsmechanismus basiert auf der Notizbuchumgebung.
Eigenständige Funktionen: Alle Importe müssen innerhalb des Funktionskörpers inline sein. Verweise auf externe Variablen, Module oder Objekte, die außerhalb der Funktion definiert sind, werden während der Serialisierung nicht erfasst.
Keine klassenbasierten Scorer: Nur dekorator-basierte Scorer können registriert werden. Klassenbasierte Scorer Unterklassen können nicht für die Remoteausführung serialisiert werden.
Keine Typhinweise, die Importe erfordern: Typhinweise in der Funktionssignatur, die Importanweisungen erfordern (z List . B. von typing), verursachen Serialisierungsfehler.

Wenn Sie einen benutzerdefinierten Scorer erstellen, schließen Sie Importe in die Funktionsdefinition ein.

# 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

Nächste Schritte

Verwalten von Produktionsbewertungen – Verwalten des Lebenszyklus Ihrer Produktionsbewertungen.
Historische Spuren mit Scorern auffüllen – Scorer rückwirkend auf historische Spuren anwenden.
Archivieren von Ablaufverfolgungen in einer Delta-Tabelle – Speichern von Ablaufverfolgungen und Bewertungen in einer Delta-Tabelle.
Erstellen Sie benutzerdefinierte, codebasierte Scorer – maßgeschneiderte Scorer, die auf Ihre Anforderungen zugeschnitten sind.
Bewerten von Gesprächen – Erfahren Sie mehr über die Auswertung von Gesprächen und die Mehrfach-Urteile.
Erstellen von MLflow-Auswertungsdatensätzen – Verwenden Sie Überwachungsergebnisse, um die Qualität zu verbessern.

Referenzhandbücher

API-Referenz zur Scorerlebenszyklusverwaltung – API-Referenz für die Scorerlebenszyklusverwaltung.
Scorer und LLM-Richter – Verstehen Sie die Metriken, die die Überwachung antreiben.
Bewerten von GenAI während der Entwicklung – Wie sich die Offline-Auswertung auf die Produktion bezieht.

Feedback

War diese Seite hilfreich?

Last updated on 2026-04-19

Überwachen von GenAI-Apps in der Produktion

Voraussetzungen

Erste Schritte

Erstellen und Planen von LLM-Richtern mithilfe der Benutzeroberfläche

Verwenden Sie die integrierten LLM-Richter

Richtlinien für LLM-Richter verwenden

Verwenden Sie LLM-Richter mit benutzerdefinierten Prompts

Verwenden von benutzerdefinierten Scorerfunktionen

Multi-Turn-Entscheider verwenden

Kombinieren von Richtern

Anzeigen der Ergebnisse

Bewährte Methoden

Samplingstrategie

Filtern von Ablaufverfolgungen

Benutzerdefiniertes Scorerdesign

Problembehandlung

Scorer werden nicht ausgeführt

Serialisierungsprobleme

Nächste Schritte

Referenzhandbücher

Feedback

Zusätzliche Ressourcen