Por que a escrita de IA ainda parece slop — Louis-François Bouchard, Towards AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: português

Vídeo original: Why AI Writing Still Reads Like Slop — Louis-François Bouchard, Towards AI · Canal: AI Engineer · 18:30 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Geração de conteúdo com IA

Resumo

Louis-François Bouchard apresenta o Tone-Bench, um benchmark para avaliar a capacidade de modelos de IA de produzir escrita criativa que soe natural e corresponda ao tom de uma pessoa específica. O benchmark avalia dez roteiros com nove métricas, combinando juízes LLM e comparações humanas, e considera aspectos como tom, qualidade da escrita, cumprimento de instruções, precisão da pesquisa e slop. Bouchard destaca a variabilidade entre gerações e os vieses dos juízes LLM, além do custo elevado de construir e atualizar avaliações desse tipo. Suas recomendações incluem fornecer prompts detalhados, limitar as revisões automatizadas, gerar vários rascunhos e manter a revisão humana.

Pontos-chave

O slop não se limita ao uso excessivo de certas palavras: também pode ser genérico, repetitivo, impreciso e ter um tom que não corresponde ao de quem escreve.
O Tone-Bench avalia se modelos conseguem produzir roteiros que soem como se tivessem sido escritos por Louis-François Bouchard.
O benchmark usa dez tarefas e cinco gerações por modelo para observar a variabilidade dos resultados em tarefas criativas.
As nove métricas do benchmark abrangem aspectos como tom, qualidade da escrita, cumprimento de instruções, precisão da pesquisa e slop.
Juízes LLM podem favorecer modelos da própria família; por isso, é importante usar juízes de famílias diferentes e conferir os resultados.
A equipe comparou manualmente mil pares de trechos de roteiros gerados para incluir avaliação humana.
Construir o benchmark exigiu cerca de 500 horas de trabalho inicial, e alterações nas rubricas ou nos prompts podem custar milhares de dólares.
Para melhorar a escrita gerada, Bouchard recomenda prompts longos com exemplos positivos e negativos, várias gerações e revisão humana.

Capítulos

Início	Capítulo	Resumo
00:13	O que é slop e por que importa	Bouchard descreve características comuns de textos de IA que parecem gerados e apresenta a necessidade de medir esse problema.
02:53	Por que criar o Tone-Bench	O apresentador explica a motivação para criar um benchmark de escrita criativa e apresenta a experiência da equipe da Towards AI.
05:27	Como o benchmark funciona	O Tone-Bench usa prompts detalhados, dez roteiros e várias gerações por modelo para avaliar a escrita.
09:06	Métricas e juízes LLM	Bouchard apresenta as métricas de avaliação, explica o formato das rubricas e alerta sobre vieses dos juízes LLM.
13:48	Avaliação humana e custo	A equipe compara pares de textos manualmente e relata o tempo e os custos necessários para construir e alterar o benchmark.
15:23	Aprendizados e recomendações	Bouchard recomenda prompts detalhados, múltiplos rascunhos, seleção por um modelo mais capaz e revisão humana.

Citações

Simplesmente não soa como você. — 02:22

Se eu consigo ler em voz alta sem me sentir desconfortável com palavras que eu mesmo não usaria. — 05:58

Você só quer encontrar um modelo que seja o menos irritante para chegar onde deseja. — 15:23

Você quer uma revisão humana. Não tem como escapar disso. — 18:30

Conceitos e entidades

slop (conceito): Termo usado no vídeo para descrever textos de IA percebidos como genéricos, repetitivos, imprecisos ou com um tom inadequado.
Tone-Bench (conceito): Benchmark apresentado no vídeo para avaliar a escrita criativa de modelos, incluindo sua capacidade de reproduzir um tom específico.
EQ-Bench (conceito): Benchmark cuja pontuação de slop é usada junto com avaliações próprias no Tone-Bench.
LLM as a judge (conceito): Método em que modelos avaliam a qualidade dos textos gerados, sujeito a preferências e vieses.
GPT-6.1 (modelo): Modelo citado como exemplo de modelo mais avançado que, ainda assim, não elimina o problema do slop.
Grok 4.7 (modelo): Modelo citado como exemplo de resultados com alta variabilidade entre diferentes gerações.
Opus 5.5 (modelo): Modelo usado na comparação de resultados e custos e mencionado como opção para selecionar ou combinar rascunhos.
GLM 5.3 flash (modelo): Modelo apresentado como uma opção barata e eficaz para gerar rascunhos em escala.
Towards AI (empresa): Empresa de educação e engenharia de IA de cuja equipe o apresentador faz parte.
Louis-François Bouchard (pessoa): Apresentador do vídeo e criador do benchmark Tone-Bench.
Karpathy (pessoa): Pessoa citada por ter chamado atenção para um possível apocalipse do slop.

