Susan Chang, cientista de dados sênior da Elastic, compartilha como a empresa evoluiu de avaliações ad hoc e isoladas para agentes de IA para um framework unificado em nível de produção. O desafio foi consolidar diferentes abordagens, balancear avaliações baseadas em LLM com regras determinísticas, integrar código Python de ciência de dados com produção em TypeScript e implementar rastreamento profundo para detectar regressões em workloads complexos de RAG e segurança cibernética, mantendo o contexto do domínio.
Os agentes de IA que a Elastic roda em produção
A Elastic constrói sobre Elasticsearch, sua plataforma de busca e recuperação de dados. Internamente, a empresa desenvolve agentes de IA para observabilidade e segurança. Um exemplo é o attack discovery, que usa agentes para extrair informações de logs e identificar possíveis ataques, em vez de analistas revisarem manualmente milhões de registros. Outro caso são chatbots corporativos que usam dados proprietários armazenados em Elasticsearch.
Um cliente bancário importante da Elastic ingere petabytes de dados para segurança cibernética. Quando ocorre um incidente, precisam filtrar logs, extrair informações relevantes e resumir achados — dados que já estão no Elasticsearch.
Quando constroem esses agentes, a Elastic quer estimar a qualidade das respostas, prevenir regressões quando fazem mudanças e testar repetidamente sem trabalho manual excessivo.
O desafio inicial: avaliações fragmentadas
Cada time de desenvolvimento criava seus próprios datasets, seus próprios avaliadores. Rastreavam os dados em lugares diferentes, armazenavam em locais distintos e executavam avaliações em plataformas completamente diferentes.
No exemplo de segurança cibernética, o time colaborava com especialistas de segurança para criar cenários de ataque realistas destinados a avaliações. O agente de IA precisa identificar esses ataques quando ocorrem.
Os times usavam métricas diferentes conforme seu domínio:
Time de segurança: precisão e recall (para evitar alucinações do agente), scores de similaridade, scores de factualidade e MITRE tactics (uma taxonomia de domínio que classifica tipos de ataques cibernéticos). Não queriam que o LLM alucinasse MITRE tactics não relacionadas.
Time de chatbot corporativo: precisão, recall, factualidade, relevância de resposta, completude de resposta. Também se preocupavam com ES|QL, uma linguagem de query que a Elastic desenvolveu — o agente deve gerar sintaxe correta. Construíram ferramentas para os agentes verificarem essas queries.
Diferentes times construindo diferentes tipos de agentes em diferentes domínios tornava cada vez mais necessário avaliar como funcionavam. Cada time criava seus próprios agentes e suas próprias avaliações.
Susan enfatiza que rastreamento é muito importante e a base de tudo. A Elastic experimentou várias ferramentas, incluindo LangSmith e Phoenix.
Um agente típico, construído com LangGraph, faz várias chamadas sob o capô. Quando um usuário pergunta "você pode me ajudar a resolver esse problema com um índice Elasticsearch?", o agente executa vector search, keyword search e toma decisões sobre qual ferramenta usar. O rastreamento captura informações granulares: quais ferramentas foram chamadas, qual vector search foi executado, quais dados foram recuperados.
Se você apenas avalia o resultado final, não sabe o que aconteceu no meio. Pode parecer que o agente tem um número errado, mas na verdade estava consultando o banco de dados errado. Sem informação granular, é muito difícil agir baseado nas avaliações.
Um recurso útil do LangSmith é "Add to Dataset". Quando novos cenários chegam e o agente comete um erro — talvez o usuário tenha dado feedback negativo — você rastreia isso e adiciona à dataset de teste. Assim garante que em iterações futuras, o agente agora funcione bem nesses cenários onde falhava antes.
Quanto a capturar "tanto dado assim", Susan aponta que em indústrias com restrições de privacidade isso é impossível. Mesmo assim, sempre houve sinais proxy ou feedback explícito e implícito em outros casos de machine learning, como sistemas de recomendação. É semelhante aqui.
O framework compartilhado de avaliações: visão geral
Era cansativo continuar construindo avaliações do zero para cada time. A Elastic quis que diferentes times de desenvolvedores colaborassem e mantivessem um framework compartilhado, tornando rápido criar avaliações completas.
Um exemplo: após construir o framework, criaram AI rules generation. Rules são arquivos YAML/JSON estruturados. Fizeram um agente para que usuários não-especialistas digitassem em linguagem natural: "crie uma regra de detecção que sinalize usuários que entraram no fim de semana" ou comportamentos anômalo. Susan conseguiu criar as avaliações e focar em outros aspectos em vez de reescrever uma suite de avaliação do zero.
Organizações de segurança e times de chatbot inicialmente construíram frameworks de avaliação completamente diferentes. Depois tiveram que consolidar.
O que o framework compartilhado faz
O toolkit compartilhado importa datasets. Casos de segurança cibernética usam dados completamente diferentes do caso de chatbot. Segurança cibernética recebe logs de segurança e precisa extrair cenários de ataque potencial. Chatbot usa tipos de pergunta-resposta. Tinha que importar tipos de dataset diferentes.
O framework oferece:
Schema padronizado e compartilhado para datasets
Avaliadores baseados em rastreamento (lado de observabilidade): uso de tokens, latência, chamadas de ferramenta, performance
Avaliadores RAG compartilhados: aplicáveis a agentes que usam busca e recuperação
Avaliadores customizados conforme necessário
Um exemplo de fluxo de avaliação: você tem datasets com inputs e outputs. Executa a tarefa ou roda um agente. No chatbot, teria uma pergunta e resposta. Executa os avaliadores (baseados em código, LLM-as-a-judge, baseados em rastreamento). Esses são customizados por caso de uso. Depois armazena os resultados no Elasticsearch ou outras ferramentas mencionadas.
De Python para TypeScript
A maioria do codebase da Elastic é escrita em TypeScript. Os cientistas de dados originalmente usavam Python: para carregar datasets, chamar agentes de IA ou executar equivalentes em Python de agentes que rodavam em produção em TypeScript. Havia mismatch entre o que rodava em produção e o que era confortável para a equipe de dados.
O time de software engineering já usava Playwright (framework para rodar testes e APIs). Trabalharam juntos, usando muito Claude e Cursor, para traduzir ferramentas de Python para TypeScript, combinando melhor com o que rodava em produção.
Não é aplicável em todos os casos. Susan não diz "portem tudo de Python para TypeScript". Mas para esse cenário específico, queriam igualar a produção mais de perto.
Rodam em Playwright customizado, chamado Scout. Carrega datasets, executa agentes implementados em TypeScript, faz coleta e avaliações. Do ponto de vista do desenvolvedor, porque usam TypeScript no codebase, podem rodar tudo localmente e ver scores e resultados no terminal — isso melhora a experiência.
Framework de avaliação compartilhado: blocos de construção
Os blocos gerais:
Métricas consolidadas
Times diferentes usavam métricas como precisão e recall. Factualidade também era testada. Isso é o tipo de métrica que eventualmente consolidaram entre times.
Similaridade semântica: identifica se a busca semântica ou vector search está recuperando os documentos mais relevantes. Importante para diferentes tipos de agentes que usam RAG ou busca e recuperação.
Factualidade: verifica se o agente hallucina. Em chatbots, não devem inventar IDs de produtos. Em segurança, não devem inventar MITRE tactics.
LLM-as-judge
Muitos casos usavam LLM-as-judge (ou avaliações baseadas em modelos), mas implementadas separadamente e de maneiras diferentes. Construíram tooling compartilhado.
Comçaram com avaliações ad hoc e depois descobriram o que podiam consolidar, porque tudo estava se movendo rápido. "Se tivéssemos planejado por dois meses e depois construído, acho que não teríamos conseguido lançar tanto."
Um exemplo em Python, depois movido para TypeScript: para ES|QL, usuários pedem "gere uma query ES|QL que faça isso". Tinham respostas boas em uma dataset de teste. O framework de avaliação compartilhado precisa puxar esses exemplos conhecidos e compará-los com a dataset de teste.
Um LLM-as-judge simples é: "essas respostas são similares?". Com maturação, ficou muito mais complexo e nuançado.
Prós e contras do LLM-as-judge
Prós:
Útil quando pareado com o tipo certo de avaliações híbridas
Bom para escalar para cenários ambíguos
Excelente para tarefas abertas
Pode auto-graduar usando chain-of-thought, explicando por que chegou ao resultado
Contras:
Pode não ser granular o suficiente. Resultados incluem query language, output, objetos JSON ou YAML que precisam seguir formato específico. LLM-as-judge sozinho talvez não funcione bem — precisa combinar com outras chamadas de ferramentas ou avaliações programáticas
Resultados podem variar entre runs, mesmo com o mesmo modelo
LLMs podem não identificar informações internas como product IDs
Viés de modelo: pesquisa de segurança cibernética (Elastic, Meta e CrowdStrike descobriram) mostrou que se usam a mesma família de modelos — Llama para avaliar Llama — eles pensam que os modelos Llama performam melhor
Em janeiro, Anthropic publicou um blog cobrindo muitas dessas descobertas que a Elastic havia encontrado internamente. Foi validação do pensamento sobre LLM-as-judge.
Avaliações baseadas em regras (avaliações programáticas)
Captura pontos cruciais que LLM-as-judge não consegue fazer bem:
Usar código (Python, TypeScript) para verificar se código gerado funciona
Heurísticas: extrair entidades diferentes. Para chatbot, precisa outputar o product ID correto. Se não outputou nenhum, está errado
Lógica de scoring simples
Verificações programáticas de sintaxe
Coisas que não querem hallucinations, respostas determinísticas
Combinar com LLM-as-judge é ideal.
Prós:
Sem ambiguidade
Captura fraquezas do LLM-as-judge
Barato
Rápido — não precisa de uma chamada LLM para cada avaliação aleatória
Contras:
Mais difícil escalar para espaços de problemas maiores e linguagem natural
Muito difícil usar avaliação baseada em regras em um grande chunk de texto e dizer "essa resposta está correta"
Melhor deixar LLM-as-judge lidar se for chunk maior de texto, linguagem natural
Mais fraco para tarefas abertas — aí tentam usar ambas juntas
O que não conseguiram abstrair?
Cada time deveria ser dono de suas próprias considerações:
Criação de dados sob medida
No caso de segurança cibernética, analistas de segurança e pesquisadores contribuem com perspectiva de usuário. Se você constrói um agente de analista de segurança cibernética para ajudar analistas a encontrar ataques mais rápido, você precisa de FEEDBACK deles, não de engenheiros de software e cientistas de dados.
Não é algo que pudessem automatizar no framework compartilhado.
Input do produto
Trabalhando perto do time de produto: o que são exemplos positivos, comportamentos positivos ou negativos? Onde o agente pode errar? Tudo isso precisa entrar nos mecanismos de scoring das avaliações.
Regressão significa coisas diferentes para diferentes agentes. Às vezes lançam atualizações e o agente que performava bem fica mais agressivo e piora. Um exemplo do agente de segurança: costumava não alucinar certos ataques. Após update, mesmo com dados benignos, começou a pensar "sim, tem alguém atacando".
Muito disso é iterativo. Não dá pra prever tudo, especialmente em workflow ambíguo.
Calibração
O framework compartilhado não pode ser responsável por calibração. Basicamente, quando rodam as avaliações, devem estar performando de forma similar. Avaliadores geralmente concordam com avaliadores humanos ou comportamento alvo. Se não estiverem bem calibrados, só vão dar lixo.
Se usam LLM-as-judge e rodam o mesmo cenário três vezes, e o LLM-as-judge pensa que é performance diferente cada vez, significa que não está bem calibrado. Tiveram que melhorar essas coisas. Tudo depende de expertise de domínio e expertise individual de cada time. Não no framework compartilhado, porque não conseguem colocar lá.
Principais conclusões
Se estão construindo os primeiros agentes
É um pouco diferente para cada companhia. Quando construíram seus primeiros agentes, trabalhavam bem perto dos especialistas de domínio.
No caso de segurança cibernética, trabalharam com analistas que montavam VMs, ambientes de teste em Okta. Coisas bem difíceis de fazer. Se o agente de IA faz algo muito complicado com aquilo, não pulem o expertise de produto e domínio. É tentador pular isso e pedir ao LLM para gerar um monte de coisas. Eventualmente fizeram para escalar a dataset, mas se certificaram de ancorar em expertise real e necessidades reais de usuários.
Nesse estágio inicial, tentaram diferentes ferramentas de rastreamento e viram o que funcionava. Começaram a construir agentes cedo com LangGraph, fez sentido começar com LangSmith. Outros times começaram com Phoenix. Outros ainda usam Elastic Observability.
Começar pequeno é importante. Muita gente fica sobrecarregada. "Como faço essa dataset? Parece tão complicado. Estou construindo chatbot corporativo, como junto exemplos de pergunta-resposta?" Eugene Yan, que agora trabalha na Anthropic, menciona em seu blog: para algumas situações, comece com amostra de 20 registros na dataset de teste, depois 50, depois escale. É importante responder, especialmente no primeiro estágio, quando AI adoption ou AI development está começando. Trabalho ad hoc é ok. Não tem nada errado com pouco dado. É importante avaliar. Assim justificam construção futura de agentes e escalam para times e domínios diferentes.
É ok não super-investir em abstrações nesse estágio. Otimizam para aprendizado e experimentação. Early on, talvez tenham trabalhado isolado. "Espera, vocês usam Phoenix? A gente usa LangSmith." Tudo bem. Um speaker do LinkedIn mencionou que alguns é coisa organizacional. Se empresa tem jeito compartilhado de usar LLMs, isso também é desafio e é importante. Comunicação entre times é chave, ver no que estão apontando.
Se têm alguns agentes em produção
Esse foi o ponto quando tinham alguns agentes e diferentes avaliações. Tinham, mas se não tiverem, comecem a construir pelo menos uma. Liderança de produto e companhia vai ter perguntas sobre como os agentes performam. Usuários podem ter problemas em produção e querem conseguir troubleshoot.
Necessitam pelo menos começar a construir rastreamento ou evals. Pensar em métricas comuns observando e iterando. No caso de segurança, após mudanças, perceberam que alucinavam ataques em dados benignos. Tiveram que refinar métricas. É tudo iterativo. Talvez eventualmente rodem em problemas de avaliações demais, talvez causadas por isolamento ou times diferentes construindo sua própria coisa.
Também querendo se mover rápido é ok. Encontraram isso também. Podem ter que ficar com uma ferramenta e decidir. Consolidam depois. Conforme agente development amadurece, todo o tooling compartilhado deve ser consolidado para evitar dor.
Essa talk é sobre framework de avaliação. Também consolidaram muitos agentes. Costumavam ter agentes de segurança que faziam isso. Encontrou que precisava clicar dropdown para mudar para outro agente também em Elastic. Em release recente, consolidaram aquele workflow e consegue identificar qual agente estão conversando em vez de clicar dropdown.
Lições aprendidas
Se pudessem fazer tudo de novo:
Comunicação anterior e consolidação: começariam a comunicar mais cedo com objetivo de trabalhar junto e consolidar. Por algum tempo era "seu time faz isso, nosso time faz aquilo". Talvez pudessem dar acesso à plataforma? Então adicionavam ao time. Ad hoc. Funcionava. Não estavam realmente falando sobre consolidação naquele tempo. Se pudessem fazer de novo, tentariam fazer isso.
Feedback para melhorar produto: tentariam tornar mais fácil feedback melhorar o produto. Sinais proxy e coisas assim. Para muitos enterprise users de Elastic, não conseguem rastrear dados com tanta granularidade. Têm que concordar compartilhar com Elastic. Mesmo compartilhando, está bastante redacted ou bare bones.
Se conseguissem construir jeito melhor para usuários dar feedback — talvez similar a thumbs up/thumbs down em ChatGPT — qualquer mecanismo, mesmo recebendo apenas sinais proxy ou indiretos, pelo menos ter mecanismo de feedback ou jeito estruturado de rastrear. Para outro produto de ML, usaram Google Forms. Ao menos tem algo.
Stack principal: porque tudo em produção era TypeScript e haviam investido bom tempo construindo framework de avaliação em Python, não tem certeza se não faria Python tudo, porque seu time era especializado nisso. "Estou meio dividida nessa."
Quando saltaram para TypeScript, usando Claude e Cursor pesadamente, com review de engenheiros de software mais experientes em TypeScript, isso realmente capacitou seu time a contribuir diretamente ao shared evaluation frameworks. Acha que foi boa decisão a longo prazo. Não começariam assim, mesmo fazendo de novo. Se já têm suas próprias avaliações compartilhadas, o que fariam?
Compartilhamento público: compartilham alguns resultados de avaliação publicamente, não para cada cenário. Diferentes indústrias e companhias usam Elastic para coisas diferentes, e internamente tentam construir blocos reutilizáveis para clientes e usuários em domínios diferentes.
Compartilham recomendações para usuários em domínio de segurança com avaliações assim, mas nem tudo. É interessante ter um pouco de escrutínio público ou compartilhar trabalho, que demonstra que é legal e útil ter evals para ver o que poderiam recomendar a outros times na organização ou até público maior.
Perguntas e respostas
Pergunta 1: "Usamos Phoenix internamente para rastreamento. Como vocês pensam sobre armazenar dados em Phoenix versus banco de aplicação ou outro lugar? Todos os dados de eval estão no framework de rastreamento ou alguns no banco de aplicação?" Também, "comparando com OTel e agora com rise de harnesses e passos determinísticos, às vezes falha não é só em passos de inference. Pode ser passo determinístico que falha, como vocês pensam em incorporar isso em debugging geral e treinamento?"
Resposta: A primeira parte era sobre Phoenix e onde armazenam dados. Algumas organizações já armazenam dados de observabilidade em algum lugar, facilita decisão. No caso da Elastic, observabilidade estava armazenada em outro lugar. Porque observabilidade, incluindo a deles, não tinha muita rastreamento específica de LLM out of the box naquele tempo, decidiram pegar algo como Phoenix que construiu muitos add-ons úteis para rastreamento específico de LLMs ou agentes. Dados em outros lugares. Se já tinha muitos dados de observabilidade armazenados, talvez usassem a mesma coisa, se começassem de novo e toda ferramenta fosse madura já. Assim fizeram decisão, sim, armazenaram em talvez lugares diferentes conforme o que queriam fazer.
Todas aplicações já tinham observabilidade que usavam há muito tempo em algo outro. É uma parte. Ouviram pessoas, digamos, usam MLflow para agent. É porque já tinham MLflow para outro caso de machine learning e aí acabaram usando, mesmo não tendo certeza se era porque mais mature ou porque armazenamento era fácil ou outra coisa. Depende do que é fácil e do que companhia já tem, e se empresa tem appetite para tentar ferramentas diferentes. Naquele tempo, muitas ferramentas não eram tão mature.
Quanto agentes pararem de ser coisa one-shot onde só providenciam contexto em caixa preta, conforme há mais harnessing e passos determinísticos, como pensam em debugability e rastreamento incorporando passos determinísticos também? Às vezes falha não é em inference, é em passos determinísticos.
Para eles, quando possível, rastreiam tudo em ambientes de desenvolvedor. Inclui muitos passos determinísticos. Quando fazem avaliação, não é só no resultado final, mas às vezes no, está fazendo chamada de ferramenta correta, por exemplo. Têm muitas avaliações granulares conforme os passos no meio que agente pode estar tomando. Só porque têm aquele dado disponível conseguem avaliar aquelas coisas. Qualquer coisa determinística, se conseguir ser avaliada e têm o dado, definitivamente levam em conta.
Pergunta 2: "Vocês poderiam detalhar um pouco, uma vez que rodam evals, quais tipos de consideração entram em setar critérios de, sim, vamos promover esse agente, ou não vamos? Alguns critérios são passa/falha, ou tem jeito de setar bars mais baixas? Ou tão só olhando para melhoria? Só querendo alguns pensamentos gerais sobre isso."
Resposta: Têm matriz que tem scores granulares, digamos precisão, recall e depois factualidade e outras coisas. Ou talvez se avaliando específicas chamadas de ferramentas, têm métricas específicas. Depois um roll-up score, coisa simples de pesos. Digamos que acham factualidade muito importante, então pesam aquilo mais alto. Depois somam e têm score composto achatado em um único valor.
Também têm outros scores disponíveis para as pessoas verem. Porque quando achatam, é muito fácil para decision-makers ou até para eles, tipo só querem ver um valor no final. Podem ter threshold e tem que melhorar, mas precisa estar acima de certo threshold também. Também querem investigar talvez métricas mais detalhadas se conseguirem.
Produção é mais simples. Achatam em um score, threshold e podem rodar testes ad hoc, manual. Manual tipo usar o produto e clicar por aí e tal, fazer último smell check. Depois lançam. É rigoroso, mas também não é realmente.
Tecnologia
Google pausa programa de recompensas por vulnerabilidades em código aberto por conta de envios com IA
