No. 003Determinismo9 min de leitura

O número de receita confidentemente errado: por que LLMs não sabem somar

Um modelo entrega um número de receita com postura impecável e nenhuma aritmética por trás. A pesquisa mostra que a falha é estrutural — e a solução também.

Em outubro de 2025, a Deloitte devolveu dinheiro ao governo australiano. A firma havia entregado uma revisão de AU$ 440.000 ao Departamento de Emprego e Relações de Trabalho; o relatório publicado continha uma citação fabricada de uma decisão judicial federal e referências a artigos acadêmicos inexistentes (The Guardian, 2025). Uma versão revisada revelou que o GPT-4o havia sido usado na elaboração. Reportagens posteriores estimaram o reembolso em cerca de AU$ 97.000 — a parcela final do contrato.

Um detalhe importa mais do que o dinheiro. As fabricações não foram detectadas pela revisão interna da firma, nem pela do cliente. Foram descobertas por um acadêmico externo que verificou as referências. O entregável havia passado por todas as camadas de escrutínio para as quais foi concebido, porque nada nele parecia errado.

Essa é a categoria: não o modelo que falha, mas o modelo que retorna. Peça a um modelo de linguagem que some a receita de duzentas linhas e você recebe uma resposta com a magnitude certa, o símbolo de moeda correto e uma frase confiante ao redor. O que você não obtém de forma confiável é a soma. Uma resposta ausente é detectada. Uma resposta errada com boa postura é encaminhada ao conselho.

E a postura nunca se quebra, porque a confiança também é texto gerado. O modelo não sabe que está errado; não há alarme interno a suprimir. A frase que afirma o número e o número em si vêm do mesmo lugar — o próximo token provável.

Plausível não é calculado

O instinto é classificar números errados como imaturidade do modelo: certamente a próxima versão soma corretamente. A pesquisa diz que a falha é estrutural, e é incomumente consistente sobre o motivo.

O GPT-4, ao multiplicar dois números de três dígitos, acertou 59% das vezes sem exemplos; o ChatGPT, 55% (arXiv, 2023). Com quatro dígitos, o GPT-4 caiu para 3%. Com cinco, 0%. Os autores de Faith and Fate rastrearam o mecanismo: transformers lidam com problemas composicionais combinando fragmentos linearizados do que já viram — busca por padrão, não procedimento. O abismo fica exatamente onde os padrões se esgotam.

A adição não é mais segura. Uma análise de 2025 constatou que LLMs somam com uma heurística de antecipação de um dígito, e não com um algoritmo: a precisão colapsa exatamente onde os carries se propagam além de um dígito, independentemente de prompting ou tokenização, e as falhas são previsíveis apenas pela estrutura dos carries (arXiv, 2025). Sistemático, não aleatório. O modelo não está quase calculando. Está fazendo outra coisa que frequentemente coincide com o cálculo.

O GSM-Symbolic da Apple fechou a última brecha — a de que talvez isso só afete aritmética difícil (Apple, 2024). Pegue problemas de matemática do ensino fundamental e mude apenas os números: todos os modelos de ponta testados pioraram. Acrescente uma cláusula plausível, mas irrelevante: a precisão caiu até 65%. E a precisão variou visivelmente entre instâncias diferentes do mesmo modelo de questão — o mesmo problema, reformulado, retorna uma distribuição diferente de respostas. Essa última descoberta explica o problema da demonstração. Uma demo é um único sorteio da distribuição. Uma auditoria é a distribuição.

O veredicto dos autores — "os LLMs atuais não são capazes de raciocínio lógico genuíno" — é incomumente direto para um artigo científico. Ninguém o refutou.

100 50 0 accuracy, % zero-shot scratchpad 59 92 3×3-digit 4 4×4-digit 0 5×5-digit
Precisão do GPT-4 em multiplicação de n dígitos × n dígitos, zero-shot vs. scratchpad passo a passo. Faith and Fate, NeurIPS 2023.

As correções óbvias, medidas

Toda equipe que se depara com essa falha recorre às mesmas quatro correções. Cada uma foi medida.

Recuperação. O FinanceBench fez ao GPT-4-Turbo 150 perguntas sobre demonstrações financeiras públicas, com um sistema de recuperação fornecendo os documentos. Ele respondeu incorretamente ou recusou 81% delas (Patronus AI, 2023). Dezesseis configurações — GPT-4-Turbo, Llama 2, Claude 2, armazenamentos vetoriais, contexto longo — apresentaram fragilidades em 2.400 respostas revisadas manualmente, e os modelos alucinaram números sempre que as páginas de evidência não eram fornecidas com perfeição. A recuperação busca o documento. O modelo ainda erra o número.

Fundamentação. A BBC deu ao ChatGPT, Copilot, Gemini e Perplexity acesso direto aos seus próprios artigos e perguntou sobre as notícias. 51% das respostas tinham problemas significativos; 91% tinham ao menos algum. 19% das respostas que citavam conteúdo da BBC introduziram erros factuais — afirmações erradas, números errados, datas erradas — e 13% das citações atribuídas a artigos da BBC foram alteradas ou nunca existiram (BBC, 2025). A fonte estava em mãos. Os números ainda se distorceram.

Um modelo mais sofisticado. O próprio system card da OpenAI relata que o o3 alucina em 33% dos prompts do PersonQA e o o4-mini em 48% — contra 16% do o1 anterior (OpenAI, 2025). Pela própria medição do fornecedor, os modelos de raciocínio mais recentes alucinam duas a três vezes mais do que o predecessor. O o3 simplesmente faz mais afirmações — mais corretas e mais fabricadas, entregues com a mesma temperatura de certeza.

