Decision Models para evals: testei a API da OpenAI

Autoria: Ronnald Hawk | Engenharia de IA · 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: Decision Models para Evals: Testei a API da OpenAI · Canal: Ronnald Hawk | Engenharia de IA · 16:38 · Assistir no YouTube

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

Resumo

O vídeo apresenta um experimento que compara o uso de decision models da OpenAI e da Cloudflare com uma abordagem de eval baseada em um LLM como juiz. O teste usa uma pergunta real feita a um agente, uma resposta de referência e uma rubrica desenvolvida com conhecimento do negócio. Os resultados indicam que é possível adaptar a rubrica para a API de decisão, mas os thresholds precisam ser calibrados e a resposta da API oferece menos transparência sobre o motivo da decisão. O autor também relata que prompt caching tornou a abordagem convencional mais barata em seu caso e defende que profissionais entendam as técnicas, em vez de seguir tendências sem análise.

Pontos-chave

O experimento avalia uma resposta real de um agente com uma resposta de referência e uma rubrica.
A rubrica deve refletir critérios de negócio e pode precisar de ajustes para se adequar à API de decisão.
Evals exigem calibração; o threshold de uma abordagem não pode ser transferido automaticamente para outra.
O score da decision API não equivale à probabilidade ou ao resultado de um eval convencional.
A abordagem convencional pode explicar como o juiz chegou a uma pontuação, o que ajuda a identificar problemas no agente, no dataset ou na rubrica.
A decision API oferece uma resposta mais rápida, mas, no experimento, não revelou a justificativa da decisão.
O uso de prompt caching reduziu o custo da abordagem convencional no caso apresentado.
A escolha da ferramenta deve considerar as necessidades do projeto, incluindo custo, velocidade e capacidade de depuração.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação dos decision models	O autor contextualiza os lançamentos da OpenAI e da Cloudflare e propõe testar decision models em evals.
03:03	Como funciona a avaliação	O vídeo explica como respostas do agente, referências e rubricas são reunidas para avaliar um caso real.
07:12	Rubrica, calibração e adaptação	O autor destaca a necessidade de testar respostas aprovadas e rejeitadas e adaptar a rubrica à saída da decision API.
10:19	Resultados e comparação de thresholds	O experimento compara os resultados das abordagens e mostra que seus thresholds não são diretamente equivalentes.
13:29	Transparência e depuração	O autor compara a justificativa oferecida pelo juiz convencional com a saída menos explicativa da decision API.
15:33	Custos e conclusão	O autor relata a economia obtida com prompt caching e conclui que a escolha deve ser guiada por análise e domínio técnico.

Citações

Não terceirize sua mente; é tudo o que você tem. — 00:30

Evals não são algo que você faz uma vez e pronto: é preciso calibrar. — 08:15

Às vezes o problema está no agente, mas às vezes está no dataset ou na rubrica. — 14:00

Você vai confiar no número; não terá como depurá-lo. — 15:03

Não deixe que controlem sua mente. — 16:05

Conceitos e entidades

Decision Models (conceito): Modelos ou APIs voltados a tomar decisões estruturadas, avaliados no vídeo como uma alternativa para executar evals.
OpenAI (empresa): Empresa cuja API de decisão é testada no experimento.
Cloudflare (empresa): Empresa mencionada por ter lançado um decision model e explicado sua implementação em um blog.
Qwen (modelo): Família de modelos citada como base de uma solução personalizada usada para produzir saídas estruturadas.
evals (conceito): Avaliações sistemáticas usadas para medir se as respostas de um agente atendem a critérios definidos.
rubrica (conceito): Conjunto de critérios que orienta a avaliação de uma resposta e ajuda a padronizar o julgamento.
LLM as a judge (conceito): Abordagem em que um LLM avalia respostas com base em referências e critérios fornecidos.
prompt caching (conceito): Técnica mencionada pelo autor como forma de reduzir o custo da abordagem convencional no experimento.
Rock Pro (empresa): Plataforma brasileira de engenharia citada como patrocinadora do vídeo.

Tradução completa (pt-BR)

00:00 Esta foi uma semana terrível para os fãs de Jeff Bezos. Isso porque a OpenAI lançou a Decisions API, baseada em um LLM, o GPT-6 Luna. E a Cloudflare lançou seu decision model. Isso é ainda mais interessante para nossa análise aqui, porque eles explicaram no blog como fizeram isso e usaram o Qwen 27B e o Qwen 9B personalizados para obter aquela saída estruturada e tudo mais.

