Como a qualidade, o custo e a latência são avaliados pela Avaliação do Agente

Importante

Esta funcionalidade está em Pré-visualização Pública.

Este artigo explica como a Avaliação de Agentes avalia a qualidade, o custo e a latência do seu aplicativo de IA e fornece informações para orientar suas melhorias de qualidade e otimizações de custo e latência. Abrange o seguinte:

• Como a qualidade é avaliada pelos juízes do 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 de MLflow para qualidade, custo e latência.

Para obter informações de referência sobre cada um dos juízes LLM integrados, consulte Referência de juízes LLM do Mosaic AI Agent Evaluation.

Como a qualidade é avaliada pelos juízes de LLM

A Avaliação do Agente avalia a qualidade usando juízes LLM em duas etapas:

1. Os juízes do LLM avaliam aspetos específicos de qualidade (como correção e fundamentação) para cada linha. Para obter detalhes, consulte Etapa 1: os juízes do LLM avaliam a qualidade de cada linha.
2. A Avaliação do Agente combina as avaliações individuais de cada juiz em uma pontuação geral de aprovação/reprovação e causa raiz para quaisquer falhas. Para obter detalhes, consulte Etapa 2: combinar avaliações de juízes LLM para identificar a causa raiz dos problemas de qualidade.

Para obter informações sobre confiança e segurança dos juízes LLM, consulte Informações sobre os modelos que capacitam os juízes LLM.

Etapa 1: Os juízes do LLM avaliam a qualidade de cada linha

Para cada linha de entrada, a Avaliação do Agente usa um conjunto de juízes LLM para avaliar diferentes aspetos da qualidade sobre as saídas do agente. Cada juiz produz uma pontuação de sim ou não e uma fundamentação escrita para essa pontuação, como mostra o exemplo abaixo:

Para obter detalhes sobre os juízes de LLM usados, consulte Juízes de LLM disponíveis.

Etapa 2: Combinar avaliações de juízes LLM para identificar a causa raiz dos problemas de qualidade

Depois de executar os juízes de LLM, a Avaliação do Agente analisa seus resultados 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, a Avaliação do Agente identifica qual juiz LLM específico causou a falha e fornece correções sugeridas.

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

A captura de tela a seguir é um exemplo de uma análise de resumo na interface do usuário:

Os resultados de cada linha estão disponíveis na interface do usuário da exibição detalhada:

Juízes LLM disponíveis

A tabela abaixo resume o conjunto de juízes de LLM usados na Avaliação de Agentes para avaliar diferentes aspetos da qualidade. Para obter mais detalhes, consulte Juízes de resposta e Juízes de recuperação.

Para obter detalhes sobre os modelos que capacitam juízes LLM, consulte Informações sobre os modelos que capacitam juízes LLM. Para obter informações de referência sobre cada um dos juízes LLM integrados, consulte Referência de juízes LLM do Mosaic AI Agent Evaluation.

Nome do juiz	Passo	Aspeto de qualidade que o juiz avalia	Entradas necessárias	Requer verdade fundamental?
relevance_to_query	Response	O endereço de resposta (é relevante para) o pedido do utilizador?	- response, request	Não
groundedness	Response	A resposta gerada está fundamentada no contexto recuperado (não alucinante)?	- response, trace[retrieved_context]	Não
safety	Response	Há conteúdo nocivo ou tóxico na resposta?	- response	Não
correctness	Response	A resposta gerada é precisa (em comparação com a verdade básica)?	- response, expected_response	Sim
chunk_relevance	Obtenção	O retriever encontrou pedaços que são úteis (relevantes) para responder ao pedido do utilizador? Nota: Este juiz é aplicado separadamente a cada parte recuperada, produzindo uma pontuação e uma fundamentação para cada parte. Essas pontuações são agregadas em uma chunk_relevance/precision pontuação para cada linha que representa a % de partes relevantes.	- retrieved_context, request	Não
document_recall	Obtenção	Quantos dos documentos relevantes conhecidos o recuperador encontrou?	- retrieved_context, expected_retrieved_context[].doc_uri	Sim
context_sufficiency	Obtenção	O recuperador encontrou documentos com informações suficientes para produzir a resposta esperada?	- retrieved_context, expected_response	Sim

As capturas de tela a seguir 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 é considerada pass. Se algum juiz falhar, a causa raiz é determinada como o primeiro juiz a falhar com base na lista ordenada abaixo. Esta ordenação é utilizada porque as avaliações dos juízes são frequentemente correlacionadas de forma causal. Por exemplo, se context_sufficiency avaliar que o retriever não buscou os blocos 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 do fundamento for fornecida como entrada, a seguinte ordem é usada:

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. Qualquer juiz de LLM definido pelo cliente

Se a verdade do fundamento não for fornecida como entrada, a seguinte ordem será usada:

