Kusursuz biçimde tekrarlanabilen bir backtest, biraz değişkenlik gösteren bir backtest’ten daha az güvenilir olabilir. Tekrarlanabilirlik aynı yanıtı iki kez alabileceğinizi kanıtlar; yanıtın tek bir keyfî veri anlık görüntüsüne, bir kütüphane tuhaflığına ya da gizli bir varsayılan ayara bağlı olup olmadığı hakkında hiçbir şey söylemez.
Bu, tekrarlanabilirliğe karşı bir argüman gibi gelebilir; ama değil. Çalıştırmayı, açıklayabilmek için sabitleyin. Ardından sonucu belirlememesi gereken varsayımları bilerek değiştirin. İlk adım sonucu denetlenebilir kılar; ikinci adım ise sonucun bir anlamı olup olmadığını gösterir.
Tekrarlanabilir bir backtest gerçekte neyi ortaya koyar?
Aynı kod, veri, yapılandırma ve rastgelelik tohumu aynı işlemleri ve metrikleri üretiyorsa, önemli bir kafa karışıklığı kaynağını kontrol altına almışsınız demektir. Bir agent’ın “iyileştirmesi” ana çalıştırmasıyla karşılaştırılabilir. Bir hata düzeltmesi, değişen ücret tarifesinden ayrıştırılabilir. Bir çalışma arkadaşınız aynı işlem defterini inceleyip aynı gerçekleşmeleri bulabilir.
Ancak sonuç, sabitlediğiniz her şeye bağlıdır. Geçmiş dosyasında 1-minute mumlar bulunan bir kripto stratejisini düşünün. Dosyanın hash’ini kaydediyor, kodu sabitliyor ve her yeniden çalıştırmada 1,4 Sharpe elde ediyorsunuz. Sağlayıcı daha sonra birkaç mumu düzeltirse, bu temiz tekrarlanabilirlik hâlâ eski dosyayı tanımlar. Sinyalin düzeltilmiş geçmiş veride ayakta kalıp kalmayacağını veya bu mumların o tarihte aynı biçimde mevcut olup olmadığını göstermez.
Hash yararlıdır: bağımlılığı görünür kılar. Bu bağımlılığın zararsız olduğuna kanıt değildir.
Çalıştırmayı sabitleyin; bulguyu sınayın
İki soruyu birbirinden ayırmayı seviyorum. Bu çalıştırmanın aynısını yeniden oluşturabilir miyiz? Araştırmanın vardığı sonuç makul değişikliklere dayanıyor mu? İlk soru değiştirilemez bir kayıt gerektirir; ikincisi ise her seferinde tek bir değişkeni kontrollü biçimde değiştirmeyi.
| Kaydedilecekler | Sonradan değiştirilecekler | Ortaya çıkarabilecekleri |
|---|---|---|
| Ham veri sürümü ve sağlama toplamları | Sağlayıcı revizyonu veya ikinci bir kaynak | Düzeltilmiş ya da sağlayıcıya özgü değerlere bağımlılık |
| Kod commit’i ve paket sürümleri | Sayısal açıdan eşdeğer bir uygulama | Sıra, yuvarlama veya kütüphane hassasiyeti |
| Ücretler, fonlama ve gerçekleşme varsayımları | Savunulabilir bir maliyet aralığı | Düşük bir avantajın olağan dışı ölçüde elverişli gerçekleşmelere ihtiyaç duyup duymadığı |
| Varlık evreni ve belirli tarihteki üyelik | Uygun piyasalar için alternatif kurallar | Dahil etme veya hariç tutma kararlarına bağımlılık |
Örneğin, bir vadeli işlem stratejisinin temel yeniden oynatımda yıllıklandırılmış %8 fazla getiri gösterdiğini varsayalım. taker maliyetlerini %25 artırarak, fonlamayı bir sonraki gözlemlenen uzlaşmaya kaydırarak ve en büyük iki katkı sağlayanı sırayla çıkararak stratejiyi yeniden çalıştırın. Bunlar modeli iyileştirmenin üç yolu değildir. Bunlar sınamalardır: her biri, makul bir ayrıntının manşet sonucu taşıyıp taşımadığını sorgular.
Her sınamayı ayrı tutun. Veriyi, ücret tarifesini ve uygulama zamanlamasını birlikte değiştirirseniz, kötüleşen sonuç size pek az şey anlatır. Bir sınama makul değilse, olası sonuç gibi sunmak yerine stres senaryosu olarak etiketleyin.
Bayt bayt aynılığı sayısal doğrulukla karıştırmayın
Bazı hesaplamalar işlem sırasına duyarlıdır. Kayan noktalı toplama birleşmeli olmadığından, çok sayıda küçük K&Z değerini farklı sırada toplamak son birkaç basamağı değiştirebilir. Paralel indirgemeler, donanım ve kütüphane sürümleri çıktının birebir aynılığını etkileyebilir. Çoğu zaman bu zararsızdır; bazen de küçücük bir sayısal değişiklik bir eşiği aşar, pozisyonu değiştirir ve simülasyonun geri kalanını farklı bir yola sokar.
Bu yüzden hem tam artefaktları hem de karşılaştırmalarda kullanılacak toleransları saklarım. Yalnızca nihai Sharpe’ı değil, işlem defterini de kaydedin. Önce kararları ve nakit akışlarını, sonra da belirtilmiş bir tolerans dahilindeki metrikleri karşılaştırın. Bir sentlik fark emir gönderilip gönderilmeyeceğini değiştiriyorsa o sınırı özellikle inceleyin.
Yararlı bir çalıştırma kaydı; veri ve kod kimliğini, yapılandırmayı, rastgelelik tohumunu, yürütme ortamını ve bir metriği gerçekleşmelere ve nakit akışlarına kadar izlemeye yetecek ara çıktıları içerir. Tek başına nihai puan, tekrarlanabilir bir araştırma artefaktı değildir.
Değişkenlik ne zaman gürültüdür, ne zaman bulgudur?
Değişen her sayı bir kriz değildir. Farklı bir indirgeme sırasından kaynaklanan çok küçük metrik kayması işlemleri değiştirmeyebilir. Bir eşiğe yakın işlemin değişmesi incelemeye değer olabilir. Bir sağlayıcı geçmiş verinin küçük bir bölümünü güncellediğinde sonucunun çoğunu kaybeden bir strateji, ilk çalıştırma kusursuz biçimde tekrarlanabilir kalsa bile, kendi kırılganlığı hakkında bir şey öğrenmiştir.
Dayanıklılık kontrollerini eleştirenler bir konuda haklı: tercih edilen bir strateji dayanıklı görünene kadar varsayımları değiştirmek veya bilerek aşırı uç bir senaryo onu bozdu diye sağlam bir sonucu reddetmek kolaydır. Makul değişiklikleri önceden belirleyin, tümünü raporlayın ve olağan alternatifleri stres senaryolarından ayırın. Ardından temel sonucu, başka bir araştırmacının gördüğünüzü aynen yeniden üretebilmesi için saklayın.
Tekrarlanabilirlik size güvenilir bir başlangıç noktası sağlar. Asıl soru sonra gelir: Bu çalıştırmanın çevresindeki dünya makul biçimde bekleyebileceğiniz şekilde değiştiğinde, yanıtın hangi kısımları sabit kalır?
← Tüm yazılar