00:30 Por que isso é importante? Isso nos revela que o imperador está nu. Como mostrei no vídeo anterior, podemos adotar uma nova tecnologia, mas, se não entendermos como ela funciona, sempre seremos influenciados pelo hype, acreditando que uma tecnologia vai substituir nosso entendimento. Não terceirizem o pensamento, pessoal; é tudo o que vocês têm. Mas um dos casos de uso que podem ser interessantes em Decision Modeling, e que eu gostaria de testar, são os evals. E, neste vídeo, vou mostrar um

01:01 eval, não um eval hipotético de um agent hipotético que supostamente funciona. Vou mostrar um eval real de um agent que centenas de pessoas usam toda semana. Vou pegar o que existe hoje, a técnica que uso hoje, e aplicar essa técnica ao decision model e usá-la com ele. Depois, ao longo do vídeo, vamos ver os resultados. Espero que vocês consigam analisar e, então, o que fazemos na engenharia? Usamos a melhor ferramenta para cada trabalho. Não viramos fãs de A ou B só porque isso muda tudo. Antes de

01:31 entrarmos no vídeo, vamos falar do patrocinador de hoje. A Rock Pro é a melhor plataforma de engenharia do Brasil. É lá que estão os profissionais. Então, vamos lá? Decision model para evals. Vou apresentar um experimento que fiz. É literalmente um estudo. E vamos ver as conclusões que tiramos desse estudo. E em que se baseia o G? Baseia-se neste aqui, neste agent que temos online. E é exatamente essa questão que vamos analisar, certo? Certo, meu agent se lembra da conversa atual, mas deixa passar fatos importantes

02:03 etc. Por que estou mostrando isso aqui? Porque isso está literalmente no meu eval, certo? Esta é uma pergunta que criei no eval. Vou mostrar o que é um eval. Se você não conhece esses termos, tudo bem. Mas é isso que a indústria faz no mundo real, certo? Não é especulação. É o que aplico tanto na Rock Pro quanto com meus clientes, e é o que o mundo inteiro faz para melhorar suas soluções, entende? Então, se sua solução tem um problema, provavelmente não funciona tão bem e corre o risco de ser assim também, certo?

02:33 Então, vamos lá. Muito bem, tivemos o lançamento do Cloudflare, da OpenAI, como mencionei aqui. Recomendo que você dê uma olhada no blog se tiver interesse, mas o importante é que as duas APIs são muito parecidas com o Jev que conhecíamos, certo? No entanto, a OpenAI mudou o nome aqui; chamou isso de “predicate”. As outras duas são iguais, então é só para referência, certo? Mas a ideia é exatamente a mesma. Você coloca algo no

03:03 contexto, e ele gera uma resposta. A principal diferença entre esses dois modelos é que eles são multimodais, ou melhor, aceitam imagens. Assim, você também pode tomar decisões com imagens, o que pode ser interessante, certo? Para seu caso de uso, o modelo da Cloudflare tem 64K de contexto, então você pode enviar uma quantidade um pouco maior. Se não me engano, o Jev tinha 32, o que limita bastante a solução que você pode implementar, mas o modelo da OpenAI é mais interessante para eval porque tem uma context window como a de um modelo normal. Então, a context

03:35 window é bem grande, e podemos explorar isso no eval. Como o contexto costuma ser grande no eval, ele vai analisar várias coisas: vai analisar a entrada do usuário e, em muitos casos, o documento recuperado. Neste caso, vamos avaliar uma regra. É importante termos uma context window um pouco mais ampla para ver o resultado. Certo? Muito bem. Você já sabe o que vamos fazer aqui. Deixe-me explicar como isso funciona, certo? Como funciona um julgamento, como funciona um

