Busca agentic vs. busca vetorial para agentes de programação: fizemos o eval

Autoria: AI Engineer (Braintrust) · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Agentic Search vs Vector Search for Coding Agents: We Ran the Eval · Canal: AI Engineer (Braintrust) · 17:37 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, RAG, busca e recuperação de informação

Resumo

Jess, da Braintrust, explica como evals ajudam equipes a tomar decisões sobre sistemas de IA com base em dados, e não apenas em impressões. Ela apresenta um fluxo que combina dados de produção, experimentos e observabilidade, e destaca que evals são um trabalho de equipe. Como exemplo, compara busca vetorial e busca agentic para localizar código com bugs no repositório TypeScript Go da Microsoft. No teste, as duas abordagens tiveram a mesma precisão, mas a busca vetorial custou quatro vezes mais; a palestrante ressalta limitações do experimento, como o conjunto pequeno de casos e a implementação da busca vetorial.

Pontos-chave

Evals ajudam a responder perguntas sobre desempenho, custo, consistência e regressões em sistemas de IA.
Um eval combina conjunto de dados, tarefa, sistema de pontuação e experimentos comparáveis.
Dados de produção podem ser amostrados para criar conjuntos de dados e orientar melhorias iterativas.
Evals envolvem diferentes funções, incluindo engenharia de IA, produto, especialistas no domínio e análise de dados.
Busca vetorial recupera trechos de código semanticamente próximos à consulta; busca agentic explora o repo usando ferramentas como grep e find.
No experimento apresentado, as duas abordagens tiveram a mesma precisão, mas a busca vetorial custou quatro vezes mais.
A busca vetorial às vezes retornou trechos sem contexto suficiente, enquanto a busca agentic conseguiu seguir relações entre funções e arquivos.
A palestrante aponta que o eval poderia ser melhorado com mais casos, mais repos e múltiplas tentativas por tarefa.

Capítulos

Início	Capítulo	Resumo
00:01	O que são evals e por que importam	A palestrante explica como evals apoiam decisões sobre qualidade, custo e regressões em sistemas de IA.
08:49	Busca vetorial e busca agentic	Jess apresenta as duas abordagens de busca e descreve como cada uma encontra código relevante.
11:23	Como o experimento foi montado	Ela detalha o conjunto de tarefas, a implementação das buscas, o rastreamento das execuções e a pontuação.
15:00	Resultados e limitações do eval	As abordagens tiveram a mesma precisão, mas a busca vetorial custou mais, e a palestrante aponta melhorias possíveis para o experimento.

Citações

O que você não quer ouvir é que as equipes estão tomando decisões de lançamento com base em impressões. — 01:02

Um eval é composto por quatro elementos principais. — 03:08

Evals são um trabalho de equipe. — 07:47

A busca vetorial dava proximidade com o código correto, mas a busca agentic tinha mais do tecido conectivo para ligar a lógica dos trechos. — 16:04

Conceitos e entidades

evals (conceito): Testes sistemáticos usados para avaliar e comparar o comportamento de sistemas de IA.
Braintrust (empresa): Empresa cuja plataforma é apresentada para executar experimentos e acompanhar observabilidade.
busca vetorial (conceito): Abordagem que representa dados como embeddings e recupera trechos semanticamente próximos a uma consulta.
busca agentic (conceito): Abordagem em que um LLM usa ferramentas para explorar o código e seguir relações entre arquivos e funções.
Claude Code (ferramenta): Ferramenta usada no experimento para executar as tarefas com busca agentic e, com restrições, busca vetorial.
TypeScript Go (repo): Repositório open source da Microsoft usado para montar o conjunto de tarefas com bugs.
Qdrant (ferramenta): Banco de dados vetorial citado como exemplo de armazenamento de embeddings.
Pinecone (ferramenta): Banco de dados vetorial citado como exemplo de armazenamento de embeddings.
Ankur (pessoa): CEO da Braintrust que sugeriu à palestrante avaliar a comparação apresentada.
Cursor (empresa): Empresa citada por ter publicado uma discussão sobre busca semântica para melhorar agentes de programação.

Tradução completa (pt-BR)

00:01 [música] >> Pessoal, eu sou Jess. Sou da BrainTrust. Sou engenheira de relações com desenvolvedores na BrainTrust e, nesta palestra, vou ensinar a vocês o que são evals, por que são importantes e, depois, vou explicar uma eval relativamente complexa, baseada em uma situação real, que fiz para ajudar a consolidar alguns dos conceitos que estou prestes a ensinar.

