Avaliação de agentes no Azure AI Foundry com RAG e métricas end-to-end

TL;DR

No Azure AI Foundry, avaliação de RAG e avaliação de agente não são a mesma coisa: a primeira mede qualidade de recuperação com ground truth; a segunda trata o agente como caixa-preta e mede o resultado final do fluxo. Para times que querem métricas end-to-end, o caminho prático é rodar inferência + avaliação no mesmo pipeline e combinar sinais de RAG com métricas de agente, como aderência à tarefa e acurácia de tool calls.

Isso importa porque um agente pode “parecer bom” na resposta final e ainda assim estar recuperando contexto errado, ou o contrário. Quando você separa as camadas, o diagnóstico fica mais claro e o ajuste de chunking, top-k, reranking e políticas de tool use deixa de ser chute.

O ponto central: avaliar o sistema inteiro sem misturar as camadas

O Azure AI Foundry organiza a avaliação em duas lentes. A primeira é a lente de RAG, que observa se o conteúdo recuperado faz sentido frente ao ground truth. A segunda é a lente de agente, que observa o comportamento end-to-end do sistema como caixa-preta, depois que o fluxo já passou por instrução, chamadas de ferramentas e geração final. A documentação de RAG evaluators descreve métricas como fidelity, ndcg@3, xdcg@3, top1_relevance, top3_max_relevance e holes; já a página de agent evaluators cobre métricas como task_adherence e tool_call_accuracy.

Na prática, isso evita um erro comum em projetos com RAG: tentar concluir que retrieval está bom só porque a resposta final saiu aceitável. Em avaliações de agente, os sinais internos de retrieval não são expostos como métricas de primeira classe na mesma tela de configuração, então o diagnóstico precisa vir da combinação entre avaliação de recuperação e avaliação do comportamento do agente. O próprio enquadramento de observability do Foundry reforça caminhos como continuous evaluation e scheduled evaluation.

Como medir RAG de forma útil

Quando o foco é RAG, você quer saber o que foi trazido da base e quão bem isso cobre a verdade de referência. O avaliador document_retrieval foi desenhado exatamente para isso, calculando métricas de ranking e cobertura com base em labels/ground truth. Entre os sinais mais práticos estão holes e holes_ratio, que ajudam a enxergar lacunas: casos em que havia conteúdo relevante disponível, mas ele não apareceu entre os documentos recuperados.

Esse tipo de métrica é valioso para tuning de chunking, estratégia de busca e reranking porque mostra onde o pipeline falha antes mesmo da geração. Em análise de causa raiz, isso é muito mais acionável do que olhar apenas a resposta final. Se o documento certo não entrou no contexto, nenhuma boa formulação do gerador vai corrigir o problema de forma consistente.

Vale notar que métricas como ndcg@3 e xdcg@3 ajudam a capturar qualidade de ordenação, não só presença de itens relevantes. Isso é útil quando o top-k é pequeno e a posição do documento dentro da lista muda bastante a qualidade do contexto recebido pelo modelo.

Como medir o agente sem tentar ‘espiar’ o retrieval interno

Na avaliação de agente, o Foundry olha o sistema inteiro como uma caixa-preta. O pipeline típico inclui seguir instruções, chamar ferramentas, usar RAG quando configurado e então produzir a resposta final. A documentação e a discussão oficial indicam que você deve avaliar o resultado observado, não esperar métricas internas de retrieval dentro da configuração de agent evaluation.

Por isso, métricas como tool_call_accuracy e task_adherence entram como sinais de sistema. Elas medem se o agente fez o que foi pedido, se chamou as ferramentas certas e se o comportamento geral ficou aderente ao objetivo. Em alguns avaliadores, o retorno inclui campos como threshold, passed e score, o que facilita automatizar gates em CI/CD.

Esse desenho é importante para aplicações reais, porque o agente pode errar a sequência de decisão mesmo quando o texto final parece convincente. Em um cenário corporativo, o que interessa é se ele executou a tarefa corretamente, não apenas se a resposta soou plausível.

Pipeline end-to-end: inferência + avaliação no mesmo fluxo

Para métricas end-to-end, o fluxo mais robusto é usar o mesmo dataset para disparar a inferência e, logo depois, a avaliação. A ideia é simples: cada item do conjunto de testes entra como entrada real de usuário, o agente executa seu pipeline completo e o resultado final é avaliado pelos avaliadores apropriados.

