Por que é mais difícil do que parece construir uma plataforma de evals — Braintrust

Autoria: AI Engineer · 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: Why Building an Eval Platform Is Harder Than It Looks — Braintrust · Canal: AI Engineer · 17:22 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Engenharia de software com IA

Resumo

Hussein, da Braintrust, explica que plataformas de evals ajudam equipes a desenvolver confiança em agentes antes e depois do deploy, combinando testes e observabilidade. Planilhas são um ponto de partida acessível, mas dificultam análise, colaboração e experimentação à medida que os sistemas crescem. Uma plataforma completa precisa conectar dados de produção a testes offline e lidar com traces volumosos, consultas complexas e diferentes tipos de usuários. O palestrante conclui que construir essas plataformas é um problema de sistemas, e que coding agents podem automatizar partes do ciclo de melhoria, deixando às pessoas a revisão dos resultados.

Pontos-chave

Evals ajudam a reduzir a incerteza sobre o comportamento de agentes antes do deploy; observabilidade acompanha os agentes em produção.
LLMs são não determinísticos: essa flexibilidade amplia suas capacidades, mas também cria riscos de confiabilidade, conformidade e manutenção.
Um sistema básico de evals executa o agente com exemplos de teste, exibe os resultados e permite avaliá-los.
Planilhas e interfaces personalizadas podem ser úteis no início, mas não oferecem facilmente colaboração e análises de longo prazo.
O ciclo de melhoria ideal transforma falhas observadas em produção em novos casos de teste para iteração offline.
Traces de agentes podem conter grandes volumes de dados semiestruturados, o que torna ingestão e consultas em tempo real desafios de infraestrutura.
Uma plataforma precisa atender engenheiros, PMs e especialistas de domínio, além de oferecer controles e permissões.
Coding agents podem localizar traces problemáticos e executar evals; as pessoas revisam os resultados e escolhem o que lançar.

Capítulos

Início	Capítulo	Resumo
00:01	Qualidade de agentes, evals e observabilidade	Hussein apresenta a Braintrust e explica como evals e observabilidade ajudam a desenvolver confiança nos agentes.
03:38	O básico das evals e os limites das planilhas	O palestrante descreve os elementos mínimos de um sistema de evals e por que planilhas são apenas um ponto de partida.
06:49	A evolução das plataformas de evals	A apresentação percorre as etapas que vão de planilhas a interfaces de experimentação e ao ciclo que conecta produção e testes offline.
10:29	Conectar falhas em produção a testes offline	O palestrante detalha como transformar falhas observadas em produção em evals e discute a complexidade de armazenar e consultar traces.
13:10	Um problema de sistemas e novos usuários	A conversa aborda os desafios de consultas, ingestão e estrutura dos dados, além do papel de PMs, especialistas de domínio e coding agents.
16:20	Automação do ciclo de melhoria	Hussein destaca recursos de infraestrutura e explica como coding agents podem sugerir mudanças enquanto as pessoas revisam os resultados.

Citações

Evals importam porque LLMs são, por natureza, não determinísticos. — 02:06

O objetivo das evals é reduzir essa incerteza antes do lançamento. — 03:38

Construir uma plataforma de evals realmente se torna um problema de sistemas. — 13:10

A responsabilidade das pessoas é revisar o resultado. — 16:51

Conceitos e entidades

Braintrust (empresa): Empresa que desenvolve uma plataforma voltada à qualidade de agentes, com recursos de evals e observabilidade.
Hussein (pessoa): Palestrante da Braintrust que apresenta os desafios de construir plataformas de evals.
evals (conceito): Testes usados para avaliar o comportamento de agentes e aumentar a confiança neles antes do deploy.
observability (conceito): Acompanhamento dos agentes em produção para entender interações e detectar problemas.
LLM (conceito): Modelo não determinístico usado como base de raciocínio por agentes, cuja variabilidade pode trazer capacidades e riscos.
BTQL (ferramenta): Camada de abstração criada pela Braintrust para oferecer uma interface de consulta aos dados.
coding agents (conceito): Agentes que podem interagir com código e infraestrutura para localizar traces, executar evals e sugerir melhorias.

Tradução completa (pt-BR)

