Resumo Técnico: Backtrader-Bench

Definição do Problema

Avaliar agentes de codificação de Grandes Modelos de Linguagem (LLMs) no domínio do trading algorítmico enfrenta três desafios críticos que os benchmarks existentes não conseguem abordar:

1. Contaminação de Dados: Benchmarks estáticos correm o risco de contaminação após a publicação, pois os modelos podem ter encontrado as questões durante o pré-treinamento.
2. Fidelidade da Verdade Fundamental (Ground-Truth): Saídas numéricas de backtests exigem uma verdade fundamental derivada exatamente do mesmo caminho de execução de código que o agente percorre. Datasets estáticos não podem garantir esse alinhamento.
3. Qualidade em Escala: A geração automatizada frequentemente produz itens trivialmente fáceis ou malformados, enquanto a curadoria manual não escala.

Os benchmarks atuais (ex: PIXIU, FinBen, InvestorBench) focam em NLP financeiro ou tomada de decisão, mas não medem a capacidade de um agente de conduzir corretamente uma biblioteca de backtesting, interpretar sua saída numérica e relatar respostas precisas. Essa lacuna é significativa porque a correção do backtest depende de interações sutis entre a lógica da estratégia, configurações de corretora (broker) e regras de dimensionamento de posição; um único erro de parâmetro pode produzir curvas de lucro e perda plausíveis, porém incorretas, com consequências financeiras diretas.

Metodologia

Os autores apresentam o Backtrader-Bench, um framework resistente à contaminação construído sobre a biblioteca Python backtrader. Ele emprega dois pipelines complementares para gerar e curar questões:

1. Pipeline Determinístico de MCQ

Este pipeline gera questões de múltipla escolha (MCQs) verificadas a partir de configurações de backtest.

• Escopo: Cobre cinco estratégias de trading canônicas (SMA Crossover, Rolling Window Mean, EWMA, RSI, MACD Crossover) e 33 templates de questões em três níveis de dificuldade:
  • Fácil: Buscas diretas de valor único.
  • Médio: Filtragem condicional ou agregação simples.
  • Difícil: Métricas derivadas de múltiplos passos ou backtests comparativos.
• Verificação: Um design de dupla verificação garante a fidelidade da verdade fundamental. Um estágio de "construção" executa um backtest para gerar questões e respostas. Um estágio de "verificador" independente reexecuta o backtest com a mesma configuração para rederivar a resposta. Inconsistências sinalizam falhas de verificação.
• Reprodutibilidade: Uma única semente aleatória (seed) controla todos os aspectos estocásticos (seleção de template, geração de distratores, embaralhamento de opções), permitindo que novos datasets sejam gerados sob demanda sem chaves de resposta públicas.

2. Pipeline de Filtragem Gerador-Solver

Para escalar além dos templates desenhados à mão e aumentar a dificuldade, este pipeline minera autonomamente questões mais difíceis.

• Gerador: Um LLM escreve uma questão de formato livre e um código de verificação Python autocontido. O código aceita uma variável de semente para parametrizar entradas (ticker, datas, etc.).
• Verificação: O código é executado em um subprocesso. Se falhar ou exceder o tempo limite, a questão é descartada.
• Conversão para MCQ: Questões verificadas são convertidas em MCQs de quatro opções. Os distratores são gerados reexecutando o código de verificação com valores de semente perturbados (jitter multiplicativo), garantindo que os distratores estejam na mesma ordem de magnitude que a resposta correta.
• Filtragem:
  • Estágio 1 (Solver Sem Ferramentas): Um solver sem execução de código tenta responder à questão. Se responder corretamente, a questão é descartada como "muito fácil" (solucionável via conhecimento paramétrico).
  • Estágio 2 (Solver Com Ferramentas): As questões restantes são passadas para um solver com execução de código. Se responder corretamente, a questão é mantida.
  • Estágio 3 (Revisão Humana): Questões que nenhum dos solvers consegue responder são sinalizadas para revisão humana.

Estrutura de Avaliação

Os autores avaliaram 11 modelos sem ferramentas e quatro configurações com ferramentas em dois datasets:

• Benchmark Curado: 30 questões (10 fáceis, 10 médias, 10 difíceis) extraídas do pipeline determinístico.
• Conjunto de Questões Mineradas: 38 questões aceitas pelo pipeline de filtragem onde o solver sem ferramentas falhou, mas o solver com ferramentas teve sucesso.

