Pular para o conteúdo principal

Configurar o monitoramento de produção

info

Beta

Este recurso está em versão Beta. Os administradores do espaço de trabalho podem controlar o acesso a este recurso na página de Pré-visualizações . Veja as prévias do Gerenciador Databricks.

O monitoramento de produção permite executar automaticamente os avaliadores do MLflow 3 em rastreamentos dos seus agentes para avaliar a qualidade continuamente. Você programa avaliadores em um experimento do MLflow, e o serviço de monitoramento avalia uma amostra configurável de rastreamentos recebidos. Os resultados são anexados como feedback a cada rastreamento avaliado.

O monitoramento da produção inclui o seguinte:

  • Avaliação automatizada da qualidade usando avaliadores integrados ou personalizados, incluindo avaliadores de múltiplas interações para avaliar conversas inteiras.
  • Taxas de amostragem configuráveis para que você possa controlar a compensação entre cobertura e custo computacional.
  • Use os mesmos avaliadores no desenvolvimento e na produção para garantir uma avaliação consistente.
  • Avaliação contínua da qualidade com monitoramento em segundo plano.
nota

MLflow O monitoramento da produção 3 é compatível com os registros de traços do site MLflow 2.

Pré-requisitos

Antes de configurar o monitoramento de produção, certifique-se de ter:

  • ExperimentoMLflow : Um experimento MLflow onde os rastreamentos estão sendo registrados. Caso nenhum experimento seja especificado, o experimento ativo será utilizado.

  • Aplicação de produção instrumentada : seu agente deve registrar rastreamentos usando o MLflow Tracing. Consulte o guia de rastreamento de produção.

  • Pontuadores definidos : Pontuadores testados que funcionam com o formato de rastreamento do seu aplicativo. Se você usou seu aplicativo de produção como o predict_fn em mlflow.genai.evaluate() durante o desenvolvimento, seus avaliadores provavelmente já são compatíveis.

  • Política de orçamento serverless : Se o seu workspace não permite a política de orçamento serverless default, defina uma política no experiment do MLflow antes de registrar avaliadores. Confira Configurar uma política de orçamento serverless para um experimento MLflow.

  • ID do SQL warehouse (para rastreamentos do Unity Catalog) : se os seus rastreamentos estiverem armazenados no Unity Catalog, você deverá configurar um ID de SQL warehouse para que o monitoramento funcione. Consulte Configurar um SQL warehouse para rastreamentos do Unity Catalog.

Configurar um SQL warehouse para rastreamentos do Unity Catalog

Se seus rastreamentos estiverem armazenados no Unity Catalog, o job de monitoramento executará queries de pontuação nas tabelas do Unity Catalog por meio de um SQL warehouse. Configure um ID de warehouse no experimento antes de registrar os pontuadores, ou os jobs de monitoramento falharão com um erro indicando que a tag mlflow.monitoring.sqlWarehouseId está ausente.

Defina o ID do SQL warehouse usando set_databricks_monitoring_sql_warehouse_id(). Este auxiliar armazena o ID na tag de experimento mlflow.monitoring.sqlWarehouseId, que é de onde o job de monitoramento o lê:

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

A definição da variável de ambiente MLFLOW_TRACING_SQL_WAREHOUSE_ID no seu notebook ou aplicativo não é um substituto. Ele se aplica somente ao processo em que você o define. O job de monitoramento é executado separadamente e lê o ID do warehouse da tag de experimento. Use set_databricks_monitoring_sql_warehouse_id() para que o ID do warehouse persista no experimento.

Configurar o monitoramento para rastreamentos do Unity Catalog requer as seguintes permissões em nível de workspace:

  • CAN USE no SQL warehouse.
  • CAN EDIT no experimento do MLflow.
  • Permissão no job de monitoramento (concedida automaticamente quando você registra o primeiro pontuador).

O job de monitoramento é executado sob a identidade do usuário que registrou um avaliador no experimento pela primeira vez. As permissões deste usuário determinam o que o job de monitoramento pode acessar.

Comece agora

O monitoramento começa no momento em que você inicia um pontuador. Registre um avaliador com o seu experimento e, em seguida, inicie-o com uma configuração de amostragem usando o padrão .register() e .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))

Esse mesmo padrão de duas etapas funciona para qualquer tipo de avaliador: juízes integrados, juízes personalizados, avaliadores baseados em código e juízes de turnos múltiplos.

Para os tipos de pontuadores e avaliadores disponíveis, consulte Pontuadores e avaliadores.

nota

A qualquer momento, no máximo 20 avaliadores podem estar associados a um experimento para monitoramento contínuo da qualidade.

visualizar resultados

Após programar os avaliadores, aguarde 15 a 20 minutos para o processamento inicial. Então:

  1. Navegue até o seu experimento MLflow.
  2. Abra o Traces tab para visualizar as avaliações anexadas aos traços.
  3. Utilize os painéis de monitoramento para acompanhar as tendências de qualidade.

Para juízes com múltiplas rodadas, as avaliações são anexadas ao primeiro traçado em cada sessão. Consulte a seção "Como as avaliações são armazenadas" para obter mais detalhes.

Melhores práticas

Estratégia de amostragem

  • Para pontuações críticas, como verificações de segurança, use sample_rate=1.0.

  • Para avaliadores caros, como juízes LLM complexos, use taxas de amostragem mais baixas (0,05-0,2).

  • Para melhoria iterativa durante o desenvolvimento, use taxas moderadas (0,3-0,5).

  • Equilibre a cobertura com o custo, conforme mostrado nos exemplos a seguir:

    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

Rastreamento de filtros

Use o parâmetro filter_string em ScorerSamplingConfig para controlar quais traços um avaliador avalia. Isso usa a mesma sintaxe de filtro 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'"
),
)

Você pode combinar várias condições:

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

Design de marcador personalizado

Mantenha os marcadores personalizados independentes, conforme mostrado no exemplo a seguir:

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)

Solução de problemas

Os marcadores não estão correndo

Se os marcadores não estiverem em execução, verifique o seguinte:

  1. Verifique o experimento : certifique-se de que os rastreamentos são registros do experimento, e não de execuções individuais.
  2. Taxa de amostragem : Com taxas de amostragem baixas, pode demorar para ver os resultados.
  3. Verifique as strings de filtro : Certifique-se de que seu filter_string corresponda aos rastreamentos reais.

Problemas de serialização

Os indicadores personalizados para monitoramento de produção são serializados para que possam ser executados remotamente pelo serviço de monitoramento. Isso impõe diversas restrições:

  • RequisitoNotebook : Funções personalizadas @scorer devem ser definidas e registradas a partir de um Notebook Databricks . O mecanismo de serialização depende do ambiente Notebook.
  • Funções autocontidas : Todas as importações devem estar embutidas no corpo da função. Referências a variáveis externas, módulos ou objetos definidos fora da função não são capturadas durante a serialização.
  • Não há avaliadores baseados em classes : apenas avaliadores baseados em decoradores @scorer podem ser registrados. Subclasses baseadas em classes Scorer não podem ser serializadas para execução remota.
  • Sem dicas de tipo que exigem importações : Dicas de tipo na assinatura da função que exigem instruções de importação (por exemplo, List de typing) causam falhas de serialização.

Ao criar um marcador personalizado, inclua as importações na definição da função.

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

Próxima etapa: Gerenciar pontuadores de produção

Recursos adicionais

Guia de referência