Não confie nos seus agentes de IA. Teste-os como um cientista — Stephanie Jarmak, Omni Analytics
원제 · Don't Trust Your AI Agents. Test Them Like a Scientist — Stephanie Jarmak, Omni Analytics
핵심 요약
A avaliação rigorosa de agentes de IA exige a criação de ambientes e cargas de trabalho realistas, uma vez que benchmarks públicos e rastreamentos automatizados muitas vezes falham em refletir o comportamento real do sistema e a eficácia operacional.
하이라이트
A alteração do prompt inicial de um agente de programação reduziu o custo em 28%, mas não resolveu o problema de o agente continuar a não utilizar a ferramenta pretendida.
A troca do harness de testes alterou a eficácia das configurações em mais de 30% entre diferentes modelos avaliados no Terminal Bench 4.
A ferramenta Claude devolveu 295 arquivos numa tarefa de busca quando apenas 6 eram necessários, demonstrando a divergência entre métricas de recall bruto e as reais necessidades de otimização.
A análise independente de registos detetou problemas de segurança injetados que tinham passado totalmente incólumes pelas verificações de hash integradas no agente.
Uma taxa de falso alarme de 1% gerada por avaliadores automáticos de LLM resulta em 10.000 revisões, excedendo a capacidade de carga humana numa organização.
타임라인
Limitações das métricas isoladas e impacto do harness
Durante os testes com ferramentas de pesquisa de código, a alteração do prompt gerou uma redução de custos de 28%, mas o agente persistiu em ignorar a ferramenta pretendida. Da mesma forma, a escolha do harness influencia diretamente os resultados de desempenho dos modelos, evidenciando que os benchmarks genéricos podem não corresponder à realidade operacional.
- A modificação de prompts ou parâmetros de custo isolados não garante que o agente utilize corretamente as ferramentas disponíveis.
- A substituição do harness de avaliação altera drasticamente a eficácia comparativa entre modelos em mais de 30%.
- A configuração de testes deve refletir de perto o ambiente e o trabalho real que será medido.
Diferença entre benchmarks públicos e avaliações internas
Os benchmarks públicos ajudam a mapear o panorama tecnológico, mas carecem de especificidade para cargas de trabalho empresariais particulares, como as de uma firma de advogados ou de uma equipa de dados. O desenvolvimento de benchmarks internos personalizados permite criar um processo iterativo alinhado com as necessidades reais do negócio.
- Os benchmarks públicos servem apenas para fornecer uma visão geral e restringir opções iniciais de exploração.
- A construção de benchmarks próprios deve basear-se nas cargas de trabalho reais da organização e abranger todo o ciclo de desenvolvimento.
- A não-determinística natureza destes sistemas obrigatoriamente exige múltiplas execuções para mapear a variação dos resultados.
Observabilidade e rastreio de falhas em pipelines
A recolha exaustiva de dados de observabilidade e traços permite diagnosticar falhas nas chamadas de ferramentas e no aproveitamento de informações. Além disso, a definição de métricas adequadas evita distorções operacionais, como o retorno de centenas de ficheiros desnecessários quando apenas poucos são exigidos pelo objetivo da tarefa.
- A decomposição do contexto disponível para o agente identifica se uma ferramenta estava acessível ou se foi chamada corretamente.
- A otimização métrica deve equilibrar a precisão e o recall de acordo com o valor de negócio pretendido, evitando excessos de dados irrelevantes.
- As barreiras de paragens automáticas devem ser implementadas diretamente no código para evitar falhas operacionais descontroladas.
Fiabilidade dos registos e autonomia controlada
Sistemas de registo internos demonstraram ser vulneráveis a adulterações não detetadas por verificações de hash simples, tornando indispensável a análise independente de tráfego. Para escalar a utilização de agentes em fábricas de software, é necessário estabelecer limites claros de autonomia que determinem quando o sistema deve parar e solicitar intervenção humana.
- Os mecanismos de verificação integrados nos agentes podem falhar na deteção de problemas de segurança injetados.
- As auditorias independentes de registos de tráfego revelam vulnerabilidades que passam despercebidas pelas verificações internas.
- A autonomia dos agentes deve ser limitada por regras estritas para equilibrar a carga de revisão humana e o risco operacional.
설명
Stephanie Jarmak, a former astronomer who now builds evals at Omni Analytics after building a large coding benchmark at Sourcegraph, argues that most agent evaluations are easy to misread. She shows how swapping only the harness moved results by 30%, why public benchmarks are for shortlisting rather than decisions, and how to design your own evals like an experiment: realistic tasks, repeated runs, full traces and a measurement that matches what you care about. She also covers quality gates that actually stop work, the human review bottleneck, agent records you can't trust, and why production is the final test. Chapters: - 00:00 Intro - 01:11 When the agent ignores your tool - 02:47 The harness changes the results - 03:51 Public benchmarks vs. your own evals - 05:34 Designing evals like a scientist - 07:05 Trace the whole pipeline - 08:50 Choose what you measure - 09:48 Quality gates that actually stop work - 11:20 The human review bottleneck - 12:20 When the agent's record can't be trusted - 13:21 Production is truth - 15:05 When to escalate to a human Stephanie Jarmak, Omni Analytics: https://omni.co Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!