Why AI Writing Still Reads Like Slop — Louis-François Bouchard, Towards AI
Read the Portuguese translation →
Author: AI Engineer · Watch on YouTube
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: Why AI Writing Still Reads Like Slop — Louis-François Bouchard, Towards AI · Channel: AI Engineer · 18:30 · Watch on YouTube
Topics: AI evaluation and benchmarks, Prompt and context engineering, AI content generation
Summary
Section titled “Summary”Louis-François Bouchard apresenta o Tone-Bench, um benchmark para avaliar a qualidade da escrita criativa gerada por modelos, com foco em tom, qualidade, cumprimento de instruções, precisão da pesquisa e slop. Ele explica como o benchmark funciona, por que avalia várias gerações de cada modelo e como combina juízes LLM com comparações humanas. Também compartilha os custos e as limitações do processo, incluindo vieses dos juízes. Por fim, recomenda usar prompts detalhados, gerar rascunhos alternativos e manter a revisão humana no fluxo de escrita.
Key points
Section titled “Key points”- Slop é caracterizado por escrita genérica, repetitiva, imprecisa e com tom inadequado, além do uso excessivo de certas palavras.
- O Tone-Bench avalia se modelos conseguem produzir textos criativos que soem como a escrita de uma pessoa específica.
- O benchmark mede nove métricas, agrupadas em cinco aspectos: tom, qualidade da escrita, cumprimento de instruções, precisão da pesquisa e slop.
- Avaliar cinco gerações por modelo ajuda a identificar a variabilidade entre rascunhos, especialmente em tarefas criativas.
- Juízes LLM podem favorecer modelos da própria família; por isso, é importante comparar diferentes famílias de modelos e incluir avaliações humanas.
- A criação do benchmark exigiu cerca de 500 horas de trabalho inicial e milhares de dólares; mudanças nos prompts e rubricas também podem ser caras.
- Para escrever melhor com IA, o palestrante recomenda prompts extensos, exemplos positivos e negativos e uma revisão por um modelo de alto raciocínio.
- Uma estratégia em escala é gerar vários rascunhos com um modelo mais barato, usar um modelo mais capaz para selecionar e combinar trechos e fazer uma revisão humana.
- O benchmark reflete uma perspectiva subjetiva e deve ser tratado como um sinal, não como uma medida definitiva de qual modelo é o melhor.
Chapters
Section titled “Chapters”| Start | Chapter | Summary |
|---|---|---|
| 00:13 | O que é slop e por que ele persiste | Bouchard define as características do slop e explica por que modelos melhores não parecem resolver o problema por si só. |
| 02:53 | Por que criar o Tone-Bench | O palestrante apresenta o objetivo do benchmark e explica a necessidade de avaliar escrita criativa para usos reais. |
| 05:27 | Como o benchmark funciona | Ele descreve os prompts detalhados, os dez roteiros de teste e a avaliação de várias gerações por modelo. |
| 09:06 | Métricas, juízes LLM e avaliação humana | Bouchard explica as dimensões avaliadas, o funcionamento das rubricas e os vieses dos juízes automatizados. |
| 14:21 | Custos e aprendizados do benchmark | O palestrante detalha o esforço necessário, apresenta resultados sobre modelos e compartilha recomendações para escrever com IA. |
| 17:58 | Limitações e lançamento | Ele ressalta a importância da revisão humana e da avaliação própria, e convida o público a consultar o benchmark publicado. |
Quotes
Section titled “Quotes”Simplesmente não soa como você. — 02:22
Se eu consigo ler em voz alta agora mesmo 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 você chegar onde deseja. — 15:23
Você não deve confiar cegamente nisso. — 18:30
Concepts and entities
Section titled “Concepts and entities”slop, Tone-Bench, EQ-Bench, LLM as a judge, GPT-6.1, Grok 4.7, Opus 5.5, GLM 5.3 flash, Towards AI, Louis-François Bouchard, Karpathy
Full transcript (original language)
Section titled “Full transcript (original language)”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.