00:01 [música] >> Obrigado por participarem desta sessão sobre por que é difícil construir plataformas de qualidade de agents. Meu nome é Hussein. Lidero a organização de engenharia de soluções no Oeste para a Braintrust. Passei 15 anos trabalhando com soluções, entre Salesforce e Databricks. Sempre fui apaixonado por tecnologia. Construo computadores desde os 5 anos de idade. Então, tenho um apetite insaciável por tecnologia, que me coloca na vanguarda da IA aqui na Braintrust, meio que…

00:33 …com uma vontade insaciável de tecnologia, o que me deixa na vanguarda da IA aqui na Braintrust. Para aqueles de vocês — sei que alguns estavam na sala mais cedo, quando Jess fez a sessão dela —, vi algumas mãos levantadas quando se falou de evals. Quantos de vocês sabem o que é a Braintrust e o que fazemos como empresa? Podem levantar a mão. Perfeito. Vejo uma ou duas pessoas. Em resumo, a plataforma da Braintrust é focada na qualidade de agents.

01:03 E a ideia central é ajudar as equipes a desenvolver e manter a confiança nos recursos de IA ou nos agents de IA que estão lançando. Há dois pilares fundamentais da qualidade de agents. O primeiro são os evals, sobre os quais falamos mais cedo. Evals são o que você faz antes de seu agent chegar à produção. É quando as equipes fazem experimentos, testam o comportamento e desenvolvem a confiança que desejam ter antes de lançar em produção.

01:34 O segundo pilar é a observabilidade. Observabilidade é quando seu agent já está em produção e interage com usuários reais. Ele cria interações. O objetivo é pegar a hipótese que você formulou no processo de desenvolvimento offline e reforçá-la no cenário de produção por meio de monitoramento contínuo. Evals e observabilidade estão estreitamente relacionados ao mesmo problema. Um acontece…

02:06 …em produção, o outro acontece durante o desenvolvimento, e ambos servem para entender como melhorar a qualidade dos agents. Agora, não vou gastar muito mais tempo aqui. Vou fechar isso. Vamos falar sobre por que estamos aqui: por que os evals são importantes? Sabe, os evals são importantes porque os LLMs, por natureza, são não determinísticos. Eles são altamente variáveis. E é justamente essa variabilidade que os torna tão poderosos.

02:37 Eles conseguem raciocinar em muitos domínios diferentes. Conseguem resolver diferentes tipos de problemas e atender a uma ampla variedade de necessidades dos usuários. Mas essa mesma flexibilidade também cria riscos. Os agents usam LLM como cérebro. E as experiências agênticas estão começando a se tornar a principal forma pela qual os usuários interagem com as empresas. Por isso, as equipes precisam confiar…

03:07 …que seus agents vão se comportar de forma confiável e produzir os resultados esperados. Sem evals, as empresas enfrentam riscos reais. A marca fica em risco quando há comportamentos inconsistentes. Há riscos de conformidade se o agent disser ou fizer algo errado. E há riscos de custo e manutenção se for difícil depurar ou controlar os sistemas, ou se eles não forem confiáveis.

03:38 O objetivo dos evals é reduzir essa incerteza antes do lançamento, para que os clientes tenham uma boa experiência e os agents se comportem como você espera. Então talvez você esteja pensando: “Certo, evals são só uma interface de usuário sobre uma planilha, né?” E acho que devo perguntar ao público. Podem levantar a mão: quantos de vocês já fizeram evals e registraram os resultados em uma planilha? Isso já aconteceu? Certo, vejo uma ou duas pessoas. E não há motivo para vergonha…

04:09 …por isso, aliás. Na verdade, é um bom primeiro passo. O importante é que as equipes reconheçam que esse é um problema real e que precisam de uma forma de entender como os agents se comportam com base em diferentes entradas. No nível mais básico, um sistema de eval testa com base em três tipos de critérios. Primeiro, precisa haver uma forma de executar agents com entradas de teste. Segundo, uma forma de visualizar as saídas ou as…

04:40 …pontuações, mesmo que elas sejam registradas em uma planilha. E, terceiro, um conjunto de entradas de teste ou exemplos que possam acionar o agent. Um exemplo de entrada é qualquer informação necessária para iniciar a execução do agent. Pode ser um prompt, uma solicitação ou um contexto que faça o agent agir. Evals em planilhas não estão errados. No entanto, muitas vezes são o primeiro passo para criar um workflow de evals útil.

