A Coerência Não É Correção: Por Que um Paper Precisa de Teses Comprováveis, Não de Prosa Impecável
Há uns dias li um paper. Só o título já me devia ter posto de sobreaviso: Conditional Realism, Stewardship, and Survivable Cognition Under Finite Constraint. Quarenta páginas no Zenodo, com DOI, ORCID e todo um aparato de referências que remetem para o programa de investigação do próprio autor, a Architecture of Limitation. Tem ar de coisa séria. Ao lê-lo, a prosa flui, nunca se contradiz, antecipa as suas próprias objeções e desarma-as com elegância.
E, no entanto, ao chegar ao fim, não havia nada a que me pudesse agarrar. Não por ser difícil — é-o, deliberadamente — mas porque nunca afirmava nada que eu pudesse testar, verificar ou refutar a partir de fora do próprio texto. Era impecável e vazio ao mesmo tempo. E o mais revelador é que o paper descreve o seu próprio modo de falha sem alguma vez se reconhecer ao espelho.
Vale a pena explicar porquê, porque o padrão está a tornar-se cada vez mais comum e, na era dos modelos de linguagem, detetá-lo passou discretamente a ser uma competência de engenharia de primeira ordem.
O grão de verdade, primeiro
Deixa-me ser justo antes de ser duro. O paper tem uma boa ideia, e começo por ela para que o resto não pareça um espantalho.
A ideia é esta: a expressão "human in the loop" funciona muitas vezes como um placeholder simbólico. Metemos um humano numa cadeia de decisão e declaramos o sistema seguro, sem nunca definir sob que condições essa participação humana é de facto significativa, proporcionada ou responsável. O paper propõe substituí-la por uma noção de stewardship: o que o humano traz não é supervisão, é exposição à consequência. O modelo gera; o humano suporta. A assimetria é estrutural, não moral.
Concordo com isto. De facto, encaixa diretamente com algo que defendo há muito tempo: a IA aumenta, não substitui. A parte da cadeia que não se pode externalizar é precisamente quem carrega o custo do erro e mantém uma relação adversarial com a realidade quando o sistema deriva. Essa intuição é sólida.
O problema é tudo o que está à volta dela.
O ponto central: o paper é o seu próprio modo de falha
É aqui que está o que me fez escrever este post.
O paper, citando trabalhos anteriores do mesmo autor, cunha dois termos para descrever como os sistemas de raciocínio falham sob pressão:
- "Coherence inflation": o momento em que a estrutura recuperável de um argumento começa a parecer explicação completa, e a consistência interna crescente se confunde com certeza metafísica.
- "Hallucination as geometric overflow": texto que mantém a fluência, a consistência e a organização explicativa enquanto deriva para além das fronteiras que originalmente fundamentavam o raciocínio.
Lê estas duas definições outra vez. São uma descrição exata do paper que as contém.
Quarenta páginas de prosa fluente, internamente consistente, que nunca toca o chão. Cada referência da bibliografia é outro documento do mesmo autor, publicado no mesmo repositório, dentro do mesmo enquadramento inventado. É um ciclo de citação fechado: o texto valida-se a si próprio no seu próprio vocabulário. O paper até antecipa esta acusação — escreve literalmente que "os leitores podem interpretar este trabalho como recursivamente autovalidante" — e descarta-a dizendo que não é essa a intenção. Mas reconhecer um círculo vicioso não o quebra. A bibliografia continua a morder a própria cauda.
E o detalhe que coroa tudo: um DOI do Zenodo não é revisão por pares. O Zenodo atribui um DOI a qualquer coisa que lá ponhas — um PDF, um dataset, um meme. É um serviço de arquivo, não um selo de qualidade. Os adereços da autoridade académica — ORCID, DOI, secções numeradas em algarismos romanos — são estética, não substância.
O que se obtém é um artefacto que passa nos seus próprios testes porque foi ele que os escreveu, e que não pode falhar nenhum porque nunca faz uma afirmação verificável.
A analogia de engenharia
Se és engenheiro, já tens o modelo mental para perceber exatamente o que se passa aqui.
Imagina um PR que compila limpo, passa no linter e mostra o CI verde. Todos os testes passam. Depois abres os testes e descobres que foi o próprio código testado que os escreveu, e que cada assert é uma tautologia: expect(x).toBe(x). O build está verde. A cobertura é de 100%. E o sistema não faz absolutamente nada.
Isto é o paper. Coerência sintática perfeita, zero contacto com um oráculo externo.
Em programação temos um instinto afinado para isto porque já nos mordeu demasiadas vezes. Sabemos que um teste que passa sempre não vale nada. Sabemos que um sistema que só se valida contra si próprio — sem ambiente de staging, sem dados reais, sem um utilizador que se queixe — pode estar profundamente partido e parecer perfeitamente saudável. Uma compilação limpa não é correção. O verde do CI não é verdade. É consistência interna, que é uma propriedade muito mais barata e muito menos valiosa.
A filosofia e a ciência têm o mesmo instinto, e ele tem um nome: falsificabilidade. Uma afirmação que não se consegue formular de maneira que possa vir a ser falsa não é falsa — nas palavras de Pauli, "not even wrong". Não entra no jogo. Não há nada a discutir, porque não há nada que o mundo possa contradizer.
O que torna um paper sólido
Aqui quero ser construtivo, porque o caminho fácil seria ficar-me pelo "isto é palha". A pergunta útil é: o que precisaria de ter para ser sólido?
Três coisas, por ordem de força decrescente.
1. Uma tese comprovável, com experiências, dados e resultados
O padrão de ouro. Afirmas algo sobre o mundo, desenhas uma forma de o medir, recolhes dados, e os resultados ou sustentam a tese ou a derrubam. A chave é que outra pessoa, a partir de fora, possa reproduzi-lo e chegar à sua própria conclusão. Os dados não são teus; são de quem os quiser replicar.
Há umas semanas escrevi sobre um paper de alinhamento de IA que trata o sistema desplegado como uma distribuição de probabilidade sobre trajetórias e define o alinhamento como pertinência topológica a um conjunto seguro. Não precisas de seguir a matemática para ver a diferença de natureza: aquele paper afirma que a pertinência se pode demonstrar com logs finitos usando bounds conformais. Tem um scope declarado (sistemas de trabalho de informação, não IA encarnada). Podes discordar dele, atacar os seus pressupostos, tentar encontrar um contraexemplo. Dá-te superfície para te agarrares. É isto que faz de um paper parte de uma conversa.
2. Uma tese falsificável, mesmo que não a pudesses testar tu próprio
Nem tudo precisa de uma experiência de laboratório no dia em que é publicado. Mas precisa de estar formulado de maneira que se pudesse pôr à prova em princípio, por alguém, algum dia. "As equipas que monitorizam trajetórias intermédias detetam desvios mais cedo do que as que só monitorizam o output final" é uma afirmação para a qual talvez hoje não tenhas dados para fechar, mas que qualquer equipa pode tentar refutar com a sua telemetria. É discutível num terreno partilhado.
3. No mínimo, uma tese discutível fora da cabeça de quem a escreve
Este é o patamar mínimo, e é exatamente o que o paper do Zenodo não consegue alcançar. Uma afirmação filosófica pode ser perfeitamente legítima sem experiência nenhuma — a filosofia séria fá-lo constantemente — desde que ofereça definições, distinções e consequências que outra pessoa possa pegar e contestar. O realismo estrutural, o falibilismo, o problema da indução: são posições filosóficas antigas, debatidas durante décadas, precisamente porque estão formuladas de maneira suficientemente precisa para que alguém possa dizer "não, e eis porquê".
O paper que li não faz isso. Reembala o realismo estrutural epistémico — uma posição que existe desde os anos oitenta — em vocabulário inventado ("survivable cognition", "recoverable continuity", "operational invariants") e apresenta-o como uma arquitetura proprietária com "camadas de capacidade". Declara-se "operational, not metaphysical" dezenas de vezes, mas nunca fornece uma única operação: nem uma métrica, nem um procedimento, nem um critério. A palavra "operational" funciona como um talismã. Tudo está definido por substantivação abstrata e nada por uma operação mensurável.
É um experimento mental selado dentro de si próprio. E um experimento mental em que ninguém consegue entrar a partir de fora não é investigação; é um diário em tipografia académica.
Por que isto é agora um problema de engenharia
Até aqui isto podia parecer uma disputa entre académicos. Não é. É o nosso problema, e tornou-se urgente por uma razão concreta: os modelos de linguagem são motores de coerência.
Um LLM está otimizado para produzir a continuação mais plausível, mais fluente, mais internamente consistente de um texto. Não está otimizado para dizer a verdade. Quando funciona bem, as duas coisas coincidem aproximadamente. Mas a coerência e a correção são eixos independentes, e um modelo pode percorrer uma distância enorme no eixo da coerência com zero movimento no da correção. Pode gerar quarenta páginas impecáveis sobre um enquadramento que não existe, com uma bibliografia que se cita a si própria, e cada frase vai encaixar com a anterior.
O paper que li tem todas as impressões digitais de ter nascido assim — e a ironia é perfeita, porque descreve este mesmo fenómeno e não se reconhece nele.
É aqui que regressa a sua única boa ideia, virada contra o próprio paper. A defesa contra a coerência vazia não é desconfiar da IA. É o steward humano que carrega a consequência e faz a verificação. O modelo gera a prosa; alguém tem de ser quem pergunta "espera, isto pode ser verificado? Contra o quê? Quem o consegue replicar? As referências existem fora deste documento?". Essa função não se pode externalizar para o mesmo sistema que gera o texto, pela mesma razão que não deixas o código escrever e aprovar os seus próprios testes.
Isto é, quase palavra por palavra, a tese a que volto sempre: a IA aumenta, não substitui. O aumento é real e enorme. Mas a responsabilidade epistémica — o contacto com um oráculo externo — continua a ser humana. O paper propôs-se argumentar isto e em vez disso prova-o, sendo o exemplo do que acontece quando essa função falta.
Uma checklist, para engenheiros
Para que isto seja acionável e não apenas uma queixa elegante, eis as perguntas que faço quando leio — ou escrevo — qualquer coisa que pretende ser uma contribuição séria. São as mesmas que farias num code review:
- Consegues enunciar a afirmação central de maneira que pudesse ser falsa? Se não há nenhum estado do mundo que a contradiga, não é uma afirmação; é uma definição disfarçada.
- Há alguma medição? Dados, uma experiência, uma observação reproduzível. E se não há, pelo menos uma consequência que alguém possa ir procurar.
- Alguém de fora poderia discuti-la nos seus próprios termos? Ou só se consegue debatê-la depois de engolir primeiro todo o vocabulário do autor?
- As referências são um ciclo fechado? Se cada citação remete para o autor ou para o seu próprio enquadramento, a bibliografia é decoração, não fundamento.
- Os termos estão definidos como operações ou como substantivos abstratos? "Recoverability" sem uma forma de a medir é uma palavra, não um conceito.
- A aparência de autoridade está a fazer o trabalho da verdade? Um DOI, um ORCID e secções em algarismos romanos não são revisão por pares. Pergunta-te quem é que realmente avaliou isto.
Se um texto falha a maioria destas perguntas, pode ser brilhante, pode ser belo, pode até ser correto por acaso — mas não te podes apoiar nele. E em produção, apoiar-se nas coisas é o trabalho todo.
O que eu levo daqui
A coerência é barata. Sempre foi, mas antes era preciso talento ou obsessão para produzir quarenta páginas internamente consistentes sobre nada. Agora é grátis e instantânea. O que significa que a coerência deixou de ser um sinal de qualidade, e todo o peso se desloca para as propriedades que sempre deveriam ter importado: comprovabilidade, falsificabilidade, exposição à contradição vinda de fora.
O paper que li não é sólido, e não é técnico — apesar de todo o seu vocabulário de geometria vetorial e representações semânticas distribuídas, não contém uma única equação, um único dado, uma única experiência. Mas foi-me útil, porque é o caso de estudo perfeito de algo que todos vamos ter de aprender a apanhar: texto que soa a tese e não é nenhuma.
O trabalho de engenharia — e o de qualquer pessoa que queira pensar bem com estas ferramentas — não é deixar de usar a máquina que gera prosa fluente. É manter a disciplina de perguntar, sempre, contra o que é que isto se verifica. Porque um sistema que só se valida contra si próprio parece perfeitamente saudável até ao dia em que o pões à frente do mundo.
A construir sistemas de IA onde a diferença entre coerência e correção se paga em produção, e preferias ter uma equipa com o instinto de a verificar contra a realidade? Fala com um CTO sobre desplegar capacidade de engenharia nearshore com a disciplina de não confundir o verde do CI com a verdade.