04:05 eval? Você terá a resposta gerada pelo agent. Então, vim aqui à Rock Pro, certo? Temos a pergunta, a resposta gerada pelo agent e, aqui, a resposta dele, certo? O que ele fez. E teremos uma referência do que seria a resposta correta. Então, se alguém fizesse esta pergunta específica, como deveria ser a resposta? Essa é a referência. E teremos uma rubrica que vai avaliá-la. Se você pensar em pedir a uma pessoa para avaliar, teria a regra, certo? Ah, de acordo com isto, é aquilo, e assim por diante. Por exemplo, se alguém fosse avaliar a prova do ENEM. Imagino que tenham uma rubrica. É exatamente isso. Você envia todas essas informações a um avaliador, e ele diz: “Ah, não, este caso foi aprovado, este caso está mais ou menos, este caso está bom, este caso está ruim”. É basicamente disso que estamos falando. Então, vamos ao nosso notebook para entender como isso está configurado. Vamos lá, certo? O que temos aqui? É exatamente aquela pergunta que mostrei antes, certo? Meu agent se lembra da conversa atual, mas perde fatos importantes quando a tradução muda, e depois

04:36 a sumarização muda, certo? O que devo estudar? Este é um caso clássico de um estudante, uma pessoa tentando entender seu problema e encontrar o material para resolvê-lo. E, sim, já temos uma resposta aqui, certo? O que estou mostrando é depois do fato, certo? Depois do estudo. Certo? Esta é a resposta completa que o agent deu, certo? Obviamente, como estamos lidando com LLMs, a mesma pergunta não vai gerar exatamente a mesma resposta. Então, o que fazemos não é avaliar letra por letra, certo? Avaliamos

05:07 o contexto geral da resposta, e é por isso que o critério é importante. Você vê aqui que ele respondeu; a resposta é bem longa, está tudo ótimo, certo? Qual é o critério? Como isso seria resolvido? Está aqui: neste caso, o agent deve consultar minha regra para a fase dois, etc., etc. Então, o contexto que o avaliador precisa conhecer é este: fase dois, aula 10. Se meu agent não incluir isso na resposta, está errado. Isso não significa que, se ele também mencionar outra coisa — mencionar este material e talvez este outro material aqui que ajude você —, estará errado. Certo?

05:38 Esse é o critério que desenvolvi. E como geramos esse critério? Com conhecimento do negócio. Pela seguinte razão: como fui eu quem gravou a aula, criou o agent e criou o eval, é muito fácil para mim, porque sei o que quero transmitir e sei o que meu agent deve responder, pois, ao mesmo tempo que sou desenvolvedor, também sou parte interessada. Se você trabalha em uma empresa, a avaliação dos critérios para a pergunta do usuário, os critérios de avaliação e a rubrica são feitos em conjunto com a área de negócio.

06:09 Recomendo que você veja meu vídeo anterior, em que falo sobre como deve entender que sua profissão está totalmente entrelaçada com o negócio. Não existe IA e negócio; existe uma coisa só, certo? E a rubrica segue exatamente essa mesma lógica. Você vai criar uma rubrica, certo? Esse é o padrão. O padrão, certo? Isso não é algo que estou inventando, é? É algo que inventei. Você vai criar uma rubrica que fará a avaliação. E dá para fazer eval sem rubrica

06:41 mas será difícil padronizar. Então, é altamente recomendável que você faça uma anotação, certo? E então vamos começar a fazer anotações, certo? Uso uma técnica chamada eval, que não é o tema deste vídeo, certo? É uma técnica conhecida no mundo todo, não é uma invenção. E, dentro dessa métrica, tenho valor, certo? Mas quero mostrar isto aqui. Ao fazer eval,

07:12 isso não significa que a resposta seja

07:43 inadequado, significa que está incorreto. Porque, em evals, muitas vezes você quer forçar uma resposta errada para ver se a sua avaliação também está correta. Então, você testa se ela é aprovada e também se é rejeitada. É preciso ter isso em mente, certo? E é exatamente isso que estamos fazendo. Aqui no nosso Bravissimo, vamos voltar ao nosso notebook. Ele está no nosso Bravissimo EVAL, certo? Então, ele fez tudo corretamente, falhou, e temos uma linha de base. E aqui vem uma parte interessante sobre

08:15 decision models e a própria avaliação, porque, como há uma probabilidade de algo estar certo ou errado, você precisa calibrar. E esse é um dos fatores mais importantes quando fazemos avaliações. Uma avaliação não é algo que você faz uma vez e pronto, funciona. Com avaliações, você vai passar um tempo calibrando. E isso é extremamente importante para o que vou falar daqui em diante sobre decision models. Para usar o decision model, preciso fazer ajustes porque, como ele tem uma saída um pouco diferente da saída do G-Eval,

