Busca Aleatória vs. Busca Inteligente: o Cruzamento é o Custo de Avaliação, Não o Algoritmo
Parte da série "Backtests Sem Ilusões".
Existe uma sabedoria convencional em otimização de hiperparâmetros: a busca aleatória é uma linha de base que se deve superar. O resultado clássico de Bergstra & Bengio (2012) estabeleceu que aleatório vence grid; depois a otimização bayesiana, o TPE, o CMA-ES e métodos multi-fidelidade como Hyperband/ASHA deveriam, por sua vez, vencer o aleatório. Então, quando nos sentamos para fazer benchmark de métodos de busca de parâmetros para o nosso próprio motor de trading, esperávamos a escada de sempre: aleatório embaixo, um sampler inteligente no topo.
Obtivemos o oposto — e depois obtivemos também a resposta de livro-texto. Mesma estratégia, mesmo espaço de parâmetros, mesmo objetivo, mesma máquina. A única coisa que mudamos foi quão caro era um único backtest, e o ranking dos métodos de busca se inverteu. Quando cada avaliação era barata, uma sequência de Sobol embaralhada e burra esmagou todo sampler "inteligente". Quando tornamos cada avaliação cara, os métodos inteligentes assumiram a liderança e encontraram a única configuração que sobreviveu fora da amostra (out-of-sample).
A lição não é "o aleatório é subestimado" nem "o bayesiano é superestimado". É que o cruzamento entre busca aleatória e busca inteligente é governado pelo custo de avaliação, não pela esperteza do algoritmo. Escolha seu otimizador pelo quanto custa um backtest, não pela sua reputação. Este artigo mede exatamente onde fica esse cruzamento, por que ele fica ali, e uma pré-condição — a fidelidade — que decide se os truques do regime caro (early stopping, pruning multi-fidelidade) são sequer seguros de usar.
Tudo abaixo vem de dois scripts do nosso backtester: bench_search.py (v4, commit ee092f1) para o regime barato de timeframe único, e bench_search_multitf.py (commit 102853c) para o regime caro multi-timeframe. Ambos são livres de vazamento (leak-free) — decisão no fechamento da barra i, execução (fill) na abertura open[i+1] — e ambos pontuam cada método em um objetivo walk-forward rolante multi-fold, com uma janela de teste reservada (held-out) que a busca nunca vê.
A pergunta: throughput ou eficiência por amostra?

Todo método de busca gasta seu orçamento de tempo de relógio (wall-clock) em duas coisas: decidir onde amostrar em seguida (o cômputo do próprio sampler) e avaliar a amostra (rodar o backtest). Vamos chamar a primeira de custo de ask/tell e a segunda de custo de avaliação. O poder de busca efetivo de um método, sobre um orçamento fixo de tempo de relógio, é, aproximadamente:
e sua qualidade final é essa contagem multiplicada por quão bem posicionado está cada ponto. Dois parâmetros, puxando um contra o outro:
- Throughput — pontos por segundo. Samplers burros (aleatório, Sobol/QMC embaralhado) têm custo de ask/tell próximo de zero: eles emitem um ponto de baixa discrepância e seguem em frente. Eles maximizam a contagem.
- Eficiência por amostra (sample-efficiency) — qualidade por ponto. Samplers inteligentes (TPE, CMA-ES, ASHA) gastam cômputo real modelando o objetivo para posicionar cada ponto melhor. Eles maximizam o posicionamento, ao custo do throughput.
Qual parâmetro vence depende inteiramente do denominador. Quando o custo de avaliação é minúsculo, o custo de ask/tell domina o denominador, então qualquer coisa que o infle — um modelo substituto (surrogate), uma estimativa de densidade por kernel, uma atualização de covariância — reduz diretamente o número de pontos que você explora. Quando o custo de avaliação é grande, o custo de ask/tell é um erro de arredondamento, então a esperteza é efetivamente grátis e você deve comprar o máximo dela que puder.
Essa é a tese inteira em uma frase: a taxa de ask/tell é fixa, mas sua importância é definida pelo custo de avaliação contra o qual ela é dividida. Agora vamos observar isso acontecer.
O regime barato: o Sobol burro vence no throughput

