PAL: Modelos de Linguagem Auxiliados por Programas para Aritmética Financeira Confiável

Depois de passar algum tempo com a literatura de raciocínio tabular, eu quis entender a abordagem complementar: em vez de fazer os LLMs raciocinarem sobre tabelas em linguagem natural, o que acontece quando você permite que eles escrevam código e deleguem o cálculo inteiramente? PAL (Gao et al., 2022, arXiv:2211.10435) é a resposta canônica, e tem implicações óbvias para qualquer sistema que precise realizar aritmética sobre dados financeiros de forma confiável.

O artigo

"PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) parte de uma observação direta: LLMs decompõem bem os problemas, mas executam mal a aritmética. O prompting de cadeia de pensamento (chain-of-thought) corrige o primeiro problema, mas deixa o segundo intocado. A correção proposta é mudar o que o LLM produz como seus "passos de raciocínio" — em vez de aritmética em linguagem natural, ele gera código Python. Um intérprete Python então executa esse código e retorna a resposta.

A divisão decomposição-execução é nítida: o LLM lida com a compreensão do problema e a estrutura do programa; o intérprete lida com tudo o que é numérico. Uma pergunta como "Olivia tem $23, compra cinco bagels por $3 cada — quanto resta?" torna-se money_left = 23 - (5 * 3), e não uma sequência de aritmética em prosa que o modelo poderia errar.

Ideias principais

• No GSM8K (problemas matemáticos de nível escolar), o PAL com Codex atinge 72,0% de precisão contra 65,6% da cadeia de pensamento com o mesmo modelo Codex — um ganho de +6,4pp — e 56,9% para CoT com o modelo PaLM-540B muito maior. Um modelo menor vence ao delegar a aritmética ao Python.
• No GSM-hard, uma versão do GSM8K onde os números são substituídos por valores maiores, o PAL alcança 61,2% contra 23,1% do CoT — uma lacuna absoluta de +38,1pp. Números grandes quebram a aritmética ao nível de tokens; eles não quebram o Python.
• Com votação por maioria em 40 amostras, o PAL atinge 80,4% no GSM8K, superando o Minerva-540B (78,5%) com um modelo de aproximadamente 1/10 do tamanho.
• Os ganhos generalizam-se para o raciocínio simbólico. Em tarefas do BIG-Bench Hard como Contagem de Objetos, o PAL marca 96,7% contra 73,0% do CoT; em Pinguins em uma Tabela, 93,3% contra 79,2%.
• Uma ablação revela onde o trabalho realmente acontece: quando o LLM atua como seu próprio intérprete (sem Python externo), a precisão no GSM8K desaba para 23,2%. O intérprete não é um aprimoramento menor — ele está realizando toda a aritmética.
• A nomeação de variáveis importa. Substituir nomes de variáveis significativos por caracteres aleatórios causa quedas substanciais de precisão em tarefas simbólicas. O modelo lê o seu próprio código.

O que se sustenta — e o que não

A afirmação central é trivialmente correta e os experimentos a confirmam de forma convincente: o Python é melhor que um LLM em aritmética, e o GSM-hard torna isso brutalmente visível. Os +38pp ali não são uma excentricidade do benchmark — refletem um modo de falha categórico do CoT sob escala.

O que considero menos convincente é o enquadramento como um avanço geral no raciocínio. O PAL funciona em tarefas que por acaso possuem respostas determinísticas e expressáveis em Python. Muito do que importa no raciocínio financeiro não se decompõe dessa forma. Decidir se um padrão de transação é "unusual for this account in Q4" (incomum para esta conta no 4º trimestre) ou se uma transferência justifica uma sinalização para revisão manual não é redutível a uma expressão em Python. O PAL fornece um motor aritmético confiável; ele não fornece julgamento.

A dimensão da segurança não recebe atenção no artigo. Os benchmarks rodam em um ambiente controlado, mas qualquer implantação que gere e execute Python arbitrário em resposta a entradas fornecidas pelo usuário é uma superfície de ataque significativa. Escapes de kernel de intérpretes em sandbox, acesso ao sistema de arquivos ou segredos, entradas criadas de forma adversária que geram código malicioso — nada disso é abordado. Para aplicações financeiras, isso não é uma nota de rodapé.

O artigo também não analisa profundamente os modos de falha quando a geração de código dá errado. Se o PAL emitir um Python sintaticamente inválido, ele não retorna nada. Os autores relatam taxas de sucesso de execução, mas não caracterizam o que causa falhas de geração ou se são aleatórias ou sistemáticas. Dado que o intérprete está fazendo toda a aritmética, a qualidade do código é o gargalo total da confiabilidade — e está subanalisada.

Por que isso importa para a IA financeira

Este é um dos artigos mais diretamente aplicáveis ao Beancount que já li. Operações de livro razão estão quase perfeitamente alinhadas com o que o PAL faz bem: somar transações por categoria, aplicar taxas de câmbio, calcular base tributária em vários lotes, reconciliar totais de extratos bancários com saldos do livro razão. Estas são tarefas determinísticas, pesadas em aritmética e expressáveis em Python. Agentes baseados em CoT alucinarão números aqui; o PAL não o fará, desde que a estrutura do programa esteja correta.

O Program of Thoughts (arXiv:2211.12588), um artigo concorrente que desenvolveu independentemente a mesma ideia, avaliou em três conjuntos de dados de QA financeiro — FinQA, ConvFinQA e TATQA — e relatou um ganho médio de ~12% sobre a cadeia de pensamento. Essa é a evidência mais direta de que a abordagem de geração de programas ajuda no raciocínio do domínio financeiro, não apenas na matemática escolar.

A questão da segurança na gravação (write-back), no entanto, é mais aguda em um contexto de livro razão do que em benchmarks. Um agente que gera Python para ler dados do Beancount é de baixo risco. Um que gera Python para escrever lançamentos no livro razão precisa de um ambiente de execução rigidamente restrito — um que possa tocar apenas em objetos do livro razão e nada mais, que feche em caso de qualquer exceção e que exija que o código gerado passe por uma lista de permissões antes da execução. O PAL trata o intérprete como um motor de computação neutro. Um agente financeiro de produção não pode fazer isso.

O que ler a seguir

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — trabalho simultâneo que avalia em FinQA, ConvFinQA e TATQA e relata um ganho médio de ~12% sobre CoT; a avaliação específica de finanças que o PAL adia.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — o benchmark subjacente às avaliações financeiras do PoT; entender o que está sendo realmente testado calibra o quanto confiar na transferência para casos de uso reais do Beancount.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — mesmo primeiro autor do PAL, estende a visão de geração de código para loops de autocorreção iterativos; relevante para saber se agentes do estilo PAL podem se recuperar de suas próprias falhas de geração de código.