05:13 Mas, é claro, como você pode imaginar, há muito mais sob a superfície do que acabamos de falar. E, se os evals fossem só executar o agent, visualizar a saída e avaliá-la em uma planilha, esta palestra já teria terminado. Mas acontece muito mais nos bastidores, ou sob a superfície. Há muitas equipes de apoio que, com o tempo, precisam criar conjuntos de dados melhores, sistemas de pontuação…

05:45 …processos de revisão, ferramentas de depuração e formas de conectar os testes de pré-produção ao comportamento em produção. Vamos abordar alguns desses pontos hoje e, se eu não conseguir falar de algum, podem vir conversar comigo depois. É aqui que as coisas começam a ficar complicadas. A tecnologia subjacente é complexa. Os LLMs não são simplesmente determinísticos. A qualidade dos agents é um problema que envolve várias personas. Não se trata apenas de engenheiros de software e engenheiros de IA. Há…

06:16 …PMs que antes criavam PRDs e agora estão executando evals. Há especialistas no assunto que têm conhecimento do domínio do produto que vocês estão desenvolvendo. E os evals são apenas uma parte do workflow de desenvolvimento e operação. Já se foram os dias em que você desenvolvia uma vez, fazia testes unitários e de regressão, lançava em produção e não pensava mais no assunto. Evals são uma forma de continuar subindo a ladeira em direção a um único objetivo: a qualidade dos agents.

06:49 Então, vamos falar das diferentes etapas das plataformas de evals que observamos. Antes disso, este é o objetivo ideal de muitas equipes. Elas querem criar um ciclo de melhoria: tenho um recurso ou uma aplicação em produção; consigo observar os modos de falha que ocorrem com base nas dimensões que defino; quero conseguir coletar esses modos de falha e criar casos de teste para poder iterar offline, assim…

07:19 …posso melhorar a qualidade do meu agent sem introduzir novas regressões. E você continua iterando ao longo do tempo, porque, assim como no ML clássico, o drift se torna um problema real. A forma como os usuários interagem com seus agents vai mudar com o tempo. A forma como você desenvolve seus agents também vai mudar. Então, como é a fase um? Algumas pessoas levantaram a mão quando falamos de planilhas, e não há motivo para se envergonhar. É por aí que muitas pessoas começam.

07:51 E a configuração básica é bem simples. É um loop com um conjunto de exemplos de entrada e uma forma de executar o agent. Com isso, você pode executar os mesmos exemplos, fazer ajustes e ver como o agent responde com suas saídas ao longo do tempo. A maior vantagem é a acessibilidade e a rapidez. Você pode começar praticamente sem barreiras. Mas os ganhos diminuem bem rápido. Nesta etapa, você está praticamente…

08:21 …apenas documentando. Não dá para fazer experimentos de verdade. Muito menos qualquer tipo de análise ao longo do tempo. Entre as limitações comuns estão a dificuldade de fazer análises, o trabalho manual, o valor da avaliação humana, que é difícil de realizar, a colaboração muito limitada e o fato de que especialistas no domínio geralmente ficam excluídos desse tipo de resultado. Então, mais uma vez, planilhas são um ótimo ponto de partida, mas é difícil desenvolvê-las além disso.

08:54 Então alguém, geralmente um engenheiro de produto, percebe o problema e pensa: “Certo, posso criar uma interface de usuário personalizada e bem feita para ajudar a resolver isso.” Embora possa parecer boa à primeira vista, ela ajuda a incluir as diferentes personas às quais, de outra forma, você não teria acesso. Isso permite que PMs passem a participar do ciclo de evals. Mas a limitação que talvez você tenha…

09:26 …imaginado continua existindo. A documentação e o processo de revisão, embora possam parecer visualmente melhores, ainda dificultam a colaboração. E, embora os ciclos de iteração fiquem mais rápidos, ainda não é fácil para os usuários persistirem esses dados e fazerem análises de longo prazo. Ainda é só uma ferramenta de relatórios. A próxima evolução é: “Ei, quero que meus usuários não técnicos tenham uma interface em que não apenas registrem os resultados, mas também possam fazer experimentos.”