1. chunk_relevance - existe pelo menos 1 pedaço relevante?
2. groundedness
3. relevant_to_query
4. safety
5. Qualquer juiz de LLM definido pelo cliente

Como o Databricks mantém e melhora a precisão dos juízes LLM

A Databricks dedica-se a melhorar a qualidade dos nossos juízes LLM. A qualidade é avaliada medindo o quão bem o juiz 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 (percentagem de etiquetas previstas que correspondem à etiqueta do avaliador humano).
• Aumento da pontuação na F1.
• Diminuição da taxa de falsos positivos.
• Diminuição da taxa de falsos negativos.

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

Para obter mais detalhes sobre como o Databricks mede e melhora continuamente a qualidade dos juízes, consulte Databricks anuncia melhorias significativas para os juízes LLM integrados na Avaliação de Agente.

Experimente juízes usando o databricks-agents SDK

O databricks-agents SDK inclui APIs para invocar diretamente juízes nas entradas do usuário. Você pode usar essas APIs para uma experiência rápida e fácil para ver como os juízes trabalham.

Execute o seguinte código para instalar o databricks-agents pacote e reiniciar o kernel python:

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

Em seguida, você pode executar o código a seguir em seu bloco de anotações e editá-lo conforme necessário para experimentar os diferentes juízes em suas próprias entradas.

from databricks.agents.eval 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."

# 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 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

A Avaliação do Agente mede a contagem de tokens e a latência de execução para ajudá-lo a entender o desempenho do seu agente.

Custo do token

Para avaliar o custo, a Avaliação do Agente calcula a contagem total de tokens em todas as chamadas de geração LLM no rastreamento. Isso se aproxima do custo total dado como mais tokens, o que geralmente leva a mais custo. As contagens de tokens só são calculadas quando um trace está disponível. Se o model argumento for incluído na chamada para mlflow.evaluate(), um rastreamento será gerado automaticamente. Você também pode fornecer diretamente uma trace coluna no conjunto de dados de avaliação.

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

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

Latência de execução

Calcula a latência de todo o aplicativo em segundos para o rastreamento. A latência só é calculada quando um rastreamento está disponível. Se o model argumento for incluído na chamada para mlflow.evaluate(), um rastreamento será gerado automaticamente. Você também pode fornecer diretamente uma trace coluna no conjunto de dados 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 de MLflow para qualidade, custo e latência

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

A Avaliação de Agentes produz as seguintes métricas:

Nome da métrica	Tipo	Description
retrieval/llm_judged/chunk_relevance/precision/average	float, [0, 1]	Valor médio de chunk_relevance/precision todas as perguntas.
retrieval/llm_judged/context_sufficiency/rating/percentage	float, [0, 1]	% das perguntas em que context_sufficiency/rating é julgado como yes.
response/llm_judged/correctness/rating/percentage	float, [0, 1]	% das perguntas em que correctness/rating é julgado como yes.
response/llm_judged/relevance_to_query/rating/percentage	float, [0, 1]	% das perguntas em que relevance_to_query/rating se julga ser yes.
response/llm_judged/groundedness/rating/percentage	float, [0, 1]	% das perguntas em que groundedness/rating é julgado como yes.
response/llm_judged/safety/rating/average	float, [0, 1]	% das perguntas em que se julga safety/rating ser yes.
agent/total_token_count/average	int	Valor médio de total_token_count todas as perguntas.
agent/input_token_count/average	int	Valor médio de input_token_count todas as perguntas.
agent/output_token_count/average	int	Valor médio de output_token_count todas as perguntas.
agent/latency_seconds/average	float	Valor médio de latency_seconds todas as perguntas.
response/llm_judged/{custom_response_judge_name}/rating/percentage	float, [0, 1]	% das perguntas em que {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 todas as perguntas.

As capturas de tela a seguir mostram como as métricas aparecem na interface do usuário:

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

• Os juízes LLM podem usar serviços de terceiros para avaliar seus aplicativos GenAI, incluindo o Azure OpenAI operado pela Microsoft.
• Para o Azure OpenAI, o Databricks optou por não participar do Monitoramento de Abuso, portanto, nenhum prompt ou resposta é armazenado com o Azure OpenAI.
• Para os espaços de trabalho da União Europeia (UE), os juízes LLM utilizam modelos alojados na UE. Todas as outras regiões usam modelos hospedados nos EUA.
• A desativação dos recursos de assistência de IA alimentados por IA do Azure impede que o juiz LLM chame modelos com tecnologia de IA do Azure.
• Os dados enviados ao juiz LLM não são usados para nenhum modelo de treinamento.
• Os juízes LLM destinam-se a ajudar os clientes a avaliar seus aplicativos RAG, e os resultados dos juízes LLM não devem ser usados para treinar, melhorar ou ajustar um LLM.