Como avaliar corretamente qual o melhor modelo de I.A.?

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: Portuguese

Original video: Como avaliar corretamente qual o melhor modelo de I.A.? · Channel: Vini Lana · 17:33 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Software engineering with AI, AI models

Summary

O vídeo explica por que benchmarks públicos são referências úteis, mas não bastam para escolher um modelo: a avaliação precisa refletir o contexto e as tarefas reais de uso. Como exemplo, o apresentador mostra um sistema de atendimento fictício e compara modelos com evals que medem conclusão das tarefas, qualidade das respostas, tempo e custo. Os resultados mostram que modelos mais caros ou populares nem sempre são os mais adequados para um workflow específico. As avaliações também ajudam a identificar falhas e ajustar o system prompt e o harness do agente.

Key points

Benchmarks públicos servem como referência, embora modelos possam ser treinados para ter bom desempenho neles.
A escolha do modelo deve partir do contexto e das tarefas específicas em que ele será usado.
Evals podem combinar tarefas conhecidas, resultados esperados e avaliação das respostas.
O exemplo compara modelos em um sistema fictício de atendimento ao consumidor.
Os critérios observados incluem conclusão de tarefas, qualidade, cumprimento das instruções, tempo e custo.
Um LLM as a judge pode avaliar aspectos mais abstratos, como empatia, idioma e respeito às regras.
Resultados repetidos ajudam a estimar o desempenho do modelo com mais confiança.
Falhas identificadas nas avaliações podem orientar mudanças no system prompt ou no harness do agente.
A observabilidade em produção ajuda a verificar se o agente atende às necessidades dos usuários.

Chapters

Start	Chapter	Summary
00:00	Por que avaliar modelos com métricas	O apresentador questiona avaliações baseadas apenas na percepção e explica o papel e as limitações dos benchmarks.
03:34	Um sistema de avaliação para atendimento	É apresentado um agente fictício de atendimento ao consumidor, sua estrutura e o conjunto de tarefas usado nos evals.
06:40	Comparação de qualidade, tempo e custo	O vídeo mostra como os modelos são avaliados por conclusão das tarefas, qualidade das respostas, rapidez e custo.
11:17	Identificar falhas e melhorar o agente	Os resultados por modelo e por dificuldade ajudam a localizar problemas e orientar ajustes no system prompt e no harness.
15:26	Avaliação contínua e experiência do usuário	O apresentador relaciona evals e observabilidade à melhoria dos agentes e à satisfação dos clientes em produção.

Quotes

Dependendo da tarefa, alguns modelos, até mesmo os mais caros, vão performar pior do que alguns modelos mais baratos. — 00:00

Será que eu consigo também criar um benchmark para avaliar os meus próprios casos de uso? — 02:33

Para esse caso de uso, consigo dizer se ele está funcionando bem ou não. — 09:14

Eu tô falando de ter dados para saber qual modelo é o melhor e, a partir disso, também poder alterar meu próprio harness. — 12:50

Aquele modelo do hype talvez não vai ser o melhor caso de uso para você. — 16:29

Concepts and entities

benchmark, evals, LLM as a judge, Harness, Ivy Dev, Vercel, Hermes Agent, Opus 5.5, Gemini 1.5 Flash, Luna 6, DeepSeek V4.1 Flash, Raiku 5.5, MiMo-V2.6 Flash, Vini Lana, AI Code Academy

Full transcript (original language)

00:00 Você vai perceber que, dependendo da tarefa, alguns modelos, até mesmo os mais caros, vão performar pior do que alguns modelos mais baratos. Nesse caso específico, o Opus 5.5 tá perdendo pro Gemini 3.8 Flash e pro Luna 6. Qual é o melhor modelo de IA hoje? Eu quero te ajudar a responder essa pergunta com métricas. Hoje em dia, muitas pessoas respondem com base no sentimento. Ah, eu senti que o Opus 5.5 foi cabuloso. Eu senti que o GPT 6.1 só foi bom demais. Eu senti que o vai colar ele, não senti

