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

Autoria: Vini Lana · 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: português

Vídeo original: Como avaliar corretamente qual o melhor modelo de I.A.? · Canal: Vini Lana · 17:33 · Assistir no YouTube

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

Resumo

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.

Pontos-chave

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.

Capítulos

Início	Capítulo	Resumo
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.

Citações

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

Conceitos e entidades

benchmark (conceito): Conjunto predefinido de tarefas usado como referência para comparar o desempenho de modelos.
evals (conceito): Avaliações estruturadas que medem o desempenho de um modelo ou agente em tarefas específicas.
LLM as a judge (conceito): Abordagem em que um LLM avalia respostas com critérios como qualidade, cumprimento de instruções e empatia.
Harness (conceito): Estrutura que executa as tarefas de avaliação com um modelo ou agente.
Ivy Dev (ferramenta): Framework da Vercel mencionado como base para desenvolver agentes.
Vercel (empresa): Empresa associada ao framework Ivy Dev apresentado no vídeo.
Hermes Agent (ferramenta): Agente citado como exemplo de solução mais genérica, em contraste com frameworks voltados à construção de agentes em produção.
Opus 5.5 (modelo): Modelo comparado no exemplo, que ficou atrás de outros em alguns critérios do sistema de atendimento avaliado.
Gemini 1.5 Flash (modelo): Modelo avaliado no exemplo, com aprovação total nas tarefas, mas desempenho diferente em tempo e custo.
Luna 6 (modelo): Modelo que obteve destaque no exemplo por combinar aprovação nas tarefas, rapidez e baixo custo.
DeepSeek V4.1 Flash (modelo): Modelo que falhou em algumas tarefas do exemplo, embora tenha sido rápido.
Raiku 5.5 (modelo): Modelo avaliado no sistema de atendimento, com falhas em algumas tarefas.
MiMo-V2.6 Flash (modelo): Modelo que apresentou falhas em diferentes tarefas do exemplo.
Vini Lana (pessoa): Apresentador do vídeo, que demonstra uma avaliação de modelos aplicada a um agente de atendimento.
AI Code Academy (empresa): Canal citado pelo apresentador como dedicado a habilidades de desenvolvimento de software na era da IA.

Tradução completa (pt-BR)

00:00 Você vai perceber que, dependendo da tarefa, alguns modelos, até mesmo os mais caros, vão ter um desempenho pior do que alguns modelos mais baratos. Nesse caso específico, o Opus 5.5 está perdendo para o Gemini 3.8 Flash e para o Luna 6. Qual é o melhor modelo de IA hoje? Eu quero te ajudar a responder a 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 foi bom demais. Eu senti que o… vai colar ele, não senti”

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

01:02 que a maioria dos modelos hoje em dia vai tentar ter um bom desempenho nos benchmarks mais famosos. Para quê? Para, quando forem lançados, terem mais hype. Acontece. Agora, isso invalida o benchmark? Não. Na verdade, o benchmark serve como um ponto de referência para nós. Mas, antes de você ficar pistola aqui nos comentários e falar: “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, para large language models, ele é um conjunto de tarefas que você pré-configura para que, toda vez que

01:33 você quiser testar, rode os modelos com base nesse mesmo conjunto de tarefas, chamado dataset. E, com base nesse dataset, você vai rodar um harness que executa 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, em que tenho várias tarefas, certo? O que vai acontecer? Vou rodar cada modelo com base naquelas tarefas e avaliar o output. Então, tenho um output

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

02:33 um benchmark serve justamente para avaliar a qualidade do modelo, aí temos um nome importante: evals, evaluation. Então, será que eu também consigo criar um benchmark para avaliar meus próprios casos de uso? É aí que entra o ponto importante deste vídeo. Para avaliar o modelo, é importante que você tenha uma métrica, uma maneira de avaliar a qualidade do modelo com base no seu caso de uso. E o seu caso de uso não necessariamente vai ser desenvolvimento de software. Você vai perceber que, dependendo da tarefa,

03:03 dependendo do workflow agêntico, alguns modelos, até mesmo os mais caros, vão ter um desempenho pior do que alguns modelos mais baratos. Eu quero te mostrar agora como a gente construiu essa base de evals no código. Nesse caso específico, o Opus 5.5 está 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 quando quer saber qual é a melhor stack, qual é a melhor

