Quant Research Framework

A referência em Python é o framework que qualquer pessoa pode instalar hoje e usar para gerar estratégias, baseadas em regras ou em ML, dentro de um pipeline com rigor de pesquisa. Você escreve uma função que recebe (df, lb) e devolve sinais int8 em {−1, 0, +1}; o framework cuida da otimização, da orquestração walk-forward, da rotação de regime, da suíte de overlays de robustez de 5 cenários e do cálculo de métricas. O loop interno em numba JIT aplica fees, slippage, funding (apenas cripto), SL/TP intrabar, janelas de sessão e lógica de forced-close sobre um trade ledger tipado, então o PnL simulado é o que uma camada de execução real veria.

Sete subsistemas principais já vêm na caixa, data loader, núcleo de indicadores, contrato de estratégia, núcleo de execução, optimizer, orquestrador walk-forward, engine de regime, mais os blocos de diagnóstico Monte Carlo e Deflated-Sharpe. A release v0.4.0 destrinchou Config dos globals, o que é o que permite dois backtests coexistirem no mesmo interpretador e também o que destravou o protocolo de paridade entre linguagens lá na frente.

• ▪Instalação: pip install quant-research-framework. DOI: 10.5281/zenodo.19798594. Licença Apache-2.0.
• ▪Contrato de estratégia deliberadamente mínimo: (df, lb) → int8[] em {−1, 0, +1}. Mesma superfície para regras escritas à mão e para modelos de ML.
• ▪CSVs incluídos pra deixar o primeiro backtest a uma linha de distância: SOLUSDT 1h (48.094 barras) e EURUSD 1h (53.160 barras).

A porta Rust te dá a mesma engine, mesmo WFO, mesmo segmentador de regime, mesma suíte de robustez, mesma semântica de estratégia, em um binário que cabe num deploy de produção sem interpretador Python. É uma implementação separada da mesma especificação, não uma transliteração: layout de memória diferente, regime de arredondamento diferente (LLVM-via-rustc vs LLVM-via-numba), RNG diferente. O ponto é exercitar a especificação algorítmica com duas engines cuja única linhagem compartilhada é a própria especificação.

O contrato de estratégia espelha o Python exatamente: fn(&[Bar], usize) → Vec<i8>. A camada de detecção de flip traduz níveis de sinal brutos em códigos de entrada/saída; essa separação permite que o autor da estratégia especifique o estado desejado (long/short/flat) em vez de transições, o que é muito mais fácil de manter no-look-ahead-correto.

• ▪DOI: 10.5281/zenodo.19798592. crates.io: cargo add quant-research-framework-rs.
• ▪Dependências deliberadamente pequenas e pinadas: rand =0.9 (exato), chrono 0.4, chrono-tz 0.10. O pin exato em rand está documentado porque rand 0.10 transforma random_range em método de trait, quebrando os call sites.
• ▪O binário Rust não precisa de warm-up; o Python paga um custo único de cache JIT do numba antes da primeira run medida.

A paridade é o protocolo que nos permite afirmar que Python e Rust estão rodando o mesmo backtester, em vez de dois backtesters que apenas se parecem. Três superfícies de configuração determinísticas são verificadas end-to-end em todo PR: config default (56 pontos métricos · WFO por candle-trigger + lookback smart-otimizado + auto-RRR), regime + WFO (98 pontos métricos · otimização de LB por regime + rotação de LB OOS + warmup de 200 barras + 4 janelas WFO) e modo forex (56 pontos métricos · sizing de posição em pip + cap de PnL em modo forex).

Tolerância é 10⁻³ relativa; o pior desvio observado entre os 210 pontos métricos é 5×10⁻⁵, vinte vezes mais apertado que a faixa declarada, o que tomamos como evidência de que equivalência algorítmica, não acumulação numérica, é a restrição que prende. A replicação de tempo-de-paper, com 210 pontos, casou bit-a-bit na precisão de impressão \%.4f.

• ▪Re-rodar a paridade é um comando por superfície, runtime total ≈ 5–10 min em um laptop recente.
• ▪Desabilitado por design: percentis Monte Carlo (implementações de RNG diferentes entre as engines) e o overlay INDICATOR_VARIANCE — um deslocamento de lookback de ±1 não-semeado, aleatório por intenção, então essas linhas variam de execução para execução em cada engine e ficam fora da superfície de paridade.
• ▪Escopo não verificado divulgado honestamente: Windows MSVC. A combinação quádrupla regime+WFO+forex+session agora é byte-exata e tem gate no CI (Fase 08), e a paridade cross-arquitetura em aarch64 é verificada por CI (Fase 06).

O ponto da fase de perf é que a engine Rust é operacionalmente utilizável em um deploy de produção, não que a referência Python seja lenta. No benchmark incluído, a porta Rust roda 23.8–57× mais rápido end-to-end com RSS de pico do processo 33–65× menor, o delta de memória atribuível à engine é plausivelmente apenas 3–5× quando se subtrai o baseline do interpretador Python (pandas/numpy/numba), e o paper lê o número headline com essa ressalva.

A comparação de speedup é significativa precisamente porque a paridade prende: sem paridade, uma reimplementação mais rápida pode estar apenas fazendo menos trabalho; com paridade, você está cronometrando duas implementações do mesmo algoritmo.

• ▪Os benchmarks rodam em fatias do SOLUSDT 1h em 15k / 25k / 35k / 48k barras, três runs warm (com um warm-up descartado para o cache JIT do numba).
• ▪O pipeline default completo roda end-to-end: baseline IS/OOS, busca smart-otimizada de lookback com auto-RRR, walk-forward por candle-trigger, diagnósticos Monte Carlo e os quatro overlays de robustez da v0.1.x.