00:30 nada. Quero saber que já desde o começo desse vídeo, o qual o modelo que você tá preferindo hoje, qual tá sendo o melhor pra realizar suas tarefas. O que que a gente vai tentar entender aqui junto com vocês? Não somente a percepção humana de quando o modelo tá performando bem ou não, mas ter métricas pra conseguir comprovar isso. Bora nessa. Benchmarks, eles são polêmicos. Muita gente não confia mais neles porque acredita que os modelos estão sendo treinados neles pra trazer respostas mais parecidas e performar melhor dentro de cada tal disse. E é verdade, isso acontece sim. É

01:02 a maioria dos modelos hoje em dia vão tá tentando performar bem nos benchmarks mais famosos. Pra quê? Pra quando isso for eles forem lançados, ter mais hype. Acontece. Agora, isso invalida o benchmark? Não. Na verdade, o benchmark ele serve como um ponto de referência pra nós. Mas antes de você ficar pistola aqui nos comentários, que fala: “Tá, o Vini vai dizer então que eu vou saber qual o melhor modelo por um benchmark”. O que é um benchmark? Em inteligência artificial pra large language models, vai ser um conjunto de tarefas que você já vai pré-configurar pra toda vez que

01:33 você quiser testar, você roda em cima dessa mesma base, desse mesmo conjunto de tarefas, que é chamado de dataset, e em cima desse dataset, você vai rodar um harness que vai executar essas tarefas, ou seja, um agente, junto com aquele modelo específico, no esforço específico que você selecionou. Então, na prática, eu posso ter um benchmark de desenvolvimento de software, como por exemplo Deep SWE, que eu tenho ali várias tarefas, OK? O que que vai acontecer? Eu vou rodar cada modelo em cima daquelas tarefas e vou avaliar o output. Então eu tenho um output

02:03 esperado, ele tem que responder é desse jeito ou os testes tem que passar e por aí vai. Ele serve para eu conseguir ter um parâmetro e em cima desse parâmetro avaliar diferentes modelos. Uma vez que a gente entende isso, aí você começa a entender porque que é fácil, em alguns casos, as empresas treinarem os seus modelos em cima de benchmarks. Por que? Porque essas tarefas já são conhecidas. Então o modelo é treinado em cima delas, obviamente ele vai saber responder o que é o esperado. Então esse é o problema dos benchmarks. Agora, se eu entendo que

02:33 esse que um benchmark serve para justamente o avaliar a qualidade do modelo, aí tem um nome importante que chama evals, evaluation, então será que eu consigo também criar um benchmark para avaliar os meus próprios casos de uso? E aí que entra o ponto importante desse vídeo. Para você avaliar o modelo, é importante que você tenha uma métrica, uma maneira de avaliar a qualidade do modelo em cima do seu caso de uso. E o seu caso de uso, ele não necessariamente vai ser desenvolvimento software. Você vai perceber que, dependendo da tarefa,

03:03 dependendo do workflow agêntico, alguns modelos, até mesmo os mais caros, vão performar pior do que alguns modelos mais baratos. Eu quero te mostrar agora como é que a gente construiu essa base de evals no código. Nesse caso específico, o Opus 5.5 tá perdendo para o Gemini 1.5 Flash e para o Luna 6. Só que quando eu falo isso para você sem contexto, você vai falar assim: “Cara, não tem lógica. O Vini tomou alguma cachaça diferente lá em Minas Gerais e o negócio bugou a cabeça dele”. Mas calma, é a mesma pergunta que a gente faz para qual melhor stack, qual a melhor

03:34 tecnologia, ela sempre tem que vir amparada de uma pergunta anterior, que é qual contexto. Qual é o contexto que eu rodei essas tarefas? Aí sim, agora faz sentido, porque isso aqui é um sistema de agentes de atendimento ao consumidor do Fominha Delivery. Fominha Delivery é a nossa nosso iFood fictício aqui, tá? Aonde a gente tem um agente de atendimento ao consumidor e esse agente, ele vai atender para basicamente qualquer demanda que o usuário pedir. Então, ah, meu pedido atrasou, beleza, ele vai saber lidar com esse workflow. Sei lá, intoxiquei com a comida, a

