Vertex AI Agent Evaluation em public preview: o que mudou

TL;DR

O Vertex AI Gen AI evaluation service entrou em public preview com suporte a agent evaluation, trazendo duas camadas de análise no mesmo fluxo: a trajetória de ações do agente e a resposta final. Na prática, isso ajuda a depurar casos em que o texto parece plausível, mas o agente escolheu ferramentas na ordem errada ou tomou um caminho inconsistente.

Para times que estão construindo agentes com tool use, essa mudança é importante porque desloca a validação de “a resposta ficou boa?” para “o agente chegou lá do jeito esperado?”. Isso reduz falsos positivos em testes e deixa a avaliação mais próxima do comportamento real de produção.

O que o public preview adiciona

O anúncio oficial descreve a nova capacidade de Agent Evaluation no Vertex AI Gen AI evaluation service como uma expansão da avaliação generativa para agentes que usam ferramentas. A documentação oficial também detalha a separação entre trajectory evaluation e final response evaluation.

Essa separação faz sentido quando o agente tem uma cadeia de passos relevante para o resultado. Em vez de analisar apenas a saída final, você consegue observar se a sequência de tool calls bate com o esperado e, depois, avaliar se a resposta final refletiu corretamente o que aconteceu no percurso.

Trajectory evaluation: avaliar o caminho, não só o destino

A trajectory evaluation verifica a sequência de ações do agente, incluindo as chamadas de ferramentas até a resposta final. A documentação do Google Cloud mostra que o fluxo pode trabalhar com métricas baseadas em comparação entre predicted trajectory e reference trajectory, o que é útil quando o comportamento do agente precisa seguir uma ordem específica.

Uma métrica documentada é a trajectory_exact_match, que retorna 1 apenas quando a trajetória prevista é idêntica à de referência, com os mesmos tool calls e na mesma ordem. Isso é especialmente útil para casos de automação em que a ordem importa tanto quanto o resultado final.

Final response evaluation: qualidade da resposta final

A final response evaluation continua focada na qualidade da saída do agente, em linha com avaliações tradicionais de resposta de modelo. A diferença é que ela agora convive com a análise da trajetória, permitindo que uma mesma execução gere sinais complementares sobre comportamento e conteúdo.

Na prática, isso ajuda a separar dois problemas que antes podiam parecer o mesmo: um agente pode até responder de forma adequada, mas por um processo errado; ou pode executar os passos corretos e ainda assim produzir uma formulação ruim. Para depuração, essa distinção vale ouro.

Execução via SDK e métricas customizadas

A documentação do SDK de avaliação mostra o uso de EvalTask para rodar avaliações em lote. O ponto relevante aqui é que a mesma execução pode calcular métricas para trajetória e resposta final, o que simplifica scripts de validação e pipelines de QA.

Esta seção descreve a versão pública de pré-lançamento do serviço no ecossistema do Google Cloud. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.

O anúncio também cita métricas customizadas para checar se a resposta segue logicamente o que os tools fizeram, como uma métrica do tipo response follows trajectory. Isso é útil quando a regra de negócio não cabe bem em comparação exata, mas ainda exige consistência entre ação e resposta.

Como isso afeta a engenharia de agentes

Na prática, a novidade muda o desenho da suíte de testes. Em vez de testar apenas prompts e respostas, o time passa a validar rastros de comportamento: quais ferramentas foram chamadas, em qual sequência, com quais efeitos e se a resposta final respeitou esse histórico.

Esse tipo de avaliação é valioso para agentes que consultam bases internas, fazem buscas, criam tickets ou operam fluxos com múltiplas etapas. Quando a falha acontece, o diagnóstico fica mais objetivo: foi a escolha da ferramenta, foi a ordem dos passos ou foi a síntese final?

Onde o sinal extra ajuda de verdade

Em fluxos com automação e tool use, uma resposta “bonita” pode mascarar um caminho ruim. Com trajectory evaluation, você consegue capturar regressões que passariam despercebidas numa avaliação só de texto, como invocar uma ferramenta fora de ordem ou ignorar uma etapa obrigatória.

Isso também facilita testes de regressão quando o agente evolui. Se um ajuste de prompt, modelo ou roteador altera a trajetória esperada, a métrica acusa o desvio antes que o problema vire incidente em produção.

