Eugen Soloviov
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.
Articoli
Il negativo onesto: decine di migliaia di backtest, cinque major, nessun edge robusto
Il culmine dell'arco narrativo su ricerca e overfitting, e si conclude con un risultato negativo — quello corretto. Una ricerca single-symbol dual-timeframe su ETHUSDT ha trovato una configurazione che valeva +16,35% out-of-sample e +2,62% su un holdout mai toccato; il Deflated Sharpe Ratio, tenendo conto di ~37.000 prove, l'ha sgonfiata a 0,00. Un passaggio cross-instrument su cinque major (ETH/BTC/SOL/BNB/XRP, ~1,18M di barre da 1m ciascuno), selezionando per mediana out-of-sample, la elimina definitivamente: dual DSR 0,24 / PBO 0,264, triple DSR 0,14 / PBO 0,327 — entrambi falliscono i gate. Il campione e profittevole su 1 di 5 simboli e negativo sugli altri. E' proprio a questo che serve l'apparato anti-overfit: a impedirti di spacciare il migliore del rumore per alpha.
Dimostrare l'assenza di look-ahead nei backtest multi-timeframe: perturbare il futuro per dimostrare che il passato non può vederlo
I backtest multi-timeframe fanno trapelare il futuro attraverso una barra di timeframe superiore ancora in formazione, la cui chiusura finale non esiste ancora. Non si può raggiungere la certezza con una semplice code review — bisogna testarlo. Riproduciamo esattamente la regola closed-bar del bot live, poi dimostriamo l'assenza di leakage con una probe a futuro perturbato: perturbiamo ogni barra futura e verifichiamo che ogni segnale e trade passato resti bitwise invariato. 25/25 controlli di parità superati, e la probe ha i denti.
Quando la GPU Ripaga: Il Roofline dello Sweep di Parametri, Dove un 167x da Titolo è in Realtà 27x di Algoritmo per 6.2x di Hardware
Il vantaggio della GPU sulla CPU cresce con la dimensione del batch — da 54.5x a un combo per chiamata fino a 359.6x a 61 sul nostro precompute di indicatori multi-timeframe — perché uno sweep piccolo non può ammortizzare l'overhead di lancio dei kernel e di trasferimento. Scomponiamo un 167x da titolo in una vittoria algoritmica di 27x che aiuta anche la CPU e una vittoria hardware di 6.2x, mostriamo che il vero vantaggio GPU-vs-migliore-CPU è solo 3.2x single-timeframe e 6.2x multi, e diamo una guida decisionale su quanto largo debba essere uno sweep prima che una GPU valga l'investimento.
La trappola della precisione GPU: come un backtest in fp32 su Apple Metal restituisce silenziosamente spazzatura
La GPU Metal di Apple non ha float64. Porta ingenuamente un backtest vettorizzato su di essa e la tentante WMA a somma prefissa manda in overflow l'fp32 — errore relativo massimo 211× — eppure gira comunque e restituisce numeri dall'aspetto plausibile. La soluzione non è più precisione; è una formulazione diversa: una convoluzione a finestra diretta, sicura in fp32 fino a 8×10⁻⁷ e 55,9× più veloce del numba a thread singolo. La trappola, l'aritmetica e come dimostrare di non esserci caduto.
Il Fidelity Gate: il Backtesting dal Grossolano al Fine Ti Inganna Più in Fretta a Meno che il Proxy Economico non Classifichi Come Quello Costoso
La ricerca drill-down / multi-fedeltà (ASHA, successive halving, Hyperband) filtra economicamente migliaia di configurazioni e promuove solo i sopravvissuti alla costosa valutazione completa. È un'accelerazione autentica — ma collassa silenziosamente se il ranking a bassa fedeltà non concorda con quello ad alta fedeltà. Abbiamo misurato la correlazione di rank tra fold: con un solo fold lo Spearman ρ può essere 0.03 (classifica quasi a caso), salendo a 0.43, 0.67, 0.78, 0.91 man mano che i fold si accumulano. La soluzione è un gate obbligatorio — misurare prima ρ(economico, completo) e alzare automaticamente la fedeltà minima al primo livello in cui ρ ≥ 0.5.
Ricerca casuale vs ricerca intelligente: il punto di incrocio è il costo di valutazione, non l'algoritmo
Quando un singolo backtest è economico, una sequenza Sobol scombinata e stupida vince in termini di puro throughput — i sampler "intelligenti" (TPE, CMA-ES, ASHA) pagano una tassa ask/tell in Python che li rallenta di 20 volte, facendo sì che valutino molti meno punti a parità di tempo reale trascorso, e perdono. Rendi ogni valutazione costosa (multi-TF + fold walk-forward) e il punto di incrocio si ribalta. Abbiamo misurato entrambi i regimi, e perché la fedeltà del rango tra fold (ρ@1 che sale da 0.03 a 0.43) è la precondizione perché il pruning ripaghi.
Lo spazio dei parametri a due assi: perché gran parte del tuo sweep dovrebbe essere quasi gratis
Non tutti i parametri costano allo stesso modo in fase di ricerca. I parametri di una strategia si dividono in un asse costoso (gli indicatori — ricalcolati sull'intera serie) e un asse economico (le soglie decisionali — una passata O(n) su segnali precalcolati). Poiché gli indicatori sono invarianti rispetto alle soglie, li calcoli una volta sola e scandagli migliaia di configurazioni di soglie a ~5,600 cfg/s — circa 1,600x più economico che ricalcolare a ogni configurazione. Una riprezzatura della maledizione della dimensionalità.
La tassa del framework: quando la tua libreria di backtest è più lenta di un ingenuo ciclo pandas
Abbiamo messo a confronto otto motori di backtest su un'unica identica ricerca di parametri — 150k barre, 80 combinazioni di incrocio HMA, parità del conteggio operazioni bloccata a 2707. Due dei framework event-driven più popolari sono risultati più lenti di un ciclo pandas scritto a mano, mentre un motore vettorizzato/compilato ha eseguito lo stesso lavoro ~13,000× più velocemente. Uno studio sull'overhead per barra che le librerie popolari non sono mai state costruite per ammortizzare.
La Probability of Backtest Overfitting: La Tua Ricerca Ha Battuto un Lancio di Moneta?
Il Deflated Sharpe Ratio prezza la strategia vincente; il PBO prezza la ricerca che l'ha scelta. La Combinatorially Symmetric Cross-Validation esegue C(16,8) = 12,870 split train/test su una matrice di performance 1000x200 e chiede: il vincitore in-sample finisce nella metà inferiore out-of-sample? La trappola che quasi tutti si perdono — il nullo del PBO è 0.5, non 1. Su 200 strategie a vantaggio zero, il miglior Sharpe annualizzato in-sample di 1.98 collassa a 0.06 out-of-sample e PBO = 0.476: un lancio di moneta, completamente overfit. Pianta un vantaggio reale (Sharpe annualizzato 2.38) e il PBO scende a 0.001, con l'in-sample 3.73 che sopravvive a un out-of-sample 2.34. Anche una griglia di medie mobili su un puro random walk non ha alcuna abilità out-of-sample — PBO 0.463 mediato su 60 matrici, statisticamente indistinguibile dal nullo — e su una matrice rappresentativa il miraggio è vivido: un miglior Sharpe in-sample di 2.33 collassa a un out-of-sample mediano di -0.22, PBO 0.573, un 63% di probabilità di perdita.
La Tassa IPC: Metti il Motore di Backtest Dietro un Socket e Perdi il 13% — Ma Quasi Nulla è Colpa del Socket
Abbiamo portato un kernel di backtest numba riga per riga in Rust e lo abbiamo chiamato attraverso un confine di processo in quattro modi diversi, con un gate di equivalenza che conferma un PnL identico fino all'ultimo trade. Spedire l'intera serie di prezzi da 1.2 MB attraverso un Unix socket costa ~2 ms — circa lo 0.1% del lavoro. Codificare lo stesso payload in JSON costa 1348 volte più dei byte raw, le chiamate chatty per-combo rispediscono i dati 80 volte, e un pattern di chiamata per-barra pagherebbe 2.1 s di puro IPC su un job da 2.0 s. Il confine è economico; la tassa sta in come lo attraversi.
Il Deflated Sharpe Ratio: Quanti dei 'Vincitori' del Tuo Backtest Sopravvivono ai Test Multipli?
Una ricerca di parametri è una macchina per fabbricare fortuna. Su puro rumore — 1,000 strategie con vantaggio reale pari a zero — lo Sharpe annuale migliore ha una media di 1.63 e il test di significatività ingenuo segnala una scoperta il 100% delle volte. Costruiamo una ground truth controllata e mostriamo che il Deflated Sharpe Ratio, l'haircut di Harvey-Liu e la Reality Check di White ripristinano l'onestà: le scoperte false scendono da 1.000 a 0.001-0.057, i vantaggi genuini sopra il tetto di rumore vengono mantenuti con potenza ~1 — e un'unica vera trappola (griglie correlate) in cui il DSR grezzo sovra-deflaziona e il verdetto va letto attraverso un'intera banda di stime dei trial effettivi, non una sola.
Il Design della Funzione Obiettivo: La Metrica che Ottimizzi Sceglie di Nascosto la Tua Strategia
Per cercare la strategia 'migliore' devi prima definire 'migliore' — e quello scalare sceglie di nascosto il vincitore. Su dati sintetici con un vantaggio noto (600 seed, T=2000, 80 soglie), uno Sharpe per-trade ingenuo incorona una lotteria: sceglie un vincitore con esposizione sotto il 5% nel 56% dei seed e degenera nel 57% — nel seed più estremo, 8 trade che ottengono uno Sharpe in-sample di 21.09 che collassa a 0.13 out of sample. La riparazione onesta è quasi banale: misurare sull'intera timeline, che non degenera mai (out-of-sample 1.71). Uno shrinkage sul conteggio dei trade (conf_k) e un floor di esposizione possono correggere retroattivamente una metrica per-trade, ma anche completamente riparati eguagliano soltanto lo Sharpe sull'intera timeline (1.70 contro 1.71) — senza mai batterlo. La legge di Goodhart, in un backtest, con una ground truth controllata.