Tradução completa (pt-BR)

00:13 Então, estou aqui para falar sobre todas essas palavras que chamamos de “lixo” e, mais importante, quero tentar ajudar a corrigir o que Karpathy chamou de apocalipse do “lixo”, que ele achava que começaria em 2026. Acho que já estamos vendo isso nas redes sociais. Para tentar consertar isso e acabar com esse “lixo”, primeiro precisamos defini-lo. Afinal, o que é “lixo”?

00:46 Existem várias definições diferentes, dadas por vários especialistas da área, mas acho que todos podemos concordar que é muito ruim ler algo que parece ter sido gerado por IA. Geralmente, esse tipo de texto se parece com isto, com palavras que conhecemos, como “aprofundar-se”, “gera” e outras coisas do tipo. O problema principal é que, mesmo com modelos melhores, como o GPT-6.1 e todos os outros, esse tipo de texto não parece desaparecer. Ele continua aumentando.

01:18 Portanto, parece que precisamos de algo diferente de apenas treinar mais os modelos. Quero mesmo tentar, pelo menos, definir primeiro o que é esse tipo de texto para que possamos entender por que ele existe. Para mim, ele é composto por seis elementos principais. Primeiro, há várias palavras usadas em excesso por modelos de linguagem que nós não usamos de verdade, como “aprofundar-se”, que conhecemos muito bem. Segundo, o texto geralmente é genérico demais. Fala sempre sobre a maioria das coisas, a maioria dos projetos. Não compartilha nada específico. Eu mesmo

01:51 sou culpado de usar isso no LinkedIn também, o que acho que é o padrão da plataforma, então é normal por lá. E, pior ainda, textos desleixados geralmente não dizem nada. São apenas palavras bonitas agrupadas, que nem costumamos usar. Pior do que isso: não dizem nada e ainda se repetem muito. Então, repetem o vazio e são genéricos demais. E, pior ainda, alucinam. Como

02:22 sabemos, os modelos alucinam, então também não podemos confiar totalmente em textos desleixados. Por último, o pior para mim é que geralmente têm o tom errado ou, pelo menos, não têm tom nenhum, como se tivessem o tom de todo mundo ao mesmo tempo. Simplesmente não soam como você. Não compartilham coisas que você compartilharia. Portanto, meu objetivo aqui hoje, e com este projeto em que venho trabalhando, é, primeiro, medir essa escrita desleixada. Não apenas as palavras associadas a esse tipo de texto. Não quero reconstruir a pontuação de texto desleixado do

02:53 EQ-Bench. Trata-se realmente de medir o quanto um texto é desleixado. Para fazer isso, estamos lançando hoje, neste exato momento, um novo benchmark que chamamos de Tone-Bench. O principal objetivo desse benchmark é medir se os novos modelos são bons em escrita criativa, algo que também tentarei definir. Então, este é o plano para hoje: justificar se realmente precisamos de outro benchmark; depois, explicar como ele funciona e o que medimos, como o construímos, e compartilhar o custo de construção, nossas decisões, o que já aprendemos sobre escrever com IA a partir do benchmark e mais algumas coisas sobre ele.

03:25 Dito isso, vamos começar. A primeira pergunta é: realmente precisamos de mais um benchmark? Olhando para o LinkedIn e para as respostas no X — as minhas respostas no X —, acho que precisamos. É como se as pessoas estivessem

03:56 enviando cada vez mais spam de conteúdo gerado. Então, que esse conteúdo seja pelo menos razoavelmente bom. Mais especificamente, eu também preciso muito disso. Somos uma equipe pequena na Towards AI, minha empresa, e temos um setor dedicado à educação. Criamos toneladas de conteúdo educacional, principalmente sobre engenharia de IA. Como somos uma equipe pequena, obviamente também usamos IA para isso. E tem sido extremamente irritante revisar constantemente esse lixo e tentar consertá-lo.

04:26 Eu publiquei centenas de vídeos. Publicamos milhares de artigos. Lançamos um livro e estamos trabalhando em um segundo, sobre engenharia de IA. Portanto, precisamos muito dos melhores modelos possíveis, que nos ajudem a escrever melhor e não sejam cheios de lixo. Outra coisa legal é que venho compartilhando informações sobre este benchmark no X há algum tempo, enquanto o construía. E ele teve um engajamento muito

04:57 bom. As pessoas parecem confirmar que precisávamos de algum tipo de benchmark de escrita mais criativa como este. Por último, só para provar que acho que somos a equipe certa para trabalhar neste benchmark: venho avaliando modelos de IA desde o meu mestrado e, depois, no doutorado. Agora, na Towards AI, construímos pipelines de avaliação para nossos clientes. Temos 15 engenheiros de IA