00:31 Antes de começarmos, levantem a mão, por favor, se já ouviram falar de evals ou se diriam com confiança que sabem o que são. Certo, legal. Praticamente todo mundo aqui. Faz sentido. Legal. Então, vou começar explicando o básico: o que são evals e por que são importantes. Já participei de chamadas com clientes em que eles disseram que lançaram funcionalidades porque a equipe de engenharia avisou que estavam prontas ou talvez porque um PM testou alguns prompts e disse que pareciam bons. E isso é o que

01:02 vocês não querem ouvir, porque, no fundo, essas equipes estão tomando decisões de lançamento com base na intuição, o que não é bom. O que vocês querem ouvir é algo mais como: “Ah, executei 200 casos de teste diferentes, e 94% deles passaram. Por isso, estamos lançando esta funcionalidade.” Ou então poder dizer coisas mais específicas, como: “Lancei esta funcionalidade, que aumentou a precisão em 5%, mas, na verdade, diminuiu o tom em 5%.” Então, quando me perguntam o que são evals, acho que a melhor maneira de responder é dizer que

01:34 é simplesmente uma maneira de responder a perguntas sobre seu sistema de IA. Por exemplo: qual LLM é a melhor opção para as nossas necessidades? Especialmente quando novos modelos são lançados o tempo todo, é bom poder ter dados para embasar suas decisões. Como a IA se comporta em diversos cenários do mundo real? Por exemplo, seu sistema pode se sair muito bem com respostas em inglês, mas não em japonês; com entradas em inglês, mas não em japonês; ou pode se sair muito bem com Python, mas não com TypeScript. Um aspecto importante é a eficiência de custos. Então, como podemos

02:05 alcançar alto desempenho sem custos excessivos? Isso está definitivamente se tornando um tema cada vez mais relevante. Consistência da marca: a IA reflete de forma confiável a voz e os padrões da nossa empresa? Feedback: estamos aprendendo com os usuários e melhorando de forma iterativa? E uma das perguntas mais importantes é: como sabemos quando algo quebra ou piora? Um exemplo do mundo real que gosto bastante de usar aconteceu há cerca de um ano, em abril de 2025: a OpenAI lançou uma alteração e uma atualização de modelo que

02:36 basicamente deveria tornar o modelo mais útil, mas, na verdade, tornou-o bajulador e, portanto, excessivamente concordante e menos verdadeiro. Esse é um ótimo exemplo de como evals podem ajudar a detectar esse tipo de problema, especialmente porque os sistemas de IA são muito complexos e não determinísticos. Por isso, é muito importante ter esses sistemas de eval na sua empresa ou no que quer que você esteja tentando desenvolver. Vamos entrar em mais detalhes sobre os componentes das evals. As evals são compostas por quatro

03:08 elementos principais. O primeiro é um conjunto de dados. São os dados que você passa para o seu sistema de IA e, em geral, incluem coisas como casos de referência ideais, casos extremos e modos de falha. Depois de ter seu conjunto de dados, você precisa escrever uma tarefa. Uma tarefa define como você quer que o sistema de IA se comporte ao receber a entrada e produzir uma saída. Em termos concretos, isso geralmente inclui um system prompt e o

03:38 modelo escolhido para executar essa tarefa. Depois, você precisa escrever um sistema de pontuação que diga se a saída da IA é boa ou ruim. Geralmente, é o PM ou o engenheiro que escreve os critérios que definem o que é bom e ruim. Talvez vocês já tenham ouvido termos como pontuação determinística, LLM as a judge e revisão humana. Esses são diferentes tipos de estruturas de pontuação. Então, é isso: você escreve seu sistema de pontuação.

04:09 E a última coisa que você faz, que é a parte mais divertida de escrever evals, é experimentar. Cada configuração de um conjunto de dados específico, de uma tarefa específica e de um sistema de pontuação específico corresponde a um experimento. Enquanto testa diferentes hipóteses sobre como melhorar seu sistema, você ajusta o conjunto de dados, a tarefa ou o sistema de pontuação, e cada ajuste leva a experimentos diferentes. Depois de ter seus diferentes experimentos, você começa a compará-los. Por exemplo, pode executar o experimento um

