Como a qualidade, o custo e a latência são avaliados por Agent Evaluation (MLflow 2)

importante

A Databricks recomenda usar o MLflow 3 para a avaliação e monitoramento de aplicativos GenAI. Esta página descreve o MLflow 2 Agent Evaluation.

• Para uma introdução à avaliação e ao monitoramento no MLflow 3, consulte Avaliar e monitorar agentes de AI.
• Para obter informações sobre como migrar para o MLflow 3, consulte Migrar para o MLflow 3 a partir da Agent Evaluation.
• Para informações sobre o MLflow 3 sobre este tópico, consulte Avaliadores personalizados.

Este artigo explica como o Agent Evaluation avalia a qualidade, o custo e a latência do seu aplicativo de AI e fornece percepções para guia suas melhorias de qualidade e otimizações de custo e latência. Abrange o seguinte:

• Como a qualidade é avaliada por juízes de LLM.
• Como o custo e a latência são avaliados.
• Como as métricas são agregadas no nível de uma execução do MLflow para qualidade, custo e latência.

Para informações de referência sobre cada um dos juízes LLM integrados, consulte Juízes de AI integrados (MLflow 2).

Como a qualidade é avaliada por juízes LLM

Agent Evaluation avalia a qualidade usando juízes LLM em dois os passos:

1. Juízes LLM avaliam aspectos de qualidade específicos (como correção e fundamentação) para cada linha. Para obter detalhes, consulte o passo 1: juízes LLM avaliam a qualidade de cada linha.
2. A Agent Evaluation combina as avaliações de juízes individuais em uma pontuação geral de aprovação/reprovação e causa raiz para quaisquer falhas. Para obter detalhes, consulte O passo 2: Combine as avaliações do juiz LLM para identificar a causa raiz de problemas de qualidade.

Para obter informações de confiança e segurança do juiz LLM, consulte Informações sobre os modelos que impulsionam os juízes LLM.

nota

Em conversas de vários turnos, os juízes LLM avaliam apenas a última entrada na conversa.

O passo 1: os juízes LLM avaliam a qualidade de cada linha

Para cada linha de entrada, Agent Evaluation usa um conjunto de juízes LLM para avaliar diferentes aspectos de qualidade sobre as saídas do agente. Cada juiz produz uma pontuação de sim ou não e uma justificativa escrita para essa pontuação, conforme mostrado no exemplo abaixo:

Para detalhes sobre os juízes LLM usados, consulte juízes de AI integrados.

O passo 2: Combine as avaliações do juiz LLM para identificar a causa raiz dos problemas de qualidade

Após executar juízes LLM, o Agent Evaluation analisa suas saídas para avaliar a qualidade geral e determinar uma pontuação de qualidade de aprovação/reprovação nas avaliações coletivas do juiz. Se a qualidade geral falhar, o Agent Evaluation identifica qual juiz LLM específico causou a falha e fornece correções sugeridas.

Os dados são mostrados na IU do MLflow e também estão disponíveis na execução do MLflow em um DataFrame retornado pela chamada mlflow.evaluate(...). Consulte revisar a saída da avaliação para obter detalhes sobre como acessar o DataFrame.

A captura de tela a seguir é um exemplo de uma análise de resumo na IU:

Clique em uma solicitação para ver os detalhes:

Juízes de AI integrados

Consulte Juízes de AI integrados (MLflow 2) para obter detalhes sobre os Juízes de AI integrados fornecidos pela Agent Evaluation.

As seguintes capturas de tela mostram exemplos de como esses juízes aparecem na interface do usuário:

Como a causa raiz é determinada

Se todos os juízes passarem, a qualidade será considerada pass. Se algum juiz falhar, a causa raiz será determinada como o primeiro juiz a falhar com base na lista ordenada abaixo. Essa ordenação é usada porque as avaliações dos juízes geralmente estão correlacionadas de forma causal. Por exemplo, se context_sufficiency avaliar que o recuperador não buscou os trechos ou documentos corretos para a solicitação de entrada, é provável que o gerador não consiga sintetizar uma boa resposta e, portanto, correctness também falhará.