Nossa estratégia de timeframe único é uma regra de separação HMA/HMA3 livre de vazamento, sobre um espaço de 7 parâmetros, avaliada por um eval_batch numba in-process que roda prange sobre as configurações sem overhead entre processos. Nesse motor, um backtest é quase gratuito — o kernel bruto avalia configs a aproximadamente 3–4k cfg/s. Este é o regime barato, e é onde o trading difere drasticamente do cenário de deep learning de onde vem a maior parte do folclore de HPO: nossa "função objetivo" não é um treinamento de 6 horas em GPU, é uma passagem de array de 0.3 milissegundos.
Demos a cada método o mesmo orçamento — 1,500 avaliações — e registramos o tempo de relógio que cada um precisou para gastar essas avaliações, além do objetivo de teste held-out que encontrou. Como o orçamento de avaliações é fixo, a coluna de tempo de relógio é uma leitura direta do overhead de cada sampler:
| Método | Avaliações | Tempo de relógio | Throughput | TEST held-out |
|---|---|---|---|---|
| sobol (QMC) | 1,500 | 0.53 s | ~2,830 cfg/s | −259 |
| random | 1,500 | 0.85 s | ~1,770 cfg/s | −27 |
| sobol→cmaes | 1,500 | 1.38 s | ~1,085 cfg/s | −367 |
| cmaes | 1,500 | 1.76 s | ~850 cfg/s | −85 |
| tpe | 1,500 | 9.76 s | ~154 cfg/s | −161 |
| tpe-mv+sobol | 1,500 | 12.15 s | ~123 cfg/s | −151 |
| asha (folds) | 1,500 | 15.79 s | ~95 cfg/s | −165 |
TEST é o objetivo de walk-forward (PnL anualizado por tempo ativo × confiança pelo número de trades) em uma janela held-out que a busca nunca tocou; quanto maior, melhor.
Dois fatos saltam aos olhos. Primeiro, olhe para a coluna de throughput. O Sobol embaralhado roda a ~2,830 cfg/s — perto do teto do motor. O TPE roda a ~154 cfg/s e o ASHA a ~95. Isso é uma desaceleração de 18–30x para fazer o mesmo número de avaliações. Os samplers inteligentes não estão avaliando nada a mais; estão gastando esse tempo dentro de sua própria maquinaria de ask/tell.
Segundo — e essa é a parte que mantém a história honesta — nenhum método encontrou um resultado positivo fora da amostra. Todo valor de TEST é negativo. No regime de timeframe único, nossa estratégia simplesmente não tem uma vantagem (edge) OOS durável, então "qual método vence" não é uma pergunta sobre lucro final; é uma pergunta sobre eficiência de busca. E em eficiência de busca com um orçamento fixo de avaliações, os métodos burros vencem de forma categórica: Sobol e aleatório alcançam números held-out iguais ou melhores que os samplers inteligentes, gastando 1/20 do tempo de relógio.
Agora inverta a comparação do jeito que um praticante realmente vivencia — fixe o tempo de relógio, não a contagem de avaliações. Se você der a cada método os 15.8 segundos que o ASHA precisou para suas 1,500 avaliações, o Sobol não para em 1,500. Ele continua, chegando a aproximadamente 45,000 configurações. No regime barato, a pergunta nunca é "qual sampler posiciona melhor 1,500 pontos" — é "você prefere ter 1,500 pontos posicionados com esperteza ou 45,000 embaralhados, quando cada ponto é quase grátis?" Com uma avaliação quase gratuita, a amplitude (breadth) vence. Trinta vezes mais cobertura de um espaço de 7 dimensões supera um modelo melhor dele.
A taxa de ask/tell
Para onde vai esse 20x? Não vai para o backtest — que é idêntico entre os métodos. Vai para a contabilidade por ponto do sampler, executada em Python, dentro do loop:
- TPE ajusta um par de estimativas de densidade por kernel (trials bons vs. ruins) a cada
ask, e o custo cresce com o histórico de trials. O TPE multivariado os ajusta conjuntamente entre as dimensões — mais modelagem, mais Python. - CMA-ES atualiza e amostra de uma matriz de covariância a cada geração. Mais barato que o TPE aqui (rodou a ~850 cfg/s), mas ainda assim uma ordem de magnitude de overhead acima de simplesmente emitir um ponto de Sobol.
- ASHA paga a contabilidade de promoção/rung do pruner e, em nosso design de folds-como-fidelidade, paga o precômputo fixo do indicador antes de poder podar (prune) qualquer coisa — então suas avaliações "economizadas" economizam menos do que a contabilidade sugere.
Nada disso é uma crítica aos algoritmos. É o ponto central: o custo de ask/tell é um número aproximadamente fixo de milissegundos por ponto, e quando a avaliação que ele envolve também é de alguns milissegundos, esse custo fixo se torna subitamente 90% do seu orçamento. O sampler inteligente gasta nove décimos do seu tempo de relógio pensando onde olhar e um décimo efetivamente olhando. Uma sequência de Sobol embaralhada gasta tudo olhando. Quando olhar é barato, olhar vence.
Deliberadamente não fizemos benchmark de um otimizador bayesiano completo baseado em processo gaussiano (Gaussian-process) aqui, e pelo mesmo motivo: um substituto (surrogate) GP é na contagem de trials. Contra uma avaliação que custa milissegundos, ajustar o substituto consumiria todo o orçamento de busca antes de avaliar uma fração significativa do espaço. No regime barato, o GP-BO é desqualificado pela aritmética.
O regime caro: o cruzamento se inverte