Esse padrão aparece com clareza em repositórios da Microsoft para automação de avaliação de agentes, como o microsoft/ai-agent-evals, que enfatiza automação em CI/CD e análise estatística para reduzir falso positivo de melhoria. Também há exemplos no Azure-Samples/Agentic-Evaluations, que mostram variações como evaluation-only e inference+evaluation em fluxos de avaliação de sistemas agentic.

Na prática, isso permite comparar duas versões do mesmo agente sem depender de sensação subjetiva. Você roda a mesma bateria de casos, coleta os scores por categoria e acompanha se a mudança melhorou o comportamento geral ou só mexeu em um ponto isolado do pipeline.

O que fazer com as métricas na rotina de engenharia

Se o seu objetivo é operação contínua, não basta gerar relatório uma vez. O Foundry inclui caminhos para avaliação contínua e agendada, o que combina bem com pipelines de release e observabilidade. Em um time de produto, isso significa criar checks automáticos antes de promover mudanças de prompt, ferramentas, embeddings, indexação ou políticas de orquestração.

Uma forma prática de organizar o uso das métricas é esta: usar RAG evaluators para detectar degradação de recuperação; usar agent evaluators para validar aderência à tarefa e uso correto de ferramentas; e usar a combinação dos dois para entender se o problema está no contexto, na orquestração ou na geração final. Isso reduz o risco de tratar todo problema como “problema do modelo”.

Outro ponto útil é acompanhar significância estatística quando você compara versões. O repositório microsoft/ai-agent-evals menciona análise com intervalos de confiança e teste de significância estatística, o que ajuda evitar decisões baseadas em poucas execuções ou ruído aleatório do modelo.

Por que isso importa pro dev brasileiro

No Brasil, essa separação de métricas ajuda de um jeito bem concreto: muitas equipes trabalham com orçamento em BRL, acesso a ambientes de teste limitados e janelas curtas de validação antes de subir mudança para produção. Quando o time não consegue rodar observabilidade pesada em larga escala, medir bem cada camada do pipeline vira uma forma de economizar retrabalho e reduzir custo de inferência.

Há também um aspecto regulatório importante. Se o agente processa dados pessoais de clientes, a LGPD exige cuidado com minimização, finalidade e rastreabilidade. Em projetos com RAG, isso pesa bastante porque índice, chunks e logs de avaliação podem carregar trechos sensíveis; então separar métricas de recuperação e de comportamento ajuda a localizar onde o dado foi exposto ou usado de forma indevida.

Em empresas brasileiras que lidam com latência e integração com serviços em regiões fora do país, como times que usam Azure, AWS ou ferramentas SaaS hospedadas fora do Brasil, uma avaliação end-to-end bem definida também evita depuração longa de ‘o agente falhou’, quando na verdade o gargalo está no retrieval, no tool call ou em uma regra de negócio. Em ambiente de produção, esse detalhe poupa muito tempo de equipe enxuta.

Um modelo mental simples para aplicar já

Pense em três perguntas, nesta ordem. Primeiro: o contexto certo foi recuperado? Use métricas de RAG. Segundo: o agente seguiu as instruções e usou as ferramentas certas? Use métricas de agente. Terceiro: o resultado final resolveu o caso de uso? Use a avaliação end-to-end no mesmo dataset, com comparação entre versões.

Com esse modelo, você consegue separar sinais que antes ficavam misturados. Isso facilita tuning do índice, revisão de prompt, ajuste de tool use e validação de release. Para um time de produto ou plataforma, o ganho principal é transformar avaliação de agente em processo repetível, e não em opinião de demo.

Conclusão

Se você está implementando avaliação de agentes com RAG no Azure AI Foundry, a recomendação prática é não tentar reduzir tudo a uma métrica única. Use avaliadores de recuperação para entender qualidade do contexto, avaliadores de agente para medir aderência e ferramentas, e o pipeline completo para enxergar o comportamento sistêmico. Assim, você tem um diagnóstico mais justo do que está quebrando e do que realmente melhorou.

Para sair do artigo com algo aplicável em até uma hora, abra a documentação oficial de RAG evaluators e agent evaluators, escolha um dataset pequeno do seu projeto e descreva quais métricas vão medir recuperação, execução da tarefa e resposta final. Depois, rode uma primeira avaliação comparando duas variantes do seu fluxo e registre os deltas como baseline.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.