Frameworks e arquitetura de agentes

O anúncio oficial menciona compatibilidade com diferentes formas de construção de agentes, incluindo Reasoning Engine, LangChain, LangGraph e CrewAI. O ponto central é que a avaliação se concentra no comportamento do agente, não no framework em si.

Isso é relevante porque muita equipe começa num framework e depois muda de stack. Se a camada de avaliação for baseada em trajetória e resposta final, o contrato de teste fica mais estável do que um conjunto de checks acoplado à implementação.

Exemplo de uso em uma pipeline de validação

Um desenho comum seria: gerar um dataset com casos de referência, executar o agente com o SDK e comparar o comportamento observado com a trajetória esperada. Quando o caso exige precisão estrutural, a métrica exata ajuda; quando o caso é mais semântico, uma métrica customizada faz mais sentido.

Em ambientes de times pequenos, isso pode virar uma rotina simples de pré-release. Num cenário brasileiro de produto SaaS, onde budgets costumam ser apertados e mudanças precisam sair sem longas janelas de validação, automatizar esse tipo de teste reduz retrabalho e evita custo extra em chamadas de modelo e suporte.

Esboço mínimo do fluxo no SDK

O SDK documenta o uso de EvalTask para organizar a execução da avaliação. Abaixo está um esboço conceitual do fluxo, alinhado ao que a documentação descreve: montar o conjunto de dados, definir as métricas e rodar a avaliação.

Exemplo conceitual: a estrutura exata de parâmetros pode mudar entre versões do preview e do SDK. Consulte a documentação oficial antes de incorporar em automações críticas.

undefined

O valor do exemplo é mostrar a lógica do processo, não copiar uma implementação fechada. Em produção, o time deve alinhar nomes de métricas, esquema do dataset e versão do SDK com a documentação atual.

Por que importa pro dev brasileiro

O contexto brasileiro pesa por motivos bem concretos. Em muitas empresas, a infraestrutura ainda roda com forte dependência de regiões da AWS ou do Google Cloud fora do Brasil, então qualquer ciclo de avaliação que reduza chamadas desnecessárias e diminua retrabalho ajuda a conter custo em dólar e latência de ida e volta.

Há também um componente regulatório e operacional. Se o agente toca dados pessoais, a imagem do caminho executado ajuda a auditar decisões com mais clareza em discussões internas de conformidade com a LGPD, especialmente quando o fluxo envolve consulta, transformação e resposta automatizada.

Outro ponto é a maturidade das equipes. No ecossistema brasileiro, muita gente veio de bootcamps, migrou para cloud ou aprendeu IA de forma prática; por isso, ferramentas que tragam sinais objetivos de comportamento ajudam a encurtar a curva entre protótipo e operação. A avaliação por trajetória torna a depuração mais concreta para times que ainda estão consolidando padrões de engenharia de agentes.

Limites e cuidados do public preview

Como qualquer preview público, o serviço pode evoluir em métricas, nomes e integrações. Por isso, o ideal é tratar a adoção como validação técnica controlada, não como contrato imutável de plataforma.

Também vale separar as métricas do objetivo do produto. Se seu agente precisa apenas responder perguntas simples, a avaliação de trajetória talvez seja excesso. Já em fluxos com ferramentas, recomposição de estado ou regras de negócio, ela passa a ser parte central do teste.

Por fim, a métrica exata não deve ser a única régua. Ela é ótima para regressão estrutural, mas pode ser rígida demais em cenários em que rotas alternativas continuam corretas; nesses casos, uma métrica customizada ou uma combinação de sinais tende a refletir melhor o comportamento esperado.

Conclusão

O Agent Evaluation do Vertex AI muda a conversa sobre qualidade de agentes: sair do foco exclusivo na resposta final e incluir a trajetória de tool calls aproxima os testes do comportamento real do sistema. Para quem constrói agentes com execução em etapas, isso cria uma base mais confiável para debug, regressão e governança.

Na prática, o primeiro passo útil é ler a documentação oficial de avaliação e adaptar um dataset pequeno com casos reais do seu fluxo. Reserve menos de uma hora para abrir o guia do Google, mapear uma trajetória de referência do seu agente e rodar um teste inicial com EvalTask no SDK.

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