09:58 Quero poder ajustar um system prompt. Quero mudar o modelo subjacente. Quero iterar sobre alguns valores de parâmetros. Assim, conseguir fazer esse tipo de comparação lado a lado se torna a próxima evolução do ciclo de evals que observamos. Mas ainda há uma lacuna principal. E é que os casos de teste usados para fazer esse tipo de comparação…

10:29 ainda é um conjunto selecionado que surge nas suas evals offline. Mas o que acontece em produção? Já fiz minhas iterações aqui. Tenho uma boa ideia do que posso esperar que aconteça em produção, mas, depois que faço o deploy, fico às cegas. Então, não faço ideia de quais etapas meu agent está executando nem quando essas falhas estão realmente acontecendo no meu ambiente em produção. E, voltando ao flywheel, quando pensamos nos melhores sistemas que permitem isso,

11:01 bem, você deveria conseguir começar pelo início, observar os modos de falha, registrar cada entrada, saída e cada etapa da execução do rastreamento que seu agent realiza, analisar e entender o que deu errado. Você cria as dimensões de falha e sucesso porque conhece os resultados. Depois, reúne esses modos de falha, os diferentes cenários em que seus usuários tiveram interações ruins, e cria evals com eles no seu processo offline, iterando sobre eles para poder fazer melhorias sem criar novas

11:33 regressões. E então faz o deploy em produção e vai melhorando com base nisso. E, pensando no resultado final, bem, você tem equipes construindo o flywheel. Todo esse ciclo de desenvolvimento fica dentro da sua plataforma, mas aí surge o problema: você precisa mantê-la. Você é responsável pelo produto que criou. E isso é especialmente fácil de fazer em pequena escala ou em ambientes de POC e

12:06 demonstração. Mas os rastros de agents são complicados. São JSON semiestruturados. Em alguns casos, vemos equipes registrando o equivalente a um filme inteiro de dados em cada interação: centenas de megabytes. Então, consultar esse tipo de dado pode ser difícil. E os data warehouses em nuvem típicos acabam não dando conta desse volume e dessa carga. Esse foi o mesmo problema que encontramos. Não vou gastar muito tempo falando

12:37 sobre a Braintrust, mas, quando os rastros de produção chegam, você quer poder consultar esses dados em tempo real, à medida que são recebidos. Porque, se seus usuários estiverem tendo experiências ruins, você vai querer saber em tempo real o que está acontecendo, por que estão tendo essas experiências ruins e como resolver isso o mais rápido possível. Você também quer poder executar consultas de longa duração. Se pensar em ajustar a experiência do seu agent ou até mesmo em ter pessoas fazendo alinhamento ao anotar os resultados dos seus juízes. São duas cargas de trabalho diferentes. Então, criamos uma camada de abstração chamada BTQL, que é mais uma fonte de complexidade, porque você quer uma interface que permita às pessoas consultar esses dados. Portanto, não se trata necessariamente apenas de um problema de UI ou UX: criar uma plataforma de evals realmente se torna um

13:10 fazer alinhamento anotando os resultados dos seus avaliadores. São duas cargas de trabalho diferentes. Então, criamos uma camada de abstração chamada BTQL, que é outra forma de complexidade, porque você quer uma interface que permita às pessoas consultar esses dados. Portanto, não é necessariamente apenas um problema de UI ou UX, mas construir uma plataforma de evals realmente se torna uma questão de sistemas

13:40 problema de sistemas. E surgiram novas questões com a explosão do ChatGPT, alguns anos atrás: preciso fazer ingestão em tempo real; tenho cargas úteis enormes, às vezes com dezenas ou centenas de megabytes, em comparação com a observabilidade tradicional de sinais periódicos, que têm apenas alguns kilobytes. A estrutura e o formato dos dados são diferentes. Ter texto completo semiestruturado e profundamente aninhado

14:12 é difícil de consultar, e os padrões de leitura também são diferentes. Você quer poder agregar grandes volumes, mas também criar snapshots de dados em determinado momento. E criar o sistema certo deve permitir capacitar não só o engenheiro de IA, mas também os PMs e os especialistas no assunto. Mais recentemente, vimos que os agents se tornaram

14:43 elementos de primeira classe dessas plataformas de evals: você quer poder usar linguagem natural em uma experiência sem interface, na qual possa dizer ao coding agent de sua preferência: “Encontre todos os rastros das últimas 24 horas em que o usuário teve uma experiência ruim. Execute as evals para mim.” E, como esses coding agents têm acesso a toda a sua infraestrutura e à sua base de código, eles se tornam o mecanismo para executar as evals e registrar os resultados.