05:27 conosco, além de escritores criativos e editores na equipe. Já temos tudo isso para o nosso conteúdo. Então, acho que queria aproveitar esses recursos para construir um benchmark e ajudar ainda mais a comunidade. Então, o que construímos exatamente? Espero compartilhar o máximo possível e fico feliz em conversar, caso possamos ajudar você a construir o seu próprio ou caso eu possa simplesmente compartilhar alguns dos nossos aprendizados. Então, o que construímos é algo muito subjetivo. É uma

05:58 forma de medir se um modelo consegue escrever como eu. E defino isso de maneira simples: consigo ler o texto em voz alta agora mesmo sem me sentir desconfortável com palavras que eu mesmo não usaria? O processo do benchmark é muito simples. Temos um prompt com um resumo e uma pesquisa, que enviamos a um modelo e, com sorte, ele gera um roteiro de vídeo completo que eu poderia ter escrito.

06:29 Obviamente, isso não acontece. Geralmente, o resultado é bem ruim, mas esse é o objetivo. Avaliamos o roteiro final com base nas nossas rubricas e em todo o nosso pipeline de avaliação. O prompt que enviamos a cada modelo no benchmark é muito mais detalhado do que isso. Ele se parece mais com isto: temos muitos detalhes sobre como falo e escrevo, além de toneladas de exemplos de vídeos de conteúdo anteriores.

07:00 Temos muitas informações sobre storytelling em geral, frases na voz ativa e simplesmente sobre como escrever bem. Também temos instruções sobre o que gerar e fazer nesta tarefa específica, na qual o modelo deve gerar um roteiro. E este é apenas um dos roteiros. No benchmark atual, temos 10 roteiros diferentes, nos quais trabalhamos muito para deixá-los o melhor possível. Também criamos rubricas para ajudar, como

07:30 veremos, os juízes LLM a avaliar essas gerações. Temos 10 roteiros diferentes. Alguns foram publicados, outros não. Não dizemos quais são os roteiros do benchmark para que também possamos verificar a contaminação. Então, o que fazemos com esses 10 roteiros? Pegamos todos os modelos disponíveis e tentamos avaliar as gerações deles. Isso significa que, para cada modelo, fazemos esse processo 10 vezes, gerando o artigo a

08:03 partir do prompt. Na verdade, geramos cinco versões. Em breve, vou explicar por quê. Depois, quatro juízes LLM diferentes as analisam. Recentemente, adicionei o Jeff como teste. Não tenho certeza se vou mantê-lo, mas o adicionei só para ver se funcionava bem. Então, no final, calculamos uma pontuação definitiva para o ranking. Vou percorrer todas essas etapas da esquerda para a direita. Primeiro, por que geramos cinco roteiros? Para verificar a variabilidade dentro de cada modelo. Recomendo muito fazer isso se você estiver criando suas próprias avaliações, porque, especialmente em tarefas criativas, às vezes, como vemos aqui com o Grok 4.7, algumas gerações são pontos fora da curva. Como vemos no benchmark, ele é tão bom quanto o Opus 5.5, mas só em uma geração a cada cinco.

08:35 Queremos medir isso. Quanto pior o modelo, maior a variância. Temos alguns aprendizados sobre isso que também compartilharei no final. Mas, sim, descobrimos que cinco rascunhos

09:06 parecem ser um bom meio-termo em termos do custo para executar o processo e medir essa variabilidade. Então, o que medimos exatamente e como quantificamos a qualidade da escrita? Esse tem sido o desafio, e trabalhamos nele por bastante tempo. No momento, tudo está aberto no benchmark, e há muito mais detalhes na página do benchmark também. Medimos nove métricas diferentes, que descrevemos em detalhes, mas posso condensar em cinco aspectos principais.

09:38 Primeiro, medimos o tom. Então, o texto soa como eu? Ou seja: o modelo consegue se adaptar a um tom específico? Segundo, avaliamos simplesmente se a escrita é boa. Tem bons ganchos, boas transições emocionais e todos os aspectos que buscamos em uma boa história? Também medimos se as instruções foram seguidas. O texto respeitou o comprimento e o formato esperados? Incluiu as imagens

10:11 certas e colocou as coisas certas no lugar certo? Em quarto lugar, medimos a precisão da pesquisa. Temos um resumo de pesquisa junto com cada roteiro e avaliamos apenas se o modelo alucinou ou usou a pesquisa corretamente. Por último, medimos o texto desleixado usando a pontuação correspondente do EQ-Bench, mas também as nossas próprias medições. E é mais ou menos assim que isso aparece para os juízes.

10:42 Temos cerca de mil palavras de exemplos e instruções sobre cada métrica, junto com o roteiro para analisar, meu próprio roteiro como uma espécie de orientação, além do resumo e da pesquisa. Então, ao todo, é um prompt de 14.000 palavras que enviamos para cada juiz para obter o feedback que analisaremos a seguir. Assim, o juiz apenas analisa a qualidade da escrita. Ele não foca