08:45 não posso simplesmente usar minha rubrica como está, nem meu conjunto de testes como está, para usar o decision model. Então, no meu experimento, tentei adaptar essas saídas para um formato que fosse bom o bastante para avaliar se o modelo seria adequado para ser usado como avaliação. O modelo não está pronto para ser usado diretamente em avaliações, então precisamos fazer uma adaptação. E, quando digo avaliação, quero dizer avaliação feita por LLMs, certo? Muito bem.

09:17 E, chegando a essa conclusão, acredito que as duas melhores oportunidades aqui estão em predicate e score. E foi exatamente isso que fiz no experimento. Deixe eu mostrar, certo? No primeiro caso, a probabilidade de estar correto era exatamente zero, então a resposta foi rejeitada, como eu esperava. Mas aqui perdemos um pouco de nuance, certo? E não sei exatamente o que aconteceu. No outro caso, o score é bom porque fornece uma distribuição de probabilidade, certo? Então, transformei minha rubrica em cada uma dessas probabilidades e, no fim,

09:48 só estou incluindo os casos que seriam aprovados. Nesse caso, deu 8 e foi excluído porque eu estava fazendo algo com 5. Esse é basicamente o experimento. Então, consigo aplicar minha rubrica ou minha avaliação ao processo de tomada de decisão da API? Sim, consigo. Mas agora vou mostrar os resultados. E aí fica interessante, por esse motivo, certo? Vamos lá. Executando o G-Eval, certo? Então, é exatamente aquela pergunta ali, é

10:19 exatamente aquela rubrica, é exatamente o meu juiz, certo? Está dentro do meu G-Eval. E aqui estou usando um limiar de 0,7, ou seja, 70%, se preferir pensar assim, e ele foi aprovado. Então, em todas essas rodadas aqui, aprovei esse cara 15 vezes, certo? 15 vezes em 17 respostas. E executei isso aqui várias vezes. Ele passou em todas, certo? Sim, usando predicate. Usei as mesmas técnicas e funcionou. Então, pelo menos para mim, essa portabilidade indica aqui que funciona, certo?

10:50 Então, este é o experimento. Parece que a portabilidade funcionou, o que é bom para nós, certo? Mas aqui no score, o que eu fiz, certo? Ah, certo. Usei os limiares de 0,5 e 0,7, certo? Aqui no predicate, certo? Por quê? Esse limiar aqui não é o mesmo; ele foi convertido, como expliquei. Então, é impossível saber se é 0,5 ou 0,7. Isso é algo que precisa ser testado, e recomendo fortemente que, se você estiver fazendo isso, teste exaustivamente, certo? Quanto ao score,

11:24 tive 15, 15, 17. Ótimo. Mas, quando aumentei para 0,7, deu erro, certo? Chegou a 0,68, que ficou bem perto, mas essa diferença permanece. No fim, o que você precisa entender é que o G-Eval não é o mesmo que a probabilidade retornada pela Decision API. E isso é muito importante levar em conta. Agora vamos mostrar números. Números, números, números. Você gosta de números, certo? Tempo. Aí você vai dizer: “Cara, valeu a pena

11:56 usar a Decision API. Foi muito mais rápido. Muito mais rápido.” E então posso fazer uma pergunta: você precisa que sua avaliação seja muito rápida ou executa em lotes de vez em quando? Não sei. Você me diz, certo? Mas a outra informação que tenho aqui para você é que estou usando um modelo normal no G-Eval e também estou usando Luna — esqueci de mencionar isso. Então, estou usando Luna no G-Eval ou estou usando Luna na versão com a Decision API, e na outra ali. O que posso

12:27 fazer? Tenho um vídeo aqui falando sobre prompt caching. O que fiz? Fiz prompt caching das entradas das minhas perguntas porque elas se repetiam. Testei várias vezes. E o que isso fez? Deixou meu custo final com o G-Eval menor do que usando a Decision API, certo? Então, muitas vezes, o que importa é a técnica. Você pode fazer algo que… sai mais barato usando o modelo existente para obter a resposta de que precisa,

12:59 basta usar a técnica, certo? Então, se você é engenheiro, se é profissional, deve considerar essas coisas. Mais uma vez, é o custo agregado do G-Eval. E tem algo que quero mostrar aqui no meu notebook, que é o seguinte. Deixe eu ver se encontro aqui, certo? Tudo isso aqui, abrir o G-Eval. Sim, no G-Eval ainda tenho a seguinte vantagem: meu modelo, meu juiz, certo, quando usa a rubrica, o que ele vai