04:40 e o experimento dois e ver se houve melhorias ou regressões. Você também pode clicar em linhas específicas para ver exatamente quais casos de teste mudaram. Esta captura de tela é da interface do Braintrust. Outra coisa que você pode fazer é usar linguagem natural para consultar seus traces e experimentos. Por exemplo, pode pedir coisas como: “Resuma meus experimentos” ou “Destaque os problemas nestes experimentos”. Acho isso especialmente útil quando você está executando um experimento ou

05:11 está analisando traces com conversas longas, com várias interações. Isso ajuda a detectar coisas como alucinações ou desvios, que são difíceis de identificar manualmente. Se estiver executando experimentos diferentes, também pode perguntar quais tiveram o melhor desempenho entre todos eles. Essa é outra maneira de encontrar padrões nos seus traces. Isso é usando a interface do Braintrust, mas também temos um CLI e um servidor MCP, caso prefira fazer desse jeito.

05:42 E o último pilar do Braintrust é a observabilidade tradicional. Basicamente, você pode usar o SDK do Braintrust para envolver seu código e fazer com que seus logs de produção apareçam no Braintrust. Assim, você faz observabilidade tradicional: monitora seus logs de produção, cria dashboards e coisas do tipo. Para amarrar tudo isso, vou explicar um fluxo de como você pode usar observabilidade e

06:13 evals para melhorar seu sistema de IA. Vamos começar no canto superior esquerdo, onde está escrito “app”. Imagine que você tem algum tipo de aplicação de IA. Neste cenário, digamos que você acabou de lançar uma nova página de documentação com um chatbot de IA integrado, para que os usuários possam fazer perguntas sobre sua documentação ao chatbot de IA. Digamos que você lançou essa página ontem. Então, os clientes começam a usar seu chatbot de IA. Quando começarem a interagir com ele, você começará a receber logs reais de produção

06:45 no seu sistema. Depois que receber esses logs de produção, você pode selecionar uma amostra deles, talvez de 10 a 20 linhas, e criar um conjunto de dados. Quando tiver esse conjunto de dados, podemos executar evals nele, certo? Você tem seu conjunto de dados, pode escrever sua tarefa, escrever seu sistema de pontuação e executar evals com esses elementos. Pode começar a ajustar seu conjunto de dados, seus prompts ou sua pontuação e executar várias evals diferentes. Depois de executar algumas evals diferentes e começar a ver

07:16 qual eval tem o melhor desempenho, você talvez aprenda algo sobre seu sistema. Então, vai fazer uma alteração no código ou no sistema de IA que estiver usando e depois fazer o deploy dessa alteração na sua aplicação. Aí, o fluxo todo se repete, porque essas mudanças vão aparecer nos seus logs de produção e o ciclo inteiro acontece de novo. É assim, mais ou menos, que o fluxo funciona como um todo. O último slide que vou mostrar antes de entrar em um exemplo concreto é um de que gosto muito, porque, conceitualmente, eu…

07:47 Quero deixar bem claro para as pessoas que evals são um trabalho em equipe. Há muita coisa envolvida na criação de evals, desde obter dados do mundo real para a sua plataforma e rotulá-los até desenvolver hipóteses e coisas assim. Então, o engenheiro de IA trabalha, obviamente, nas alterações de código, mas também em inserir os dados na plataforma. O gerente de produto é muito importante. Acho que geralmente é quem lidera as evals em uma empresa, mas também é quem desenvolve a hipótese sobre como é o sucesso e ajuda a ajustar os prompts e coisas assim.

08:18 Especialistas no assunto são muito importantes, especialmente em áreas mais específicas, como seguros, medicina, direito e coisas assim. Eles podem ajudar a rotular os dados ou fornecer uma verdade de referência do que significa excelência. E então, obviamente, analistas de dados para analisar os dados. Por isso, sempre acho que este slide é muito útil de consultar. Certo. Então, vamos ver um exemplo interessante do mundo real de como vocês poderiam usar uma eval. Neste caso,

08:49 Estou comparando busca agêntica com busca vetorial. E a história por trás desta eval específica é que, às vezes, meu CEO Ankur entra no Twitter e me manda artigos de coisas que quer que eu avalie. Então, ele me mandou este tuíte do Cursor, em que o Cursor fala sobre como usou busca semântica, também conhecida como busca agêntica, para melhorar significativamente o desempenho do seu agente de programação. E ele disse: “Jess, você pode avaliar isso para mim?” E eu respondi: “Certo. Estou ocupada, mas tudo bem.”