15:16 E aí a pergunta passa a ser: e daí? Por que isso é importante? Bem, tudo o que mostrei até agora exige que as pessoas — o engenheiro, o PM — estejam profundamente envolvidas nesse processo, que às vezes pode ser trabalhoso. Na Braintrust, pensamos nisso da seguinte forma: queremos ajudar você a operar em escala.

15:46 Em vez de você ter que pensar nessas dimensões de sucesso e falha do seu agent de IA, a Braintrust pode revelar esses insights automaticamente. Como registramos os dados dos seus rastros na nossa plataforma, podemos executar inference sobre eles e mostrar o que você não sabia que desconhecia. Por exemplo: em quais cenários meu agent está falhando silenciosamente? Ou em quais cenários meus usuários estão ficando frustrados por pedir a mesma coisa ao meu agent repetidas vezes?

16:20 E há muitas coisas sobre as quais não falamos. Coisas como o banco de dados subjacente que dá suporte à plataforma, ou ter que criar o backend no sistema para gerenciar controles e permissões, ou mascaramento de dados. Cada um desses recursos mostra que não se trata apenas de uma UI e de uma planilha, mas sim de um problema de sistemas que dá suporte à plataforma. E, quando pensamos na evolução do ciclo de melhoria, mencionei antes que eram as pessoas que faziam esse ciclo e agora vemos coding

16:51 agents que podem fazer mudanças iterativamente e sugerir que tipo de melhorias você deveria fazer na sua aplicação. E, no fim, a responsabilidade das pessoas é revisar o resultado. Se eu tiver diferentes iterações dessas evals executadas pelo meu coding agent, posso analisar o resultado e decidir qual versão é a melhor para o que quero colocar em produção. Então, com isso, chego ao fim da minha

17:22 apresentação. Agradeço a todos por terem vindo e aprendido por que é difícil criar sistemas de evals. Obrigado. >> [música]

Transcrição original

[00:01] [music] >> Thank you for joining this session on why building agent quality platforms is hard. My name’s Hussein. I lead the solution engineering organization on the West for Braintrust. Um, I spent 15 years in solutions between Salesforce and Databricks. I’ve been a lifelong technologist. I’ve built computers since I was 5 years old. So, I have this like

[00:33] insatiable appetite for technology, which finds me kind of on the bleeding edge of AI here at Braintrust. For those of you, I know some of you were in the room earlier when Jess did her session. I saw some hands about evals. How many of you know what Braintrust is and what we do as a company? Just show of hands. Perfect. I see one or two. So, at a glance, Braintrust as a platform is focused around agent quality.

[01:03] And the core idea is helping teams build and maintain confidence with the AI features or the AI agents that they’re shipping. And there are two key pillars of agent quality. The first is evals, which we talked about earlier. Evals is what you do before your agent reaches production. This is when teams experiment, they test the behavior, and they build the confidence that they want to have before they ship to production.

[01:34] The second pillar is observability. Observability is once your agent is in production and is interfacing with real-life users. It’s creating interactions. And the goal is to take that hypothesis that you built in your offline development process and then reinforce that in your production scenario through continuous monitoring. Evals and observability are closely related to the same problem. One happens

[02:06] in production, the other one happens in development, and both is the understanding to improve agent quality. Now, I won’t spend much more time here. Let me close that. Let’s talk about why we’re here, which is why are evals important? You know, evals matter because LLMs by nature are non-deterministic. They are highly variable. That variability is exactly what makes

[02:37] them so powerful. They can reason across many different domains. They can solve different kinds of problems, and they can handle a wide range of user needs. But that same flexibility also creates risk. Agents use LLM as their brain. And agentic experiences are starting to become the primary way in which users will interact with companies. So teams need confidence

[03:07] in their agents that they will behave reliably and produce the outcomes that they expect. And without evals, companies face real risks. Brand Brands become a risk if there’s inconsistent behaviors. Compliance if the agent says or does the wrong thing. And there’s a cost and maintenance risk if the systems are hard or unreliable to debug or control.

