Avaliar agentes sem esconder regressões dentro de uma nota média
A Elastic combina infraestrutura comum e critérios por produto. O ponto decisivo é testar o comportamento real, inclusive nos casos benignos.
Susan Chang, cientista de dados principal da Elastic, descreve no InfoQ a passagem de avaliações isoladas para um framework reutilizável de agentes.[4] A apresentação compara agentes de descoberta de ataques com chatbots empresariais, preservando conjuntos de dados e critérios próprios de cada produto.[4] Um exemplo de regressão mostrou um agente que passou a identificar ataques em dados inofensivos depois de uma atualização.[4]
Esse é o tipo de erro que uma nota agregada pode esconder. Para engenharia, a pergunta relevante não é só se a média melhorou. É qual comportamento piorou, para qual usuário e com qual consequência.
O que muda para quem desenvolve
Na avaliação de segurança, a Elastic inclui cenários de ataque e cenários benignos; nos chatbots, entram recuperação de informação e correção de consultas ES|QL.[4] A infraestrutura comum reúne execução, coleta e avaliadores, mas criação dos dados, comportamento desejado e calibração permanecem responsabilidades específicas.[4]
Minha leitura: compartilhe o mecanismo de medir, não uma definição universal de qualidade. Um chatbot pode precisar reconhecer falta de informação. Um agente de investigação pode precisar evitar acusações falsas. Dar a ambos a mesma rubrica genérica facilita o relatório, não necessariamente a decisão de lançamento.
Chang também relata uma divergência entre avaliações inicialmente feitas em Python e agentes de produção escritos em TypeScript.[4] Parte do ferramental foi transportada ao stack principal, com Playwright e uma adaptação interna chamada Scout.[4] A análise útil aqui não é “reescreva tudo”. É conferir se a avaliação percorre as mesmas integrações e decisões que o produto entregue.
Como aplicar
A palestrante sugere começar com algo como 20 a 50 exemplos.[4] Para um piloto, organize os casos por função: resposta correta, informação ausente, recuperação errada, ferramenta indevida e entrada benigna que não deve gerar alerta. Escreva o resultado esperado antes de ajustar o agente.
Separe duas camadas de avaliação:
- Verificações determinísticas: estrutura da saída, entidades obrigatórias, ferramenta permitida e validade de consultas.
- Julgamentos de conteúdo: fidelidade à evidência, completude e adequação da resposta ao pedido.
Como experimento verificável, execute a versão atual e a candidata sobre o mesmo conjunto. Mostre resultados por categoria, além da média, e examine os casos que mudaram de acerto para erro. Defina quais regressões bloqueiam a promoção mesmo quando o agregado melhora.
Capture etapas intermediárias suficientes para distinguir recuperação inadequada de raciocínio inadequado. Um resultado final ruim exige correções diferentes se a fonte nunca foi encontrada ou se foi encontrada e ignorada.
Cuidados e limites
A apresentação alerta que avaliadores baseados em modelos podem variar, preferir saídas da mesma família e não reconhecer identificadores internos inventados.[4] Calibre essas notas com exemplos revisados por pessoas do domínio. Não pague por um julgamento probabilístico para verificar algo que uma regra confiável decide.
O compartilhamento de conteúdo de produção também depende de concordância do cliente e pode exigir ocultação ou redução de dados.[4] Portanto, rastreabilidade não significa exportar tudo. Defina o mínimo necessário para diagnosticar a falha e proteja informações sensíveis. Uma avaliação reutilizável só vale a pena se preservar o contexto que torna cada erro importante.
Fonte
[4] Fonte: InfoQ, apresentação de Susan Chang, com transcrição integral