03:34 tecnologia: ela sempre tem que vir acompanhada de uma pergunta anterior, que é: qual é o contexto? Qual é o contexto em que rodei essas tarefas? Aí sim, agora faz sentido, porque isso aqui é um sistema de agentes de atendimento ao consumidor do Fominha Delivery. Fominha Delivery é o nosso iFood fictício aqui, tá? Nele, temos um agente de atendimento ao consumidor, e esse agente vai atender basicamente qualquer solicitação que o usuário fizer. Então, “Ah, meu pedido atrasou”; beleza, ele vai saber lidar com esse workflow. Sei lá, “Me intoxiquei com a comida”, a

04:04 comida chegou toda amassada, toda quebrada. Aqui, vamos tratar todos esses casos dentro desse sistema de avaliação. E estamos usando o Ivy Dev, que é um framework da Vercel para desenvolver agentes. Por que eu gosto desse cara? Porque, como framework de agentes, ele oferece mais simplicidade de código, manutenção e escalabilidade para colocar algo no ar. Comparado ao Hermes Agent, por exemplo, talvez eu não conseguisse ter esse nível de gestão da base de código. Então, eu sempre falo: cara, se você vai trabalhar com agentes em produção, evite usar um agente muito amplo,

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

05:06 MCPs, tools e conectores para o meu agente, trago somente o que ele precisa e reduzo o escopo de manutenção do agente. Então, 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 estão as instruções, que são o nosso system prompt. “Você é a Fifi, assistente virtual de atendimento do Família Delivery.” Então, maravilha, aqui está o system prompt do agente. Todas as políticas que ele tem que seguir também estão escritas aqui dentro. E, do outro lado, temos os evals. Dentro dos casos, tenho aqui um YAML

05:38 com todos os casos de uso, com todas as tarefas que quero validar com esses agentes. Então, a primeira tarefa: pedido de sal para entrega; aí tem o contexto. Aí tem outra tarefa, aqui com 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 de teste quando eu rodar esse eval. Ele vai rodar o eval e pegar todas as etapas que a gente definiu, que estão configuradas aqui dentro do SAC eval. Então, vai chamar e definir o eval aqui com essa função, né? E aí vai rodar todos os casos que temos ali.

06:09 Ao final disso, temos a nossa resposta, e ela fica guardada aqui dentro do nosso dashboard. Nesse dashboard específico, tenho aqui os casos: cada tarefa que foi executada, “pedido ainda em preparo”, “cliente cobra pedido sem se identificar” e todos os outros. Consigo avaliar modelo por modelo e, aqui, tenho uma visão geral de como cada um está se comportando nisso. Tenho meu próprio benchmark. Tenho meu sistema de agente: ele tem todas as tool calls que vão acontecer e todo o

06:40 workflow que esperamos que aconteça, e 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 e evals, sabendo medir em tempo real se o seu agente está funcionando ou não, trabalhar com teste A/B e com rollout de features específicas para agentes — perceba que estou falando de colocar agentes de verdade em produção —, estou com uma formação e uma lista de espera abertas 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 também no primeiro comentário fixado. Então, veja bem: aqui temos esses três modelos. O que está sendo avaliado aqui? A gente criou o nosso dataset e 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 agent alucinou, se o agent falou coisas que não deveria ter dito. E aí, como é que a gente pega isso? A gente trabalha no system prompt e também trabalha no output. Então, tudo

07:42 isso foi avaliado aqui dentro, junto com uma avaliação não só de conseguir completar a tarefa, mas também de qual tem 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 está em terceiro lugar; isso me surpreendeu. Quando rodei o benchmark, falei: “Cara, com certeza o Opus 5.5 vai ganhar isso aqui”. E não foi bem isso que aconteceu. Vamos lá. Luna 6: tirou nota 5, demorou, em média, 6,8 segundos para executar as

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

08:44 coisa. No Opus 5.5, ele gastou 6 centavos de dólar e levou 10 segundos, mas tirou nota 4,86. Isso significa que, em algum momento, seja na resposta que trouxe, ele trouxe uma informação que não deveria ter trazido; pode ser um pouco de alucinação, ele desrespeitou um system prompt ou 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 dataset só uma vez. Vai rodar o teste dessa avaliação várias vezes para pegar

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