Se a verdade fundamental for fornecida como entrada, a seguinte ordem é usada:

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. guideline_adherence (se guidelines ou global_guidelines forem fornecidos)
6. Qualquer juiz LLM definido pelo cliente

Se a verdade fundamental não for fornecida como entrada, a seguinte ordem é usada:

1. chunk_relevance - há pelo menos 1 fragmento relevante?
2. groundedness
3. relevant_to_query
4. safety
5. guideline_adherence (se guidelines ou global_guidelines forem fornecidos)
6. Qualquer juiz LLM definido pelo cliente

Como a Databricks mantém e aprimora a precisão do juiz LLM

A Databricks dedica-se a aprimorar a qualidade dos nossos juízes de LLM. A qualidade é avaliada medindo o quão bem o juiz de LLM concorda com os avaliadores humanos, usando as seguintes métricas:

• Aumento do Kappa de Cohen (uma medida de concordância entre avaliadores).
• Maior precisão (percentual de rótulos previstos que correspondem ao rótulo do avaliador humano).
• Pontuação F1 aumentada.
• Taxa de falsos positivos diminuída.
• Taxa de falso negativo reduzida.

Para medir essas métricas, a Databricks usa exemplos diversos e desafiadores de datasets acadêmicos e proprietários que são representativos dos datasets de clientes para comparar e aprimorar os juízes em relação às abordagens de juízes de LLM de última geração, garantindo melhoria contínua e alta precisão.

Para mais detalhes sobre como a Databricks mede e melhora continuamente a qualidade dos juízes, consulte A Databricks anuncia melhorias significativas nos juízes de LLM integrados na Agent Evaluation.

Chame os juízes usando o SDK Python

O SDK databricks-agents inclui APIs para invocar diretamente juízes nas entradas do usuário. É possível usar estas APIs para um experimento rápido e fácil para ver como os juízes funcionam.

Execute o código a seguir para instalar o pacote databricks-agents e reiniciar o kernel Python:

Python

%pip install databricks-agents==0.16.0 -U
dbutils.library.restartPython()

Você pode então executar o seguinte código em seu notebook e editá-lo conforme necessário para testar os diferentes juízes em suas próprias entradas.

Python

from databricks.agents.evals import judges

SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
        {
            "content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
        }
    ]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
# You can also just pass an array of guidelines directly to guidelines, but Databricks recommends naming them with a dictionary.
SAMPLE_GUIDELINES = {
    "english": ["The response must be in English", "The retrieved context must be in English"],
    "clarity": ["The response must be clear, coherent, and concise"],
}
SAMPLE_GUIDELINES_CONTEXT = {
  "retrieved_context": str(SAMPLE_RETRIEVED_CONTEXT)
}

# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
  request=SAMPLE_REQUEST,
  expected_response=SAMPLE_EXPECTED_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  expected_response=SAMPLE_EXPECTED_RESPONSE
)

# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For guideline_adherence, the required inputs are `request`, `response` or `guidelines_context`, and `guidelines`.
judges.guideline_adherence(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  guidelines=SAMPLE_GUIDELINES,
  # `guidelines_context` requires `databricks-agents>=0.20.0`. It can be specified with or in place of the response.
  guidelines_context=SAMPLE_GUIDELINES_CONTEXT,
)