11:14 no tamanho e não sabe qual modelo está escrevendo. Fazemos isso depois, com código propriamente dito. Em uma métrica como tom e voz, que é a nossa principal, funciona mais ou menos assim: temos várias descrições detalhadas sobre qual é o tom e o que esperar, além de como analisar isso. Primeiro, o juiz classifica o texto em seis categorias e, depois de encontrar uma categoria, atribui uma nota.

11:45 Descobrimos que essa é a melhor forma de medir essa tarefa, que é mais qualitativa, em vez de usar apenas uma lógica binária, categorias diretas ou porcentagens. Percebemos que isso funciona muito bem. E há muitos exemplos do que cada pontuação significa em termos de escrita para cada tarefa. O que o juiz retorna é algo assim. Ele traz as

12:16 nove métricas pontuadas, com uma justificativa para cada nota e um exemplo, como: “Dei esta nota por causa deste exemplo em particular”. Mas o ponto principal é que tudo isso é automatizado. Obviamente, com 120 modelos, geramos cinco rascunhos para cada uma das 10 tarefas. Isso rapidamente chega a milhares de roteiros para revisar, então não podemos realmente revisar tudo sozinhos. E o problema com juízes de LLM é

12:46 que eles têm preferências. Alguns modelos preferem a si mesmos. A maioria dos modelos prefere a si mesma. E, particularmente, a OpenAI. O que achei bastante engraçado ao estudar isso é que parece que a Anthropic e a OpenAI estão realmente em uma guerra: parece que fizeram um pós-treinamento para se odiarem, o que é bem divertido. Mas tudo isso é para dizer que você realmente precisa verificar quando usa juízes de LLM, como o GPT, por exemplo. Se quiser

13:17 saber qual modelo é o melhor para sua tarefa, tenha cuidado e use diferentes famílias de modelos, só para garantir, pois vemos aqui que a OpenAI realmente tem uma forte preferência por sua própria família de modelos — não apenas por um modelo, mas por todos os modelos da OpenAI. Para corrigir isso também, recebemos alguns comentários no X sugerindo usar humanos para uma tarefa criativa. Isso seria ideal, mas bastante impraticável. Ainda tentamos fazer

13:48 isso de uma forma escalável. Agora, eu e três membros da minha equipe comparamos manualmente 1.000 pares A/B de roteiros gerados — não os roteiros completos, mas uma boa parte comparável entre dois roteiros, duas gerações. Esperamos fazer mais, e também quero divulgar isso para obter ajuda da comunidade no futuro, mas não agora. Então, quanto isso nos custou e qual é a carga de trabalho por trás disso? Para mim, para nós, o custo

14:21 inicial, em horas, foi de cerca de 500 horas para criar os 10 roteiros, definir todas as rubricas, encontrar os exemplos e tentar quantificar a qualidade, o que é muito difícil. Depois, eu mesmo fiz as iterações com quatro assinaturas 20X diferentes por quatro meses para construir um benchmark e todo o resto, experimentando e alterando a proporção das métricas e todas essas coisas. E assim simplesmente gastamos milhares de

14:53 dólares nisso. Se você quiser fazer um tipo semelhante de benchmark, precisa saber que custa bastante. Agora, se eu mudar apenas uma coisa nas rubricas ou na forma como o avaliador classifica as gerações, isso nos custará mais de 2.000 dólares. E, se eu mudar apenas uma linha em um prompt de entrada para um modelo quando ele gera algo, isso nos custa mais de 4.000 dólares. Portanto, é muito caro experimentar e mudar essas coisas no

15:23 prompt. Então, você quer fazer isso com cuidado. Agora, o que podemos tirar desse benchmark, o Tone Bench? Você pode encontrar muitas informações no próprio site. Há muitos detalhes por lá. Mas, o mais importante, quero compartilhar o que aprendi nos últimos quatro meses: para redação criativa, você não quer escolher o modelo que gerará uma postagem incrível logo de primeira. Você só quer encontrar um modelo que seja o menos irritante para chegar onde deseja. Então, acho que não haverá perfeição tão cedo. E o que isso significa agora no benchmark é que, em escala, o GLM 5.3 flash é extremamente bom e extremamente barato. Ele é 50 vezes mais barato que o melhor, que é o Opus 5.5 extra high, que, por sua vez, é 2,5 vezes mais barato que o Max thinking, mas com os mesmos resultados. Portanto, em geral, você não quer usar o Max para escrever. E, além