Agora tornamos um backtest caro. A estratégia multi-timeframe empilha um timeframe alto, um médio e um baixo (triplo-TF), cada um contribuindo com uma passagem de indicador e seus próprios limiares (thresholds), tudo pontuado no mesmo walk-forward multi-fold. Uma única avaliação agora custa da ordem de 0.1–0.5 segundos em vez de 0.3 milissegundos — um salto de três ordens de magnitude. O custo de avaliação se moveu do termo de erro de arredondamento do nosso denominador para o termo dominante. Pela tese, a taxa de ask/tell deveria deixar de importar e a esperteza deveria começar a compensar. E é o que acontece.
Rodamos cada método sob um orçamento fixo de ~150 segundos de tempo de relógio no problema triplo-TF (um espaço de 18 parâmetros), deixamos cada um gastar esse orçamento da forma que seu sampler ditasse, e avaliamos a única melhor config que cada um retornou em uma janela de teste held-out:
| Método (triplo-TF, 150 s) | Avaliações | TEST held-out | Veredito |
|---|---|---|---|
| sobol (QMC) | 349 | −673 | perde |
| cascade (sobol²×64) | 20,864 | −585 | perde |
| asha (folds) | 292 eff. | −239 | perde |
| tpe-mv+sobol | 455 | −43 | perde |
| sobol→cmaes | 15,239 | +226 | único positivo em OOS |
TEST é o mesmo objetivo de walk-forward de antes. Apenas um método cruzou o zero.
A baseline burra de Sobol, que dominou o regime barato, agora está em último lugar isolado, em −673. A amostragem cega de baixa discrepância de um espaço de 18 dimensões, com apenas 349 avaliações para gastar porque cada uma é cara, nunca localiza nada. O método inteligente, sobol→cmaes — 30% do orçamento em Sobol para semear uma bacia (basin), depois refinamento por CMA-ES a partir da melhor semente — é o único método que produziu algum resultado positivo fora da amostra. No holdout final, nunca tocado, o campeão retornou +2.62% (19 trades, ~6.6% de exposição de capital) em cima de uma janela de teste que retornou +16.35% (46 trades, ~15.7% de exposição). O campeão de todo concorrente perdeu dinheiro fora da amostra.
Esse é o cruzamento, medido na mesma família de estratégia, o mesmo objetivo, a mesma máquina: mude apenas o custo de uma avaliação, e o ranking dos métodos de busca se inverte. No regime barato, o Sobol vence e os samplers inteligentes são um desperdício de 20x; no regime caro, o sampler inteligente é a única coisa que funciona e o Sobol é o desperdício.
Por que o "inteligente" vence aqui — e não é só eficiência por amostra

