Backtestin ortasında stratejini yeniden başlat. Sahip olduklarını hatırlıyor mu?

İyi bir backtest testi, daha iyi bir parametre bulmakla ilgili değildir: süreci yarıda durdurun, durumunu geri yükleyin ve aynı tekrar oynatmayı tamamlayın. Girdiler aynı ve yürütme simülatörü denetim altındaysa kararlar, emirler ve öz sermaye kesintisiz çalıştırmadakiyle eşleşmelidir.

Eşleşmiyorlarsa bir durum yönetimi sorunu buldunuz demektir. Strateji, kaydetmediğiniz veya yeniden oluşturamadığınız bir şeye bağlıdır. Bu bağımlılık, araştırma çalışmaları kaldığı yerden sürdürüldüğünde, çalışanlar değiştirildiğinde ya da paper trading hizmetine yeni kod dağıtıldığında önem kazanır.

Bu testi seviyorum; çünkü beklenen yanıt olağanüstü derecede net. Piyasanın değişip değişmediği tartışma konusu değil. Her iki çalıştırma da aynı piyasayı alır.

İşte yeniden başlatmanın 3 hatalı yolu. Sayılar açıklama amaçlıdır; bu hataların her biri, başka açılardan deterministik bir sistemde de görülebilir.

1. Birkaç bar yükleyip göstergelerin ısındığını varsayın

Diyelim ki bir strateji 100 dönemlik üstel hareketli ortalama kullanıyor. Güncellemesi şöyledir:

alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previous

Kesintisiz çalışan süreç, birikmiş EMA değerini taşımaya devam eder. Yeniden başlatılan süreç 100 bar çeker, EMA'yı ilk kapanış fiyatıyla başlatır ve 100 dönemlik bir göstergenin 100 gözleme ihtiyacı olduğunu varsayar.

Bu varsayım, göstergenin yumuşatma parametresini sınırlı bir bellek penceresiyle karıştırır. EMA, başlangıç durumunun giderek azalan katkısını korur. İki sürümün EMA değerleri başlangıçta 10 fiyat birimi farklıysa, sonraki fiyatlar aynı olduğunda bu fark şöyle küçülür:

Hesaplama 10 * (99 / 101)^k. 100 bar çekerseniz, ilk gözlem başlangıç değerini sağladığı için yalnızca 99 güncelleme elde edersiniz.

Sorun genellikle bir karar eşiğinin yakınında ortaya çıkar. Bir çalıştırmada fiyat EMA'nın üzerindeyken diğerinde altında kalır. Küçük bir sayısal fark, fazladan bir işlemin tamamını doğurur. Bu olduğunda soğuma süreleri, kullanılabilir nakit ve sonraki kararlar da birbirinden sapabilir.

Özyinelemeli gösterge durumunu, başlatma durumunu ve en son işlenen olayı kaydedin. Alternatif olarak, bilinen bir başlangıç durumundan yeniden oynatın. Daha uzun bir ısınma süresi kabul edilebilir bir yaklaşık değer sağlayabilir; ancak süresini açık bir hata toleransına göre belirleyin ve bu toleransın kararları değiştirip değiştiremeyeceğini kontrol edin. “Dönemin 5 katı” bir teamüldür, kanıt değil.

Üstelik geçmişin tamamı göstergelerden ibaret değildir. Kayan yüzdelik dilim için pencere gerekir. Çevrimiçi bir modelin eniyileyici durumuna ihtiyacı olabilir. Kayıptan sonra 3 bar bekleyen bir kuralın, kaybı ve sayacı hatırlaması gerekir.

2. Pozisyonları kaydedip hâlâ işlemdeki emirleri unutun

Hedef pozisyonunuz 10 birim. 10 birimlik alış emrinin 4 birimi gerçekleşti; 6 birim hâlâ bekliyor. Kontrol noktasında pozisyonu 4 olarak kaydediyor, yeniden başlatıyor ve eksik 6 birim için yeni bir alış emri gönderiyorsunuz.

Hem ilk emrin kalan kısmı hem de yeni emir gerçekleşirse 16 birime sahip olursunuz.

Backtest'te bu hata çoğu zaman fark edilmeden kalır; çünkü fill motorunu yeniden başlatmak çalışan emirleri sessizce siler. Paper trading'de simülatör veya harici hizmet bu emirleri koruyabilir. Aynı kurtarma kodu, hangi bileşenin ayakta kaldığına bağlı olarak farklı bir pozisyon riski doğurur.