13:29 fazer? Vai dar a pontuação, fornecer a distribuição de probabilidade e dizer por que deu aquela pontuação. Por que isso é importante? Porque, como eu disse, muitas vezes, quando você está criando uma rubrica, precisa entender qual foi o raciocínio do juiz para dar aquela pontuação com base nela. Isso porque, às vezes, sua rubrica não fica boa de primeira — e geralmente não fica, certo? E os critérios do seu juiz também podem falhar. Podem ser ruins. Então, você vai começar a entender que, certo, ele chegou

14:00 a essa nota usando este critério; esse foi o caminho que ele seguiu. E aí você consegue ver que, às vezes, o problema está no agent, mas, às vezes, está no conjunto de dados que você está usando para fazer o teste; às vezes, está na rubrica, e você vai ter que investigar tudo isso. É um trabalho investigativo, que é sua função, é mesmo sua responsabilidade. Você precisa ser capaz de analisar isso. E qual é o problema de usar um decision model? É que o retorno é este, cara. Certo? Então, você começa a trabalhar às cegas, né? Porque não consegue

14:31 saber exatamente a justificativa. Como é mais rápido, ele não mostra um token. Então, se não mostra um token, é melhor. Depende. Se você quer fazer algo que domina e entende o que está fazendo, pelo menos para avaliações, fica meio complicado. Mas tem uma coisa legal. Se aqui, olha, pudermos criar um pareamento… De repente, talvez valha a pena usar. Mas aí o trabalho seria como usar um LLM normal: você conseguiria

15:03 criar muito bem sua rubrica e seu conjunto de dados. Ótimo. Depois, você faria essa adaptação para usar o decision model às cegas; vai confiar no número, meu amigo. O número que chega, você não tem como depurar. É tipo: cara, ele simplesmente chega. É isso. Então, acredito mesmo que talvez não tenha tanto valor, certo? Então, você chega à sua conclusão, como vê aqui: nem sequer tem a justificativa do custo menor, porque provei que, usando prompt caching, tive um retorno melhor sobre o investimento do que usando a Decision API, porque sei usar a API.

15:33 É basicamente isso. São coisas que mostro constantemente aqui no YouTube e que sei que estão em alta: ficar bom no que você faz. É brega dizer que você precisa estudar, cara. Mas é isso, é tudo o que você tem. Certo? Quanto mais você terceiriza seu cérebro para alguém na internet, com “agora vai funcionar” e “agora é isso que você tem que fazer”, pior fica para

16:05 a você. E quanto mais você terceiriza sua capacidade de execução para o token, pior fica para você, porque estamos chegando a um ponto em que quem controla os tokens controla o mundo. Mas não deixe que aqueles que controlam os tokens e aqueles que controlam a narrativa da internet controlem sua mente. Espero que este vídeo tenha sido útil para você. Aqui falei sobre muitas coisas avançadas, então não tem problema se você não conhece essas coisas, mas é necessário mostrar essas coisas à comunidade brasileira de engenharia de IA, porque precisamos sair da infância. Há um mundo lá fora

16:38 que precisa de pessoas que queiram fazer isso, que possam fazer isso, que tenham capacidade para fazer isso, mas essa demanda não está sendo atendida porque literalmente há poucas pessoas capazes de fazer isso. E espero que esse seja o seu desejo. Espero que essa já seja a sua capacidade. E vamos conquistar o mundo. É uma questão de tempo. Mais uma vez, não. Há concorrência. Se você continuar fazendo isso, continuar melhorando, continuar ficando cada vez melhor, há muitas oportunidades para quem realmente está fazendo isso.

Transcrição original

[00:00] This week was a terrible week for Jeff Bezos fans. That’s because OpenAI released the Decisions API based on an LLM, GBT6 Luna. And CloudFlir released their decision model. And this is even more interesting for our analysis here, because they explained how they did it on their blog, and they used the customized Quin 27B and Quin 9B to get that structured output and all that.

[00:30] Why is this important? It reveals to us that the emperor has no clothes. As I showed in the previous video, we can adopt a new technology, but if we don’t understand how it works, we’ll always be swayed by hype, believing that a technology will replace our understanding. Don’t outsource your minds, guys, it’s all you have. But one of the use cases that could be interesting in Decision Modeling, and that I’d like to test, is EVALs. And in this video, I’m going to show you an

