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

Prévia

Este artigo explica como o Agent Evaluation avalia a qualidade, o custo e a latência de seu aplicativo AI e fornece percepções para orientar suas melhorias de qualidade e otimizações de custo e latência. Ele 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 integrados LLM, consulte Mosaic AI Agent Evaluation LLM judges reference.

Como a qualidade é avaliada pelos juízes do LLM

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

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

Para LLM obter informações sobre a LLM confiança e a segurança dos juízes do site, consulte as informações sobre os modelos que alimentam os juízes do site.

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

Para cada linha de entrada, a Avaliação de agentes usa um conjunto de juízes do LLM para avaliar diferentes aspectos da qualidade dos resultados do agente. Cada juiz produz uma pontuação de sim ou não e uma justificativa por escrito para essa pontuação, conforme mostrado no exemplo abaixo:

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

o passo 2: Combinar avaliações do juiz do LLM para identificar a causa raiz dos problemas de qualidade

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

Os dados são mostrados na UI do MLflow e também estão disponíveis na execução do MLflow em um DataFrame retornado pela chamada mlflow.evaluate(...). Consulte o resultado 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 resumida na interface do usuário:

Os resultados de cada linha estão disponíveis no detalhe view UI:

Juízes de LLM disponíveis

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

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

Nome do juiz	Passo	Aspecto de qualidade que o juiz avalia	Entradas necessárias	Requer verdade fundamental?
`relevance_to_query`	Resposta	A resposta aborda (é relevante para) a solicitação do usuário?	`response`, `request`	Não
`groundedness`	Resposta	A resposta gerada está baseada no contexto recuperado (não é alucinante)?	`response`, `trace[retrieved_context]`	Não
`safety`	Resposta	Há conteúdo nocivo ou tóxico na resposta?	`response`	Não
`correctness`	Resposta	A resposta gerada é precisa (em comparação com a verdade básica)?	`response`, `expected_response`	Sim
`chunk_relevance`	Recuperação	O retriever encontrou partes que são úteis (relevantes) para responder à solicitação do usuário? Nota: Esse juiz é aplicado separadamente a cada pedaço recuperado, produzindo uma justificativa de pontuação & para cada pedaço. Essas pontuações são agregadas em uma pontuação `chunk_relevance/precision` para cada linha que representa a porcentagem de partes que são relevantes.	`retrieved_context`, `request`	Não
`document_recall`	Recuperação	Quantos dos documentos relevantes conhecidos o recuperador encontrou?	`retrieved_context`, `expected_retrieved_context[].doc_uri`	Sim
`context_sufficiency`	Recuperação	O retriever 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 forem aprovados, a qualidade será considerada pass. Se algum juiz falhar, a causa raiz é 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 são correlacionadas de forma causal. Por exemplo, se context_sufficiency avaliar que o recuperador não buscou os blocos ou documentos corretos para a solicitação de entrada, é provável que o gerador falhe em sintetizar uma boa resposta e, portanto, correctness também falhe.

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

context_sufficiency
groundedness
correctness
safety
Qualquer juiz LLM definido pelo cliente

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

chunk_relevance - há pelo menos uma parte relevante?
groundedness
relevant_to_query
safety
Qualquer juiz LLM definido pelo cliente

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

A Databricks se dedica a aprimorar a qualidade de nossos juízes de LLM. A qualidade é avaliada medindo-se o grau de concordância do juiz do LLM com os avaliadores humanos, usando as seguintes métricas:

Aumento do Kappa de Cohen (uma medida de concordância entre avaliadores).
Aumento da precisão (porcentagem de rótulos previstos que correspondem ao rótulo do avaliador humano).
Maior pontuação na F1.
Diminuição da taxa de falsos positivos.
Diminuição da taxa de falsos negativos.

Para medir essas métricas, o site Databricks usa exemplos diversificados e desafiadores de conjuntos de dados acadêmicos e proprietários que são representativos do conjunto de dados do cliente para avaliar e aprimorar os juízes em relação às abordagens de juízes de última geração do site LLM, garantindo aprimoramento contínuo e alta precisão.

Para obter mais detalhes sobre como o site Databricks mede e melhora continuamente a qualidade dos juízes, consulte Databricks anuncia melhorias significativas nos juízes integrados do site LLM em Agent Evaluation.

Tente juízes usando o SDK `databricks-agents`

O databricks-agents SDK inclui APIs para invocar juízes diretamente nas entradas do usuário. O senhor pode usar essas APIs para fazer um experimento rápido e fácil para ver como os juízes trabalham.

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

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

Em seguida, o senhor pode executar o código a seguir em seu Notebook e editá-lo conforme necessário para testar 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

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

custo dos tokens

Para avaliar o custo, a Avaliação de agentes 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 um custo maior. A contagem de tokens só é calculada quando um trace está disponível. Se o argumento model for incluído na chamada para mlflow.evaluate(), um rastreamento será gerado automaticamente. O senhor também pode fornecer diretamente uma coluna trace na avaliação dataset.

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 períodos de LLM no rastreamento do agente.
`total_input_token_count`	`integer`	Soma de todos os tokens de entrada em todos os períodos de LLM no rastreamento do agente.
`total_output_token_count`	`integer`	Soma de todos os tokens de saída em todos os períodos de LLM no rastreamento do agente.

Latência de execução

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

A seguinte medida 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 Agent Evaluation agrega essas avaliações em métricas por execução que são registradas em um MLflow execução e resumem a qualidade, o custo e a latência do seu agente em todas as linhas de entrada.

A avaliação do agente 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]`	% de perguntas em que `context_sufficiency/rating` é julgado como `yes`.
`response/llm_judged/correctness/rating/percentage`	`float, [0, 1]`	% de perguntas em que `correctness/rating` é julgado como `yes`.
`response/llm_judged/relevance_to_query/rating/percentage`	`float, [0, 1]`	% de perguntas em que `relevance_to_query/rating` é considerado `yes`.
`response/llm_judged/groundedness/rating/percentage`	`float, [0, 1]`	% de perguntas em que `groundedness/rating` é julgado como `yes`.
`response/llm_judged/safety/rating/average`	`float, [0, 1]`	% de perguntas em que `safety/rating` é considerado `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]`	% de 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` em 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 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.
AI A desativação do recurso assistido por parceiros impede que o LLM juiz do chame os modelos alimentados por parceiros.
Os dados enviados para o juiz do LLM não são usados para nenhum treinamento de modelo.
Os juízes do LLM têm como objetivo ajudar os clientes a avaliar seus aplicativos RAG e os resultados dos juízes do LLM não devem ser usados para ensinar, melhorar nem ajustar um LLM.