Prompting aprimorado. O prompting com scratchpad passo a passo eleva a multiplicação de três dígitos do GPT-4 de 59% para 92% (arXiv, 2023). Melhor — e ainda assim um produto errado a cada doze. Mesmo o fine-tuning exaustivo do GPT-3 em multiplicação de quatro dígitos produziu cerca de 40% em problemas inéditos de quatro dígitos, e 0% com cinco dígitos. O teto é o mecanismo, não o prompt.

Cada correção melhora as probabilidades. Nenhuma delas muda quem faz a aritmética. A resposta ainda é amostrada de uma distribuição de números plausíveis, e exatamente um membro dessa distribuição é a soma.

0 50 100 % RETRIEVAL · FINANCEBENCH 2023 wrong or refused 81% GROUNDING · BBC 2025 significant issues 51% factual errors introduced 19% REASONING · PERSONQA, OPENAI 2025 o1 (predecessor) 16% o3 33% o4-mini 48%
Taxas de falha após a correção. FinanceBench 2023 · BBC 2025 · OpenAI o3 / o4-mini system card 2025.

Mude quem faz a aritmética

A resposta estrutural é uma divisão de trabalho traçada exatamente ao longo da linha de competência. Modelos de linguagem são excelentes em linguagem e pouco confiáveis em contabilidade, portanto o modelo nunca deve ser o responsável pelo cálculo.

O SQAI é construído sobre essa divisão. O modelo cria uma intenção tipada — sum amount where region = "east" — e um motor determinístico a executa como código compilado: validado contra um contrato fixado por hash, verificado contra a política, calculado em float64 em uma única thread, retornado com proveniência.

{
  "status": "ok",
  "value": 2130.5,
  "rows_matched": 5
}

Esse 2130.5 não é um token provável. É a soma, produzida por um kernel determinístico a partir de uma superfície de 4.574 capacidades somente leitura em 445 módulos — 4.564 deles totalmente determinísticos — respondendo em 0,83–0,93 ms a quente.

Determinístico significa verificável. finance.npv(0.1, [-1000, 300, 420, 560, 680]) retorna 505.020148896933 sob o hash de computação b74f67d0… — o mesmo valor e o mesmo hash independentemente de a chamada ser feita em TypeScript ou Python, porque os resultados são hasheados sobre uma única forma canônica em JSON. A afirmação é honestamente delimitada: determinístico dentro do escopo de execução declarado, com um envelope que registra versão do runtime, plataforma, modo de precisão e contagem de threads, em vez de prometer demais. A resposta de um modelo ao mesmo prompt não pode garantir que coincidirá consigo mesma na próxima execução. Esta reproduz byte a byte, meses depois, em qualquer uma das duas linguagens.

Há uma segunda brecha, e a maioria das stacks a deixa aberta. Conecte um motor de cálculo e depois despeje as linhas brutas da consulta no contexto "para sumarização" — e o modelo silenciosamente re-deriva e reinventa números a partir das linhas. O SQAI trata o contexto como uma fronteira governada: no máximo 25 linhas, 250 células e 32.000 bytes chegam ao modelo, com um limite padrão de 100 linhas e um teto rígido de execução de 1.000. O truncamento é sempre declarado, de modo que o modelo não pode honestamente afirmar ter totalizado o que viu. Linhas parciais nunca são exibidas, para que nenhum registro incompleto o tente a completar pela imaginação. Agregados são calculados antes da fronteira. O modelo recebe a resposta, não o dever de casa.

E a política não é um prompt. Fontes, campos e funções permitidos são fixados em código no momento de createSQAI() e verificados em processo antes da execução; a entrada de ferramenta do modelo não carrega nenhum campo de política, portanto não há nada que ele possa ampliar. Solicitar uma capacidade fora da política não produz uma solução criativa — produz policy_denied_function. O argumento é o mesmo por trás de não deixar agentes escreverem SQL: não governe texto gerado com instruções de melhor esforço; governe a execução com listas de permissão que o texto não pode tocar.

GOVERNED BOUNDARY MODEL language in, language out sum(amount) · region = "east" typed intent — never a SQL string ENGINE contract → policy → execute float64 · 1 thread · sub-ms warm value 2130.5 · rows 5 plan_hash f87610d8afeb… byte-identical replay · TS ≡ PY answer, not rows ≤ 25 rows · ≤ 250 cells · ≤ 32,000 B truncation always declared
A divisão de trabalho: o modelo cria uma intenção tipada; um kernel float64 calcula; limites de linhas mantêm os dados brutos fora do contexto.

Quem fez a aritmética?

Da próxima vez que um sistema de IA lhe entregar um número de receita, uma pergunta classifica todas as arquiteturas do mercado: quem fez a aritmética?

Se a resposta for "o modelo", você tem em mãos um número com excelente postura e proveniência desconhecida, e o único caminho de verificação é um humano refazendo o trabalho — exatamente o que você tentava automatizar. As fabricações da Deloitte foram descobertas porque um acadêmico externo ao processo decidiu verificar. Isso não é um controle. É sorte.

Se a resposta for "um motor determinístico, e aqui está o hash", a verificação é uma reprodução: mesma intenção, mesmo motor, mesmos bytes. A falha fica mais sutil — e mais silenciosa — quando o número errado vem de um join ramificado em vez de uma adição incorreta, o que é uma história à parte. Mas a disciplina cabe em uma frase: o modelo escreve a pergunta, nunca a resposta.

O número de receita errado não se anuncia. Ele chega formatado, citado e confiante — e com cinco dígitos de multiplicação, nunca correto. Construa o pipeline de modo que ele não consiga entrar.