LLMs pontuam 2,3% na Geração de DSL Beancount: O Benchmark LLMFinLiteracy

Este é o artigo pelo qual eu esperava desde o LOG-001: um teste empírico direto se os LLMs conseguem gerar transações DSL Beancount válidas a partir de cenários financeiros em linguagem natural. Figueroa et al., da Universidade de Ciências Aplicadas de Berlim, apresentam o que afirmam ser — corretamente, até onde posso dizer — a primeira avaliação publicada de LLMs na geração de transações financeiras em contabilidade em texto simples. A resposta curta é: eles não conseguem, pelo menos não de forma confiável, mesmo com prompts de cadeia de pensamento (chain-of-thought) e com o balanço patrimonial real do Beancount entregue a eles como contexto.

O artigo

Figueroa, Grundmann, Freidank, Löser e Nejdl avaliam cinco modelos de pesos abertos de ~7B em um benchmark de duas tarefas que chamam de LLMFinLiteracy. A Tarefa 1 pede aos modelos que gerem cenários textuais que afetariam um determinado índice de liquidez (corrente, seca ou imediata), dado um balanço patrimonial trimestral real de uma das cinco empresas listadas no DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). A Tarefa 2 pede aos modelos que traduzam esses cenários em transações Beancount compiláveis. O compilador Beancount serve como o verificador sintático de verdade absoluta (ground-truth); especialistas humanos avaliam a correção semântica. O artigo introduz uma taxonomia de erros de 12 classes nas duas tarefas e utiliza um prompt de cadeia de pensamento de 9 etapas que inclui regras de contabilidade de dupla entrada, um exemplo de entrada/saída e o balanço patrimonial real da empresa no formato Beancount. Os modelos avaliados — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B e CodeQwen-1.5-7B — foram todos executados localmente (on-premise) devido à sensibilidade dos dados financeiros. O corpus totaliza 1.500 amostras geradas, com 300 entradas estratificadas avaliadas por especialistas humanos.

Ideias principais

• Apenas 7 dos 300 pares cenário-transação avaliados (2,3%) estavam totalmente corretos de ponta a ponta; mesmo restringindo aos três modelos de uso geral, a taxa sobe apenas para 3,8%.
• Os dois melhores modelos, Qwen-2-7B e Mistral-7B, produzem cenários corretos apenas 21,67% e 20,00% das vezes, e transações compiláveis corretas apenas 16,67% e 10,00% das vezes.
• Modelos especializados em código (CodeLlama, CodeQwen) pontuaram 0% em ambas as tarefas; eles responderam ao template do prompt com uma string literal "Processed — Waiting for next input", ignorando completamente a tarefa.
• A sintaxe não é o gargalo: nenhum modelo produziu um único erro de sintaxe. As falhas estão inteiramente no raciocínio contábil — erros de saldo dominam no Qwen-2 (61,67%) e Llama-3 (38,33%), enquanto o Mistral refere-se principalmente a contas que não existem no balanço patrimonial fornecido (45% de erros de conta desconhecida).
• Uma fração significativa das transações que compilam com sucesso está semanticamente errada — o truque favorito do modelo é chamar a redução de um passivo de "vender sua dívida", o que aumenta o caixa, mas pelo motivo errado.
• O GPT-4o usado como juiz automatizado falhou em sinalizar inconsistências em todos os 10 cenários absurdos que lhe foram mostrados, confirmando que a autoavaliação de LLM não é um filtro de qualidade confiável para saídas contábeis.
• Os modelos copiam amplamente o exemplo de entrada/saída do prompt em vez de generalizar: os 7 pares corretos assemelham-se de perto à estrutura da transação de exemplo fornecida.

O que se sustenta — e o que não se sustenta

A contribuição empírica central do artigo é sólida. O compilador Beancount é um critério de correção objetivo e reproduzível, e usar balanços patrimoniais de empresas reais em vez de dados fictícios adiciona validade ecológica. A taxonomia de erros hierárquica é cuidadosamente projetada — interromper a avaliação no primeiro erro evita inflar o "crédito parcial" para saídas inúteis.