# For safety, the required inputs are `request` and `response`.
judges.safety(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

Como o custo e a latência são avaliados

O Agent Evaluation mede as contagens de tokens e a latência de execução para ajudar a entender o desempenho do seu agente.

Custo do tokens

Para avaliar o custo, o Agent Evaluation calcula a contagem total de tokens em todas as chamadas de geração de LLM no rastreamento. Isso aproxima o custo total dado como mais tokens, o que geralmente leva a mais custo. A contagem de tokens é calculada apenas quando um(a) trace está disponível. Se o argumento model for incluído na chamada para mlflow.evaluate(), um rastreamento é gerado automaticamente. Você também pode fornecer diretamente uma coluna trace no dataset de avaliação.

As seguintes contagens de tokens são calculadas para cada linha:

Campo de dados	Tipo	Descrição
total_token_count	integer	Soma de todos os tokens de entrada e saída em todos os spans de LLM no rastreamento do agente.
total_input_token_count	integer	Soma de todos os tokens de entrada em todas as extensões de LLM no rastreamento do agente.
total_output_token_count	integer	Soma de todos os tokens de saída em todos os intervalos LLM no rastreamento do agente.

Latência de execução

Compute toda a latência do aplicativo em segundos para o rastreamento. A latência é calculada somente quando um rastreamento está disponível. Se o argumento model for incluído na chamada para mlflow.evaluate(), um rastreamento será gerado automaticamente. Você também pode fornecer diretamente uma coluna trace no dataset de avaliação.

A seguinte medição de latência é calculada para cada linha:

Nome	Descrição
latency_seconds	Latência de ponta a ponta com base no rastreamento

Como as métricas são agregadas no nível de uma execução do MLflow para qualidade, custo e latência

Após calcular todas as avaliações de qualidade, custo e latência por linha, o Agent Evaluation agrega essas avaliações em métricas por execução que são registradas em uma execução do MLflow e resumem a qualidade, o custo e a latência do seu agente em todas as linhas de entrada.

Agent Evaluation produz as seguintes métricas:

Nome da métrica	Tipo	Descrição
retrieval/llm_judged/chunk_relevance/precision/average	float, [0, 1]	Valor médio de chunk_relevance/precision em todas as perguntas.
retrieval/llm_judged/context_sufficiency/rating/percentage	float, [0, 1]	Porcentagem de perguntas onde context_sufficiency/rating é julgado como yes.
response/llm_judged/correctness/rating/percentage	float, [0, 1]	Porcentagem de perguntas onde correctness/rating é julgado como yes.
response/llm_judged/relevance_to_query/rating/percentage	float, [0, 1]	% das perguntas em que relevance_to_query/rating é julgado como yes.
response/llm_judged/groundedness/rating/percentage	float, [0, 1]	Porcentagem de perguntas onde groundedness/rating é julgado como yes.
response/llm_judged/guideline_adherence/rating/percentage	float, [0, 1]	Porcentagem de perguntas onde guideline_adherence/rating é julgado como yes.
response/llm_judged/safety/rating/average	float, [0, 1]	% de perguntas em que safety/rating é julgado como yes.
agent/total_token_count/average	int	Valor médio de total_token_count em todas as perguntas.
agent/input_token_count/average	int	Valor médio de input_token_count em todas as perguntas.
agent/output_token_count/average	int	Valor médio de output_token_count em todas as perguntas.
agent/latency_seconds/average	float	Valor médio de latency_seconds em todas as perguntas.
response/llm_judged/{custom_response_judge_name}/rating/percentage	float, [0, 1]	Porcentagem de perguntas onde {custom_response_judge_name}/rating é julgado como yes.
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average	float, [0, 1]	Valor médio de {custom_retrieval_judge_name}/precision em todas as perguntas.

As capturas de tela a seguir mostram como as métricas aparecem na UI:

Informações sobre os modelos que capacitam os juízes do LLM

• Os juízes do LLM podem utilizar serviços de terceiros para avaliar suas aplicações GenAI, incluindo o Azure OpenAI operado pela Microsoft.
• Para o Azure OpenAI, a Databricks optou por não utilizar o Abuse Monitoring, portanto nenhum prompt ou resposta é armazenado com o Azure OpenAI.
• Para os espaços de trabalho da União Europeia (UE), os juízes do LLM utilizam modelos hospedados na UE. Todas as outras regiões utilizam modelos hospedados nos EUA.
• Desativar os recursos de IA desenvolvidos por parceiros impede que o juiz do LLM ligue para modelos desenvolvidos por parceiros. Ainda é possível usar juízes LLM fornecendo seu próprio modelo.
• Os juízes de LLM destinam-se a ajudar os clientes a avaliar seus agentes/aplicativos de GenAI, e as saídas dos juízes de LLM não devem ser usadas para ensinar, melhorar ou ajustar um LLM.