15:54 menos irritante para você chegar onde deseja. Então, acho que não haverá perfeição tão cedo. E o que isso significa agora no benchmark é que, em escala, o GLM 5.3 flash é extremamente bom e extremamente barato. Ele é 50 vezes mais barato que o melhor, que é o Opus 5.5 extra high, que, por sua vez, é 2,5 vezes mais barato que o Max thinking, mas com os mesmos resultados. Portanto, você geralmente não quer usar o Max para escrever. E, além

16:25 disso, a melhor forma de escrever com modelos que extraímos disso é, primeiro, ter um prompt extremamente longo e detalhado. Ele nunca será longo o suficiente: quanto mais longo, melhor. Você deve adicionar todos os exemplos que puder imaginar sobre o que fazer e como fazer. O mesmo vale para exemplos negativos de coisas de que você não gosta, que não soam bem, e palavras que você não quer — tudo. Você pode compartilhar tudo; se escrever boletins informativos ou qualquer outra coisa, pode compartilhar na íntegra, e isso também será melhor.

16:56 E o que vimos que realmente ajuda muito é usar um juiz com alto nível de raciocínio apenas uma vez — ou de uma a três vezes. Caso contrário, ele entrará em um ciclo de desleixo. Então, basta fazer uma revisão por outro modelo, com as mesmas instruções, que dará um feedback ao autor. Na verdade, não tenho métricas quantitativas sobre isso, mas ajuda bastante. E, para uma empresa que trabalha com APIs e quer obter os melhores resultados possíveis em escala, o que sugiro é

17:28 gerar vários rascunhos, uns 10, de algo específico com um modelo mais barato, como o GLM 5.3 flash. Depois, use um juiz mais inteligente, com alto nível de raciocínio, como o Opus ou qualquer outro que você queira, para selecionar e combinar as melhores partes de cada um desses rascunhos. Acho que isso ainda sairá bem mais barato do que fazer apenas uma geração pelo Opus 5.5. E

17:58 acho que levará a melhores resultados, pelo que tenho visto. Por último, você precisa de uma revisão humana. Não tem como escapar disso. Mas todos esses benchmarks obviamente medem a minha opinião, então são super subjetivos. São apenas um ponto de referência; você não deve confiar cegamente neles. Isso não significa que o Opus 5.5 seja o melhor modelo. Mas, idealmente, é um sinal forte para descobrir qual modelo é bom em escrita e qual é menos desleixado. Sugiro que você construa seus

18:30 próprios pipelines de avaliação. Se quiser, podemos ajudar. Você pode conversar conosco ou entrar em contato. Quanto ao benchmark, ele está disponível. Acabamos de publicá-lo e lançá-lo. Há muitos gráficos, muitos insights, muitas comparações e detalhes sobre a implementação, além da metodologia completa. Então, dê uma olhada. Espero que seja útil. Obrigado.

Transcrição original

[00:13] Então, estou aqui para falar sobre todas essas palavras que chamamos de “ slop” e, mais importante, quero tentar ajudar a corrigir o que Karpathy chamou de apocalipse do “slop”, que ele achava que começaria em 2026, e acho que já estamos vendo isso nas redes sociais. Então, para tentar consertar isso e parar o “slop”, primeiro precisamos defini-lo. Primeiro, o que é “slop”?

[00:46] Existem várias definições diferentes de vários especialistas na área, mas acho que todos podemos concordar que é muito ruim ler algo que parece gerado. E geralmente parece com isso, com as palavras que conhecemos, como “delve”, “generates” e outras coisas do tipo, e o problema principal é que, mesmo com modelos melhores como o GPT-6.1 e todos os outros, o “slop” não parece ir embora. Ele continua aumentando.

[01:18] Portanto, parece que precisamos de algo diferente do que apenas treinar mais os modelos. E eu realmente quero tentar, pelo menos, definir primeiro o que é “ slop” para que possamos entender por que ele existe. Para mim, o “slop” é composto por seis coisas principais. Primeiro, há várias palavras usadas em excesso por modelos de linguagem que nós não usamos de verdade, como “ delve”, que conhecemos muito bem. Segundo, geralmente é genérico demais . Sempre falando sobre a maioria das coisas, a maioria dos projetos. Não compartilha nada específico. Eu mesmo

[01:51] sou culpado de usar isso no LinkedIn também, o que acho que é o padrão do LinkedIn, então é normal por lá. E pior, textos desleixados geralmente não dizem nada. São apenas palavras bonitas juntas que nem costumamos usar. E ainda pior do que isso, não diz nada , mas também se repete muito. Então ele repete o nada e é genérico demais . E, ainda pior, ele alucina. Como

[02:22] sabemos, os modelos alucinam, então também não podemos confiar totalmente em textos desleixados. E por último, o pior para mim é que geralmente tem o tom errado ou, pelo menos, não tem tom nenhum, como se fosse o tom de todo mundo ao mesmo tempo. Então, simplesmente não soa como você. Não compartilha coisas que você compartilharia. Portanto, meu objetivo aqui hoje e com este projeto em que venho trabalhando é, primeiro, medir essa escrita desleixada. Não apenas palavras de “slop”. Não quero reconstruir a pontuação de “slop” do

