Abrir extratos bancários não é algo que alguém faça por diversão. Eles chegam como PDFs digitalizados, exportações CSV ou arquivos XML repletos de acrônimos obscuros como OFX. Para contadores, escriturários e desenvolvedores de fintechs, transformar esses documentos em dados limpos e estruturados é uma dor de cabeça constante. Quando os grandes modelos de linguagem (LLMs) surgiram, eles pareceram oferecer uma saída de emergência. Bastava alimentar a máquina com um PDF e pedir um JSON. O que poderia dar errado?

Eu aprendi exatamente o que poderia dar errado enquanto construía o StatementDecoder, uma ferramenta projetada para converter extratos bancários em dados utilizáveis. Como muitos desenvolvedores, presumi que a parte difícil seria ensinar o sistema a ler diversos layouts de documentos. Eu estava errado. Ler os documentos era quase trivial. O verdadeiro pesadelo era reconhecer quando a máquina havia inventado silenciosamente um número ou trocado dois dígitos em um valor de transação.

A Demonstração que Funcionou Bem Demais

Minha primeira tentativa foi sedutoramente simples. Eu enviei extratos bancários diretamente para um LLM e solicitei um JSON estruturado em retorno. Os resultados pareceram mágica. O modelo lidou com diferentes layouts com facilidade. Ele leu PDFs digitalizados nos quais parsers padrão travavam. Parecia entender tabelas, cabeçalhos e extratos de várias páginas sem instruções explícitas. Por algumas horas gloriosas, pensei que o problema estivesse resolvido.

Então, testei contra dados reais de clientes, e a mágica evaporou. Os bancos do Reino Unido usam designs de extratos próprios, e as diferenças não são meramente cosméticas. Os extratos da Wise possuem suas próprias peculiaridades de formatação. As exportações CSV da Revolut parecem diretas até você notar como elas lidam com transações multi-moeda e campos de metadados. Arquivos OFX antigos, um formato que realmente parece pertencer à década de 1990, lançam estruturas de tags arcaicas e problemas de codificação em qualquer parser que espere uma marcação moderna.

O modelo ainda extraía dados muito melhor do que qualquer sistema de templates pronto para uso. Mas "muito melhor" não é o suficiente quando dinheiro está envolvido.

Quando 99% de Precisão é um Fracasso

Aqui está o problema fundamental de usar IA para extração de dados financeiros. Se um modelo processa duzentas linhas de transação e acerta cento e noventa e nove, o resultado parece impecável. O JSON está bem formado. As chaves e valores estão alinhados. Uma revisão casual pode não mostrar nada suspeito. No entanto, se esse único erro transpor dois dígitos em um valor, inverter um depósito em um saque ou deslocar um ponto decimal, sua contabilidade será corrompida. Você não perceberá isso apenas olhando rapidamente para uma parede de dados estruturados.

Um humano revisando um JSON bruto raramente percebe um dígito trocado em um valor de transação. A formatação é perfeita, o que, paradoxalmente, torna o erro mais perigoso. Você não pode lançar uma ferramenta financeira que esteja certa na maior parte do tempo. Ela deve estar certa, ou deve anunciar claramente que não tem certeza.

Minha reação inicial foi previsível. Desenvolvi prompts melhores. Fiz o upgrade para modelos mais capazes. Experimentei o raciocínio de cadeia de pensamento (chain-of-thought) para fazer o modelo mostrar seu processo. Nada disso resolveu o problema central. Eu estava pedindo ao mesmo sistema probabilístico para gerar uma resposta e, em seguida, pedindo a esse mesmo sistema para certificar que a resposta estava correta. Isso não é verificação. Isso é teatro de auticonsistência.

Deixe a Matemática Decidir

Extratos bancários têm uma característica que a maioria dos documentos não tem: restrições aritméticas integradas. O saldo inicial mais a soma de todas as transações deve ser igual ao saldo final. Os saldos progressivos, quando presentes, devem alinhar-se linha por linha. Estas não são preferências estilísticas. São regras rígidas.

Reconstruí a arquitetura em torno dessa percepção. Agora, cada extração, independentemente da origem, passa por uma camada de validação antes que qualquer usuário a veja. Não importa se os dados vieram de um LLM interpretando um PDF nebuloso, de um mecanismo de OCR lendo uma página digitalizada ou de um parse direto de CSV. O validador trata todas as fontes como igualmente suspeitas.

A verificação é brutalmente simples. Some cada transação ao saldo inicial. Compare o resultado com o saldo final declarado. Se os números não coincidirem, algo está errado. Sinalize o extrato para revisão. Rejeite a extração. Não permita que ela chegue ao usuário.

Essa única mudança alterou todo o caráter do produto. O modelo de linguagem não precisava mais ser perfeito. Ele só precisava ser bom o suficiente para produzir uma saída que pudesse sobreviver a um teste matemático. A pressão mudou de alcançar uma precisão impossível em um domínio sem restrições para construir um ciclo de feedback fechado entre geração e verificação.

O validador também expôs padrões nos erros. Certos tipos de documentos falhavam consistentemente na verificação matemática, o que me indicou exatamente onde investir esforço. Em vez de melhorar cegamente a engenharia de prompt de forma generalizada, pude ver que layouts bancários específicos causavam erros sistemáticos.

Código onde o código pertence, IA onde ela brilha

Talvez a lição mais humilde tenha sido perceber o quanto do pipeline não precisava de IA de forma alguma. Quando encontrei arquivos OFX australianos bagunçados, meu instinto foi jogar tokens no problema. Por um breve momento, considerei alimentar o modelo com o XML corrompido e pedir que ele reparasse a estrutura antes do parsing. Em vez disso, escrevi vinte linhas de código determinístico. Isso corrigiu as peculiaridades de codificação e as tags malformadas instantaneamente, com custo zero por arquivo e reprodutibilidade perfeita.

Essa experiência cristalizou como os pipelines de extração devem ser organizados. Existem três tarefas distintas, e elas não devem ser misturadas.

  • O modelo entende documentos bagunçados. PDFs digitalizados com tabelas distorcidas, fontes mistas e escrita à mão