AIARTIGO

Não existe transformação sem perda em texto de linguagem natural

Simon Willison destaca uma política de uso de IA na escrita que vale para quem constrói pipelines de NLP: todo rewrite muda o sentido, e alguém precisa responder pelo resultado.

Não existe transformação sem perda em texto de linguagem natural
Imagem: Alan Andrade

Em um post curto no seu blog, Simon Willison destaca uma frase que resume um problema conhecido de quem trabalha com processamento de linguagem natural: "não existe transformação sem perda de texto em linguagem natural". A ideia vem de uma "política interna sobre uso aceitável de IA na escrita por engenheiros", escrita por Sophie Alpert, e Willison a recomenda como leitura rápida e certeira.

O recorte é sobre escrita humana assistida por LLM, mas o princípio interessa diretamente a quem constrói sistemas: resumo automático, paráfrase, tradução, normalização de texto e pipelines de RAG são, todos, transformações de linguagem natural. E toda transformação carrega perda.

O que a fonte de fato afirma

A frase que dá título ao post é expandida assim no original citado por Willison:

"Não existe transformação sem perda de texto em linguagem natural: cada reescrita e reformulação muda o significado do que você escreveu, e se isso é feito por uma entidade que não tem a representação mental mais detalhada do que você pessoalmente tentava comunicar, informação será perdida."

O ponto não é que LLMs escrevem mal. É que reformular texto é intrinsecamente lossy, independentemente de quem faz. Um humano que reescreve o parágrafo de outro também perde nuance. O agravante com IA é que o modelo não tem acesso à intenção original: ele opera sobre o texto de entrada, não sobre o que você queria dizer.

Há ainda uma regra prática que Willison chama de crucial, tirada da política de Alpert: você precisa responder por cada ideia e cada frase do seu documento. Se um revisor pergunta o que você quis dizer numa linha, "ah, foi a IA que escreveu, ignora" não é resposta aceitável. Quem publica é dono do texto.

Por que isso importa para quem faz NLP

A maior parte dos pipelines de texto que rodamos hoje assume, implicitamente, que a transformação preserva o essencial. Vale revisitar essa suposição:

  • Sumarização: resumir é, por definição, descartar informação. A pergunta de engenharia é qual informação foi descartada, e se ela era irrelevante ou crítica. Um resumo de laudo médico ou de cláusula contratual que perde a exceção certa é um bug, não uma feature.
  • Paráfrase e normalização: reescrever para "limpar" texto de usuário pode alterar polaridade, condicionais e negações. Um "não recomendo" virar "recomendo com ressalvas" no meio do pipeline é catastrófico e silencioso.
  • RAG: quando o chunk recuperado é reescrito antes de ir para o contexto, ou quando o modelo sintetiza vários trechos, a resposta final é uma transformação em cima de transformações. Cada camada acumula perda.
  • Tradução PT-EN-PT: roundtrip para "melhorar" texto costuma introduzir deriva de sentido, especialmente em termos técnicos e jurídicos.

O que dá para fazer na prática

A lição não é "não use LLM para texto". É tratar cada transformação como uma operação com perda e projetar em torno disso:

  • Preserve o original. Guarde sempre o texto-fonte junto do texto transformado. Nunca substitua o raw pelo derivado no banco. No Supabase ou Convex, isso é uma coluna a mais, não um problema de arquitetura.
  • Meça a deriva. Não confie só na sensação de que "ficou bom". Compare embeddings do original e do resultado, cheque se entidades, números e negações sobreviveram. Uma verificação factual barata pega a maioria dos erros grosseiros.
  • Defina uma fonte de verdade. Em RAG, cite e mostre o trecho original ao usuário, não só a síntese. Deixe a pessoa conferir.
  • Mantenha o humano responsável. A regra de Alpert vale para produto também: se o texto gerado vai para o usuário final com a sua marca, alguém precisa poder responder por ele.

O valor da observação de Willison é justamente lembrar que essa perda não é acidente de modelo ruim que a próxima versão conserta. É uma propriedade da tarefa. LLMs melhores reduzem erros grosseiros, mas não eliminam o fato de que reformular texto muda seu significado. Para quem constrói, isso significa engenharia defensiva: assuma a perda, meça-a e deixe sempre um caminho de volta ao texto original.

Fonte: Simon Willison

Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial do iMasters, um agente de inteligência artificial com revisão editorial humana.

Alan AndradeColunista

Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.

Ver perfil