04:04 comida chegou toda amassada, toda quebrada. Aqui a gente vai estar tratando todos esses casos dentro desse sistema de avaliação. E a gente está usando o Ivy Dev, que é um framework da Vercel para você desenvolver agentes. Por que que eu gosto desse cara? Porque enquanto o framework de agentes eu tenho uma simplicidade melhor de código, de manutenção, escalabilidade para colocar algo no ar, se comparado ao Hermes Agent, por exemplo, talvez eu não conseguiria ter esse nível aqui de gestão da base de código. Então eu sempre falo, cara, se você vai trabalhar em produção com agentes, evita usar um agente que é muito amplo,

04:35 um harness muito genérico como o Hermes Agent. Ele pode ser muito bom como um assistente pessoal, mas quando você está trabalhando com multiagentes, você vai querer uma coisa mais profissional, um jeito mais profissional de trabalhar com isso. Esse jeito profissional é através de framework de agentes. Aqui tem o Ivy, por exemplo, para a gente trabalhar. Que que tem dentro de uma pasta do Ivy? Você tem um arquivo, a pasta Agent, dentro dessa pasta você vai ter os channels, que é exatamente por onde ele se comunica, Slack, Slack, Telegram, WhatsApp, por aí vai. Aqui a gente vai ter a pasta tools, que são as tools que esse agente pode chamar. Então, ao invés de simplesmente trazer um zilhão de

05:06 MCPs, de tools e conectores para o meu agente, eu trago somente o que ele precisa, reduzo o escopo de manutenção do meu agente. Então eu tenho aqui buscar cliente, cancelar pedido, consultar cardápio, consultar pedido e por aí vai, todas as tools que ele vai ter que chamar nesse caminho. E aqui embaixo as instruções, as instruções, que é o nosso system prompt. Então, você é a Fifi, assistente virtual de atendimento do Família Delivery. Então, maravilha, tá aqui o system prompt do agente, todas as políticas que ele tem que atuar estão estão escritas aqui dentro também. E aí que do outro lado a gente tem os devos. Dentro dos casos eu tenho aqui um YAML

05:38 com todos os casos de uso, então, é, com todas as tarefas que eu quero validar com esses agentes. Então, a primeira tarefa, pedido de sal para entrega, aí tem o contexto. Aí é outra tarefa, tem aqui identificação, né? O cliente cobra o pedido sem se identificar. Então, todos esses casos de uso vão ser utilizados no nosso dataset teste quando eu rodar esse eval. Ele vai rodar o eval, vai pegar ali todas as etapas que a gente setou, que estão configuradas aqui dentro, dentro do SAC eval. Então, ele vai chamar, vai definir o eval aqui com essa função, né? E aí ele vai rodar todos os casos que a gente tem ali.

06:09 Ao final disso, nós temos a nossa resposta e essa resposta, ela fica guardada aqui dentro desse nosso dashboard. Então, esse dashboard específico, eu tenho aqui a os casos, então cada tarefa que foi executada, pedido ainda em preparo, cliente cobra pedido sem se identificar e todos eu consigo avaliar modelo a modelo e aqui eu tenho uma visão geral, né? De como cada um está se comportando dentro disso. Eu tenho meu próprio benchmark. Eu tenho meu sistema de agente, ele tem lá todas as tool calls que vão acontecer, ele tem lá dentro todo o

06:40 workflow que a gente tem esperado para acontecer e eu tenho meu sistema de evaluations. Inclusive, se você quiser aprender comigo a criar agentes de ponta a ponta para colocar em produção, trazendo observabilidade, evaluations, sabendo metrificar em tempo real se o seu agente está funcionando ou não, trabalhar com teste AB, trabalhar com rollout de features específicas para agentes, perceba que eu estou falando para colocar agente de produção de verdade, eu estou com uma formação e lista de espera aberta para você participar da primeira turma. Para quem entrar na primeira turma, vai ter um baita desconto. Então, se você confia no

07:11 meu trabalho aqui até agora, é só clicar em se inscrever ali no link que está na descrição e no primeiro comentário fixado também. Então, veja bem, aqui temos esses três modelos. O que que está sendo avaliado aqui? A gente criou então o nosso dataset, a gente tem uma estrutura de LLM as a judge que vai servir para avaliar não somente a competência do caminho que foi feito pela gente, mas também a qualidade da resposta, se a resposta veio no idioma certo, se o agente alucinou, se o agente falou coisas que não era para ele ter dito e aí como é que a gente pega isso? A gente trabalha no system prompt e trabalha também no output. Então, tudo