09:20 Então, entrei no Twitter e vi que havia muita discussão sobre esse tema, por isso achei que poderia ser interessante avaliá-lo. Vamos avaliar a busca vetorial e a busca agêntica. Só quero fazer um breve resumo de cada uma, para que todos estejam na mesma página. A busca vetorial é essencialmente o processo de pegar dados, como código ou texto, e transformá-los em embeddings, que basicamente representam o significado semântico daquele trecho de texto ou código. Então, se vocês olharem para

09:50 o gráfico aqui, é um exemplo visual muito bom: os embeddings de lobo, cachorro e gato ficam bem próximos uns dos outros porque, semanticamente, são todos animais. E os embeddings de banana e maçã também ficam próximos uns dos outros porque são frutas, mas ficam distantes dos outros, porque frutas e animais são coisas diferentes. E o que acontece é que, em uma implementação real de busca vetorial, você pegaria esses embeddings e os armazenaria em um banco de dados vetorial. Algo como Qdrant ou Pinecone, ou

10:22 algo assim. E, se você fizer uma consulta como, por exemplo, “Onde fica a lógica do banco de dados na minha base de código?”, o banco de dados vetorial retornará os trechos de embeddings que correspondem semanticamente mais de perto às palavras da sua consulta. Ou seja, os trechos mais próximos de coisas como “banco de dados” ou “lógica”. É assim que funciona a busca vetorial. A busca agêntica é um pouco diferente. Ela funciona mais como um ser humano. Então, com a busca agêntica,

10:52 você dá ferramentas a um LLM, como grep, find, ls, cat e comandos bash. E ele basicamente explora a sua base de código como uma pessoa faria. Então, procura o nome de uma função, abre um arquivo, lê o arquivo, segue a chamada dessa função até outro arquivo, depois abre esse arquivo e o lê, e continua até encontrar o que precisa. Isso é muito mais parecido com a maneira como uma pessoa percorreria uma base de código para procurar determinadas partes da lógica.

11:23 Certo, então como fizemos essa eval? A primeira parte da criação de uma eval é montar o nosso conjunto de dados, certo? Para isso, usamos o repositório TypeScript go da Microsoft, que é open source. Basicamente, encontramos todos os PRs mesclados que tinham “fix” no título. Depois, voltamos ao commit pai. Ou seja, voltamos ao commit em que o bug ainda estava presente. E então usamos Claude para gerar uma espécie de

11:53 tarefa de bug, ou uma tarefa linear, com base no diff. Ou seja, com base na diferença entre o código com bug e o código corrigido. Depois, fornecemos isso a um LLM e pedimos que ele usasse busca RAG ou busca agêntica para encontrar o código com bug, para localizar onde estava a lógica com bug. Foi assim que criamos nosso conjunto de dados. Encontramos, talvez, uns 20 PRs diferentes e executamos a eval neles. Quanto à nossa tarefa, tivemos que

12:24 implementar a busca vetorial e a busca agêntica, obviamente. Implementar a busca agêntica foi muito fácil, porque Claude Code usa busca agêntica por padrão. Então, simplesmente executamos Claude Code nessas tarefas. Implementar a busca vetorial foi um pouco mais complicado, porque ainda queríamos usar o harness do Claude Code para executar a busca vetorial, só para manter o experimento consistente. Mas tivemos que impedir que Claude Code recorresse por padrão à busca agêntica. Então, fizemos duas coisas. A primeira foi

12:54 dizer explicitamente nas instruções do prompt para não usar busca agêntica. Mas, se você já fez isso antes, sabe que só o prompting nunca é suficiente. Então, também tivemos que usar a flag disallowed tools para impedir Claude Code de chamar certas ferramentas que normalmente usaria na busca agêntica. Foi assim que implementamos a busca vetorial e a busca agêntica, ambas usando o harness do Claude Code. Outra coisa interessante que encontramos foi quando estávamos executando os traces,

13:25 executamos as execuções do Claude Code como subprocessos, mas isso acabou fazendo com que os traces ficassem órfãos. A nossa solução foi passar os IDs dos spans pai como variáveis de ambiente. Se isso não fizer sentido, tudo bem, porque vou mostrar com imagens. Esta imagem que vocês veem aqui mostra como o trace fica quando está sendo executado como um subprocesso órfão. Dá para ver no painel destacado à esquerda, onde diz “run Claude agent”.

