Por que 80% de confiabilidade não é suficiente — Felipe Blanes, Amazon AGI Lab

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 80% Reliability Isn’t Good Enough — Felipe Blanes, Amazon AGI Lab · Canal: AI Engineer · 17:07 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Avaliação e benchmarks de IA

Resumo

Felipe Blanes apresenta o problema das evals estáticas: elas podem ter bons resultados em benchmarks, mas não refletir o que os clientes fazem em produção. Para resolver essa lacuna, propõe um ciclo contínuo que parte das necessidades dos clientes, coleta sinais, diagnostica problemas e transforma os achados em decisões de produto, engenharia e pesquisa. Ele explica que 80% de confiabilidade pode aumentar o trabalho de monitoramento, enquanto a transparência sobre capacidades e limitações ajuda a conquistar confiança. A recomendação final é atualizar as evals continuamente com cenários observados em produção.

Pontos-chave

Benchmarks públicos e dados sintéticos não garantem que um produto funcione para os usos reais dos clientes.
O ciclo de evals começa por definir sucesso segundo os critérios do cliente, não os da equipe.
A coleta de sinais deve combinar instrumentação com conversas diretas com os clientes.
As lacunas identificadas devem ser categorizadas como problemas de modelo, engenharia ou produto.
A jornada do cliente passa por descoberta de casos de uso, experimentação inicial, identificação de padrões e descoberta de lacunas do produto.
Uma confiabilidade de 80% pode exigir monitoramento e intervenção manual, tornando o produto menos útil para o cliente.
Ser transparente sobre o que funciona, o que está sendo melhorado e o que está fora de escopo pode gerar mais confiança do que benchmarks melhores.
Casos de uso reais podem revelar necessidades inesperadas, como cache de trajetórias, experiências para usuários não técnicos e flexibilidade na camada de execução.
As evals devem refletir cenários de produção e evoluir junto com as necessidades dos clientes.

Capítulos

Início	Capítulo	Resumo
00:01	Contexto e o problema das evals estáticas	O palestrante apresenta o trabalho com a Nova e explica por que benchmarks e evals estáticas podem falhar em representar o uso em produção.
04:25	O ciclo de evals baseado no cliente	A proposta é definir sucesso com os clientes, coletar sinais, diagnosticar lacunas e transformar os achados em decisões.
07:38	A jornada dos clientes	O uso do produto revela casos de uso, possibilidades, padrões recorrentes e lacunas que podem orientar o desenvolvimento futuro.
11:00	Confiabilidade, transparência e confiança	A palestra discute o efeito da confiabilidade na disposição de confiar em um produto e a importância de explicitar suas limitações.
14:20	Princípios para manter o ciclo em funcionamento	Os princípios apresentados incluem derivar cenários das situações de produção, categorizar lacunas, ser transparente e acelerar o ciclo de melhoria.
15:59	Evals que evoluem com os clientes	A conclusão reforça que as evals devem refletir as prioridades atuais dos clientes e ser atualizadas conforme seus usos mudam.

Citações

Não se trata de benchmarks melhores. Trata-se de fechar o ciclo com o cliente. — 04:25

Converse com seu cliente: entenda exatamente o que ele está tentando fazer. — 05:27

A transparência sobre as limitações do produto aumenta a confiança mais do que benchmarks melhores. — 12:09

As evals precisam refletir aquilo com que o cliente se importa, não aquilo que você acha que importa para ele. — 15:59

Conceitos e entidades

Felipe Blanes (pessoa): Integrante da equipe técnica do Amazon AGI Lab que apresenta práticas para criar evals alinhadas às necessidades dos clientes.
Amazon AGI Lab (empresa): Laboratório da Amazon onde a equipe desenvolve produtos e agentes, incluindo a ferramenta Nova.
Nova (ferramenta): Ferramenta apresentada como meio de criar agentes de navegador e automatizar tarefas em navegadores web.
eval flywheel (conceito): Ciclo contínuo que usa feedback dos clientes para definir sucesso, identificar lacunas e orientar melhorias nas evals e no produto.
static evals (conceito): Evals fixas que podem deixar de representar os comportamentos e as necessidades encontrados em produção.
benchmark illusion (conceito): A discrepância entre bons resultados em benchmarks e problemas que surgem quando clientes usam o produto em situações reais.
Amazon Leo (empresa): Empresa de internet via satélite da Amazon mencionada como cliente cujas necessidades revelaram oportunidades de otimização de custos.
Hertz (empresa): Empresa de aluguel de carros citada como cliente que ajudou a identificar a necessidade de uma experiência acessível a usuários não técnicos.
RPA (conceito): Sigla de automação robótica de processos, usada na palestra para descrever a atividade da empresa Sol.