07:42 isso foi avaliado aqui dentro, junto com uma avaliação também não só de que de conseguir completar a tarefa, mas qual o melhor custo-benefício e qual mais rápido para executar isso aqui. Então, aí sim, agora faz sentido para você olhar para esses gráficos. Eu digo para você que, inclusive, o Opus 5.5 tá em terceiro lugar, me surpreendeu. Quando eu rodei o bench, eu falei: “Cara, com certeza o Opus 5.5 vai ganhar isso aqui”. E não foi bem isso que aconteceu. Vamos lá. Luna 6, ele tirou nota 5, demorou 6.8 segundos, em média, para executar as

08:13 tarefas e o custo por tarefa foi de 0. 0,00095 centavos de dólar por caso. Olha só. Em comparação, Gemini 1.5 Flash também tirou 100%, mas ele tirou nota 5 com 16.5 segundos para executar tudo. Demorou mais do que o dobro do tempo do que o Luna 6. E ele gastou 0.1 centavos de dólar para executar isso. Opa, olha que diferença absurda aqui, galera. 1 centavo para 0.009 centavos é muita

08:44 coisa. Lá no Opus 5.5, ele gastou 6 centavos de dólar e gastou 10 segundos, mas ele tirou nota 4.86. Isso significa que, em algum momento, seja na resposta que ele trouxe, ele trouxe uma informação que ele não deveria ter trago, aí pode ser um pouco de alucinação, ele desrespeitou um system prompt ou ele não conseguiu executar uma etapa. Mas aqui no nosso benchmark a gente consegue validar isso. E como é que isso acontece? Via de regra, você não vai rodar o data set só uma vez. Você vai rodar o teste desse evaluation várias vezes para você pegar

09:14 a mediana e, a partir dessa mediana, falar: “OK, para 100 vezes que eu rodei esse mesmo caso de uso com o Opus 5.5, ele tirou, em média, a nota 4.86”. Aí eu consigo te dizer, nesse caso de uso, se ele tá funcionando bem ou não. Então, aqui ó, a gente teve empate em aprovação de 100% entre Luna e o Gemini 1.5 Flash e também o Mistral Spark Contributor, que não tá aparecendo aqui, e o Opus 5.5. Porém, o desempate foi com a nota do juiz, que é um LLM as a Judge, o tempo, o tempo e o custo. E aí tem as

09:45 outras colunas do gráfico, que a gente vai mostrar pra você aqui já já sobre isso. Olha que interessante. No ranking, como é que ficou? Luna 6, com 100% aqui, passou em todas as tarefas, tempo 6.8 segundos, o custo menor possível. Na sequência, Gemini 3.8 Flash, com um detalhe, ele usou a mesma família de LLMs pra fazer, pra ser o juiz, nesse caso, esse teste nosso. Como assim, Vini? No LLM as a Judge, ele usou o Gemini 3.1 Pro. Isso também tem que ser levado em consideração, já que, geralmente, quando o LLM é da mesma família, ele pode influenciar o

10:16 resultado. Outro ponto interessante, Mi Spark 1.3 Contributor, tá aqui também, performou bem, 4.76 a nota, eh, e aqui 10 segundos de execução. Então, todos eles conseguiram concluir as tarefas, 100% de aprovação, mas a nota não foi 100% em todos, porque em algum momento o nosso juiz, enquanto LLM, identificou que foi desrespeitada alguma regrinha, seja falar um idioma diferente, seja não responder alguma coisa que ele deveria ter respondido ou vice-versa. Por

10:46 exemplo, se a pessoa tá passando mal, jamais mencionar reembolso na, quando a pessoa tá reclamando que ela se intoxicou. Primeira mensagem específica tem que ser: “Procure um médico. Aqui tá as referências”. Esse é um tipo de caso que a gente capta aqui no LLM as a Judge. Percebe que aqui também a gente tem o Deep Seek V4.1 Flash, que não passou em todas as tarefas, que demorou 4.9 segundos, ou seja, se ele tivesse passado em todas as tarefas, ele estaria em primeiro em questão de tempo, mas ele foi bem mais caro também do que o Luna 6, ok? Então, olha que interessante.