13:57 Isso basicamente aparece no trace dizendo: “Certo, está executando o subprocesso do Claude.” Mas não dá para ver o que acontece enquanto esse processo do Claude está sendo executado. Com a correção que fizemos, agora o trace fica assim. Dá para ver que ele está chamando o subprocesso do Claude Code, mas também dá para ver tudo o que está sendo executado nesse subprocesso. Dá para ver todos os turnos, todas as chamadas ao LLM, cada comando de terminal chamado, como grep, bash, ls, find e coisas assim. Isso permite ver o que está acontecendo nesta

14:28 execução propriamente dita. Implementar essa correção foi muito importante, porque ter transparência sobre o que está acontecendo é importante para a depuração mais tarde. E a pontuação foi muito simples. Para a nossa pontuação, dissemos basicamente o seguinte: “Como estamos usando o repositório TypeScript Go da Microsoft, se o teste passar no conjunto de testes do TypeScript Go da Microsoft, recebe 100%; se falhar, recebe 0%.” Então, a pontuação aqui era bem binária.

15:00 Certo. Quanto aos resultados, o resumo é que a busca vetorial e a busca agêntica tiveram o mesmo nível de precisão, mas a busca vetorial custou quatro vezes mais do que a busca agêntica. Quando analisamos os traces e os percorremos manualmente para tentar entender o que aconteceu, chegamos a algumas conclusões. A primeira é que a busca vetorial retorna trechos de código, mas muitas vezes esses trechos não incluem coisas como imports, chamadas de ferramentas ou o

15:32 código que faz a chamada acima deles. Por isso, não é suficiente: não fornece contexto suficiente para que o agent consiga realmente resolver o bug. Um exemplo: em uma das linhas, vimos que o agent vetorial fez 26 buscas e ainda assim não conseguiu entender como três funções interagiam entre si ao longo do arquivo. Em contraste, a busca agêntica conseguiu, como eu disse, trabalhar mais como um ser humano. Ou seja, usar grep para procurar o nome da função, ler a função inteira, identificar a falha na lógica e, em seguida, seguir a chamada

16:04 chamando a lógica em outro arquivo. E a forma como gosto de pensar nisso, enquanto analisava os traces, é que parecia que a busca vetorial aproximava bastante do código correto, mas a busca agentic tinha mais tecido conectivo para ligar a lógica real desses trechos de código. E, conectando isso ao terceiro aprendizado que tive, o motivo pelo qual a busca vetorial foi muito mais cara que a busca agentic é que ela fazia mais buscas, porque ficava

16:35 constantemente buscando, retornando um trecho de código e buscando de novo, retornando um trecho de código e buscando de novo. Como resultado, todas essas chamadas de LLM se acumularam e tornaram a execução muito mais cara. Este é o último slide, mas talvez vocês estejam pensando: “Nossa, há tantas lacunas nesta eval”, o que é muito justo. Há muitas coisas que eu poderia ter feito. Sabe, há muitas boas práticas para executar evals, como fazer várias tentativas por tarefa, especialmente porque os LLMs são tão

17:06 não determinísticos. É bom fazer várias tentativas para confiar muito mais na pontuação que se recebe. Minha implementação de busca vetorial era relativamente fraca. Eu poderia ter feito uma implementação melhor. Também poderia ter ampliado o conjunto de dados. Acho que só executamos isso em umas 20 linhas diferentes. Então, teria sido melhor ampliar isso para incluir outros repos ou coisas assim. Mas o objetivo desta palestra não é criar a melhor eval possível, mas sim

17:37 ilustrar o conceito de como criar uma eval de ponta a ponta. Então, espero ter conseguido fazer isso. E essa é a conclusão da minha palestra. Espero que vocês tenham aprendido um pouco sobre o que são evals, por que são importantes e como poderiam fazer uma na prática. E é isso, acho. Obrigado por ouvirem.

Transcrição original

[00:01] [music] >> Everyone, I’m Jess. I’m from BrainTrust. I’m a dev rel engineer at BrainTrust, and in this talk today, I’m going to be teaching you guys what evals are, why they’re important, and then I’m going to be talking through a relatively complex real-life eval that I did to try to solidify some of the concepts I’m about to teach you.

[00:31] Uh before we get started, has Can you just raise your hand if you’ve heard of evals before or like would confidently say that you know what they are? Okay, cool. Pretty much everyone here. Makes sense. Um cool. So, I’m just going to start off with a basis of what evals are, why they’re important. Um I’ve been on um calls with customers where they’ve said that they’ve shipped features because either the engineering team told them that it was ready or maybe a PM said that they tried out a couple of prompts, and they said it looked good. Uh and this is what