09:45 outras colunas do gráfico, sobre as quais a gente vai falar para você já já. Olha que interessante. Como ficou o ranking? Luna 6, com 100% aqui, passou em todas as tarefas, levou 6,8 segundos e teve o menor custo possível. Na sequência, Gemini 3.8 Flash. Com um detalhe: ele usou a mesma família de LLMs para ser o juiz nesse nosso teste. 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 também está aqui. Teve um bom desempenho, nota 4,76 e 10 segundos de execução. Então, todos eles conseguiram concluir as tarefas, com 100% de aprovação, mas a nota não foi 100% para todos, porque, em algum momento, o nosso juiz, enquanto LLM, identificou que alguma regra foi desrespeitada: seja falar em um idioma diferente, seja não responder alguma coisa que deveria ter respondido ou vice-versa. Por

10:46 exemplo, se a pessoa está passando mal, jamais mencionar reembolso quando ela está reclamando que se intoxicou. A primeira mensagem específica tem que ser: “Procure um médico. Aqui estão as referências”. Esse é um tipo de caso que a gente capta aqui no LLM as a Judge. Perceba que aqui também temos o Deep Seek V4.1 Flash, que não passou em todas as tarefas e levou 4,9 segundos. Ou seja, se tivesse passado em todas as tarefas, estaria em primeiro lugar em termos de tempo, mas também foi bem mais caro que o Luna 6, OK? Então, olha que interessante.

11:17 Agora, tenho um mecanismo para responder quando alguém me perguntar: “Qual é o melhor LLM?”, vou dizer: “No meu stack lá do Fominha, o melhor LLM, disparado, é o Luna 6”. Vamos analisar os outros aqui. GLM 5.3 Flash também não teve um bom desempenho. O Raiku 5.5 me desapontou nesse caso: também não acertou todas as tarefas e não foi mais rápido. E aqui temos o Mimo V2.6 Flash, que também desapontou para caramba; foi o pior nesta avaliação. Agora, falando sobre qualidade versus custo, também temos isso aqui.

11:48 Então, o mais caro de todos é o Opus 5.5, com qualidade alta; aqui está o mais barato de todos, o Luna 6. E aqui a gente também avalia a qualidade versus o custo no nosso próprio benchmark desse sistema. Vou ter clareza sobre em que cada modelo falha, com base nas tarefas que criamos dentro dessa estrutura de avaliaçã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 tanto nas tarefas fáceis quanto nas médias. Nas difíceis, 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 vai acertar as tarefas mais fáceis, e vice-versa. Também não é porque ele é o modelo mais baratinho que vai errar as mais difíceis. Se o DeepSeek-V4.1 Flash está sendo mais rápido para a gente e eu quero muito usar esse modelo, talvez a alteração que eu faça seja identificar essa tarefa específica e

12:50 ver: será que, se eu mudar o system prompt, será que, se eu mudar alguma coisa no harness do meu agent, consigo fazer o agent passar aqui? Então, olha bem: estou falando de ter dados para saber qual modelo é o melhor e, a partir disso, também poder alterar o meu próprio harness para melhorar a execução. É exatamente o que o Claude Code e o Codex fazem com os próprios LLMs. Eles pegam o modelo, identificam onde ele falha e aí trazem recursos para melhorar, com base no harness, a qualidade do output do modelo. Então, aqui a gente poderia aplicar isso. Ou digamos que, sei lá, o

13:21 Raiku 5.5 seja muito melhor para a gente e o custo dele seja muito melhor. Quero usar esse modelo de qualquer jeito. Então, vamos lá, vamos usar de qualquer jeito. Vou identificar as tarefas em que ele falha, melhorar, alterar esse system prompt e reexecutar a nossa avaliação até ele conseguir ter um desempenho bom o suficiente. Aqui a gente consegue trabalhar nisso e não ficar refém do modelo. Se você gostou dessa ideia e quer ver esse código com as próprias mãos, também deixei o link do material aqui na descrição para você poder baixar e validar esse código. Aqui temos um caso de uso específico