[03:38] The goal of evals is to reduce that uncertainty before launch so that customers have a good experience and the agents behave the way that you expect them to. So you might be thinking, “Okay, well, Evals is just a UI on a spreadsheet, right?” And I guess I should ask the audience. Just show of hands, how many of you have run Evals and logged the results into a spreadsheet? Has that happened? Okay, I see one or two. So, there’s no shame in

[04:09] that, by the way. It’s actually the a good first step. The important thing is that teams acknowledge that this is a real problem and they need a way to understand how agents behave based on different inputs. At the simplest level, an eval system tests against or it has three different kind of criteria. It has a way to execute agents against test inputs. Second, a way to view the outputs or the

[04:40] scores, even if those are being logged in a spreadsheet. And third, a set of test inputs or examples that can invoke the agent. An input example is whatever information is needed to start the agent run. It could be a prompt, a request, or context that causes the agent to act. Now, spreadsheet-based Evals are not wrong. However, they’re often the first step for a useful version of eval workflow.

[05:13] But, of course, as you can imagine, there’s more to the iceberg than just what we just talked about. And if Evals were only, you know, run the agent, view the output, and then score it in a spreadsheet, this talk would be over right now. But, there’s a lot more that happens behind the scenes or underneath the iceberg. There are many supporting teams that eventually need to build better data sets, scoring systems,

[05:45] review process, debugging tools, and the way to connect pre-production testing with production behavior. We’ll touch on some of these today, and anything I don’t get to, you feel free to come up afterwards and we can chat about. And this is where things start to get complicated. The underlying technology is complex. LLMs are not simply deterministic. Agent quality is a multi-persona problem. It’s not just software engineers and AI engineers. There are

[06:16] PMs who used to build PRDs that are now running evals. There are SMEs who have the domain expertise of the product that you’re building. And evals themselves are just one part of the development and operating workflow. And gone are the days where you build once with unit tests and regression tests, you ship to production, and you don’t think about it. Evals are a way for you to continue hill climbing against one target, which is agent quality.

[06:49] So, let’s talk about the different stages of the the eval platforms that we see. And before we do that, this is the North Star for many teams. They want to build the improvement loop, which is I have a feature or application that’s in production. I can observe the failure modes that happen based on dimensions that I define. I want to be able to grab those failure modes and create test cases so that I can iterate offline, so

[07:19] I can improve my agent quality without introducing new regressions. And then you continue iterating over time, because just like in classical ML, drift becomes a real thing. The way users interact with your agents will change over time. The way you build your agents will change over time. So, what What phase one look like? There were some hands that were raised around spreadsheets and it is not There’s nothing to be shameful about. This is where many people start.

[07:51] And as the basic setup is pretty simple. It’s a four loop with a set of input examples and a way to execute the agent. And with that, you can run the same examples that you tweak and see how the agent responds with the outputs over time. The big biggest advantage is accessibility and time. You can start this with basically zero barrier to entry. But the the returns diminish pretty quickly. At this stage, you’re pretty

[08:21] much only documenting. You can’t really do true experimentation. And let alone do any kind of type of analysis over time. Common limitations are analytics are hard, they’re manual, human scoring is valuable but difficult to do, collaboration is very weak, and domain experts are usually boxed out of these type of results. So, again, spreadsheets are a great starting place but difficult to evolve.

[08:54] Then someone, usually a product engineer, you know, they see this problem and they think, “Okay, I can build a nice UI, a bespoke UI to help serve to solve this problem.” And while it might be nice at a glance, um it helps you bring in the different personas that you would otherwise not have access to. This allows PMs to now kind of get into the loop of doing evals. But the limitation that you might have

[09:26] thought about, it continues. That the documentation, the review process, though it might visually look nicer, still collaboration becomes difficult. And though iteration cycles become quicker, it is still not easy for users to persist that data and do long horizon analytics on. Still just a reporting tool. Then the next evolution becomes hey, I want my non-technical users to have an

[09:58] interface where not that they just log the results, but they should be able to experiment. I want to be able to tweak a system prompt. I want to change the underlying model. I want to iterate on some parameter values. So, being able to do this type of side-by-side comparison becomes the next evolution of the eval cycle that we see. But, there’s still one primary gap. And that is that the test cases in which you use to do these kind of comparisons are