[02:53] EQ-Bench. É realmente sobre medir o quão desleixado um texto é. Então, para fazer isso, hoje, agora mesmo, estamos lançando um novo benchmark que chamamos de Tone-Bench. O objetivo principal desse benchmark é medir se os novos modelos são bons em escrita criativa, o que eu também tentarei definir. Então, aqui está o plano para hoje. O plano é justificar se realmente precisamos de outro benchmark . Depois, como ele funciona, o que

[03:25] medimos, como o construímos, e quero compartilhar o custo de construção, nossas decisões, o que já aprendemos sobre escrever com IA a partir do benchmark e compartilhar mais algumas coisas sobre isso. Então, dito isso, vamos começar. Primeira coisa: nós realmente precisamos de mais um benchmark? E olhando para o LinkedIn e para as respostas no X, as minhas respostas no X, eu acho que precisamos. É como se as pessoas estivessem

[03:56] enviando cada vez mais spam de conteúdo gerado. Então, que pelo menos seja decentemente bom. E, mais precisamente, eu também preciso muito disso. Somos uma equipe pequena na Towards AI, minha empresa, e temos um lado da empresa focado em educação. Criamos toneladas de conteúdo educacional, principalmente para engenharia de IA. E como uma equipe pequena, obviamente, também usamos IA para isso. E tem sido extremamente irritante revisar esse lixo constantemente e tentar consertá-lo.

[04:26] Nós, eu publiquei centenas de vídeos. Publicamos milhares de artigos. Lançamos um livro. Estamos trabalhando em um segundo, para engenharia de IA. E , portanto, precisamos muito ter os melhores modelos possíveis que nos ajudem a escrever melhor e que não sejam cheios de lixo. E outra adição legal a isso é que venho compartilhando sobre este benchmark no X há algum tempo, conforme o construía. E teve um engajamento muito

[04:57] bom, e as pessoas parecem confirmar que precisávamos de algum tipo de benchmark de escrita mais criativa como este. E por último, apenas para provar que acho que somos a equipe certa para trabalhar neste benchmark, bem, eu venho avaliando modelos de IA desde o meu mestrado e depois no doutorado. E agora, na Towards AI, construímos pipelines de avaliação para nossos clientes. Temos 15 engenheiros de IA

[05:27] conosco, e temos escritores criativos e editores a bordo. Então, já temos isso para o nosso conteúdo. Então, acho que, bem, eu queria aproveitar isso para construir um benchmark e ajudar a comunidade ainda mais. Então, o que construímos exatamente? Espero, eu tento compartilhar o máximo possível, e fico feliz em conversar se pudermos ajudar até a construir o seu próprio ou se eu puder apenas compartilhar alguns dos nossos aprendizados. Então, o que construímos é super subjetivo. É uma

[05:58] forma de medir se um modelo consegue escrever como eu. E como eu defino isso é simplesmente se eu consigo ler em voz alta agora mesmo sem me sentir desconfortável com palavras que eu mesmo não usaria. Então, o processo é muito simples. O o benchmark o processo benchmark o processo de benchmark é muito simples. Temos um prompt que é o resumo e a pesquisa que enviamos a um modelo e, com sorte, ele gerará inteiramente um roteiro de

[06:29] vídeo que eu poderia ter escrito. Obviamente, isso não acontece. Geralmente é bem ruim, mas esse é o objetivo, e avaliamos esse roteiro final com base em nossas rubricas e em todo o nosso pipeline de avaliação. E o prompt que enviamos para cada modelo no benchmark é muito mais detalhado que isso. Ele se parece mais com isto, onde temos muitos detalhes sobre como falo, como escrevo, toneladas de exemplos dos meus vídeos de conteúdo

[07:00] anteriores. Temos muitas informações sobre storytelling em geral, frases ativas e apenas sobre como escrever bem . E temos instruções sobre o que gerar e o que fazer para esta tarefa atual, na qual o modelo geraria um roteiro. E este é apenas um deles. No benchmark atual, temos 10 roteiros diferentes que trabalhamos muito para deixar o melhor possível, e criamos rubricas para eles para ajudar, como

[07:30] veremos, juízes LLM a avaliar essas gerações. Então, temos 10 roteiros diferentes. Alguns deles são publicados, outros não. Não dizemos quais são os benchmarks para que possamos verificar também a contaminação. E então, o que fazemos com esses 10 roteiros? Pegamos todos os modelos disponíveis e tentamos medir suas gerações. O que isso significa é que, para cada modelo, faremos esse processo 10 vezes, gerando o artigo a

