6 padrões que tornam o texto de IA difícil de ler

O texto de IA cansa porque foi otimizado para outro leitor

Texto de IA cansa de um jeito específico. Você lê dois parágrafos do ChatGPT ou do Claude, a informação está correta, mas o cérebro pede pausa. Não é preguiça sua. É arquitetura. Uma pesquisa da New York University com a University of Texas at Austin mediu isso em larga escala e encontrou seis padrões linguísticos que os modelos de fronteira repetem sem parar e que cobram um imposto direto da sua memória de trabalho.

Se você constrói produto com LLM, escreve com IA ou revisa saída de modelo o dia inteiro, precisa entender esse problema como operador, não como crítico literário. Não estamos falando de estilo bonito ou feio. Estamos falando de fricção de leitura, custo de revisão e latência humana. Cada frase mal construída aumenta o tempo que você gasta para validar, editar e colocar em produção.

O fato

A equipe testou 14 modelos em três cenários bem diferentes: conversa casual, sessões de código e ensaios argumentativos. No total foram 120 conversas, 45 sessões de programação e 980 ensaios. Do outro lado, texto humano real para comparação, com legendas de filmes, respostas do StackExchange e redações de estudantes. Entraram na lista nomes como Claude, GPT-5.6, GLM-5, Kimi K2.5, além de modelos abertos menores como Llama e Olmo.

O resultado é direto. Os modelos de fronteira abusam sistematicamente de estruturas raras em escrita humana. Eles criam combinações estranhas como 'reader-patience budget', esticam a distância entre sujeito e verbo até você perder o fio e empilham substantivos que obrigam o leitor a adivinhar quem modifica quem. Não é erro aleatório. É um dialeto consistente que aparece em conversa, código e ensaio.

Os seis padrões que travam a leitura

Os pesquisadores listaram seis vícios recorrentes. Vale ler com atenção porque você vai reconhecer todos no seu dia a dia com IA:

• Combinações raras: pares de palavras que humanos quase nunca usam juntos e que forçam uma decodificação extra.
• Dependências longas: como em 'A cat who can always get up and away is a much calmer cat', onde sujeito e predicado ficam longe demais e a memória de trabalho sofre.
• Conector apagado: trocar 'the book that the professor wrote' por 'the book the professor wrote' economiza uma palavra, mas cria microambiguidade.
• Substantivos empilhados: sequências como 'horror movie soundtrack generator' que deixam para o leitor decidir a hierarquia.
• Substantivo virando verbo: como 'calendar it' no lugar de 'put it in the calendar', que soa eficiente mas quebra a expectativa.
• Verbo animado em sujeito inanimado: como 'The whole conversation is eating its own tail', que dá para entender, mas exige um segundo de processamento a mais.

Como funciona: densidade venceu clareza

Na visão de operador, isso não é bug de vocabulário. É consequência de função objetivo. Linguagem humana equilibra dois custos: facilidade para produzir e facilidade para entender. Os LLMs atuais foram empurrados para o primeiro lado. Eles são treinados e reforçados cada vez mais em matemática, código e raciocínio lógico, tarefas onde o que conta é acertar, comprimir informação e encadear passos. Clareza para humanos não entra na métrica.

A mudança de RLHF para RLVR piorou esse desvio. No RLHF clássico, ainda havia gente no loop dizendo se o texto soava natural. No RLVR, o reforço com recompensa verificável tira o humano da jogada e premia resposta correta e densa. O modelo aprende um dialeto ótimo para resolver problema complexo e péssimo para ser lido por gente. É eficiente para a máquina, exaustivo para você. E isso tem reflexo direto em API, porque respostas mais densas e enroladas custam mais tokens, aumentam latência e exigem mais chamadas de revisão.

A prova de conceito do estudo é reveladora. Os autores treinaram um modelo menor com uma penalidade que recompensava respostas mais curtas. Em certas condições, o modelo passou a preferir a forma curta em quase todo contexto, até em padrões de frase que ele nunca tinha visto no treino. Humanos fazem o oposto. A gente escolhe entre forma curta e longa dependendo da situação, do público e do risco de ambiguidade. O modelo generalizou uma regra burra. A gente adapta. Essa diferença explica por que a saída parece correta e ao mesmo tempo cansativa.

O que isso muda na prática

Quem ganha com esse dialeto são os benchmarks e os agentes que leem saída de outros agentes. Se o seu pipeline é IA falando com IA, densidade alta até ajuda. Quem perde é quem coloca texto na frente de humano, com suporte, documentação, marketing, educação, jornalismo, produto. Ali o custo aparece em retrabalho, em leitura abandonada e em desconfiança. O famoso 'AI slop' não é só sobre conteúdo genérico. É sobre sintaxe que exige esforço.

A ação prática imediata é parar de pedir para o modelo 'escrever bem' e começar a restringir estrutura no prompt e no pós-processamento. Teste isso hoje: limite o tamanho da frase, proíba substantivos empilhados com mais de duas palavras, exija conector explícito como 'que' e 'onde', e peça verbo simples com sujeito claro. Em teste interno, trocar uma instrução vaga por três regras sintáticas reduz drasticamente a necessidade de reescrita. Outra saída é operacional: para texto voltado a humano, teste um modelo menor ou uma versão com menos otimização para raciocínio. No estudo, Llama e Olmo base ficaram mais próximos do humano, e a linha Olmo mostra a piora clara do base para o instruct até o Olmo Think, que já bate nível de fronteira. Post-training pesado cobra preço em legibilidade.

A tensão que ninguém quer admitir

Aqui fica a dúvida real. Será que dá para ter um modelo ótimo em código e matemática que também escreva de forma leve para humanos, ou vamos ter que bifurcar os modelos? O dado de que o Claude Opus 5.5 superou o Opus 5 em 19 de 21 comparações sugere que ajuste fino direcionado consegue melhorar. Mas isso escala quando a pressão do mercado é por raciocínio, agentes e custo por token? Um funcionário do time de ajuste do Claude admitiu que o Opus 4.6 foi o último bom modelo de escrita justamente porque os modelos novos foram otimizados para explicações técnicas voltadas a outros modelos.

Isso resolve ou só move o gargalo? Se você comprime mais informação por frase, economiza tokens na geração, mas transfere o custo para o leitor humano, que demora mais para revisar e erra mais na interpretação. Para quem opera, a conta precisa incluir tempo de edição, taxa de rejeição e suporte. Texto denso que precisa de três revisões não é mais barato. É mais caro com outra etiqueta.

Conclusão

No fim, a pesquisa só colocou número no que você já sentia: modelos de fronteira falam um dialeto denso que cansa gente. A pergunta que fica para quem constrói é simples e incômoda. Você vai continuar otimizando para acertar o benchmark ou vai voltar a otimizar para ser entendido?