Avaliações por string matching premiam agentes que fingem compliance

O problema do string matching em evals de agentes

Waldek Mastykarz, developer advocate na Microsoft, argumenta que usar verificações de "string contains" para avaliar agentes de codificação com IA produz evidência enganosa. A prática é tentadora porque é rápida, determinística e praticamente gratuita, permitindo rodar em cada mudança no CI sem custo de inferência ou latência.

O exemplo central: se um eval exige que a solução gerada use Azure e o grader apenas procura a string "Azure" nos arquivos, o que se prova é mínimo. A string pode aparecer em um comentário como "// Don't use Azure here.", em código morto, dependência não usada, documentação ou fixture de teste - tudo passa. No sentido inverso, a ausência da string também não prova nada: o agente pode usar um SDK sem mencionar Azure, referir-se apenas a um nome de pacote ou expressar a mesma intenção com outras palavras. Em linguagem natural, a diferença entre "usou" e "não usou" pode ser uma única palavra, mantendo a palavra-chave idêntica.

O teste de completar a frase

O autor propõe um exercício simples: completar literalmente as frases "Se este grader passar, eu sei que ______" e "Se este grader falhar, eu sei que ______". Para um grader de string contains, as respostas honestas descrevem apenas o que foi observado - que a string ocorre ou não no conteúdo inspecionado. Completar com "o agente usou Azure corretamente" é uma inferência que a evidência não sustenta. O grader pode ser perfeitamente preciso no que faz, mas estar sendo usado para provar algo que não consegue.

Evidência fácil, falsa segurança

Eval agênticos custam dinheiro e demoram; judges com LLM adicionam custo e latência de inferência; construir ou implantar aplicações geradas traz infraestrutura e complexidade. Por isso, equipes otimizam o eval em torno do que é conveniente medir, e não do que precisam saber - o resultado pode ser um pipeline rápido e repetível que oferece falsa segurança a cada execução. O autor prefere rodar menos evals com evidência significativa do que muitos evals que dizem pouco.

Pergunte a quem pode responder

Para propriedades determinísticas, use a ferramenta determinística: quer saber se o código compila? Compile - já houve casos de soluções com nota perfeita de um LLM judge que falhavam na compilação. Quer validar dependências, esquema de JSON ou testes? Restaure, valide e execute. Usar um LLM para prever se um projeto compila é aproximar uma resposta que o compilador dá de forma autoritativa.

Rodar a aplicação completa é mais difícil que compilá-la: exige credenciais, configuração, dados, infraestrutura e acesso a serviços externos - fronteiras onde agentes de código frequentemente falham. Quando executar não for viável, o eval não precisa provar tudo, mas seu relatório deve deixar claro o que estabeleceu e o que não estabeleceu.

LLM judges e integração

LLM judges respondem a perguntas semânticas: distinguem "use Azure para armazenar os dados" de "não use Azure", inspecionam contexto e reconhecem implementações sem o vocabulário antecipado. Mas não substituem de forma confiável a construção e execução do software.

O autor sugere tratar evals agênticos como testes de integração, não de unidade. Em seus evals, construir, testar, rodar e implantar são portões separados, com LLM judges avaliando propriedades semânticas ao lado. Graders determinísticos são excelentes quando a propriedade medida é determinística; o problema começa quando se escolhe um sinal conveniente e se expande silenciosamente a alegação feita a partir dele. Um eval não se torna confiável por rodar a cada commit, mas quando sua evidência sustenta as alegações que se faz com ele.