Tradução completa (pt-BR)

00:01 [música] Todo mundo consegue me ouvir? Ótimo, perfeito. Primeiro, obrigado a todos por estarem aqui. Meu nome é Filipe e sou membro da equipe técnica do Amazon AGI Lab. Como parte da minha função, ajudo a criar a próxima geração. Gerencio

00:31 os programas para criar a próxima geração de produtos que nosso laboratório está desenvolvendo. Hoje vou falar sobre como projetar evals que conquistam a confiança dos clientes. Antes de falar sobre evals, preciso dar um pouco de contexto sobre o que nosso laboratório fez no ano passado. Tudo começou em março do ano passado, quando lançamos nossa prévia de pesquisa do Nova. Para contextualizar, Nova é uma ferramenta que desenvolvemos como parte do nosso laboratório e que ajuda a criar agentes de navegador. Basicamente, tudo

01:04 o que você faz em um navegador pode ser automatizado usando o Nova. Como parte da prévia de pesquisa, nosso principal objetivo era lançar um produto para receber o máximo possível de feedback dos clientes. Lançamos o produto em março. Depois, em julho, fizemos uma melhoria adicional: desenvolvemos uma experiência de desenvolvimento totalmente nova. Isso porque, nos primeiros meses, percebemos algumas lacunas na experiência de desenvolvimento

01:36 e queríamos garantir que os clientes tivessem a melhor experiência possível ao criar agentes. Então, em dezembro, finalmente lançamos nosso serviço na AWS. Hoje, o Novax é um serviço de primeira linha na AWS que qualquer pessoa pode usar para criar agentes prontos para produção. Durante esse período, fui basicamente responsável pela parte de capacitação dos clientes. Para contextualizar, o que é capacitação dos clientes? Basicamente, eu trabalhava diariamente com todos os nossos clientes para entender quais eram os problemas deles e como poderíamos

02:11 ajudá-los a resolvê-los. Essa foi minha principal função no ano passado. Agora, vamos ao problema que discutiremos hoje. Gosto de chamar isso de ilusão do benchmark. Todos vocês trabalham com IA. Provavelmente estão trabalhando e criando coisas com base em benchmarks, certo? Podem ser benchmarks públicos que todos usam e para os quais todos tentam otimizar os produtos, além de benchmarks que vocês mesmos criam com dados sintéticos

02:45 e usam para avaliar o produto. O principal objetivo aqui é otimizar, certo? Vocês querem ter o melhor desempenho possível nesses benchmarks. Mas, quando lançam o produto em produção e os clientes começam a usá-lo, o que acontece é isto: eles começam a encontrar problemas. Basicamente, tentam fazer tudo aquilo que vocês não esperavam que fizessem e acabam quebrando o produto. Isso acontece porque a maioria de nós está trabalhando com evals estáticas. Nós estamos

03:19 trabalhando com evals estáticas. O que são evals estáticas? Vamos falar um pouco sobre o processo padrão de desenvolvimento de um produto, certo? Primeiro, você recebe os requisitos da sua equipe de produto e começa a desenvolver. Todo mundo faz isso, espero. Depois que o produto está em boas condições, a próxima coisa que você faz é executar suas evals de novo: benchmarks públicos, dados sintéticos que você

03:50 gerou, e otimizar para esses dados. Quando começa a se sentir confortável, você pensa: “Tudo bem, agora vou lançar o produto”, e o lança para os clientes. Mas, se suas evals são estáticas, o que você pode fazer depois disso? Basicamente, só resta ter esperança, certo? Você espera que suas evals tenham refletido exatamente o que os clientes fariam com seu produto. Se não refletiram, o produto começa a falhar. Essa é a lacuna, exatamente o que vamos discutir hoje e o que fizemos no nosso laboratório para resolver esse problema. E