[01:02] you don’t want to hear cuz essentially, these teams are making ship decisions based off of vibes, uh which is not good. Uh and essentially, what you want to hear is more something like, “Oh, I ran um 200 different test test cases, and 94% of them passed, and that’s why we’re shipping this feature.” Or be able to say nuanced things like, um you know, “I shipped this feature that increased accuracy by 5%, but actually decreased tone by 5%.” So, when people ask me what evals are, I think the best way to answer it is that

[01:34] it’s just a way to answer questions about your AI system. So, for example, uh which LLM is the best choice for our needs? Especially when there’s new models dropping all the time, it’s good to be able to have data to back up your decisions. Uh how does AI perform across diverse real-world scenarios? So, for example, your system could do really well with English outputs, but not Japanese or English inputs but not Japanese or types uh do really well with Python but not TypeScript. Um a big one is cost efficiency. So, how can we

[02:05] achieve high performance without excessive costs? This is definitely becoming more topical now. Uh brand consistency. So, does AI reliably affect our company’s voice and standards? Uh feedback. Are we learning from users and improving iteratively? And then one of the biggest ones is how do we know when something breaks or gets worse? So, a real-world scenario that I like to use a lot is uh about a year ago, so April of 2025, um OpenAI actually shipped a model change and model update um that

[02:36] essentially made their model more was supposed to make it more helpful but actually made it sycophantic and therefore uh too agreeable and therefore less truthful. So, this is a really good example of where evals can help you catch that um especially because uh AI systems are so complex and undeterministic that it’s really important to have these eval systems in place at your company or whatever you’re trying to build. So, we’re going to get down into more of the specifics of what evals are comprised of. So, evals comprise of four

[03:08] main things. Uh the first thing is a data set. So, this is the data that you’re passing into your AI system and it usually includes things like uh your golden standard uh cases, your edge cases, your failure modes. Um then once you have your data set, you want to write a task. So, a task defines how you want your AI system to behave when it takes in the input and produces an output. So, concretely this usually includes a system prompt and then the

[03:38] model that you’re picking to execute this task. Then the next thing you need to do is you need to write a scoring system that will tell you whether the AI’s output is good or bad. Um and so usually it’s uh maybe the PM or engineer that is writing the criteria that comprises that goodness and badness. Uh, and you might have heard of terms like uh deterministic scoring, LLM as a judge, human in review. Those are different types of scoring um frameworks. Uh, but yeah, that’s so you write your scoring system.

[04:09] And then the last thing you do, which is the most fun part of writing evals, is you experiment. So, every configuration of a specific data set, a specific task, and a specific scoring system equals to one experiment. And as you are testing out different hypotheses for how to make your system better, you’re tweaking either your data set, your task, or your scoring system, and these all lead to different experiments. So, once you have your different experiments, then you start to compare them. So, you might run experiment one

[04:40] and experiment two, and you can see whether there’s been improvements or regressions. And you can also uh click into specific rows to see exactly which test cases have changed. Uh, this screenshot is from the Braintrust UI. Another thing that you can do is you can use uh natural language to query across your traces and experiments. Um, so for example, you can ask it things like summarize my experiments for me, um highlight the problems in these experiments. Um, I find this especially useful when you’re running experiment or

[05:11] you’re running like um tra- you see traces with like long multi-turn conversations, it’s good for um helping you catch things like hallucination or drift that’s kind of hard to catch manually. Um, you can also if you’re running different experiments, you can ask it like which performance or which experiments performed the best off of out of all of these experiments. Um So, this is another way you can like find patterns in your traces. Um, we also this is using like the UI in Braintrust, but we also have a CLI and

[05:42] MCP server if you prefer to do it that way as well. Um, and then the last pillar of Braintrust is just like regular observability. So, you can basically use the Braintrust SDK to wrap your code um and then uh have your production logs show up in Braintrust and essentially do traditional observability where you can monitor your production logs and create dashboards and things like that. Um, so kind of to tie this together, I’m going to walk you through kind of a flow of how you might use observability and

[06:13] evals to improve your AI system. So, we’re going to start on the top left corner where it says app. So, imagine you have some sort of AI application. Uh in this scenario, I’ll say you have a a new docs page that you just shipped with like an AI chatbot built in so that users can ask questions to your AI chat chatbot about your documentation. So, let’s say you shipped that yesterday. And then you have customers start to use your AI chatbot. So, when they start to hit your AI chatbot, you’re going to start to get real production logs coming