Modos de Avaliação:

• Com Ferramentas (With-Tools): Agentes usam o Cursor Agent CLI com execução de código completa, instalação de pacotes e I/O de arquivos em ambiente isolado (sandbox).
• Sem Ferramentas (No-Tools): Agentes usam o Cursor SDK com todo o uso de ferramentas explicitamente desativado e reforçado via inspetores de tempo de execução.

Principais Resultados

Desempenho no Benchmark Curado (30 Questões)

• Aumento por Ferramentas: Agentes aumentados por ferramentas (GPT-5.5 e Opus 4.7) alcançaram 90,0% de precisão em uma única passagem.
• Linha de Base Sem Ferramentas: Os melhores modelos sem ferramentas (Opus 4.7, Gemini 3.1 Pro) tiveram uma média de 73,0% de precisão ao longo de 10 execuções.
• Lacuna: O aumento por ferramentas proporcionou uma melhoria de 17 pontos percentuais.
• Sensibilidade à Dificuldade: Enquanto os agentes com ferramentas pontuaram 100% em questões fáceis, os modelos sem ferramentas caíram significativamente em questões difíceis (variando de 20% a 68%).
• Estabilidade: A avaliação sem ferramentas mostrou alta variância; por exemplo, o Opus 4.6 obteve 76,7% em uma única execução, mas uma média de 64,3% em 10 execuções, destacando a necessidade de média de múltiplas execuções para a avaliação sem ferramentas.

Desempenho nas Questões Mineradas (38 Questões)

• Colapso de Precisão: No conjunto minerado (desenhado para ser insolúvel sem código), a precisão sem ferramentas caiu ainda mais. Metade dos modelos caiu para níveis de aproximadamente chance aleatória (~25%).
• Melhores Desempenhos: Mesmo os modelos mais fortes (Gemini 3.1 Pro, GPT-5.5) caíram para ~60,5%, enquanto modelos mais fracos (Kimi K2.5, Grok 4.3) caíram para 15–21%.
• Dependência do Filtro: A dificuldade das questões mineradas é relativa ao modelo de filtro (GPT-5.4 neste estudo). Modelos mais fortes ainda resolveram ~60% dessas questões sem ferramentas, sugerindo que o modelo de filtro define o teto de dificuldade.

Análise de Erros

• Agentes falharam consistentemente em métricas financeiras derivadas de múltiplos passos (ex: drawdown máximo, retornos ajustados ao risco, razão de Sharpe).
• As maiores quedas de precisão ocorreram em mecânicas de ordens de gatilho (bracket-order) e stop móvel (trailing-stop), que dependem fortemente do loop de eventos de estado e das mecânicas de execução de ordens da biblioteca backtrader.

Significância e Alegações

O artigo alega que o Backtrader-Bench aborda a lacuna específica de avaliar se um agente pode conduzir corretamente um motor de backtesting e interpretar sua saída numérica, um pré-requisito para a adoção segura na finança quantitativa.

• Relevância Prática: As capacidades testadas mapeiam diretamente para fluxos de trabalho quantitativos: configurar motores, executar variantes de estratégia e interpretar métricas de risco. Os resultados sugerem que, sem execução de código, os agentes podem reportar incorretamente métricas críticas (como drawdown) em aproximadamente uma em cada quatro questões, potencialmente levando a uma seleção de estratégia falha.
• Infraestrutura para RL: Além da avaliação, a infraestrutura escalável de MCQ é projetada para produzir um corpus de treinamento verificado para aprendizado por reforço (RL). O objetivo final é construir um agente especializado para fluxos de trabalho de trading quantitativo que possa conduzir de forma confiável motores de backtest e evitar erros de configuração.
• Modéstia sobre Limitações: Os autores reconhecem que a dificuldade das questões mineradas é relativa ao modelo de filtro, que a escala de avaliação é limitada pelos custos computacionais (uso de tokens e tempo) e que o escopo atual é restrito a dados históricos de equity única e à biblioteca backtrader. Eles observam que a significância estatística para classificações detalhadas de modelos é limitada pelo tamanho da amostra (n=30).

O trabalho demonstra que, embora os agentes aumentados por ferramentas superem significativamente as linhas de base apenas paramétricas em tarefas de trading algorítmico, uma parte substancial dos modelos atuais ainda luta com o raciocínio numérico preciso exigido para backtesting financeiro quando privados de capacidades de execução de código.