[08:03] partir do prompt. Na verdade, geramos cinco deles. Compartilharei muito em breve o porquê. Então, temos quatro juízes LLM diferentes analisando-os. Recentemente adicionei o Jeff como um teste. Não tenho certeza se vou manter , mas adicionei apenas para ver se funcionava bem. E então calculamos no final uma pontuação definitiva para o ranking. Vou percorrer todas essas etapas da esquerda para a direita. Então, primeiro, por que geramos cinco roteiros? É para verificar a variabilidade intra-modelo, o que eu

[08:35] recomendo muito se você estiver criando suas próprias avaliações, porque, especialmente em tarefas criativas, às vezes, como vemos aqui com o Grok 4.7, algumas gerações são pontos fora da curva, onde, como vemos no benchmark, ele é tão bom quanto o Opus 5.5, mas apenas em uma geração de cada cinco. Então, queremos medir isso, e quanto pior o modelo, maior a variância. Então, ah, temos alguns aprendizados sobre isso que compartilharei no final também. Mas sim, descobrimos que cinco rascunhos

[09:06] parecem ser o bom meio-termo em termos de custo para executarmos e medirmos essa variabilidade. Então, o que medimos exatamente e como quantificar a qualidade da escrita? Esse tem sido o desafio e trabalhamos nele por um bom tempo. No momento, tudo está aberto no benchmark e há muito mais detalhes na página do benchmark também. Mas o que medimos são nove métricas diferentes que detalhamos muito bem, mas que posso

[09:38] condensar em cinco aspectos principais. Primeiro, medimos o tom. Então, soa como eu? O que significa: o modelo consegue se adaptar a um tom específico? Segundo, medimos puramente : é uma boa escrita? Tem bons ganchos, boa transição emocional e todos os aspectos que buscamos em uma boa história? Então, medimos se segue as instruções. Seguiu o comprimento, o formato esperado? Colocou as imagens

[10:11] certas e as coisas certas no lugar certo? Quarto, medimos a precisão da pesquisa. Então, temos um resumo de pesquisa junto com cada roteiro e apenas medimos se ele alucinou ou usou a pesquisa corretamente. E por último, medimos o “slap” usando a pontuação de “slap” do EQ-Bench, mas também nossas próprias medições. E a aparência disso, em termos do que os juízes veem, é mais ou menos assim.

[10:42] Temos cerca de mil palavras de exemplos e instruções sobre cada métrica que temos, junto com o roteiro para analisar, meu próprio roteiro como algum tipo de orientação, além do resumo e da pesquisa. Então, ao todo, é um prompt de 14.000 palavras que enviamos para cada juiz para então obter o feedback que analisaremos a seguir. E assim, o juiz apenas analisa a qualidade da escrita. Ele não foca

[11:14] no tamanho e não sabe qual modelo está escrevendo. Nós fazemos isso depois, com código propriamente dito. Em uma métrica como tom e voz, que é a nossa principal, funciona mais ou menos assim: temos várias descrições detalhadas sobre qual é o tom e o que esperar, além de como analisar isso. Primeiro, o juiz classifica entre seis categorias e, depois de encontrar uma categoria, ele atribui uma nota.

[11:45] Descobrimos que essa é a melhor forma de medir essa tarefa mais qualitativa do que usar apenas uma lógica binária , categorias diretas ou porcentagem. Percebemos que isso funciona muito bem. E tem muitos exemplos do que cada pontuação significa em termos de escrita para cada tarefa. E o que o juiz retorna é algo assim. Ele traz as

[12:16] nove métricas pontuadas com uma justificativa para a nota e um exemplo como: “dei esta nota por causa deste exemplo em particular”. Mas o ponto principal é que tudo isso é automatizado. Obviamente, porque com 120 modelos, nós geramos cinco rascunhos para cada uma das 10 tarefas. Isso rapidamente chega a milhares de roteiros para revisar, então não podemos realmente revisar tudo sozinhos . E o problema com juízes de LLM é

[12:46] que eles têm preferências. Alguns modelos preferem a si mesmos. A maioria dos modelos prefere a si mesmos. E, particularmente, a OpenAI. E o que achei bastante engraçado ao estudar isso é que parece que a Anthropic e a OpenAI estão realmente em uma guerra, onde parece que fizeram um pós-treinamento para se odiarem, o que é bem divertido. Mas tudo isso para dizer que você realmente precisa verificar quando usa juízes de LLM, como o GPT, por exemplo; se quiser

[13:17] saber qual modelo é o melhor para sua tarefa, tenha cuidado e use diferentes famílias de modelos apenas para garantir, pois vemos aqui que a OpenAI realmente tem uma forte preferência por sua própria família de modelos, não apenas por um modelo, mas por todos os modelos da OpenAI. E para corrigir isso também, ouvimos alguns comentários que recebi no X, sugerindo usar humanos para uma tarefa criativa, o que seria ideal, mas bastante impraticável. Ainda tentamos fazer