Dito isso, existem limitações óbvias que os autores reconhecem em grande parte. Cinco modelos de pesos abertos de ~7B de 2023–2024 são uma fatia estreita do cenário de capacidades; GPT-4o e Claude foram excluídos por razões de privacidade, o que é compreensível, mas significa que o número principal (2,3% correto) subestima a fronteira. As fórmulas dos índices financeiros foram deliberadamente omitidas dos prompts para testar o conhecimento inerente do domínio — uma escolha metodologicamente interessante, mas que torna os resultados incomparáveis a qualquer sistema que razoavelmente incluiria a documentação das fórmulas. E 300 amostras avaliadas por humanos em cinco modelos, três índices e cinco empresas é modesto; as células por modelo por índice são pequenas demais (12 amostras) para tirar conclusões fortes sobre a variância.

A lacuna metodológica mais interessante é a ausência de qualquer protocolo iterativo ou baseado em feedback. Nada de chamada de ferramentas (tool-calling), nada de autocorreção, nada de loop de feedback com o compilador — apenas geração one-shot. Dado que o CRITIC (LOG-012) e trabalhos relacionados mostram que o refinamento interativo com ferramentas melhora substancialmente a precisão em tarefas com saídas verificáveis, um experimento com o compilador Beancount no loop teria sido muito mais informativo sobre a viabilidade de implantação.

Por que isso importa para a IA nas finanças

Cada decisão de design para o agente de gravação (write-back) do Bean Labs baseia-se em suposições sobre o que os LLMs podem fazer com a DSL do Beancount. Este artigo é a primeira âncora empírica. As descobertas principais são sóbrias, mas também interpretáveis de uma forma útil.

Primeiro, os modos de falha são específicos, não aleatórios. Erros de saldo e contas desconhecidas são os dois problemas dominantes, e ambos são endereçáveis com um loop de feedback do compilador: o compilador Beancount diz exatamente qual conta é desconhecida e se a transação está equilibrada. Uma arquitetura de agente que itera sobre a saída do compilador — em vez de gerar uma vez e parar — deve superar substancialmente os resultados one-shot apresentados aqui. Segundo, a sintaxe é "de graça". Os modelos aprenderam claramente a gramática de superfície do Beancount; eles apenas não conseguem traduzir de forma confiável a intenção financeira em movimentos de conta corretos. Essa distinção importa para saber onde investir em prompting e ajuste fino (fine-tuning). Terceiro, a descoberta de que o GPT-4o não pode avaliar a qualidade contábil automaticamente eleva o nível para qualquer sistema de verificação automatizado: você precisa do compilador, além de verificações pontuais de especialistas no domínio, e não de um LLM crítico.

O artigo também confirma algo que eu suspeitava do trabalho de detecção de anomalias (LOG-049): LLMs operando sobre transações financeiras compilam e enviam com facilidade excessiva. A categoria "Incorreta | Compila" — transações que passam na verificação sintática, mas estão semanticamente erradas — é exatamente o modo de falha que uma barreira de segurança de gravação deve capturar. Uma transação pode estar perfeitamente equilibrada e ainda assim registrar receita como uma diminuição de passivo, o que passaria despercebido por qualquer verificação puramente sintática.

O que ler a seguir

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — pontuação de anomalias baseada em probabilidade como alternativa à abordagem de detecção em lote; combina-se naturalmente com um sinal do compilador Beancount para sinalizar entradas estruturalmente válidas, mas estatisticamente anômalas.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — encaminha decisões de baixa confiança para um modelo maior ou para um humano; aborda diretamente a questão de quando um agente de gravação Beancount deve delegar à revisão humana em vez de prosseguir após um loop de feedback do compilador.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — o trabalho existente mais relevante para construir um agente de correção com o compilador no loop sobre a arquitetura que este artigo avalia.