04:25 só para dar um spoiler: isso não é sobre benchmarks melhores. É sobre fechar o ciclo com o cliente. O que queremos que vocês façam é coletar o feedback dos clientes e fechar esse ciclo. Com isso em mente, o que propusemos no nosso laboratório foi um ciclo contínuo de evals. Se vocês não conhecem o termo, um ciclo contínuo é basicamente um ciclo que vocês repetem o tempo todo, e a primeira etapa desse

04:55 processo é definir o sucesso — e isso é muito importante. Definir o sucesso aqui não é definir o que você considera sucesso, mas o que seu cliente considera sucesso. Certo? Então, depois de entender o que seu cliente realmente precisa e qual problema você está tentando resolver, o próximo passo é capturar sinais. E nós, como engenheiros, pensamos primeiro em instrumentação, certo? Vamos coletar métricas e dados

05:27 sobre o que o cliente está fazendo, o máximo possível. Mas há uma parte muito importante que está faltando: você precisa conversar com seu cliente. Converse com ele, agende reuniões, visite-o e entenda exatamente o que está tentando fazer. Seus dados podem ser um pouco enganosos. Talvez você não esteja identificando exatamente qual problema seu cliente está tentando resolver. Na terceira etapa, você diagnostica as lacunas. Isso é fácil. Basicamente, você coleta

05:57 todos esses sinais dos clientes. Pode ser instrumentação, mas também podem ser suas informações e percepções das reuniões que teve com eles. Então, você começa a categorizar esses dados. E, quando falo em categorizar, há três tipos de informação, em alto nível, que você pode encontrar nessas conversas. A primeira são informações sobre seu modelo: em que situações ele está falhando. Isso alimenta as evals do seu modelo. O segundo tipo são informações para sua equipe de engenharia: qual é a lacuna no seu harness

06:31 que vocês deveriam corrigir. Isso é mais parecido com a correção tradicional de bugs. O terceiro tipo diz respeito ao produto. O que está faltando no produto? Por exemplo, será que seus clientes entendem exatamente qual problema seu produto tenta resolver? O produto está posicionado corretamente? Isso é muito importante. Assim que as lacunas estiverem categorizadas, você as encaminha para a tomada de decisões. Encaminhar para a tomada de decisões significa basicamente priorizar essas lacunas e

07:02 pedir às equipes de ciência, engenharia e produto que as resolvam. É simples, certo? Depois, é só continuar repetindo esse ciclo sem parar. Com isso em mente, no nosso laboratório repetimos esse ciclo contínuo várias e várias vezes desde março do ano passado. Outra coisa que percebi ao longo da minha jornada com o produto é que cada cliente tem sua própria jornada ao usar meu produto. O que isso significa? Significa que meu cliente evolui à medida que

07:38 usa meu produto, certo? Há quatro coisas que você pode aprender enquanto seu cliente usa seu produto. A primeira é o que você faz na primeira vez que se encontra com um cliente: descobrir casos de uso. Nessa primeira etapa, você quer entender qual é o problema dele. Qual é o problema do seu cliente? E garantir que o que você está desenvolvendo resolva esse problema. Certo? Depois disso, você terá

08:09 alguns usuários pioneiros, certo? O principal sinal que você quer obter deles é o que é possível fazer. É nessa fase que os clientes tentam coisas malucas. Você vai descobrir coisas com as quais não consegue ajudá-los de jeito nenhum, certo? Mas também vai encontrar coisas que seus clientes estão usando seu produto para resolver. Muitas vezes, você vai se surpreender, porque é algo que nunca imaginaria. O terceiro ponto é quando você começa a escalar, certo? Você tem seus usuários pioneiros, mas agora começa a escalar. Você

08:43 conquista mais clientes e consegue identificar alguns padrões, certo? Quais são esses padrões? Basicamente, são os principais casos de uso: os problemas que todos estão usando seu produto para resolver. O último ponto é mais voltado para o futuro: são as lacunas do seu produto. Ao trabalhar com usuários pioneiros e também depois de começar a escalar, você vai encontrar algumas lacunas no produto. Sua equipe de produto pode ajudar a priorizá-las e

09:18 Essas são as metas para o seu futuro, certo? O que você deve construir em seguida. Como eu disse, trabalho com vários clientes ao longo dessa jornada, e há alguns aprendizados que quero compartilhar. Alguns podem ser óbvios, mas outros são muito, muito esclarecedores. O primeiro é o que gosto de chamar de precipício da confiança. Então, o que é o precipício da confiança? Imagine que você construiu um produto, está pronto para lançá-lo e mede a confiabilidade dele.