[10:29] still a curated set that arise in your offline evals. But, what happens in production? I’ve done my iterations here. I have a good idea of what I can expect to happen in prod, but once I ship it to production, I’m operating in the blind. So, I have no idea what steps my agent is taking and when those failures are actually happening in my live environment. And when we think kind of going back to the flywheel, when we think about what are the best systems that enable this,

[11:01] well, you should be able to starting at the top observe the failure modes, log every input, output, every step of your trace execution that your agent takes, analyze, understand what went wrong. You create the dimensions of failure and success because you know the outcomes. Then grabbing those failure modes, those different scenarios where your users had poor interactions, and creating evals in them in your offline process, iterating on them so you can create the improvements without developing new

[11:33] regressions. And then shipping to production and hill climbing against this. And when you think about the final outcome of this, well, you get teams that are building the flywheel. You get that entire development cycle inside of your platform, but then the problem becomes you have to have you have to maintain it. You own this this product that you’ve built. And especially this is easy to do when it comes to smaller scale or POC and

[12:06] demo environments. But agent traces are nasty. They are semi-structured JSON. In some cases we see teams that are logging a movie’s worth of data in each interaction, hundreds of megabytes. So being able to query that type of data can be difficult. And your typical cloud data warehouses kind of collapse under this type of volume and load. And this is the same problem that we ran into. I won’t spend much time talking

[12:37] about Brain Trust, but when you have production traces coming in, you want to be able to query that data in real time as it lands in there. Because if your users are having poor experiences, you want to be able to know in real time what is happening, why are they having these poor experiences, and how can I remedy that as soon as possible. You also want to be able to do long-running queries. If you think about being able to fine-tune your your agent experience or even have humans who are

[13:10] doing alignment by annotating your your judges’ outcomes. Two different workloads. So we built an abstraction layer called BTQL, which is a another form of complexity because you want an interface for people to be able to query that data. So, it’s not necessarily that it’s just a UI or UX problem, but building an eval platform truly becomes a systems

[13:40] problem. And there are novel set of issues when the chat GPT boom happened a few years ago where I need to do real-time ingest. I have huge payloads that are tens of megabytes, hundreds of megabytes in size sometimes, compared to traditional heartbeat observability, which are just kilobytes in size. The structure and the shape of the data is different. Having deeply nested semi-structured

[14:12] full text is difficult to query, and the read patterns are different as well. You want to be able to aggregate in large volumes, but also be able to do snapshots of of of in-time data. And building the right system should allow you to not only empower the AI engineer, but also the PMs, as well as the SMEs. And more recently, we’ve seen that agents have become a

[14:43] first-class citizen of these eval platforms where you want to be able to use natural language in a headless experience where you can tell your coding agent of choice, “Find me all traces in the last 24 hours where the user had a poor experience. Run the evals for me.” And because these coding agents have access to all of your underlying infrastructure and your code base, they become the mechanism to run the evals and log those results.

[15:16] And then it becomes a question of like, so so what? Why is this a Why is this important? Well, the goal is everything that I’ve shown you so far, it requires the humans, the the engineer, the PM to be deeply involved in this process and it could be laborious at times. I BrainTrust, the way we think about this is we want to help you operate at scale.

[15:46] Rather than you having to think about these dimensions and of success and failure for your AI agent, BrainTrust can surface these insights automatically. Because we log your tracing data into our platform, we can run inference on them and we can tell you the unknown unknowns. Hey, what are what are scenarios and when my agent is failing silently or what are scenarios that my users are experiencing frustration by prompting my agent for the same request over and over again.

[16:20] And it’s a lot of things that we didn’t talk about. Things like the underlying database that powers it or having to build our back into the system to manage controls and permissions or data masking. You know, each one of these features proves that this is not just a UI and a spreadsheet, but rather it is a a systems problem that powers it. And as we think about the evolution of of the improvement loop, I said this earlier where humans were doing the improvement loop and now we see coding

[16:51] agents where they could iteratively make changes and suggest what kind of improvements you should be making to your application. And ultimately, the humans responsibility is to review the outcome. If I have different iterations of these e-vals that are run by my coding agent, I can look at the outcome and make the decision of which version of it is the best for what I want to ship to production. So, with that, that is the end of my

[17:22] talk. I appreciate you all coming out and learning about why it’s hard to build eval systems. Thank you. >> [music]