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.

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.