09:53 E descobriu que a confiabilidade é de 80%. Parece bom, certo? Você pensa: “Ok, posso entregar isso ao meu cliente e ele pode começar a usar”, certo? Mas, quando você diz ao cliente que a confiabilidade é de 80%, ele pensa: “Não posso confiar neste produto. Não posso confiar.” E por quê? Porque, quando você mostra uma confiabilidade de 80%, o que ele vai pensar é: “Ah, ok, então, se é 80%, eu…

10:25 ainda preciso monitorar este agent. Se ele falhar, vou ter que fazer algum trabalho manual. Então, na verdade, isso dá mais trabalho para mim, não menos. Preciso construir este agent, monitorá-lo e também fazer algum trabalho manual depois. Mas, quando você chega a algo em torno de 90% de confiabilidade, a mensagem para o cliente muda, e ele pensa: “Ok, 90%. Posso realmente confiar nisso para cuidar das minhas tarefas e entregar completamente um workflow ao meu produto.” Então, é

11:00 basicamente uma questão de tudo ou nada: ou você confia, ou não confia. Não existe meio-termo. O segundo aprendizado é a transparência das evals. Sempre que você começa a trabalhar com um cliente, precisa ser transparente sobre três coisas que seu produto faz. A primeira é fácil. Todo mundo gosta de fazer isso: o que funciona. Você basicamente mostra ao cliente: “Sou muito bom nisso.” Esse é o nível

11:34 de confiabilidade. Você pode confiar no meu produto. Basta usar meu agent, e ele oferecerá a confiabilidade de que você precisa. O segundo ponto é: estas são as coisas que estou fazendo para melhorar meu produto. Certo? Há algumas lacunas que conheço, mas estou investindo tempo agora para melhorar isso. E a terceira coisa é a mais difícil. Ninguém quer fazer isso: dizer o que está fora do escopo. Então, você realmente precisa ser transparente. Se algo não funciona no seu produto, simplesmente conte ao cliente. Não deixe que ele tente.

12:09 Caso contrário, há tantas ferramentas no mercado agora que, se você mostrar algo que não funciona, eles simplesmente vão esquecer nosso produto e passar para o próximo. Então, seja transparente. O principal aprendizado aqui é que ser transparente sobre as limitações do produto aumenta a confiança mais do que apresentar benchmarks melhores. É uma descoberta muito interessante, certo? Seja transparente sobre o que seu produto é capaz de fazer e, mais importante, sobre o que não é capaz de fazer. É assim que você conquista a confiança do cliente.

12:43 O terceiro aprendizado é que, se você trabalhar muito de perto com os clientes, poderá encontrar muitos casos de uso que nunca teria imaginado. Um exemplo é a Amazon Leo. É a empresa de internet via satélite da Amazon. Trabalhando com eles, aprendemos algumas coisas sobre a criação de recursos para armazenar em cache trajetórias. Em vez de fazer inference o tempo todo em que usam nosso produto, armazenamos as trajetórias em cache. Se falhar, voltamos para o modelo. Assim,

13:13 otimizamos os custos para eles. O segundo aprendizado veio da Herz, a empresa de aluguel de carros. Eles também estavam usando nosso produto para automação de QA, e aprendemos que, dentro da empresa, havia engenheiros de QA muito técnicos, capazes de criar scripts em Python e em outras linguagens de programação. No entanto, algumas pessoas da equipe de QA não são tão técnicas. Foi essa informação que precisávamos para construir uma

13:47 experiência totalmente não técnica para nosso produto, que permitiria que mais clientes o usassem. O último exemplo é uma startup chamada Sol. A Solar é basicamente uma empresa de RPA. Se você não conhece o termo, RPA significa automação de processos repetitivos, e eles oferecem ferramentas para automatizar processos para outras empresas. Então, imagine a variedade de casos de uso que podem ter. São muitos casos de uso diferentes. E o que aprendemos com eles é que poderíamos oferecer uma flexibilidade adicional