[01:01] EVAL, not a hypothetical EVAL of a hypothetical agent that supposedly works. I’m going to show you a real EVAL from an agent that hundreds of people use every week, and I’m going to take what exists today, the technique I use today, and I’m going to take the decision model, apply the technique, and use it with it. And then throughout the video, we’ll see the results. And I hope you have the ability to analyze, and then, what do we do in engineering? We use the best tool for the job. We don’t become fans of A or B simply because that changes everything. Before

[01:31] we get into the video, let’s talk about today’s sponsor. Rock Pro is the best engineering platform in Brazil. That’s where the professionals are. So let’s go, shall we? Decision model for EVALs. So I’m going to go through an experiment I did. It’s literally a study. And we’re going to see the conclusions we drew from this study. And what is G based on? It’s based on this guy here, this agent we have online. And that’s exactly the question we’re going to look at, okay? Okay, my agent remembers the current conversation, but misses important

[02:03] facts, etc. Why am I showing this here? Because it’s literally in my EVA, okay? This is a question I created in EVAL. I’m going to show you what EVAL is. If you don’t know these terms, that’s okay . Uh, but this is what the real-world industry does, okay? This isn’t speculation. This is what I apply both at Rockpr and with my clients, and it is what the entire world is doing to improve their solutions, if you know what I mean? So, if you have a problem with your solution, it probably doesn’t work so well, it runs the risk of being

[02:33] this too, okay? So, let’s go. Very well , we had the launch of Cloud Flir from Upai, as I mentioned here. And I recommend you take a look at the blog if you’re interested, but the important thing is that both APIs are very similar to the JV we knew, okay? However, OpenAI changed the name here; they called it “predicate.” The other two are the same, so this is just for your reference, okay? But the idea is exactly the same. You put something in

[03:03] the context, and it outputs a response. The main difference between these two models is that they are multimodal, or rather, they accept images. So you can decide with images as well, which can be interesting, right? For your use case, the Cloudflare model has 64K of context, so you can send a slightly larger amount. If I’m not mistaken, the JV was 32, so it greatly limits the solution you can implement, but the OpenAI model is more interesting for EVAL because it has the context window like a normal model. So, the context

[03:35] window is quite large, and we can explore that in EVAL. So, for EVAL, since the context is often large, it will analyze several things; it will analyze the user input, it will analyze the retrieved document in many cases. In this case, we’re going to evaluate a rule. It’s important that we have a slightly wider context window to see the result. Okay? So, that’s good. You already know what we’re going to do here. Let me explain how this works, okay? How does a judgment, how does an

[04:05] EVAL work? You’ll have the response generated by the agent. So I came here, to Rockpr, right? There’s the question, there’s the response generated by the agent, and here’s its response, right? What it did. And we’ll have a reference of what the correct answer would be. So , if someone were to ask you this specific question, how should the answer look? So that’s the reference. And we’ll have a rubric that will evaluate it. If you think about giving this to a human to evaluate, you would have the rule, right? Ah, according to

[04:36] this, it’s that and so on. For example, if someone is to evaluate the ENEM exam . So I imagine they have a rubric. So that’s exactly it. You send all this information to a judge, and they’ll say , oh no, this case passed, this case is so-so, this case is good, this case is bad. That’s basically what we’re talking about. So let’s go to our notebook to understand how this is configured. Let’s go, right? What do we have here? It’s exactly that question I showed you earlier, okay? My agent remembers the current conversation, but loses important facts when the translation changes, then the

[05:07] summarization changes, okay? Uh, what should I study? So, this is a classic case of a student, a person trying to understand their problem and trying to find the material to solve it. And yes, we already have an answer here, okay? So, what I’m showing you is after the fact, right? After the study, okay? Okay? And this is the complete answer the agent gave, okay? Obviously, since we’re dealing with LLMs, the same question won’t produce exactly the same answer. So, what we do isn’t evaluate letter by letter, right? We evaluate

[05:38] the overall context of the answer, and that’s why the criterion is important. You see here that he answered, the answer is quite long, everything’s great, right? What’s the criterion? How would it be resolved? It’s here, for this case, uh, the agent should look in my rule for phase two, etc., etc. So, the context that the judge has to know is this: Phase two, lesson 10. If my agent doesn’t bring this in his answer, he’s wrong. It doesn’t mean that if he brings something else too, he mentions this material and maybe this other