[06:45] into your system. Once you get those production logs, you can uh sample a subset of them, maybe like 10 to 20 rows or something, and create a kind of data set. Uh once you get that data set, then we can run evals on that, right? So, you can you have your data set, you can write your task, and you can write your scoring system, and you can run uh evals on them. And you can start to tweak your data set, you can start to tweak your prompts or you tweak your score and run multiple different evals on that. Once you have your evals like run a couple different evals um and start to see

[07:16] which eval does the best, you might learn something about your system, and then you’re going to go ahead and make your code change or make a change to whatever AI system that you’re using uh and then deploy that back into your application, and then the whole flow repeats again because uh those changes will show up in your production logs and the whole system happens again. So, that’s kind of how the flow works as a whole. Um, the last slide I’ll show before I get into a concrete example is I love this slide because uh conceptually I I

[07:47] want to hammer into people that evals are a team sport. Uh, there’s so much that goes into creating evals uh from getting real-world data into your platform, labeling it, developing hypotheses, things like that. So, the AI engineer kind of works on obviously making the code changes, but also getting the data into the platform. Uh, the product manager is very important. I think they’re they’re usually spearhead evals at a company, but they’re the ones that develop the hypothesis of what success looks like, um and help uh tweak tweak the prompts and things like that.

[08:18] Uh, subject matter experts are really important, especially in like more niche uh areas like um insurance, medicine, law, and things like that. Um, they can help uh label the data or provide a ground truth for what what excellence looks like. Uh, and then data analysts obviously to analyze the data. So, I always think that this slide is is really useful to look at. Okay. So, let’s go into a like interesting real-world example of how you might use an eval. Um, in this one

[08:49] I’m comparing agentic search to vector search. And the story behind this specific eval is um is that my CEO Ankur sometimes goes on Twitter and sends me articles of things he wants me to eval. Uh, so he sent me this uh tweet from Cursor where Cursor talks about how they used semantic search, also known as agentic search, um to significantly improve their coding agent uh performance. And he was like, “Jess, can you eval this for me?” And I was like, “Okay. I’m busy, but okay.” Um,

[09:20] and so I kind of went on Twitter and I saw that there was a lot of uh discourse or discussion around this topic, so I thought it might be interesting to eval. So, uh we’re going to eval a vector search and agentic search, so I just want to give a quick uh summary of what each one is just so everyone’s on the same page. So, vector search essentially is the process of taking uh a data like uh code or text and turning them into embeddings where embeddings basically represent the semantic meaning of that chunk of text or code. So if you look at

[09:50] the graph here, it’s a very good visual example where um the embeddings uh wolf, dog, and cat are very close to each other cuz semantically they all are animals. And then uh the embeddings banana and apple are also close to each other cuz they’re fruit, but then uh they’re far apart from each other because fruit and animals are different things. Um And so what happens is in, you know, um in a real vector search implementation, you would take these embeddings and store them in a vector database. So something like Qdrant or Pinecone or

[10:22] something like that. And if you come up with a query like, uh for example, where does the database logic in my code base live? Uh what would happen is the vector database would return back the chunks of um embeddings that most closely semantically match the words in your query. So the the chunks that are closest to things like database or logic. So that’s how vector search works. Agentic search is slightly different. Agentic search works more like a human would. So essentially with agentic

[10:52] search uh you give an LM tools like uh grep, find, ls, cat, um bash commands. And it basically explores explores your code base like a human would. So it would uh look up a function name, open a file, read the file, follow that function call to another file, then open that file and read that file, and then continue until it’s found what it’s what it needs to. So this is uh much more similar to how a human would kind of go through a code base and and look up look for certain pieces of logic.

[11:23] Okay, so then how did we eval this? So the first part of creating eval is creating our data set, right? So to do this, we basically used uh Microsoft’s TypeScript go repo, uh which is open source. And what we did is we basically found all the PRs, the merged PRs with the title fix in them. And we basically checked out the parent commit. So, essentially, we checked out the commit to the point where it still has the bug in it. And then we used Claude to generate a like a

[11:53] bug task or like a linear task based on the diff. So, based on the diff between the buggy code and the fixed code. And then we fed that into an LLM and had that LLM either use rag search or agentic search to find the buggy code, to locate where the logic, the buggy logic lives. So, that’s how we created our data set. We had like maybe we we found like 20 different PRs and and ran the eval on that. In terms of our task, we actually had to