14:20 no nosso produto para que personalizassem especialmente a pilha de atuação da nossa ferramenta. Esses aprendizados são menos importantes do que ter em mente que você vai aprender muito sobre o que seus clientes estão tentando fazer, certo? E sobre quais devem ser os próximos recursos que você vai construir para seu produto. Ao executar esse flywheel várias vezes, chegamos a quatro princípios para ele. O primeiro é derivar cenários de evals

14:54 da produção, não da imaginação. Mais uma vez, criar dados sintéticos pode ser muito importante no início do processo, mas, assim que começar a receber sinais dos clientes, garanta que eles alimentem suas evals. Segundo, categorize em áreas acionáveis. Mais uma vez: problemas de produto, de engenharia e de pesquisa. Garanta que sua equipe os priorize adequadamente. Terceiro, compartilhe com honestidade as capacidades. Mais uma vez, transparência gera confiança. Garanta que você

15:27 compartilhe com o cliente, especialmente aquilo em que seu produto não é bom. O terceiro princípio é executar o flywheel o mais rápido possível. Basicamente, quanto mais rápido você executar esse flywheel, mais rápido seu produto vai melhorar, certo? Isso é quase óbvio, certo? Mas tenha isso em mente: execute seu flywheel o mais rápido possível. E, com esses quatro princípios, você verá que

15:59 suas evals devem ficar mais inteligentes a cada semana. Mas é muito importante: se você não está vendo suas evals ficarem mais inteligentes a cada semana, isso significa que elas estão ficando obsoletas. Certo. Para concluir a apresentação, há duas ideias que quero que vocês levem para casa. Só duas. A primeira é que as evals devem refletir o que importa para o cliente, não o que você acha que importa para ele. Certo? O importante é obter a contribuição do cliente e garantir que suas

16:33 evals reflitam o problema dele. A segunda é que as evals não são feitas uma única vez. São um flywheel que evolui à medida que o cliente evolui. Uma observação: lembre-se da jornada do cliente. À medida que o cliente avança nessa jornada, o que ele está tentando fazer com seu produto também muda. As tarefas vão ficar mais complexas, certo? Então, suas evals precisam estar atualizadas e refletir exatamente o que seu cliente está tentando fazer agora.

17:07 E, com isso, o que você precisa fazer é simplesmente criar o ciclo, lançar o que importa e então conquistar a confiança do cliente. E é tudo o que tenho para hoje. Muito obrigado por participar. Vou ficar no nosso estande depois para conversar mais. Mas, de novo, aproveitem a conferência.

Transcrição original

[00:01] [music] Can everybody hear me? Okay, perfect. So, first thanks for joining everyone. Uh, my name is Filipe and I am a member of technical staff at the Amazon AGI lab. Um, as part of my role, I help us to build the next generation. I manage

[00:31] the programs to build the next generation of products our lab is building. And today I will talk to you about designing evolves that earn customer trust. Before talking about evolves, I just need to give you some context about what our lab was doing the past year. So everything started in March last year where we launched our Nova research preview. for context like Nova is a tool that we build as part of our lab and it’s a tool that helps you to build browser agents. So basically everything

[01:04] that you do in a web browser you can use Nova to automate those tasks. Uh and as part of the research preview our main goal was we wanted to ship a product to get as much feedback as we could from our customers. Uh in March we launched that. Then in July we made one additional improvement in our product which was basically develop a whole new developer experience and this was because basically during the first couple months we noticed like some gaps

[01:36] in the developer experiment experience and we wanted to make sure customer had the best experience building agents. Then in December we finally launched our service on AWS. So today Novax is a top tier service on AWS that anyone can use to build production level agents and during this period I was basically responsible for the customer enablement piece of that. What’s customer enablement just for context? It’s basically I was working daytoday with all of our customers to understand what was their problem and how we were

[02:11] helping them to solve that. So that was my main uh role uh during last year. And then let’s go to uh the problem that we will be discussing today. So I like to call this is the benchmark illusion. So you all working on AI. You are probably working on and building things based on benchmarks, right? It could be public benchmarks that everybody’s using and everybody’s trying to optimize the products on that and also benchmarks that you are creating your own synthetic

[02:45] data that you are creating and you are evaluating your product. Uh and the main goal here is you want to optimize right you want to be the best as you can there in those benchmarks but then when you ship that to production and your customers start using that what happen is it’s this right they start seeing problems and it’s basically everything that you were not expecting them to do they try to do that and they break your product and this is happening because you basically most of us we are doing we are

