Pular para o conteúdo principal

Agentes de LLM podem ser CFOs? Simulação de 132 meses do EnterpriseArena revela uma grande lacuna

· 7 min para ler
Mike Thrift
Mike Thrift
Marketing Manager

A questão mais ambiciosa na IA financeira agora não é "uma LLM consegue responder a uma pergunta sobre um balanço patrimonial?", mas sim "uma LLM consegue gerir o dinheiro de uma empresa ao longo do tempo sem que ele acabe?". O estudo de Yi Han et al., Can LLM Agents Be CFOs? (arXiv:2603.23638), constrói o EnterpriseArena para testar exatamente isso, e a resposta é: mal e por pouco, e não das maneiras que você esperaria.

O artigo

2026-07-11-can-llm-agents-be-cfos-enterprisearena-resource-allocation-benchmark

O EnterpriseArena é uma simulação de 132 meses (11 anos) de alocação de recursos em nível de CFO. Cada passo representa um mês. O agente recebe observações parciais das finanças da empresa, documentos de negócios anonimizados e sinais macroeconômicos extraídos de dados do FRED, CBOE e S&P Global. Ele possui um orçamento de 20 chamadas de ferramentas por mês, distribuídas em quatro operações — verificar a posição de caixa, revisar registros financeiros, analisar condições de mercado e projetar fluxos de caixa — e deve escolher uma de três ações: fechar os livros (reconciliação), solicitar financiamento (capital próprio ou dívida, com resultados estocásticos) ou passar. A restrição principal é que o saldo de caixa da empresa deve permanecer não negativo em todos os passos; a violação encerra o episódio com uma pontuação de zero. Sujeito à sobrevivência, o agente maximiza a avaliação final da empresa sob a fórmula Rev_T × 5 + Cash_T − 5.000 × N_tools, que penaliza explicitamente o uso excessivo de ferramentas.

Onze LLMs foram avaliadas, incluindo Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B e Qwen3.5-9B, juntamente com uma linha de base de especialistas humanos validada por dois profissionais de finanças com 8 e 14 anos de experiência, respectivamente.

Ideias principais

  • As taxas de sobrevivência variam drasticamente entre os modelos: Qwen3.5-9B sobrevive a 80% das execuções, Gemini-3.1-Pro a 50%, Claude-Haiku-4.5 e GLM-5 a 20% cada, e GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B e Mixtral-8x7B a 0%. A média geral das LLMs é de 26%.
  • Modelos maiores não superam necessariamente os menores: Qwen3.5-9B (9B parâmetros, 80% de sobrevivência, valoração terminal de $78,8M) supera decisivamente o Qwen3.5-397B (397B parâmetros, 20% de sobrevivência) e o GPT-5.4 (0% de sobrevivência).
  • A lacuna em relação aos humanos é grande: a linha de base humana atinge 100% de sobrevivência e uma valoração terminal de $152,2M ± $29,6M; a média das LLMs é de $28,2M com 26% de sobrevivência.
  • O fechamento de livros é o gargalo crítico: especialistas humanos fecham os livros (reconciliam) em 94,3% dos passos; a média das LLMs é de 19,3%. Esta é a ação que produz demonstrações financeiras confiáveis e permite decisões subsequentes racionais.
  • Coleta de informações sem ação é letal: o Qwen3.5-397B usa ferramentas de análise de mercado e previsão em uma taxa alta durante toda a simulação, mas quase nunca fecha os livros (0,0% de taxa de fechamento) e quase nunca solicita financiamento, morrendo por exaustão de caixa apesar de "saber" o que estava acontecendo.
  • A penalidade do orçamento de ferramentas é importante: a fórmula de pontuação pune ativamente agentes que verificam compulsivamente em vez de agir, uma restrição que espelha o custo de oportunidade real.

O que se sustenta — e o que não

O design de objetivo duplo — sobrevivência como uma restrição rígida mais a avaliação terminal — é uma das escolhas mais fortes em benchmarks de agentes recentes. Reflete como os CFOs reais operam: você não pode otimizar o crescimento se estiver sem dinheiro. A anonimização de datas do calendário e identidades de empresas impede que os modelos façam correspondência de padrões com base em resultados históricos memorizados, o que é uma melhoria metodológica genuína sobre benchmarks financeiros que usam tickers e datas reais.