[06:09] material here helps you, he’s wrong. OK ? So that’s the criterion I developed. And how do we generate this criterion? Uh, with business knowledge. For the following reason: since I was the one who recorded the class, and I created the agent, and I created the EVAL, it’s very easy for me because I know what I want to convey and I know what my agent should answer, because, at the same time that I’m a developer, I’m also a stakeholder. If you’re working in a company, this evaluation of the criteria for the user’s question, the

[06:41] evaluation criteria, and the rubric are done in conjunction with the business. I recommend my previous video here, where I talk about how you should understand that your profession is entirely intertwined with the business. There is no AI and business, there is only one thing, okay? And the rubric goes exactly in that sense as well. Uh, you’re going to create a rubric, okay? This is the standard. The standard, okay? This isn’t something I’m making up, is it? It’s something I made up. You’re going to create a rubric that will evaluate. And you can do EVAL

[07:12] without a rubric, but you’ll have difficulty standardizing it. So, it’s highly recommended that you make a note , okay? And then, uh, we’re going to start taking notes, okay? Uh, I use a technique called EVAL, which isn’t the topic of this video, okay? It’s a globally known technique, so it’s not an invention. And within this metric, I have value, okay? But I want to show you this here. Uh, when we’re doing EVAL, uh, it doesn’t mean the answer is

[07:43] inadequate, it means it’s incorrect. Because, uh, in EVAL, many times you want to force a wrong answer to see if, uh, your EVAL is also correct. So, you uh test if it’s approved and test if it’s rejected as well. So, you have to keep that in mind, okay? And that’s exactly what we’re doing. Uh, here in our Bravissimo, let’s go back to our notebook, it’s in our Bravissimo EVAL, okay? So he did everything correctly, he failed, and we have a baseline. And here’s an interesting part about

[08:15] decision models and EVAL itself, because since you have a probability of something being right or wrong, you need to calibrate. And this is one of the very important factors when we do EVAL. EVAL isn’t something you do once and it works. With EVAL, you’ll spend time calibrating. And this is extremely important for what I’m going to talk about from now on regarding decision models. To use the decision model, I need to make adjustments because, since it has a slightly different output than

[08:45] the Gval output, I can’t just use my rubric as it is, my test hold as it is, to use the decision model. So, what I did in my experiment was try to adapt these outputs to a format that would be good enough for me to evaluate if the model would be good enough to use as an EVAL. The model isn’t ready to use EVAL directly, so we have to make an adaptation, and when I say EVAL, I mean EVA from LLMS, right? Very well. Okay.

[09:17] And arriving at this conclusion, I believe that the two best opportunities here are in predicate and score. And that’s exactly what I did in the experiment. Let me show you, okay? Uh, and the first case, I had exactly a zero probability of it being correct, so the answer was rejected, which is what I expected. But here we lost a little nuance, right? And I don’t know exactly what happened. In the other case, the score is good because it gives a probability distribution, right ? So I transformed my rubric into each of these probabilities, and in the end,

[09:48] I’m only adding the cases that would be approved. So in this case, it gave 8, and it was excluded because I was doing something with 5. That’s basically the experiment. So, I am able to apply my rubric or my EVAL to the IPI decision-making process; yes, I can. But now I’m going to show you the results. And then it gets interesting for this reason, okay? Uh, let’s go, right? Running the GVAL, okay? So, it’s exactly that question there, it’s

[10:19] exactly that rubric, it’s exactly my judge, okay? It’s within my GVAL. And here I’m using a threshold of 07, so it’s 70%, if you want to think of it that way, and he passed. So, in all these rounds here, I passed this guy 15 times, right? 17 answers 15 times. And I ran this here several times. He passed all of them, okay? Yes, using predicate, okay? I used the same techniques and it worked. So, my portability is saying here, at least to

[10:50] me, that this portability works, okay? So this is the experiment. It seems that the portability worked, which is something good for us, okay? Uh, but here in the score, what did I do, right ? Ah, okay. I used both the threshold 05 and 07, okay? Here in the predicate, okay? Why? Okay, this threshold here isn’t the same; it’s ported, as I explained. So, it’s impossible to know if it’s 05 or 07 FL 07. This is a matter of testing, and I strongly recommend that if you’re doing this, you test exhaustively, okay? Score, uh,