13:52 para você entender quando um juiz vai falhar, vai dar uma nota ruim para o modelo. Olha só. O cliente cobra o pedido sem se identificar. Então, o cliente não informou e-mail, telefone nem número do pedido. Pela política, o agent deve pedir identificação antes de consultar qualquer coisa. E é justamente aqui que o Raiko 5.5 foi aprovado, enquanto o Deep Seek V4.1 Flash e o Mimo V2.6 Flash falharam. Eles falharam em executar a tarefa? Não necessariamente. Falharam na avaliação do juiz. Para que serve o LLM as a Judge? Para 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 resolver simplesmente com código. Então, logo no começo, o Raiko 5.5 trouxe o seguinte: “Oi, sinto muito pela demora. Para localizar seu pedido, informe o e-mail ou o telefone cadastrado na sua conta, por favor.” Aqui, onde o V4.1 Flash falhou? Ele não demonstrou empatia pela espera do cliente. Simplesmente respondeu: “Oi, vou verificar isso para você agora mesmo.” E mandou um sorrisinho. A mesma coisa aconteceu com o Mimo V2.6 Flash. Ou seja, se eu quero avaliar, dentro do meu workflow, não só se ele consegue executar a lógica, mas também se está respeitando uma regra do meu system prompt, uma instrução que passei — seja a de sempre demonstrar empatia quando alguém relatar um problema —, consigo captar isso com o LLM as a judge. O mesmo caso aqui: o cliente cobra um estorno que já está em processamento. Aqui, você vai observar que o Mimo V2.6 Flash falhou: informou que o estorno de 83,90 já está em processamento. Então, seria uma questão de dados a serem apresentados, e eu consigo avaliar cada uma das respostas. Um ponto interessante aqui é que também consigo avaliar qual ferramenta foi chamada,

14:56 qual resposta ela trouxe para a gente naquele momento. E é assim que vamos trabalhar com Involves. Vou criar essa estrutura de tarefas, de etapas que precisam ser seguidas, e definir a expectativa para a avaliação final: quão boa foi a resposta, se atendeu ao que era esperado, se estava no idioma certo e por aí vai. Percebo que os problemas que temos hoje com fluxos de agentes não são tão diferentes dos que temos no desenvolvimento de software. Vou precisar trabalhar com uma funcionalidade específica, vou trabalhar com sinalizadores de funcionalidade, que são a ideia de poder fazer testes A/B, e com a ideia de poder fazer um lançamento gradual, ou seja, liberar uma atualização somente para uma parte dos meus clientes, enquanto a outra parte continua usando outra versão. Trabalhar com observabilidade e tudo isso é exatamente o que vamos ensinar na nossa formação Agent Builder. Então, se você está curtindo este vídeo, já peço que se inscreva na lista de espera. Tenho certeza de que você vai curtir para caramba, e garanto que não viu nada igual no mercado. O maior insight que você vai ter quando começar a rodar esses testes é que aquele modelo que está em alta, aquele de quem todo mundo está falando no mercado agora, talvez não seja o melhor para o seu caso de uso. O Open 5.5 está dizendo aqui,

15:26 dando a letra, né? Claramente, ele não é o melhor modelo para usarmos neste nosso workflow agêntico. E, com isso, você vai começar a ter as respostas de que o mercado precisa. O mercado sempre vai perguntar para você: “Tá, vamos lá. Você vai construir meu workflow de agentes aqui, vai construir meus multiagentes. Quero saber quanto vou gastar com isso, quero saber se a qualidade está boa, quero saber se meu cliente lá na ponta está satisfeito com o atendimento ou se simplesmente coloquei uma IA para atendê-lo e, toda vez, ele responde ao meu agente: ‘Ah, eu quero falar com um humano’.” Se toda vez o

15:58 seu cliente responder ao agente que quer falar com um humano, provavelmente o seu sistema de agentes não é interessante. Não é que as pessoas sejam simplesmente resistentes a usar um agente de IA. Provavelmente, é porque o seu agente de IA ainda não parece algo que de fato reduza a fricção para o usuário: a ideia de eu pedir algo e ele me retornar aquilo de que eu precisava. E aí, com um sistema de observabilidade bem estruturado — existem várias ferramentas no mercado —, trabalhando com Involves, você consegue perceber isso durante a execução e antes dela. Antes da execução, com o Involves rodando no conjunto de dados; e depois

16:29 em produção, com dados reais de usuários interagindo com aquilo. Se você curtiu este vídeo, eu sou o Vini, e este é o canal da AI Code Academy. Ajudo pessoas como você a aprimorar suas habilidades de desenvolvimento de software na era da inteligência artificial. No mais, estamos juntos. Aquele abraço e valeu.

17:00 Se o seu cliente responde ao agente que quer falar com um humano, provavelmente o seu sistema de agentes não está interessante. Não é que as pessoas estejam simplesmente resistentes a usar um agente de IA. Provavelmente é porque o seu agente de IA ainda não parece algo que realmente reduz a fricção para o seu usuário. A ideia é eu pedir algo e ele me retornar aquilo de que eu precisava. E aí, a partir de um sistema bem estruturado de observabilidade, há várias ferramentas no mercado. Trabalhando com o Involves, você consegue perceber isso durante a execução e antes da execução. Antes da execução, com o Involves rodando no dataset, e depois

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

Transcrição original

[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.