[03:19] working on evals that that are static. So what are static evals? Basically let’s talk a little bit about what’s the standard development process of a product right first thing that you do you receive uh the requirements from your product chain and you start building right everybody does that I hope then when you have a product in a good shape the next thing that you will do is running your evals again public benchmark synthetic data that you

[03:50] generated and you optimize for that when you start feeling comfortable you’re like okay now I will ship that and you ship that to the customers but if you have a static evals what’s the only thing that you can do after that it’s basically this is hope right you just hope your evals were reflecting exactly what your customers would do with your product and if not it will start failing right and this is the gap this is exactly what we will be discussing today and what we were doing in our lab to solve this problem. And

[04:25] just a spoiler, so this is not about better benchmarks. It’s about closing the customer loop. So what we want you to do here is get the feedback from your customer and close the loop. So with that in mind, what we did in our lab was basically propose an eval flywheel. So if you are not aware about the terminology but flywheel is basically a loop that you keep repeating like all the time and the first step of

[04:55] this evolve is define success and very important here. So define success here it’s not what you think it’s success it’s what your customer think it’s success. Okay. So next step as soon as you understand what your customer really needs and the problem you are trying to solve you go to capture signals and we as engineers what’s the first thing that comes to your mind it’s like instrumentation right let’s get metrics let’s get data

[05:27] as much as you can about what your customer is doing but one very important piece of that that we are missing is you should talk to your customer like talk to your customer go schedule meetings uh visit them and understand exactly what they are trying to do. Your data might be a little bit misleading. You might be missing exactly what’s the problem that your customer is trying to solve. Third step, you go to diagnose gaps. That’s easy. That’s basically you get

[05:57] all these signals from customers. Could be instrumentation but also your inputs, your insights from the meetings that you had with them. And you just start categorizing those. And when I say categorizing there are basically very high level but there are three things that you could find from those discussions. First it’s basically inputs about your model. So where your model is failing there and this feeds into evals right to your model. The the second point it’s inputs to your engineering team. So basically what uh is the gap in

[06:31] your hardness that you should fix. This is more traditional bug fixing. And the third one is also on the product side. So what are you missing in terms of product like do your customer understand exactly what your product is trying to solve? Is your product like properly positioned? So that’s very important. So as soon as you have the gaps di the gaps categorized you just feed that into decisions. So feed that into decisions is basically you prioritize that and you

[07:02] ask your science, your engineering, your product team to address those. That’s basic, right? And then you just continue repeating this loop over and over. So with that in mind, like in our lab, we repeated this flywheel several several times since March last year. And what I also noticed is basically as part of my journey as a product, each of my c each customer will have their own journey using my product. What that means? So my customer evolves as they

[07:38] use my product, right? So there are basically four things that you can learn while your customer use your product. The first one is that’s the first thing that you will do the first time that you meet a customer. It’s basically use case discovery. So what you want to do here at this first step it’s basically understand what’s their problem. So what’s the problem of your customer and make sure what you are building solves that. Right? Then after that you will

[08:09] have couple early adopters. Right? from these early adopters the main signal that you want to get. It’s basically what’s possible. So that’s the time where customer will try crazy things. You will find things that you cannot help them at at all, right? But you will also find things that your customers are using your product to solve and many times you will be surprised because it’s something that you would never imagine. Third point, this is when you start scaling, right? You get your early adopters but now you start scaling. you

[08:43] are getting more customers and you are able to identify some patterns, right? What are the patterns? The pattern is basically your hero use case, right? That’s the case, that’s the problem that everybody is using your product to solve. And last one, this is more future looking, but these are your product gaps. So when you were working with early adopters and also after you start scaling you will also be finding some gaps on your product. Your product team can help you to prioritize those and

[09:18] these are the bats for your future right what you should build next. Um as I said I work with several several customers during this journey and there are a couple learnings that I want to share that some might be obvious but others it’s very very insightful. So the first one is the the trust cliff that I I like to call. So what’s the trust cliff? So imagine you build a product, you are ready to ship and you and you measure the reliability of this product

[09:53] and you found 80% reliability. That seems fine, right? You’re like, okay, I can give that to my customer and they they can start using it, right? But what your customer thinks when you say you are 80% of reliability is I cannot trust this product. I cannot trust. Uh and why? Because when you show 9 80% reliability, what they will think is oh okay so if it’s 80% I

