FinanceBench: Por que o RAG com Vector-Store falha em documentos financeiros reais

O FinanceBench chega em um momento em que todos os fornecedores de IA empresarial afirmam que seu sistema pode "responder a perguntas de seus documentos financeiros". Este artigo da Patronus AI coloca essas afirmações à prova usando registros reais da SEC e perguntas de livro aberto cuidadosamente selecionadas. Os resultados são uma leitura desconfortável para quem está construindo IA para finanças.

O artigo

Islam et al. apresentam o FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944), uma suíte de testes com 10.231 perguntas sobre empresas de capital aberto extraídas de registros reais da SEC — relatórios anuais 10-K, relatórios trimestrais 10-Q, relatórios correntes 8-K e transcrições de resultados. Ao contrário de conjuntos de dados de QA financeiro anteriores (FinQA, TAT-QA), que apresentam tabelas e passagens pré-extraídas, o FinanceBench exige que o sistema recupere evidências de documentos completos antes de responder. Esse é o cenário realista. As perguntas são projetadas para serem factualmente inequívocas e, nas palavras dos autores, "um padrão mínimo de desempenho".

A equipe avaliou 16 configurações abrangendo GPT-4-Turbo, Llama2 e Claude2 em quatro estratégias de recuperação: closed-book (sem recuperação), vector store compartilhado, vector store por documento e prompts de contexto longo alimentando a página relevante completa. Avaliadores humanos revisaram manualmente todas as 2.400 respostas em 150 casos de código aberto.

Ideias principais

• A recuperação não é o gargalo. O GPT-4-Turbo, com a passagem oráculo — a página exata contendo a resposta — ainda atinge apenas 85% de precisão. O prompting de contexto longo (alimentando a página correta automaticamente) atinge 79%. Uma recuperação perfeita garante apenas seis pontos de melhoria.
• O RAG com vector-store é o problema real. GPT-4-Turbo com um vector-store por documento: 50% correto, 39% de recusa. Com um vector-store compartilhado entre empresas: 19% correto, 68% de recusa. A manchete de "taxa de falha de 81%" vem dessa configuração de store compartilhado — a configuração que a maioria das demonstrações empresariais realmente usa.
• Os modelos falham de formas diferentes. O Llama2 alucina agressivamente (54–70% incorreto); o GPT-4-Turbo recusa (39–68% recusado em vez de errado). Ambos os modos de falha são inaceitáveis em produção, mas não representam riscos equivalentes.
• 66% das perguntas exigem raciocínio numérico. Taxas de crescimento, margens, variações ano a ano. É aqui que os modelos erram mais comumente — erros de cálculo, confusão de unidades, erros de sinal.
• O contexto longo quase salva. Contexto longo do Claude2: 76% correto. Contexto longo do GPT-4-Turbo: 79%. Esses são os melhores números práticos, alcançados ao ignorar a recuperação e alimentar a página relevante inteira diretamente.
• Até o oráculo falha. Com evidências perfeitas, o teto é de 85%, não 100%. Quinze por cento das falhas são falhas puras de raciocínio, sem componente de recuperação.

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

O design do benchmark é sólido. Insistir em documentos reais em vez de trechos pré-extraídos é a escolha metodológica correta — testa o que realmente importa na implementação. A avaliação manual de 2.400 respostas é cara e credível.

O que considero menos convincente é extrair classificações de n=150. A diferença entre o contexto longo do Claude2 (76%) e o contexto longo do GPT-4-Turbo (79%) é estatisticamente insignificante com esse tamanho de amostra, mas o artigo a apresenta como um ranking. O benchmark completo de 10.231 perguntas existe, mas não é pontuado publicamente, o que limita a reprodução independente.

O resultado do oráculo é também a descoberta mais importante e menos analisada. Se os modelos falham 15% das vezes com a página correta em mãos, o problema é o raciocínio e a aritmética, não a recuperação. O artigo aponta ferramentas de calculadora e chain-of-thought como trabalhos futuros — esses experimentos deveriam ter sido o centro deste artigo, não uma nota de rodapé.

O benchmark também reconhece que visa o "desempenho mínimo": perguntas de documento único com respostas inequívocas. Raciocínio entre documentos, tendências de vários anos e comparações entre empresas são excluídos. Artigos que citam o número de 79% para contexto longo raramente mencionarão essa ressalva.

Por que isso importa para a IA financeira

O caso de uso de escrita (write-back) no Beancount mapeia quase diretamente os modos de falha do FinanceBench. Um agente que recupera uma entrada de transação e verifica se o valor corresponde a um extrato bancário está realizando a mesma tarefa de recuperação seguida de aritmética que este benchmark mede. O teto do oráculo — 85% mesmo com contexto perfeito — é a restrição de design relevante: mesmo que o agente encontre a entrada correta no livro-razão (ledger), há uma probabilidade real de que ele calcule mal a comparação, confunda o sinal ou interprete mal as unidades.

A divisão de falhas Llama2/GPT-4 importa para a arquitetura do agente. Uma recusa é recuperável (encaminhamento para revisão humana); uma correspondência alucinada registrada no livro-razão não é. Isso corrobora a preferência por um comportamento de recusa conservador em vez de alucinação confiante, mesmo ao custo de uma taxa de sucesso aparente menor.

A vantagem do contexto longo (79% vs. 50%) é praticamente frustrante para aplicações de livros contábeis. Arquivos Beancount de vários anos são grandes demais para serem alimentados na íntegra. Resolver a recuperação em documentos numéricos densos — e não apenas a recuperação de texto — continua sendo um problema em aberto.

O que ler a seguir

• FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — o benchmark precursor que o FinanceBench explicitamente aprimora; útil para entender o que a área acertou antes que a recuperação de documentos reais fosse exigida.
• DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — estende o FinanceBench com perguntas mais difíceis de multi-hop que exigem raciocínio entre seções dentro de um único registro.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — delega a aritmética a um intérprete Python, abordando diretamente os 66% das perguntas do FinanceBench que falham no raciocínio numérico.