Sorun, kurtarma işleminin hemen ardından açıklanamayan bir emir patlaması olarak kendini gösterir. Bazen pozisyon riskini ikiye katlar. Bazen hâlâ beklemede olan koruyucu emre rağmen pozisyonu kapatır; böylece o emir daha sonra yeni bir pozisyon açabilir.

Bir kontrol noktası, pozisyonların yanı sıra emir kimliğini ve yaşam döngüsü durumunu da içermelidir. Kurtarma, yeni işlemler oluşturmadan önce bu kayıtları yürütme sistemiyle eşleştirmelidir. Sonucu bilinmeyen bir emir araştırılmalıdır; “kaydedilmiş bir onay yok” durumunu “hiç gönderilmedi” diye kabul etmek, yinelenen emirlerin doğmasına yol açar.

Kalıcı istemci emir kimlikleri, ne olduğunu bulmanıza yardımcı olur. Yinelenen emirleri ancak alıcı sistem gerekli benzersizlik veya idempotency kurallarını gerçekten uyguluyorsa önlerler. İşlenmiş fill kimliklerini de kalıcı olarak saklayın; böylece yeniden oynatılan bir fill pozisyonu ikinci kez artırmaz.

Sıkıcı emir durumu ekranına karşı özel bir zaafım var. Yeniden başlatma günü geldiğinde, o küçük satırlar birden binadaki en ilgi çekici arayüze dönüşüyor.

3. Pozisyonu geri yükleyip yeni bir K&Z defteri başlatın

Ücret içermeyen, kaldıraçsız bir spot örneği düşünün. $10,000 nakitle başlayın, $100 fiyatından 10 birim alın ve işaret fiyatı $110 olduğunda kontrol noktası oluşturun.

Doğru durum, $9,000 nakit ve değeri $1,100 olan bir pozisyondan oluşur: öz sermaye $10,100'dür. Kurtarma 10 birimi geri yükler ama nakdi ilk $10,000 seviyesine sıfırlarsa $11,100 raporlar. Süreci yeniden başlatarak $1,000 yaratmış olursunuz.

Diğer örnekler bu kadar çarpıcı değildir. Kurtarma öz sermayeyi korur ama giriş fiyatını $110 olarak sıfırlar. Toplam öz sermaye doğru kalırken gerçekleşmiş ve gerçekleşmemiş K&Z dağılımı değişebilir. Zarar durdurma veya çıkış koşulu giriş fiyatına bağlıysa, bu muhasebe kestirmesi artık işlem davranışını değiştirir.

Ya da sistem önceki öz sermaye zirvesini unutur. Diyelim ki öz sermaye $10,100'e düşmeden önce $10,600 ile zirve yaptı. Düşüş yaklaşık 4.72%'dir. Kurtarma sırasında zirve değerini sıfırlayın; strateji birden düşüşün sıfır olduğuna inanır. Düşüşe dayalı her risk kontrolü yetkisiz bir sıfırlama almış olur.

Dolayısıyla sorun öz sermayedeki ani bir kopuş, kuşku uyandıracak kadar iyileşmiş bir düşüş oranı veya dağıtımlardan sonra devreye girmeyi bırakan bir risk kuralı olabilir. Defteri ve stratejinin muhasebeye bağlı durumunu koruyun: nakit hareketleri, pozisyonlar, geçerli maliyet esası, tahakkuk etmiş masraflar ve risk kontrolü belleği. Geri yüklenen öz sermayeyi aynı değerleme zaman damgasındaki defterle mutabık hâle getirin.

Araştırma test düzeneğinde tutacağım test, önce kesintisiz bir referans tekrar oynatması çalıştırır, sonra ikinci çalıştırmayı bilerek zor anlarda yeniden başlatır: gösterge başlatılırken, kısmi fill sonrasında ve bir risk limiti etkinken. Aynı olay sırasını kullanın ve varsa simülatörün rastgele durumunu koruyun. Kurtarma sonrasındaki ilk kararı, emir ve fill kayıtlarını, öz sermaye seyrini karşılaştırın. Yalnızca son bakiyenin eşleşmesi, birbirini dengeleyen hataları gizleyebilir.

Gönderimden sonra ama onaydan önce yaşanan bir çökme için test düzeneğinin, yürütme hizmetinin durumunu strateji sürecinden bağımsız olarak da koruması gerekir. Aksi hâlde test etmeye çalıştığınız belirsizliği ortadan kaldırırsınız.

Bir stratejinin tanımı, neleri hatırladığını da kapsar. Bu belleği yeterince açık hâle getirin ki tekrar oynatmanın ortasında süreci durdurup nasıl yeniden işe koyulduğunu adım adım gösterebilesiniz.