Como a qualidade, o custo e a latência são avaliados pela Avaliação do Agente
Importante
Esse recurso está em uma versão prévia.
Este artigo explica como a Avaliação do Agente avalia a qualidade, o custo e a latência do aplicativo de IA e fornece insights para orientar suas melhorias de qualidade e otimizações de custo e latência. Ele aborda as seguintes tarefas:
- 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 do 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 de avaliação do agente Mosaic AI.
A Avaliação do Agente avalia a qualidade usando juízes LLM em duas etapas:
- Os juízes do LLM avaliam aspectos específicos da 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.
- A Avaliação do Agente combina as avaliações individuais do juiz em uma pontuação geral de aprovação/reprovação e causa raiz de quaisquer falhas. Para obter detalhes, consulte Etapa 2: Combinar avaliações de juízes do LLM para identificar a causa raiz dos problemas de qualidade.
Para obter informações sobre confiança e segurança dos juízes do LLM, consulte Informações sobre os modelos que alimentam os juízes do LLM.
Para cada linha de entrada, a Avaliação do Agente usa um conjunto de juízes LLM para avaliar diferentes aspectos da qualidade sobre as saídas 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 LLM usados, consulte Juízes LLM disponíveis.
Etapa 2: Combine as avaliações de juízes do LLM para identificar a causa raiz dos problemas de qualidade
Depois de executar juízes 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 do MLflow e também estão disponíveis na execução do 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 resumida na interface do usuário:
Os resultados de cada linha estão disponíveis na interface do usuário da exibição de detalhes:
A tabela abaixo resume o conjunto de juízes LLM usados na Avaliação do 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 juízes de LLM, consulte Informações sobre os modelos que alimentam juízes de LLM. Para obter informações de referência sobre cada um dos juízes LLM integrados, consulte Referência de juízes LLM de avaliação do agente Mosaic AI.
Nome do juiz | Etapa | Aspecto de qualidade que o juiz avalia | Entradas necessárias | Requer verdade básica? |
---|---|---|---|---|
relevance_to_query |
Resposta | A resposta aborda (é relevante para) a solicitação do usuário? | - response , request |
Não |
groundedness |
Resposta | A resposta gerada é baseada no contexto recuperado (não alucinante)? | - response , trace[retrieved_context] |
Não |
safety |
Resposta | Existe 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 pedaços que são úteis (relevantes) para responder à solicitação do usuário? Nota: Este juiz é aplicado separadamente a cada pedaço recuperado, produzindo uma pontuação e justificativa para cada pedaço. 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 |
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:
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. Essa ordenação é usada porque as avaliações dos juízes são frequentemente correlacionadas de forma causal. Por exemplo, se context_sufficiency
avaliar que o recuperador não buscou as partes 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 falhe.
Se a verdade do fundamento for fornecida como entrada, a seguinte ordem será usada:
context_sufficiency
groundedness
correctness
safety
- Qualquer juiz de LLM definido pelo cliente
Se a verdade fundamental não for fornecida como entrada, a seguinte ordem será usada:
chunk_relevance
- Existe pelo menos 1 pedaço relevante?groundedness
relevant_to_query
safety
- Qualquer juiz de LLM definido pelo cliente
A Databricks se dedica a melhorar a qualidade de nossos juízes de LLM. A qualidade é avaliada medindo o quão bem o juiz do 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 (porcentagem de rótulos previstos que correspondem ao rótulo do avaliador humano).
- Aumento da pontuação F1.
- Taxa de falsos positivos reduzida.
- Diminuição da taxa de falsos negativos.
Para medir essas métricas, a Databricks usa exemplos diversos 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 a Databricks mede e melhora continuamente a qualidade do juiz, consulte Databricks anuncia melhorias significativas nos juízes LLM internos na Avaliação do Agente.
O databricks-agents
SDK inclui APIs para invocar diretamente juízes nas entradas do usuário. Você pode usar essas APIs para um experimento rápido e fácil para ver como os juízes funcionam.
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 notebook 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,
)
A Avaliação do Agente mede as contagens de tokens e a latência de execução para ajudá-lo a entender o desempenho do agente.
Para avaliar o custo, a Avaliação do Agente calcula a contagem total de tokens em todas as chamadas de geração do LLM no rastreamento. Isso aproxima o custo total fornecido como mais tokens, o que geralmente leva a mais custo. As contagens de tokens só são calculadas quando a trace
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 conjunto de dados 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 de saída em todos os intervalos de LLM no rastreamento do agente. |
total_input_token_count |
integer |
Soma de todos os tokens de entrada em todos os intervalos de LLM no rastreamento do agente. |
total_output_token_count |
integer |
Soma de todos os tokens de saída em todos os intervalos de LLM no rastreamento do agente. |
Calcula toda a latência do aplicativo 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. Você também pode fornecer diretamente uma coluna trace
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 |
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 do MLflow e resumem a qualidade, o custo e a latência do 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 onde context_sufficiency/rating é julgado como yes . |
response/llm_judged/correctness/rating/percentage |
float, [0, 1] |
% de perguntas onde correctness/rating é julgado como yes . |
response/llm_judged/relevance_to_query/rating/percentage |
float, [0, 1] |
% de perguntas onde relevance_to_query/rating é julgado como yes . |
response/llm_judged/groundedness/rating/percentage |
float, [0, 1] |
% de perguntas onde groundedness/rating é julgado como yes . |
response/llm_judged/safety/rating/average |
float, [0, 1] |
% de perguntas onde é 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] |
% 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 interface do usuário:
- Os avaliadores LLM podem usar serviços de terceiros para avaliar os aplicativos GenAI, incluindo o Azure OpenAI operado pela Microsoft.
- Para o Azure OpenAI, a Databricks optou por não usar o Monitoramento de Abuso, portanto, nenhum prompt ou resposta é armazenado com o Azure OpenAI.
- Para workspaces da União Europeia (UE), os avaliadores LLM usam modelos hospedados na Europa. Todas as outras regiões usam modelos hospedados nos EUA.
- Desabilitar os Serviços de IA do Azure Recursos de assistência de IA impedem que o avaliador de LLM chame os modelos da plataforma de IA do Azure.
- Os dados enviados ao avaliador de LLM não são usados para nenhum treinamento de modelo.
- Avaliadores LLM destinam-se a ajudar os clientes a avaliar os aplicativos RAG, e os resultados dos avaliadores LLM não devem ser utilizados para treinar, melhorar ou fazer um ajuste fino no LLM.