O paper que acompanha o projeto documenta a arquitetura, o pipeline WFO + regime + robustez, a metodologia de paridade, a comparação de performance e um blueprint de reprodutibilidade adequado para publicação acadêmica. Ele posiciona o framework contra seis backtesters open-source amplamente usados e a literatura estatística relevante; a contribuição é a combinação mais o protocolo de paridade, não uma nova máquina estatística.

Doze rodadas internas de revisão levaram o paper de uma média de score de 7,0 para a trajetória final 8/8/9. O repositório do paper traz requirements-paper.txt com deps Python pinadas, um Makefile que roda make verify contra SHAs irmãos pinados e um parity_residuals.csv gerado que sustenta cada figura.

• ▪Fonte completa: github.com/DaruFinance, repositório do paper + repositório python + repositório rust como irmãos.
• ▪Os dois artefatos têm DOIs Zenodo separados; o repositório do paper receberá seu próprio DOI quando arquivado no Zenodo no momento da publicação.

A porta Rust foi cross-compilada para aarch64-unknown-linux-gnu e rodada sob emulação user-mode QEMU contra os mesmos inputs do binário x86_64. Após semear o overlay de variância-de-indicador antes não-semeado (uma falha descoberta e corrigida durante a preparação do paper), cada métrica determinística impressa é byte-idêntica entre as duas arquiteturas em todos os seis datasets, 1.176 linhas de métrica, zero diferenças. Apenas o load e o wall-clock total diferem, ambos inflados pelo overhead de emulação do QEMU.

A comparação é igualdade exata de string do bloco de métricas impresso, estritamente mais forte que a checagem por tolerância relativa usada na paridade cross-linguagem, e se sustenta porque o hot path usa apenas operações IEEE-754 corretamente arredondadas, sem fast-math nem codegen de fused-multiply-add. Um job ARM nativo num runner ARM público gratuito roda a mesma asserção de byte-identidade em silício real ao lado do job QEMU, de modo que ambas as arquiteturas são checadas a cada mudança e o resultado QEMU fica como backstop reprodutível.

O núcleo de execução, na versão fixada pelo paper, operava sobre uma única série OHLC de cada vez. O substrato multi-ativo que remove essa limitação foi lançado na v0.5.0 nas duas engines: uma camada panel (detecção de regime cross-asset, baskets long/short, sizing por equal-risk-contribution, neutralizações beta / dólar / sigma, restrições de portfólio) mais primitivas de pairs e carry, sobre um trade-ledger por-leg redesenhado que carrega leg id, trade-group id e uma decomposição completa de custos (fee, slippage, funding, bruto e líquido) satisfazendo bruto − custos = líquido até tolerância de ponto flutuante.

Cada primitiva é espelhada Python ↔ Rust e exercida por seu próprio gate de paridade no CI, com a mesma disciplina das superfícies originais, oito superfícies agora concordam dentro de 1e-3 (contagem de trades exata). A saída de ativo único é byte-idêntica à do release anterior. A pesquisa de estratégias proprietária que roda sobre esse substrato permanece privada; o release público é a capacidade da engine, não as estratégias.

O record publicado de paridade cobria três superfícies; a combinação quádrupla, regime + WFO + forex + session, era a que faltava, e agora está fechada. Ao investigar a divergência do combo, encontraram-se duas causas. A dominante era um descasamento no harness, não um bug de engine: o driver do combo alimentava as duas engines com knobs de seleção diferentes (mínimo de trades e otimização de risk-to-reward são constantes de compilação no lado Rust, mas estavam sendo sobrescritos no lado Python), então a fase in-sample escolhia um lookback diferente.

O resíduo eram três divergências na barra de fim de sessão no core Rust: na última barra em-sessão do dia ele deixava um sinal de flip oposto abrir posição, nunca bloqueava uma nova entrada, e rodava a checagem intrabar de stop/alvo, enquanto a engine de referência força o fechamento incondicionalmente e pula a checagem de stop/alvo ali. Alinhar os três (totalmente protegido pela flag de sessão, então as superfícies de feature única ficam byte-idênticas) torna o combo byte-exato em todos os estágios. Agora roda como uma quarta superfície de paridade com gate no CI, encolhendo o footprint não-verificado-divulgado-honestamente para Windows MSVC.

O utilitário de DSR (Bailey & López de Prado 2014) era só em Python porque depende da distribuição normal do scipy e é invocado uma vez por trajetória de otimização, não por barra. Agora está espelhado em Rust atrás de uma feature flag leve, com a mesma disciplina de paridade aplicada à sua saída escalar: um harness dedicado alimenta fixtures idênticas de (Sharpe, trial-Sharpes, retornos), incluindo casos assimétricos, de cauda pesada e todos os casos-guarda degenerados, para as duas implementações e confirma concordância no Sharpe-máximo-esperado e no Sharpe deflacionado dentro da tolerância padrão, e de fato abaixo de 1e-9 em todos os casos finitos, já que ambos são fechados em forma.

A CDF normal e sua inversa vêm de um crate de estatística confiável que casa com o scipy em cerca de 1e-12; a aproximação grosseira da função-erro usada em outras partes do port é deliberadamente não reusada, porque seu erro de cauda corromperia o termo de Sharpe-máximo-esperado no quantil relevante. O benefício é um deploy só-Rust que computa diagnósticos de Sharpe deflacionado sobre suas próprias trajetórias de otimizador sem round-tripping pelo Python.