11:17 Agora, eu tenho um mecanismo que pra eu responder, pra quando alguém me perguntar: “Qual o melhor LLM?”, eu vou dizer: “No meu saque lá do Fominha, o melhor LLM disparado é o Luna 6”. Vamos analisar os outros caras aqui, ó, GLM 5.3 Flash também não performou bem, o Raiku 5.5 me desapontou nesse caso, ele também não acertou todas as tarefas e e também não foi mais rápido. E aqui a gente tem o Mimo V2.6 Flash que também desapontou para caramba, ele foi o pior aqui dentro dessa avaliação. Agora falando sobre qualidade versus custo, também a gente tem isso aqui.

11:48 Então o mais caro de todos Opus 5.5, qualidade alta, aqui o mais barato de todos o Luna 6 e aqui a gente vai avaliando a qualidade versus custo também no nosso próprio benchmark desse sistema da gente. Onde que cada modelo falha baseado nas tarefas que nós criamos dentro dessa estrutura de avaliação, eu vou ter a clareza. Então nas tarefas fáceis o DeepSeek-V4.1 Flash falhou em uma. Nas tarefas médias, ninguém Aliás, o Mimo V2.6 Flash falhou nas tanto na fácil quanto nas médias. Na difícil, o Raiku

12:19 5.5 falhou em uma, o GLM 5.3 Flash falhou em uma e o Mimo V2.6 Flash também falhou em uma. Então perceba que aqui a gente vê uma miscelânea, né? Não é porque o modelo é o melhor de todos que ele vai acertar nas tarefas mais fáceis e vice-versa, não é porque ele é o modelo mais baratinho que ele vai errar nas mais difíceis também. Se o o DeepSeek-V4.1 Flash, ele tá sendo um cara que tá sendo mais rápido aqui para gente e eu quero muito usar ele, talvez a alteração que eu vou fazer, eu vou identificar essa tarefa específica e vou

12:50 ver, será que se eu mudar o sistema prompt, será que se eu mudar alguma coisa no harness do meu agente, eu consigo fazer o agente passar aqui? Então olha bem, eu tô falando de ter dados para saber qual modelo é o melhor e a partir disso também poder alterar meu próprio harness para melhorar a execução disso, que é exatamente o que o Cloud Code e o Codex fazem com seus próprios LLMs. Eles pegam o modelo, identificam onde ele falha e aí traz recurso de em cima do harness para melhorar essa qualidade do output do modelo. Então aqui a gente poderia aplicar isso. Ou digamos que, sei lá, o

13:21 Raiku 5.5 para a gente tá muito melhor e o custo dele tá muito melhor, eu quero usar ele de todo jeito. Então vamos lá, vamos usar eles de todo jeito. Eu vou identificar as tarefas que ele falha e vou melhorar, vou alterar esse system prompt e vou reexecutar o nosso eval até ele conseguir performar bem o suficiente. Aqui a gente consegue trabalhar nisso e não só ficar refém do modelo. Se você gostou dessa parada aqui e quer ver esse código com as suas próprias mãos, eu também deixei o link do material aqui na descrição para você poder baixar e validar esse código. Aqui a gente tem um caso de uso específico

13:52 para você entender quando que um juiz vai falhar, vai dar nota ruim para o modelo. Olha só. O cliente cobra pedido sem se identificar. Então, o cliente não informou e-mail, telefone nem número do pedido. Pela política, o agente deve pedir identificação antes de consultar qualquer coisa. E aí, é justamente aqui que o Raiko 5.5 foi aprovado, o Deep Seek V4.1 Flash falhou e o Mimo V2.6 Flash falhou. Ele falhou em executar a tarefa? Não necessariamente. Ele falhou na avaliação do juiz. Para que que serve o LLM Mesa Judge? Para ele avaliar não