[13:48] isso de uma forma escalável, onde agora comparamos manualmente, eu e três membros da minha equipe, 1.000 pares AB de roteiros gerados, não os roteiros completos, mas uma boa parte comparável entre dois roteiros, duas gerações. Esperamos fazer mais e quero divulgar isso também para obter ajuda da comunidade no futuro, mas não agora. Então, quanto isso nos custou e qual é a carga de trabalho por trás disso? Para mim, para nós, o custo

[14:21] inicial em horas foi de cerca de 500 horas para criar os 10 roteiros, definir todas as rubricas, encontrar os exemplos e tentar quantificar a qualidade, o que é muito difícil. E então eu mesmo fiz as iterações com quatro assinaturas 20X diferentes por 4 meses para construir um benchmark e todo o resto, experimentando e alterando a proporção das métricas e todas essas coisas. E assim nós simplesmente gastamos milhares de

[14:53] dólares nisso. E se você quiser fazer um tipo semelhante de benchmark, precisa saber que custa bastante. Agora , se eu mudar apenas uma coisa nas rubricas ou na forma como o avaliador classifica as gerações, isso nos custará mais de 2.000 dólares. E se eu mudar apenas uma linha em um prompt de entrada para um modelo quando ele gera algo, nos custa mais de 4.000 dólares. Portanto, é muito caro experimentar e mudar essas coisas no

[15:23] prompt. Então, você quer fazer isso com cuidado. Agora, o que podemos tirar desse benchmark, do Tone Bench? Você pode obter muitas coisas no próprio site. Há muitos detalhes por lá. Mas, importante, eu quero compartilhar que o que aprendi nos últimos 4 meses é que , para redação criativa, você não quer escolher o modelo que gerará uma postagem incrível de primeira. Você só quer encontrar um modelo que seja o

[15:54] menos irritante para você chegar onde deseja. Então, acho que não haverá perfeição tão cedo. E o que isso significa agora no benchmark é que, em escala, o GLM 5.3 flash é extremamente bom e extremamente barato. Ele é 50 vezes mais barato que o melhor, que é o Opus 5.5 extra high, que por sua vez é 2,5 vezes mais barato que o Max thinking, mas com os mesmos resultados. Portanto, você geralmente não quer usar o Max para escrever. E, além

[16:25] disso, a melhor forma de escrever com modelos que extraímos disso é, primeiro, ter um prompt extremamente longo e detalhado. Ele nunca será longo o suficiente, e quanto mais, melhor. Você deve adicionar todos os exemplos que puder pensar sobre o que fazer e como fazer. O mesmo vale para exemplos negativos de coisas que você não gosta, que não soam bem e palavras que você não quer, tudo. Você pode compartilhar tudo; se escrever newsletters ou qualquer coisa,

[16:56] pode compartilhar na íntegra, e será melhor também. E o que vimos que realmente ajuda muito é usar um juiz de alto raciocínio apenas uma vez, uma a três vezes, caso contrário, ele entrará em um ciclo de desleixo. Então, apenas uma revisão de outro modelo com as mesmas instruções que dará um feedback ao autor. Na verdade, eu não tenho métricas quantitativas sobre isso, mas ajuda bastante. E para uma empresa, se você trabalha com APIs

[17:28] e quer obter os melhores resultados possíveis em escala, o que sugiro é gerar vários rascunhos, tipo uns 10, de algo específico com um modelo mais barato como o GLM 5.3 flash. E então ter um juiz mais inteligente e de alto raciocínio como o Opus, ou qualquer outro que você queira, para selecionar e combinar as melhores partes de cada um desses rascunhos, o que eu acho que ainda sairá bem mais barato do que apenas uma geração pelo Opus 5.5. E

[17:58] eu acho que levará a melhores resultados, pelo que tenho visto. E por último, você quer uma revisão humana . Não tem como escapar disso. Mas todos esses benchmarks medem obviamente a minha opinião, então é super subjetivo, e é apenas um ponto, você não deve confiar cegamente nisso. Não significa que o Opus 5.5 seja o melhor modelo. Mas, idealmente, é um sinal forte para descobrir qual modelo é bom em escrita e qual é menos desleixado. Hum, eu sugiro que você construa seus

[18:30] próprios pipelines de avaliação. Se você quiser, nós podemos ajudar. Você pode conversar ou entrar em contato. E sobre o benchmark, ele está disponível. Nós acabamos de publicá- lo e lançá-lo agora mesmo. Então, há muitos gráficos, muitos insights, muitas comparações e detalhes sobre a implementação, além da metodologia completa. Então, dê uma olhada e espero que seja útil. Obrigado.