Ir para o conteúdo principal
Voltar aos artigos

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.

·3 min de leitura·2 visualizações

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

Continue lendo