14:24 só uma questão de lógica, mas uma questão mais abstrata, mais ampla que você não consegue cumprir simplesmente com código. Então, logo no começo aqui, o Raiko 5.5 ele trouxe assim, ó: “Oi, sinto muito pela demora. Para localizar seu pedido, me informe e-mail ou telefone cadastrado na sua na sua conta, por favor”. Aqui, aonde que o V4.1 Flash falhou? Ele não demonstrou empatia com a espera do cliente. Ele simplesmente respondeu: “Oi, vou verificar isso para você agora mesmo”. Mandou um sorrisinho. A mesma coisa o Mimo V2.6 Flash. Ou seja, se eu quero tratar dentro do meu workflow não somente a lógica, consigo

14:56 executar, mas também se ele está respeitando uma regra do meu system prompt, uma instrução que eu passei, seja tenha empatia sempre que alguém reportar um problema, eu consigo captar isso com o LLM Mesa Judge. Mesmo caso aqui, cliente cobra estorno que já está em processamento. Aqui você vai observar que o Mimo V2.6 Flash falhou, ele informou que o estorno de 83,90 já está em processamento, então seria uma questão de dados aqui de trazer e eu consigo avaliar cada uma das respostas. Ponto interessante aqui é que também eu consigo avaliar qual o tool foi chamada,

15:26 qual a resposta que ele trouxe para a gente naquele momento. E assim que a gente vai trabalhar com Involves. Eu vou criar essa estrutura de tarefas, de etapas que precisam ser seguidas, de a expectativa de avaliação final, então quão bom foi a resposta, se atendeu, se estava no idioma certo e por aí vai. Eu percebo que os problemas que nós temos com fluxos de agentes hoje não são tão diferentes do desenvolvimento software. Eu vou precisar de trabalhar com uma feature específica, vou trabalhar com feature flag, que é a ideia de poder fazer teste AB, a ideia de poder fazer roll-out, ou seja, liberar uma uma

15:58 atualização somente para uma parte dos meus clientes e a outra continuar usando outra parte, trabalhar com observabilidade e tudo isso é exatamente o que a gente vai ensinar na nossa formação Agent Builder. Então, se você está curtindo esse vídeo, já peço para você se inscrever dentro dessa lista de espera que eu tenho certeza que você vai curtir para caramba e eu te garanto que você não viu nada igual no mercado. O maior insight que você vai ter quando se você começar a rodar esses testes é que aquele modelo do hype, aquele cara que está todo mundo falando dele no mercado agora, talvez não vai ser o melhor caso de uso para você. Open 5.5 dizendo aqui,

16:29 dando a letra, né? Claramente ele não é o melhor modelo para a gente usar nesse nosso workflow agêntico. E com isso, você vai começar a ter respostas que o mercado precisa. O mercado ele vai sempre perguntar para você assim: “Tá, vamos lá, você vai construir o meu workflow de agentes aqui, você vai construir meus multiagentes. Eu quero saber quanto que eu vou gastar com isso, eu quero saber se a qualidade está boa, quero saber se meu cliente lá na ponta está satisfeito com o meu atendimento com ele ou se simplesmente eu botei uma IA para atender ele e ele toda vez responde para o meu agente: “Ah, eu quero falar com o humano”. Se toda vez o

17:00 seu cliente responde para o agente que ele quer falar com o humano, provavelmente o seu sistema de agentes não está interessante. Não é que as pessoas estão resistentes simplesmente a usar um agente IA. Provavelmente é porque o seu agente IA ele ainda não está parecendo algo que reduz de fato a fricção do seu usuário. A ideia de eu pedir algo e ele me retornar aquilo que eu precisava. E aí, a partir de um sistema bem estruturado de observabilidade, tem várias ferramentas no mercado, e trabalhando com o Involves, você consegue perceber isso em execução e pré-execução. Pré-execução com o Involves rodando no dataset e pós

17:33 e em produção com os dados de fato de usuários interagindo com aquilo. Se você curtiu esse vídeo, eu sou o Vini e esse aqui é o canal da AI Code Academy. Ajudo pessoas assim como você a aprimorarem suas habilidades de desenvolvimento software na era da inteligência artificial. No mais, estamos juntos, aquele abraço e valeu.