[12:24] implement vector search and agentic search, obviously. Implementing agentic search was really easy because Claude code uses agentic search by default. So, we just set Claude code on these tasks. Implementing vector search was slightly more complicated because we still wanted to use the Claude code harness to execute the vector search, just to keep the experiment consistent. But we had to basically prevent Claude code from defaulting to agentic search. So, we did two things. The first thing is

[12:54] that we explicitly said in the prompt instructions not to use agentic search. But if you’ve ever done this before, you know that prompting is never enough. So, what we also had to do is use the disallowed tools flag to prevent Claude code from calling certain things that it would normally use in agentic search. So, that’s how we implemented vector search and agentic search, both using the Claude code harness. Another kind of interesting thing that we ran into is when we were trace running the traces,

[13:25] we ran the Claude code runs as sub processes, but it essentially mean meant that the traces were orphaned. Um, and uh, our solution was basically passing the parent span IDs as environment variables. So, if that doesn’t make sense, that’s fine because I’ll show you via pictures. So, this picture that you see here is what the trace looks like when it’s running as a orphaned sub process. So, you can see in the highlighted unlike the left panel where it says run Claude agent. Um,

[13:57] that’s basically in the trace saying, “Okay, it’s running the Claude sub process.” But, you can’t you don’t actually get any visibility into what happens when it’s running that Claude process. With the fix that we did, uh, this is what you see now in the trace. So, you can see that it’s calling the Claude code sub process, but you can also see everything that’s being run in that sub process. So, you can see all the turns, all the LLM calls, every single terminal command that’s being called like grep, bash, ls, find, things like that. Uh, and it gives you visibility into what’s happening in this

[14:28] actual run. Uh, and implementing this fix was really important because being able to have transparency into what’s happening, um, is is important for debugging, uh, later on. And scoring was really simple. Uh, for our scoring we basically said, uh, “Because we’re using Microsoft Microsoft’s TypeScript Go repo, we basically said if the test uh, passed the uh, uh, Microsoft TypeScript Go test suite, then it gets 100% and if it fails it gets a 0%.” So, it was very binary scoring here.

[15:00] Uh, okay. So, in terms of our results, uh, the summary is basically vector search and agentic search both got the same level of accuracy, but essentially vector search cost, uh, four times more than agentic search. So, when we looked at the actual traces and uh, kind of manually like went through to try to understand what happened, we had a couple of learnings. So, the first thing is that vector search returns back chunks of code, but these chunks of code often miss things like imports or tool calls or the

[15:32] calling code above it. And so, as a result, it’s not enough it doesn’t give enough context for how the agent should actually solve the bug. So, one example is in one of the rows we saw that the vector agent made 26 searches and still couldn’t piece together how three functions interacted across the file. In contrast, agentic search was actually able to like as I said, work more like a human would. So, grep the function name, read the full function, spot the flaw in the logic, and then follow the calling

[16:04] calling logic into another file. And the way that I kind of like to think about it when I was just going through the traces, is it felt like vector search gave a lot of proximity to the correct code, but agentic search had more of the connective tissue to connect the actual logic of those chunks of code. And then tying that into the third learning I had is the reason why vector search was so much more expensive than agentic search is because it made more searches because it was

[16:35] constantly searching like returning a chunk of code and then searching again, returning a chunk of code, searching again. And as a result, all of those LLM calls piled up and made it a lot more expensive to execute. And this is the last slide, but essentially you might be sitting here thinking oh there’s so many holes in this eval, which is very fair. Like there’s lots of things I could have done. You know, there’s lots of best practices when it comes to running evals like running multiple trials per task, especially because LLMs are so

[17:06] non-deterministic it’s good to run multiple trials to be able to trust the score that you’re getting back a lot better. My vector search implementation was relatively weak. Uh could have done a better implementation. Um also expanding the data set. Um I think we only ran this on like 20 different rows. So, it would have been better to expand this uh to even different um different repos or things like that. Uh but the the point of this talk is not to create the best uh off like the best eval ever, but it’s

[17:37] more to illustrate to you the concept of the kind of how to create an eval end to end. So, hopefully I’ve done that. Um and that is the end of my talk. Um so, hopefully you learned a little bit of what evals are, why they’re important, and how you might do one in real life. Um and yeah, I think that’s it. So, thank you for listening.