A taxonomia de modos de falha identificada pelos autores através de estudos de caso é crível: o GPT-5.4 atinge uma taxa de aprovação de 99,1% (o que significa que toma uma ação em quase todos os passos ao não fazer nada), enquanto o Qwen3.5-397B confunde análise com ação. Esses são modos de falha comportamentalmente distintos com remediações diferentes.

O que me convence menos: o ambiente macro estocástico usa ruído gaussiano para aproximar choques de mercado, o que os próprios autores reconhecem que não pode replicar eventos de cisne negro ou a irracionalidade humana. O orçamento de 20 chamadas de ferramenta por mês também é um tanto arbitrário — CFOs reais não enfrentam esse tipo de restrição de taxa de consulta em sua própria memória, o que levanta a questão de se o benchmark está medindo o julgamento financeiro de longo prazo ou algo mais próximo de RAG sob pressão de recursos. A estrutura de agente único é outra limitação explícita que os autores citam: CFOs reais operam dentro de hierarquias de controllers, analistas de FP&A e equipes de tesouraria, e o artigo não tenta simular isso.

A descoberta de que o tamanho do modelo não prevê a sobrevivência é impressionante e provavelmente genuína, mas o mecanismo não é bem explicado. Os autores observam isso sem detalhar totalmente se é uma falha de seguimento de instruções, coerência de contexto longo ou calibração de risco.

Por que isso importa para a IA financeira

A ação de fechamento de livros no EnterpriseArena é essencialmente a asserção balance do Beancount e a etapa de reconciliação do razão — o momento em que o agente se compromete com uma visão real do estado financeiro antes de agir. A descoberta de que as LLMs pulam isso 80% das vezes mapeia diretamente para o problema de segurança de gravação (write-back): um agente que evita a reconciliação antes de agir é um agente que age com base em um estado obsoleto ou alucinado. Para a automação do Beancount, isso sugere que a etapa de reconciliação deve ser obrigatória e verificável — não opcional — em qualquer loop de agente.

O horizonte de 132 meses também é diretamente análogo à gestão de um razão por vários anos. A descoberta de que a consciência situacional sustentada se degrada ao longo do tempo é a mesma degradação que esperaríamos em um agente de Beancount gerenciando cinco anos de histórico de transações: mesmo que o agente tenha todos os dados em contexto, ele pode não agir sobre eles de forma coerente no mês 60. Isso sugere que pontos de verificação periódicos de reconciliação forçada — e não apenas consultas reativas — são necessários em sessões de agentes de Beancount de longa duração.

A armadilha de coleta de informações em que o Qwen3.5-397B cai é um aviso de design útil: agentes equipados com muitas ferramentas de recuperação podem preferir a recuperação ao compromisso, especialmente quando o custo de uma ação errada (corrupção do razão) é alto. Restrições de orçamento de ferramentas do tipo que o EnterpriseArena usa poderiam ajudar a impor disciplina de ação em agentes de gravação do Beancount.

O que ler a seguir

  • EcoGym (arXiv:2602.09514) — benchmark econômico complementar de longo horizonte em ambientes de Vending, Freelance e Operation ao longo de mais de 1.000 passos; nenhum modelo domina em todos os três, sugerindo que os modos de falha no EnterpriseArena não são idiossincráticos de um único design de benchmark.
  • AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — reformula o design de fluxo de trabalho como uma busca em espaço de código com MCTS e feedback de LLM; se o EnterpriseArena mostra que comportamentos de agentes projetados manualmente falham, o AFlow é o próximo passo óbvio para descobrir melhores pipelines automaticamente.
  • ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — a estrutura fundamental de treinamento e avaliação de uso de ferramentas; entender como o comportamento de chamada de ferramentas é aprendido no ToolLLM esclarece se a falha de evitação de ação no EnterpriseArena é um problema de treinamento ou de prompting.