Claude automatiza criação de evals e hill-climbing de prompts

O problema: avaliar sem se enganar

A Anthropic publicou um guia no blog do Claude Code sobre como projetar avaliações (evals) e melhorar aplicações contra elas sem se autoenganar. O texto acompanha o lançamento de dois comandos na skill claude-api: /claude-api build-eval, que constrói uma avaliação dentro do seu código-base, e /claude-api hillclimb, que melhora a aplicação contra essa avaliação, uma mudança por vez, com um conjunto de exemplos separados (held-out) para detectar overfitting.

Os quatro elementos de um bom eval

Segundo o artigo, avaliações bem projetadas compartilham quatro características:

1. As tarefas espelham a produção. Amostrar casos fáceis de gerar ou de corrigir distorce a distribuição; é preciso representar o que realmente importa na aplicação.
2. Desempenho melhora com modelos mais fortes. Se não melhora, provavelmente há tarefas ambíguas ou um corretor mal calibrado.
3. Há margem "passável" na fronteira. O modelo mais capaz no esforço máximo deve ficar bem abaixo de 100%, senão não se consegue julgar o efeito das mudanças. Uma tarefa que falha em todas as execuções, independentemente de repetições, é um sinal de problema.
4. Baixa variância entre execuções. Variância alta geralmente vem de tarefas ambíguas, corretores inconsistentes ou ruído de ambiente, como arquivos ou histórico de git deixados por testes anteriores.

O texto também alerta contra a "amostragem adversarial": escolher casos apenas porque o modelo atual falha neles mede o padrão de falha de um modelo específico, e não o que é intrinsecamente difícil. A recomendação é escolher casos difíceis com justificativa humana, incluindo falhas reais de produção, mas com cautela - o tráfego de usuários tende a enviesar para casos fáceis.

Como o build-eval funciona

Ao executar /claude-api build-eval, o Claude entrevista o usuário e monta a avaliação com pausas para aprovação. As entradas são amostradas nesta ordem: transcrições de produção (após perguntar sobre retenção e dados sensíveis), relatórios de bugs e tickets, de cinco a dez casos escritos à mão e casos sintetizados do código-base. Uma página simples mostra todas as entradas e aguarda confirmação.

Para o corretor, o comando propõe a opção mais barata: verificação programática (correspondência exata, rótulo de conjunto fixo, JSON com schema ou testes) quando o espaço de saída é restrito, ou LLM como juiz quando há muitas respostas válidas - nesse caso, um segundo modelo (que não deve ser o modelo testado) pontua com base em critérios verificáveis e, se houver baseline, compara duas saídas em ordem aleatória sem saber qual é a referência.

Durante o baseline, o Claude faz verificações diagnósticas: roda o corretor duas vezes na mesma saída para checar consistência, verifica timeouts e erros de API para que ruído de infraestrutura não passe por variância do modelo, e avisa se o baseline já está perto de 95% ou mais, sugerindo então otimizar custo ou latência em vez de qualidade.

Hillclimbing e overfitting

Para o hillclimbing, o guia recomenda superfícies de mudança baratas e reversíveis (como prompts e skills), objetivos atribuíveis à métrica e bem delimitados - um eval saturado ou um pedido aberto de "melhorar tudo" tende a estagnar; reduzir custo mantendo o desempenho é um objetivo geralmente robusto.

O overfitting é o principal risco: melhorias podem "vazar" para o harness (prompts, ferramentas e loop ao redor do modelo) sem se traduzir em ganhos reais - por exemplo, adicionar uma ferramenta de OCR que só ajuda nos exemplos do eval. Três contramedidas são citadas: dividir os casos em conjunto de treino e conjunto de teste nunca visto, nunca colar o conteúdo de falhas diretamente no prompt e manter respostas estruturalmente fora do alcance do modelo para evitar "reward hacking".

No /claude-api hillclimb, o usuário escolhe o que o Claude pode modificar (prompt de sistema, skills, descrições de ferramentas, parâmetros de API ou código do harness) e o objetivo. Antes de começar, o Claude verifica se o ruído do eval é menor que a menor melhoria acionável. A cada rodada, ele propõe um patch, executa o eval e decide: se o treino melhora mas o teste fica plano, suspeita de overfitting e reverte; se ambos melhoram, mantém. Quando o placar estagna duas ou três rodadas, ele classifica as falhas restantes por causa. Ao final, o código fica na melhor versão do conjunto de teste, e ganhos dentro do ruído levam à recomendação de não fazer merge.

Resultados em dois exemplos

Em um benchmark interno de suporte ao cliente com 44 tickets (30 de busca, 14 retidos), o hillclimb partiu do Opus 4.8 em esforço alto, com 74,4% de acurácia e custo de 4,6 centavos por ticket. Após auditar o prompt e remover rituais de chamadas de ferramenta, passou ao Opus 5.5 em esforço baixo (87,8%, 1,9 centavo - o preço do novo modelo é 20% menor em entrada e saída e 60% menor em leituras de cache), depois ao Sonnet 5 em esforço baixo (88,9%, cerca de 1 centavo) e, com regras de roteamento adicionadas, chegou a 98,9% no treino. Nos 14 tickets retidos, a configuração final marcou 90,5% contra 78,6% do setup original, a cerca de um quinto do custo.

Na própria skill claude-api, um eval derivado da documentação partiu de 66%. O hillclimber, com acesso à documentação e aos SDKs, identificou oito funcionalidades sem cobertura (74%), corrigiu tabelas de tipos em C# e Java (77%) e, após uma rodada de reflexão sem edições, percebeu que o conteúdo existia mas o Claude escrevia formatos antigos de API - o que motivou uma tabela de migração de padrões, elevando o desempenho a 80%. Falhas persistentes também revelaram defeitos no próprio eval: uma tarefa pedia capturar um tipo de erro enquanto o corretor exigia uma cadeia de três, e outro corretor contradizia a documentação - testes na API real mostraram que a documentação estava certa. Com esses ajustes, o desempenho chegou a aproximadamente 88%.