[11:24] I had 15, 15, 17, great. But when I increased it to 07, I had an error, okay? Uh, it hit 0.68, which was very close, but uh, that Ket remains. Uh, in the end, what you have to understand is that the Geval is not the same as the probability of exiting the uh decision API. And this is very important for you to take into account. Now let’s show numbers. Numbers, numbers, numbers. You like numbers, right? Time. And then, you’ll say: “Man, it was worth it to

[11:56] use the Decision API. It was much faster. It was much faster.” And then I can ask you a question. Do you need your EVAL to be very fast, or do you run it in batches from time to time? I don’t know. You answer me, okay? Uh, but the other piece of information I have here for you is that I’m using a normal model in GVAL, and I’m also using Luna, I forgot to mention that. So, I’m using Luna in GVAL, or I’m using Luna in the Decision API version, and in the other one there. What can I

[12:27] do? I have a video here talking about prop casing. What did I do? I did prop casing of the input of my questions because the questions were repeating. I tested it several times. And what did that do? It made my final cost with GVAL lower than using the Decision API, okay? So, many times it’s skill that matters. Uh, you can do something that …It’s cheaper to use the existing model, giving you the answer you need,

[12:59] it’s just using technique, right? So, if you’re an engineer, if you’re a professional, you should consider these things here. Again, it’s the aggregate cost of GVAL. And there’s something I want to show you here, it’s on my notebook, which is the following, let me see if I can find it here, okay? Uh, this whole thing here, open GVAL, okay? Yes, in GVAL I still have the following advantage. My model, my judge, right, when he uses the rubric, what will he

[13:29] do? He will give the score, so he will give the probability distribution and will say why he gave that score. Why is this important? Because as I said, when you are creating a rubric, many times you need to understand what the judge’s reasoning was in that rubric for him to have given that score. This is because sometimes your rubric isn’t good the first time, and usually it isn’t, okay? And usually your judge’s criteria can fail. It can be bad. So you’ll start to understand that, okay, he arrived at

[14:00] this grade using this criterion, this is the path he took. And then you can see, sometimes the problem is in the agent, but sometimes the problem is in the dataset you’re using to do the test , sometimes it’s in the rubric, and you’ll have to investigate all of that. This is investigative work, which is your job, it is indeed your own job. You have to be able to analyze this. And what’s the problem with using a decision model? Because the return is this, man. Okay? So, you start flying blind here, right? Because you can’t

[14:31] know exactly the motivation, because it’s faster, so it doesn’t print a token. So, if it doesn’t print a token, it’s better. It depends. If you want to do something that you have mastery over and you understand what you’re doing, at least for Eval, it gets kind of complicated. But there’s a cool thing. If here, look, we can, uh, no, I think she’s not on the slide, right? If here we can, we can create a pairing, Suddenly it might be worth using, but then the work you’d be doing is like using a normal LLM, you’ll be able to

[15:03] create your rubric very well, your dataset very well, great. Then you will perform this adaptation to use blind decision modeling; you are going to trust the number, my friend. The number that comes, you have no chance to debug . It’s like, man, it just comes. That’s it. So, I really believe that suddenly it doesn’t have that much value, okay? So, you come to your conclusion, as you see here, you don’t even have the justification for the lower cost, because I proved to you that using

[15:33] promptcasting, I had a better return on my investment than using the Decision API, because I know how to use the API. That’s basically it. Things that I constantly show you here on YouTube, which I know is trendy, is about getting good at what you do. Uh, uh, it’s cheesy that you study, it’s cheesy , man. But that’s it, that’s all you have. Okay? Uh, the more you outsource your brain to someone on the internet with “now it will work” and “now it’s the thing to do,” the worse it is for

[16:05] you. And the more you outsource your execution capacity to the token, the worse it is for you, because we’re reaching a point where whoever controls the tokens controls the world. But don’t let those who control the tokens and those who control the internet narrative control your mind. I hope this video has been useful to you. Uh, here I talked about a lot of things that can be advanced, so there’s no problem if you don’t know these things, but it’s necessary to show these things to the Brazilian air engineering community, because we need to get out of childhood. There’s a world out there

[16:38] that needs people who want to do it, who can do it, who have the capacity to do it, but this demand isn’t being met because there are literally few people capable of doing it. And I hope that’s your desire. I hope that’s already your capacity. And we will conquer the world . It’s a matter of time. Uh, once again , no. There is competition. If you keep doing it, keep improving, keep getting better, there are many opportunities for those who are actually doing it.