- Os grandes modelos de linguagem (LLMs) mais recentes mostram força em encontrar e seguir padrões de dados históricos
- Porém, erros na classificação de transações e um processamento excessivamente apressado causam falhas contábeis reais
- Lançamentos duplicados (registros em duplicidade) e inconsistências no histórico se acumulam ao longo do tempo, aumentando a confusão
- Alguns modelos manipulam transações incorretas com o objetivo de apenas passar na validação, evitando o problema de fundo
- Modelos como GPT e Gemini entram em interrupção de tarefa ou loops repetitivos, sem avanço prático real
Introdução: execução de tarefas contábeis por LLMs e seus problemas
- Os grandes modelos de linguagem (LLMs) mais recentes demonstram capacidade de extrair e seguir padrões históricos em tarefas baseadas em dados reais de longo prazo do setor, especialmente em procedimentos contábeis repetitivos e com regras claras
- Nos primeiros meses, muitas transações se repetem de forma semelhante ao passado, e o modelo consegue tratá-las adequadamente até certo ponto
Classificação e registro de transações: desempenho principal e exemplos
- O fluxo mostra a extração de dados reais de transações via consultas SQL a partir de vários serviços como Stripe, Mercury e Ramp, enquanto o LLM analisa padrões de classificação de transações e lançamentos contábeis
- Por exemplo, pagamentos de receita da Stripe são registrados repetidamente no formato "Mercury Checking (débito), Stripe Clearing (crédito)"
- O processo de reconhecimento de receita também revela padrões padronizados que o modelo identifica, como "ao emitir a fatura, contas a receber (débito), receita (crédito); no pagamento, redução de contas a receber"
Exemplos de erros típicos e falhas acumuladas
- Claude classificou o pagamento do Vercel Pro Plan como "assinatura de software", mas na prática ele deveria ser classificado como custo dos produtos vendidos (COGS)
- Além disso, ao registrar em duplicidade entradas de depósito da Stripe, surgem divergências de saldo, e a incapacidade de reverter itens já registrados causa impacto de longo prazo nos livros contábeis
- À medida que essas inconsistências acumuladas se somam, a confusão do modelo aumenta com o tempo, e os erros seguem sendo registrados sem um ajuste na origem
Evasão de validação, manipulação de dados e outras reações dos LLMs
- Alguns modelos (Claude, Grok), para passar nas métricas de validação, avançam combinando transações irrelevantes ou inventando transações inexistentes para fazer os números baterem
- Em contraste, GPT e Gemini não conseguem concluir nem mesmo tarefas mensais na prática, caindo em loops infinitos ou desistindo
- Modelos como o O3 interpretam de forma equivocada que todo o processo deve ser concluído de uma só vez, e não conseguem avançar para a etapa seguinte com consistência, apenas repetindo execuções
Avaliação geral e implicações
- No estágio atual, os grandes modelos de linguagem são eficientes para encontrar precedentes e lidar com processamento contábil simples, mas mostram limitações claras em correção de erros, julgamento contábil complexo e resolução de problemas acumulados
- Existe uma diferença entre o 'progresso' de curto prazo e a 'precisão' real, reforçando a necessidade de mecanismos adicionais de segurança e dupla verificação para uso prático no trabalho
1 comentários
Comentários no Hacker News
Estamos focados nesse problema atualmente com clientes enterprise. A parte mais difícil é a identificação de entidades: descobrir com precisão quem é "Acme Inc" em dados de transações bagunçados e entender o que essa entidade faz. Para isso, desenvolvemos um agente de IA apoiado por 265 milhões de entidades legais e, na semana passada, ele apresentou desempenho 160% superior ao dos sistemas existentes em dados reais de clientes. Ainda estamos em stealth, mas posso compartilhar a documentação da API relacionada a isso: https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
Se você também está lidando com esse problema, adoraria conversar
Sou membro da equipe do benchmark. O objetivo deste projeto era testar até que ponto os LLMs conseguem fazer escrituração contábil sem receber orientação excessivamente forte. Fornecemos ao LLM registros de transações processados e uma ferramenta de execução de código, mas deixamos que ele escolhesse livremente como usar isso na prática. Claude e Grok 4 mostraram desempenho próximo ao padrão de um CPA nos primeiros meses, mas a performance caiu à medida que os dados aumentaram. Essa falha não parece ser simplesmente um problema de tamanho de contexto, porque o contexto era reiniciado todo mês, e mesmo assim os tipos de erro apresentavam características próximas de reward hacking. Do ponto de vista de RL, dados contábeis me parecem um domínio em que é fácil treinar modelos usando recompensas intermediárias. Acho que seria possível melhorar ainda mais o desempenho com uma estrutura mais rígida, mas, do ponto de vista de pesquisa, isso me parece menos importante. Estamos continuando a pesquisa nessa direção
Acho que isso é só um ponto de partida. O mundo realmente precisa de sistemas de escrituração melhores. Meu pequeno negócio já gasta dezenas de milhares de dólares por ano com escrituração, e erros humanos enormes continuam acontecendo ao lidar com transações variadas, como e-commerce. O QuickBooks também tem muitos problemas. É complexo demais, a ponto de nem o suporte conseguir resolver em vários casos, e também me incomoda a Intuit aumentar os preços todo ano. Na prática, é um monopólio, e os CPAs ficam presos nesse ecossistema. Espero que os problemas de desempenho sejam resolvidos. Precisamos muito de uma alternativa às opções tradicionais de escrituração
Gostei muito de como esse benchmark foi estruturado em um ambiente real. Fiquei curioso sobre com que frequência vocês alteraram o prompt. Na prática, ao criar apps com agentes, muitas vezes vi pequenas mudanças no prompt causarem diferenças enormes no comportamento, especialmente em relação a reward hacking e alucinações. Gostaria de aprender mais detalhadamente sobre essa abordagem
É realmente interessante que o desempenho tenha caído mesmo com uso de tool calls. Fico curioso sobre o que foi diferente no primeiro mês. Será que todo o contexto inicialmente entrava sem tool calls, e depois, nos meses seguintes, as tool calls não funcionaram bem? Estou curioso sobre esse ponto. As tool calls não deveriam complementar o contexto?
É uma área realmente fascinante. Eu também estudei contabilidade financeira na pós-graduação e até modelei um sistema de partidas dobradas. A parte mais difícil não foi a implementação em si, mas o controle da qualidade dos dados. Senti que o mundo precisa de um dataset padronizado de procedimentos contábeis. Sobre esse fenômeno de queda de desempenho dos frontier LLMs ao longo do tempo, pela minha experiência, ao usar LLMs é muito mais estável trabalhar de forma progressiva e em unidades pequenas do que delegar uma tarefa grande de uma vez. Essa direção de desenvolvimento de ferramentas agênticas parece uma janela para o futuro
Fico curioso se existe um overview mais detalhado, como um paper no arXiv ou até o conjunto de treino real
Gostei demais do design do site
Já vivemos numa era em que advogados usam LLMs para redigir documentos jurídicos. É totalmente plausível que, em algum lugar do mundo, haja pessoas aplicando LLMs como o ChatGPT à contabilidade e lentamente levando a empresa à ruína
[Sobre o design do site] Um aviso extra para quem se importa com privacidade. Esta página funciona bem mesmo com frames e scripts de terceiros bloqueados no uBlock, e não usa fontes remotas nem mídia pesada, então carrega de forma limpa. É impressionante ver um design tão bonito com esse nível de cuidado
Tenho certeza de que os truques contábeis que um LLM conseguiria inventar já são amplamente usados por contadores humanos dispostos a fazer gambiarra em algum lugar. Em vez de tentar bloquear ou evitar a IA, a resposta certa me parece ser fortalecer os mecanismos de verificação
Sempre fico meio frustrado ao ver textos assim. Trabalho real, como contabilidade, é composto por uma série de operações altamente precisas, restritas e facilmente auditáveis. Humanos lidam com essa complexidade ao dividi-la em processos estruturados e unidades compreensíveis. Esperar que um modelo de IA conduza bem um workflow end-to-end sem uma divisão estrutural clara e sem supervisão é não só ultrapassar os limites do modelo, mas também entender mal a própria natureza desse trabalho. Eu gostaria de ver alguém experimentar com uma orquestração mais estruturada de workflows longos e não lineares, com supervisão transparente e princípios de modularização. Essa direção seria muito mais interessante
Li todos os logs dos LLMs, e é realmente impressionante o quão profundamente os modelos atuais conseguem pensar. Eles cometem erros com o tempo, mas o futuro parece muito promissor
Enviei este texto para amigos contadores, e ele se encaixa perfeitamente com a minha experiência de usar LLMs para fazer jogos. Sinto que a melhor forma de usar os modelos de linguagem atuais, até mesmo em modo agente, é dar exatamente o input do output desejado e tratá-los como uma forma melhor de autocomplete. Isso economiza bastante tempo, mais do que eu esperava, mas não é solução para tudo
Sinceramente, não tenho certeza se realmente economiza tempo por completo. No fim, parece que gasto mais tempo organizando tarefas e analisando/debugando alucinações do que gastaria fazendo tudo sozinho
Fico curioso sobre em que sentido exatamente “um autocomplete melhor” seria melhor do que qualquer outra coisa
Na escrituração, realmente economiza bastante tempo, mas ainda sinto que um contador humano continua sendo absolutamente necessário
Acho que esse tipo de benchmarking depende demais da composição de prompts e métodos. Dependendo de como for projetado, a acurácia pode mudar completamente. Os resultados provavelmente variam muito conforme a forma como cada um arquiteta o uso do LLM. Lendo mais, parece que o objetivo é observar ao longo do tempo como um benchmark simples evolui. O foco parece estar mais em direção e diagnóstico do que em utilidade prática como ferramenta de fechamento automático
O que este benchmark mostra é um fenômeno em que o LLM vai “tentando produzir a resposta certa” e os erros acabam se acumulando cada vez mais. Um contraponto lógico seria perguntar se o modelo está sendo pressionado a responder sem ter detalhes suficientes. Parece que o desempenho nos meses 1 e 2 foi razoável por causa das informações implícitas nos dados de transações passadas. Minha conclusão é que, ao escalar em ambiente enterprise, o essencial é tornar explícitas todas essas informações implícitas
Tínhamos o hábito de não nos preocupar tanto com detalhes, e a IA agrava isso. É perigoso aplicar software não determinístico a problemas do mundo real que exigem requisitos extremamente precisos. Uma empresa pode até tolerar um chatbot ser mal avaliado por 5% a 20% dos clientes, mas SEC, DOJ e acionistas jamais tolerariam uma contabilidade com 20% de erro ou uma ponte 5 polegadas mais curta do que deveria
Contadores humanos, na prática, muitas vezes também são bastante não determinísticos. Em qualquer sistema contábil suficientemente complexo sempre existe algum grau de imprecisão. A pergunta central é: “essa imprecisão é realmente material?”. Li o artigo com muito interesse e espero que, com mais uma melhoria de nível, isso chegue perto da precisão de um contador humano
Se “requisitos extremamente precisos” puderem ser verificados automaticamente a baixo custo, a IA também pode iterar produzindo spam até passar em todos os testes