As equipes que desenvolvem agentes de IA precisam de mais do que verificar a resposta final para saber se o sistema está funcionando como deveria. Em aplicações que combinam recuperação, geração e chamadas de ferramentas, o resultado incorreto pode ser causado pela seleção de um banco de dados errado ou pela recuperação de documentos inadequados, mesmo que o problema pareça estar apenas no texto final. Durante uma apresentação realizada pela InfoQ, Susan Chang, cientista de dados principal da Elastic, explicou como a empresa desenvolveu uma estrutura compartilhada para avaliar seus agentes usados em segurança cibernética e chatbots corporativos.
De avaliações isoladas a ferramentas compartilhadas
As equipes da Elastic começaram criando conjuntos de dados, avaliadores e processos de rastreamento separados para cada agente. No caso de um agente de detecção de ataques, os testes incluíam cenários de ataque e cenários benignos elaborados por analistas e pesquisadores de segurança, com métricas como precisão e revocação, correção factual, similaridade e classificação de táticas do MITRE. Já os chatbots baseados em dados corporativos testavam perguntas e recuperação de documentos, com foco na relevância e na completude da resposta, na correção dos identificadores de produtos e na formulação de consultas ES|QL.
A diferença entre esses casos resultou em uma grande repetição de trabalho. Por isso, a Elastic criou uma estrutura compartilhada capaz de importar diferentes tipos de conjuntos de dados para um esquema unificado, executar avaliações baseadas em rastros de execução e usar avaliadores compartilhados para aplicações de RAG, além de componentes personalizados para cada produto. O processo pode ser executado localmente: os dados são carregados, o agente é executado, os resultados são coletados e as pontuações são exibidas aos desenvolvedores.
O rastreamento é essencial para entender a causa da falha
A experiência confirma que o rastreamento do agente não deve se limitar à sua saída final. É necessário registrar as ferramentas chamadas, as operações de busca vetorial e textual, os dados recuperados, o consumo de tokens, o tempo de resposta e a sequência de decisões. Esse nível de detalhe permite avaliar a chamada de uma ferramenta específica ou descobrir que o agente usou uma fonte incorreta antes que o problema apareça na resposta final.
Também é possível transformar casos de falha relatados pelos usuários, como uma avaliação negativa, em novos exemplos no conjunto de testes. Assim, o feedback de produção torna-se parte dos testes de regressão em versões posteriores, em vez de permanecer como observações manuais separadas do ciclo de desenvolvimento.
Por que LLM-as-a-judge não é suficiente?
A Elastic usou modelos de linguagem para avaliar saídas de outros modelos em tarefas abertas ou ambíguas, como estilo, coerência e adequação da resposta ao contexto. Essa abordagem permite ampliar a avaliação quando é difícil escrever uma regra precisa para julgar um texto longo. No entanto, ela pode produzir resultados diferentes entre uma execução e outra e pode não detectar erros específicos, como um identificador de produto inexistente ou uma consulta inválida.
Por isso, a Elastic combinou LLM-as-a-judge com avaliações determinísticas baseadas em regras e programação. Essas avaliações verificam a estrutura de JSON ou YAML, a correção da sintaxe, a presença das entidades necessárias e a possibilidade de execução do código ou da consulta, além de métricas como precisão, revocação e correção factual. Essa combinação reduz o custo e acelera a avaliação nos casos que têm uma resposta clara, deixando o julgamento semântico para as tarefas difíceis de reduzir a regras.
O que não pode ser generalizado?
A Elastic não considerou a criação de dados de teste especializados como algo totalmente automatizável. Em segurança cibernética, a equipe precisa de analistas e pesquisadores para definir o que constitui um ataque real e qual é o comportamento aceitável para o usuário final. Além disso, a definição de regressão varia entre os agentes; um agente de segurança pode tornar-se mais propenso a declarar a existência de ataques mesmo quando são inseridos dados benignos após determinada atualização.
A calibração dos avaliadores continua sendo responsabilidade de cada equipe. Se o avaliador de linguagem atribuir pontuações diferentes ao mesmo caso ou não concordar com o julgamento humano de referência, a estrutura compartilhada produzirá números enganosos, independentemente da qualidade da arquitetura de software. Chang também apontou o risco de viés do avaliador quando membros da mesma família de modelos são usados para geração e julgamento, pois o avaliador pode superestimar o desempenho desses modelos.
O que muda na prática para as equipes?
A experiência da Elastic recomenda começar com um pequeno conjunto de exemplos de teste, que pode variar entre 20 e 50 casos, em vez de esperar por um conjunto ideal. Nas primeiras etapas, o trabalho fragmentado pode ser aceitável para acelerar o aprendizado, especialmente quando os casos de uso e as métricas ainda estão sendo descobertos. No entanto, quando vários agentes entram em produção, o rastreamento e a avaliação básica tornam-se essenciais para responder a perguntas sobre desempenho e diagnosticar problemas dos usuários.
A Elastic também transferiu algumas ferramentas de avaliação de Python para TypeScript, para corresponder ao código de produção escrito em TypeScript e usar o Playwright e uma ferramenta interna personalizada chamada Scout. Essa medida não significa que seja necessário transferir todas as avaliações de ciência de dados, mas reflete uma necessidade específica de reduzir a distância entre aquilo que a equipe testa e o que o sistema realmente executa. A conclusão prática é que a estrutura compartilhada pode unificar o esquema, a execução e as métricas gerais, mas não pode substituir a experiência de domínio nem o julgamento sobre o que deve ser considerado sucesso ou fracasso.