Olha só, avaliar agente não é a mesma coisa que avaliar modelo
Você consegue benchmarkar um modelo num dataset estático e pronto. Com agente, esquece. A qualidade depende das ferramentas que ele chama, do fluxo multi-turn que ele produz e das entradas bizarras que usuário real manda — nada disso existe em tempo de treino.
O time do Agent Platform no Google Cloud acabou de colocar Agent and Model Evaluations em GA, e a abordagem é honesta: um agente que passa verde no seu suite inteiro ainda pode dar drift uma semana depois do lançamento. Isso não é falha de teste — é a realidade da produção, onde as tarefas são maiores e mais estranhas do que qualquer caso que você escreveu.
Neste post a gente destrincha o que saiu, como as peças se encaixam e onde estão as arestas. Se você curte esse tipo de análise de sistemas em escala, dá uma olhada também no nosso texto sobre migração de sistemas de ingestão de dados em escala de petabytes no Meta.
O primitivo central: experimentos, métricas e traces
A unidade de trabalho é o experimento: um dataset de eval cases mais um conjunto de métricas e scores que você roda e revisa enquanto itera.
Três coisas fazem isso funcionar na prática:
- Mesmo motor, offline e online. As métricas que você define localmente rodam sem alteração nos monitores de produção. É esse o ponto — se o score muda em prod, o problema é o agente, não a medição.
- Artefatos transparentes. Todo artefato de experimento vai pro Cloud Storage, então dá pra versionar e auditar pra compliance.
- Acessível de onde você já constrói. SDK,
agents-cli, console do Cloud, ADK e até uma skill reutilizável pra agentes estilo Claude Code.
Trazendo sua própria métrica
Além das 20+ métricas prontas (ROUGE, BLEU, MetricX, COMET, exact match), você define as suas:
- Métrica code-based — uma função Python pura. Match exato de texto, checagem de shape de JSON, o que você conseguir expressar.
- Métrica LLM-as-a-judge — seus critérios, sua escala, seu modelo juiz. Localmente você usa qualquer provider; server-side aceita qualquer modelo do Model Garden, incluindo Gemini e Anthropic.
# Exemplo: métrica code-based que verifica conformidade de shape JSON
import json
def json_shape_metric(response: str, expected_keys: list[str]) -> float:
"""Retorna 1.0 se a resposta é JSON válido contendo todas as chaves esperadas."""
try:
data = json.loads(response)
except json.JSONDecodeError:
return 0.0
faltando = [k for k in expected_keys if k not in data]
return 1.0 if not faltando else 0.0
Rubricas adaptativas (a parte interessante)
Co-desenvolvidas com pesquisadores do Google DeepMind, as rubricas adaptativas geram testes pass/fail específicos por caso a partir de três entradas:
- a definição do eval case,
- a instrução do desenvolvedor,
- as declarações das ferramentas.
Depois, ela avalia os traces contra essas rubricas e devolve veredito + rationale por rubrica. Você pode direcionar a geração com guidelines em linguagem natural, e o grupo de rubricas resultante é revisável e reutilizável entre agentes.
De fábrica você ganha variantes calibradas pro que normalmente se quer saber: Task Success, Tool Use Quality, Safety (hate speech, assédio, conteúdo perigoso, material explícito, PII), Trajectory Quality, Final Response Quality, Hallucination e Grounding.
O que falta (e onde isso dói)
Alguns avisos honestos antes de você jogar fora seu harness caseiro de eval:
| Dimensão | O que você ganha | A pegadinha |
|---|---|---|
| Cobertura de métricas | 20+ prontas + BYO code/LLM-judge | LLM-as-a-judge cobra taxa de chamada de modelo; code/computation são grátis |
| Multi-modal | Métricas de qualidade de imagem e vídeo inclusas | Design text-first; modalidades especializadas ainda "em expansão" |
| Geração de casos | Case generator + user simulator + environment simulator | User simulator só pareia com agentes ADK hoje — outros frameworks ficam atrás |
| Monitoramento online | Sampling, filtros direcionados, alertas de drift pra email/Slack | Você paga por cada request avaliado; sampling não é opcional em escala |
| Suporte a frameworks | ADK, SDK, REST, agents-cli, pytest pra CI | CLI só pra ADK-Python hoje; outras linguagens via REST |
Duas coisas que vão surpreender quem migra de setup caseiro:
- Issue clustering é a feature escondida. Em vez de encarar 4.000 evals falhados, o sistema agrupa em clusters interpretáveis segundo sua taxonomia — ou uma taxonomia pronta de rubricas adaptativas se você ainda não tem uma. É a diferença entre "temos evals" e "agimos com base nas evals".
- O environment simulator é a peça que faltava pro teste de agente. Aponta pra uma ferramenta, diz pra retornar dado mockado, erro forçado ou latência extra, e ele intercepta a chamada durante a run. Aí você finalmente testa como o agente se comporta quando o backend tá lento ou quebrado — sem tocar em produção.
Se você curte esse tipo de design de sistema que falha com segurança sob carga, vale ler também nosso texto sobre como a proteção avançada de navegação do Messenger funciona sem comprometer a privacidade.
A conclusão
As avaliações no Agent Platform agora estão em GA, e as escolhas de design revelam uma tese clara:
- Consistência ganha de sofisticação. Um motor só pra experimentos locais e tráfego real significa que drift em produção aponta pro agente, não pra medição.
- Traga tudo do seu jeito. Métricas de código, de LLM-judge, modelos juízes de qualquer provider, taxonomias — tudo cai no mesmo registry versionado da org.
- Gere, não escreva à mão. Case generators, user simulators e environment simulators existem porque suite escrita à mão limita sua cobertura ao que você pensou em digitar.
Próximos passos
- Se você usa ADK, ligue os eval sets no
pyteste rode em CI hoje — é o ponto de partida com menor fricção. - Se já coleta traces via Cloud Trace, clica no botão de eval na UI de traces numa sessão real e vê o que as métricas padrão dizem.
- Sobe um monitor online com sampling em 5–10% do tráfego e alertas de drift no Slack antes de escalar.
Fonte: Agent and Model Evaluations in Gemini Enterprise Agent Platform are now GA