A versão simplificada dessa história é "avaliações caras recompensam a eficiência por amostra, então o método que posiciona menos pontos, porém melhores, vence." Isso é meia verdade, e os dados forçam a outra metade, honesta e mais interessante.
Olhe de novo para as contagens de avaliações. O sobol→cmaes não venceu avaliando menos pontos que o Sobol cego — ele avaliou 15,239 contra os 349 do Sobol, quarenta vezes mais, nos mesmos 150 segundos. Como? Porque nosso custo de avaliação multi-TF é estruturado, não uniforme. Há dois eixos: um eixo de indicador caro (os períodos de timeframe e os comprimentos de HMA, 30–500 ms cada para computar, porque forçam um recômputo do indicador) e um eixo de limiar barato (os níveis de separação de entrada/saída, ~1–2 ms cada sobre sinais em cache). O intervalo entre eles é de 30–100x.
O Sobol cego ignora essa estrutura. Cada ponto que ele sorteia perturba o eixo caro do indicador, forçando um recômputo do zero — então ele paga o preço cheio em todas as 349 avaliações. O sobol→cmaes, uma vez que o CMA-ES localizou uma região promissora, tende a manter a estrutura grosseira do indicador aproximadamente fixa e perturbar os limiares contínuos, que caem sobre sinais em cache e custam quase nada. O método inteligente converte o mesmo tempo de relógio tanto em pontos melhor posicionados quanto em muito mais deles, porque ser adaptativo aqui significa ser ciente de custo: permanecer no eixo barato depois que o eixo caro está fixado. Nossa exploração explícita cascade(sobol²×64) faz isso da forma mais agressiva — 20,864 avaliações agrupando limiares baratos sobre sinais em cache — e, embora tenha perdido no teste triplo-TF, na variante de dois timeframes ela venceu a janela de teste de forma categórica em +20.2% (antes de falhar no seu próprio holdout — mais sobre isso adiante).
Então, a afirmação mais afiada sobre o cruzamento: no regime caro, a taxa de ask/tell se torna desprezível, o que libera você para ser inteligente — e "inteligente" significa se adaptar à estrutura de custo do objetivo, não apenas à sua forma. A amostragem cega não consegue nenhuma das duas coisas. Essa é precisamente a estrutura de dois eixos que nosso motor de drill-down de resolução adaptativa foi construído para explorar, e é por isso que os métodos multi-fidelidade pertencem ao regime caro — desde que uma condição se mantenha.
Fidelidade: a pré-condição oculta para o pruning
Métodos multi-fidelidade — Hyperband, ASHA, qualquer pruner de early-stopping — repousam sobre uma suposição: que uma avaliação barata e parcial ordena (rank) as configurações da mesma forma que a avaliação cara e completa ordenaria. Se uma config que parece boa em um fold de walk-forward tende a parecer boa em todos eles, você pode matar as perdedoras cedo e gastar o orçamento das sobreviventes nas vencedoras. Se a fidelidade barata ordena aleatoriamente, o early stopping é apenas descartar boas configs no cara-ou-coroa.
Então, antes de confiar em qualquer pruner, medimos a suposição diretamente. Nossa fidelidade é o número de folds de walk-forward (avaliar em r folds de forma barata, ou todos os K folds a custo total), e o gate de fidelidade computa a correlação de rank de Spearman ρ entre o objetivo barato de r folds e o objetivo completo, em uma amostra de configs aleatórias. ρ@1 é a correlação quando você julga em um único fold — a fidelidade mais agressiva e mais barata. Eis o que esse gate reportou nos dois regimes:
| Fidelidade (folds usados) | ρ Single-TF | ρ Multi-TF |
|---|---|---|
| ρ@1 (1 fold) | ~0.03 | 0.43 |
| ρ@2 | — | 0.67 |
| ρ@3 | — | 0.78 |
| ρ@4 | — | 0.82 |
| ρ@5 | — | 0.91 |
No regime de timeframe único, um fold ordena as configs com uma correlação de ~0.03 com a verdade — estatisticamente indistinguível de aleatório. Isso não é coincidência; é o mesmo fato que "nenhum método encontrou uma vantagem (edge) OOS." Quando uma estratégia não tem sinal durável, seu desempenho por fold é principalmente sorte, então qualquer fold isolado é um sorteio quase aleatório, e o pruning de baixa fidelidade mataria boas configs e promoveria as sortudas. O multi-fidelidade é inseguro no regime barato aqui — não porque o método seja ruim, mas porque o sinal barato é ruído. (Nosso gate sinaliza isso e se recusa a podar de forma agressiva.)
No regime multi-timeframe, existe uma vantagem (edge) real, e o quadro de fidelidade se transforma: ρ@1 sobe para 0.43, e com cinco folds ρ chega a 0.91. Agora um fold carrega informação real de ordenação, e cinco folds carregam quase toda ela. O early stopping se torna seguro — uma config que perde nos primeiros folds é genuinamente provável de ser uma perdedora. Essa é a segunda razão pela qual os métodos multi-fidelidade pertencem ao regime caro: não apenas que avaliações caras tornam o pruning válido, mas que o regime caro é onde a fidelidade barata finalmente ordena como a completa.
A regra que isso lhe dá é direta e barata de executar: meça ρ antes de podar. A correlação de fidelidade é uma computação de duas linhas sobre algumas centenas de configs aleatórias, e é a diferença entre a busca multi-fidelidade acelerar você e a busca multi-fidelidade sabotar você silenciosamente.
Vencer a busca não é sobreviver a ela
Mais uma nota de honestidade, porque esta série é sobre backtests que mentem. Nosso campeão triplo-TF, sobol→cmaes, foi o único método a registrar um holdout positivo — +2.62%, sobre +16.35% na janela de teste. Essa é a boa notícia. Eis a ressalva: ele não sobreviveu à deflação estatística.
O campeão é o melhor entre dezenas de milhares de configurações tentadas por todos os métodos. Sob tanto teste múltiplo, um holdout de +2.62% não é automaticamente real. Rodamos os gates de overfitting nos quais toda a série se apoia — o Índice de Sharpe Deflacionado (Deflated Sharpe Ratio) com N efetivo corrigido pela correlação entre trials, e o PBO via validação cruzada combinatoriamente simétrica (CSCV). O campeão passou no PBO (0.12, confortavelmente abaixo do limiar de 0.2 — seu rank é estável entre os splits de CSCV), mas seu Sharpe deflacionado colapsou para zero (o gate exige ≥ 0.95). Veredito: não sobrevive.
Leia isso com cuidado, porque é o ponto central de todo o exercício. O resultado do cruzamento é real: a busca inteligente venceu a busca no regime caro, decisivamente, e o Sobol a perdeu. Mas vencer a busca é uma afirmação sobre o otimizador, não sobre a estratégia. A melhor config que um bom otimizador consegue encontrar em um espaço sem vantagem (edge) continua sem vantagem — a deflação é o que lhe diz qual delas você está segurando. Escolher o método de busca certo lhe dá a melhor resposta disponível de forma eficiente; isso não fabrica uma vantagem que nunca existiu. O otimizador e os gates de overfitting são instrumentos diferentes medindo coisas diferentes, e você precisa de ambos.
Uma regra de decisão que você pode realmente aplicar
Você não precisa re-executar nosso benchmark para escolher um otimizador. Você precisa de um número: quanto tempo leva um backtest? Cronometre uma única avaliação do seu objetivo — uma passagem completa de walk-forward, todos os folds — e leia o regime a partir disso.
- Avaliação barata (≲ ~10 ms/backtest): compre throughput. Use Sobol/QMC embaralhado ou aleatório. A taxa de ask/tell do TPE/CMA-ES/ASHA vai lhe custar 10–30x na contagem de pontos, por um posicionamento que uma avaliação quase gratuita não recompensa. Não se preocupe com pruning multi-fidelidade — e, se estiver tentado, verifique ρ@1 primeiro; em um regime barato de baixa vantagem, ele provavelmente está perto de zero, o que significa que o pruning é cara-ou-coroa. Gaste o tempo de engenharia economizado ampliando a busca, não a estreitando.
- Avaliação cara (≳ ~100 ms–segundos/backtest): compre eficiência por amostra. Use CMA-ES, TPE, ou um híbrido CMA-ES semeado por Sobol; o overhead do sampler agora é um erro de arredondamento frente à avaliação. Se o seu custo de avaliação é estruturado (um eixo de indicador lento e um eixo de limiar rápido, como no multi-TF), prefira métodos que explorem essa estrutura — cascatas, drill-downs, qualquer coisa ciente de custo — em vez de métodos que tratam toda dimensão como igualmente cara.
- No meio-termo, ou em caso de dúvida: um híbrido semeado por Sobol (
sobol→cmaes) é o padrão robusto. Ele se comporta como um Sobol de amplitude primeiro (breadth-first) no início (barato, sem modelo para ajustar) e como um refinador inteligente mais tarde, então se degrada com elegância em qualquer regime em que você acabe estando — que é exatamente por que ele foi nosso campeão do regime caro. - Antes de qualquer pruner, meça a fidelidade. Compute o ρ de Spearman entre a fidelidade barata e o objetivo completo em algumas centenas de configs aleatórias. Se ρ@1 for baixo, não faça pruning em um único fold; aumente o recurso mínimo até que ρ ultrapasse ~0.5. Isso custa duas linhas de código e evita que seu acelerador descarte silenciosamente suas melhores configs.
- Seja qual for o vencedor da busca, rode os gates de deflação. O vencedor do otimizador é o objeto mais propenso a overfitting que você vai produzir na semana inteira. O DSR e o PBO, não a pontuação do otimizador, decidem se ele é operável (tradable).
Onde isso se conecta
Esse resultado fica no centro de alguns fios que esta série vem puxando:
- Isso pressupõe que o motor por baixo é honesto. Toda a vantagem do regime barato existe porque nosso motor numba in-process atinge milhares de configs por segundo sem IPC — a escada de velocidade é o que lhe coloca no regime em que o throughput vence, para começo de conversa. Um motor lento, taxado por framework, colocaria todo problema no regime caro por padrão, e você nunca veria o cruzamento.
- A exploração do regime caro é a estrutura de custo de dois eixos em torno da qual nosso motor de drill-down de resolução adaptativa foi projetado: localizar no eixo grosseiro e caro, depois explorar o fino e barato.
- Todo método aqui só é confiável porque o motor é livre de vazamento. Uma busca sobre dezenas de milhares de trials é a máquina mais eficiente possível para encontrar e explorar um bug de look-ahead — o "vencedor" seria qualquer config que se apoiasse mais fortemente no vazamento. Conserte o relógio primeiro, depois busque.
- E o destino do campeão — vencer a busca, falhar na deflação — é todo o argumento para tratar a busca de parâmetros e o controle de overfitting como estágios separados, com instrumentos separados.
O pano de fundo acadêmico é o mesmo ao qual o campo continua retornando: Bergstra & Bengio (2012) sobre por que o aleatório vence o grid; o Hyperband de Li et al. (2018) e o desdobramento ASHA (2020) sobre multi-fidelidade; e Bailey & López de Prado (2014) sobre por que o vencedor de qualquer busca grande deve ser deflacionado antes de ser acreditado. Nenhum deles prescreve um único otimizador melhor, porque não existe um — existe um regime, e um custo que o seleciona.
Conclusões
- O cruzamento entre busca aleatória e busca inteligente é definido pelo custo de avaliação, não pelo algoritmo. Invertemos o ranking de todo método mudando apenas o quão caro era um backtest.
- Avaliação barata → o Sobol burro vence no throughput. No nosso motor single-TF (~3–4k cfg/s), o TPE e o ASHA rodaram 18–30x mais lentos para a mesma contagem de avaliações — ~95–154 cfg/s contra ~2,830 do Sobol. Com tempo de relógio igual, a amplitude (breadth) vence um modelo melhor do espaço quando cada ponto é quase gratuito.
- Avaliação cara → os métodos inteligentes vencem em eficiência. No problema triplo-TF,
sobol→cmaesfoi o único método a encontrar um resultado positivo fora da amostra (+16.35% teste, +2.62% holdout); o Sobol cego terminou em último lugar isolado. - No regime caro, "inteligente" significa ciente de custo. O vencedor explorou o intervalo de 30–100x entre o eixo caro do indicador e o eixo barato do limiar — ele fez mais avaliações e as posicionou melhor, permanecendo no eixo barato uma vez que o caro estava fixado.
- A fidelidade é a pré-condição para o pruning. A correlação de rank de um único fold subiu de ρ@1 ≈ 0.03 (single-TF, essencialmente aleatório) para 0.43 (multi-TF), atingindo 0.91 com cinco folds. O multi-fidelidade/ASHA só compensa quando a fidelidade barata ordena como a completa — então meça ρ antes de podar.
- Vencer a busca não é sobreviver a ela. O campeão passou no PBO, mas falhou no gate de Sharpe Deflacionado. Escolha o otimizador pelo custo de avaliação; decida a operabilidade com os gates de deflação. São instrumentos diferentes, e você precisa de ambos.
Escolha seu otimizador pelo que um backtest custa. Depois lembre-se de que a melhor resposta que um otimizador pode encontrar em um espaço sem vantagem (edge) continua sem vantagem — e deixe que os gates, não a busca, lhe digam qual delas você está segurando.
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.