[10:25] still have to monitor this agent. If they fail I will need to do some manual work. So in fact it’s actually more work for me not less work. I need to build this agent plus monitor that and also do some manual work after but when you get to a point around 90% reliability the message changes to your customer and what they think it’s okay 90% I can actually trust this right to handle my tasks and I completely hand over like a workflow to my customer. So it’s

[11:00] basically reliability is a zero to one, right? Or you trust or you don’t. There is nothing like in the middle there. Second learning, it’s the eval transparency. So every time that you start working with a customer, you basically need to be transparent about three things that your product does. First thing is that’s easy. Everybody likes to do that. So what works? So you basically show to your customer I am really good doing this. That’s the level

[11:34] of reliability. You can trust my product. Just use my agent and it will give you the reliability that you need. Second point is these are the things that I’m doing to improve my product. Okay. So there are some things that I know it’s a gap but I am investing time right now to make this better. And the third thing that’s the tough one. Nobody wants to do that that it’s what is out of scope. So you really need to be transparent. Like if something doesn’t work for your product, just go ahead and tell your customer. Don’t let them try.

[12:09] Otherwise, like there are so many tools in the market right now that if you do some if you show something for them that doesn’t work, they will just forget about our product and they will move to the next. So be transparent. And the main learning here is transparent on product limitation increase trust more than higher benchmarks. That’s a very interesting finding, right? Be transparent about what your product is capable of doing and in more important what’s not capable of. That’s how you earn customer trust.

[12:43] Third learning is if you work work very close with customers, you might find a lot of use case that you would never expected. So some examples here is Amazon Leo. It’s the satellite internet satellite company from Amazon. Working with them, we actually learn some inputs uh about creating features to do caching of trajectories. So instead of doing inference all the time that they use our product, we cache trajectories. If it fail, we just fall back to the model. So

[13:13] we optimize the cost for them. Second learning is with Herz, the car rental company. So they were also using our product for QA automation and we learned that as part of their company they had some QA engineers that were very technical and were capable of building like scripts with Python and other coding languages. However, some technical uh some people from QA they are not that technical. So that was the input that we needed to actually build a

[13:47] whole non-technical experience for our product that would enable more customers to use it. Last one, this is a startup called Sol. Solar is basically a RPA company. If you are not familiar with the term, RPA is repetitive process automation and they offer tools to automate process for other companies. So imagine the variety of use cases that they might have. It’s a lot of different use cases. And what we learned from then is we could give some additional

[14:20] flexibility in our product for them to customize especially the actuation stack of our tool. The learnings here are less important than keeping in mind that you will learn a lot about what your customers is trying to do here, right? and what should be the next features you should build for your product and then like running this flywheel several times we came up with four principles for this flywheel. First one is derive eval uh eval

[14:54] scenarios from production not imagination. So again like creating synthetic data might be very important at the beginning of the process but as soon as you start getting customer signals make sure that feeds your eval second categorize into actionable areas. Again product issues, engineering issues, research issues, make sure you prioritize that well to your team. Third one shared capabilities honestly. Again, transparency builds trust. Make sure you

[15:27] share to your customer, especially what your product is not good at. Third one is run the flywheel as fast as you can. So here it’s basically the faster you run that flywheel, faster your product will improve, right? That’s almost obvious, right? But keep it that in mind like run your flywheel as fast as you can. And then like with those four principles what you will see is uh

[15:59] your evals will should get smarter every week. But very important if you are not seeing your evals getting smarter every week that means your evals are getting stale. Okay. And just to finalize the talk here there are two ideas that I want you guys to take home. Just two. So first idea is eval must reflect what customer cares about not what you think they care about. Okay. All about getting customer input here and make sure your

[16:33] evals reflects what’s their problem. Second is evals are not built once. It’s a flywheel that evolves as your customer evolves. One note here, remember that customer journey, as your customer moves through that customer journey, what they are trying to do with your product will also change. Like it will get more complex, right? So your evals needs to be up to date and reflecting exactly what your customer is trying to do right now.

[17:07] And with that what you have to do is simply like build the loop ship evolves that matter and then you earn your customer trust. And that’s all that I have for today. Uh thanks very much for joining. Uh I will stay in our booth after for more discussions. But again enjoy the conference.