IS/OOS bölmesi yetmez: Walk-forward pencere tasarımı

Sonuç: OOS tek bir dönemse, bu hâlâ "tek seferlik bir sınav"dır

Veriyi optimizasyon (IS) ve doğrulama (OOS) olarak ayırmak, aşırı optimizasyondan şüphelenmenin ilk adımı olarak işe yarar. Ancak bölme yalnızca bir kez yapılırsa, OOS sonucu size sadece "o tek dönemde ne olduğunu" söyler.

Vardığımız sonuç şu: OOS'u birden fazla pencereye bölüp ileri doğru kaydırarak doğrulayın ve toplama değil, her pencerenin kâr edip etmediğine bakın. Toplam kârda olsa bile kâr belirli pencerelerde toplanmışsa değerlendirmeyi askıya alıyoruz.

Sabit bölmenin zayıf yönleri

Bölme noktası sonucu belirler

Sabit bölmede kesim noktasını geliştirici seçer. OOS tesadüfen trendin net olduğu bir döneme denk gelirse, mantık gerçek gücünden daha iyi görünür. Tersi olursa kullanılabilir bir mantığı çöpe atmış olursunuz. İki durumda da sonuç, bölme noktası denen tek bir seçime bağlıdır.

OOS'a defalarca bakarsanız OOS olmaktan çıkar

Bir diğer sorun geliştiricinin davranışıdır. OOS performansı kötü çıkınca parametreleri düzeltip OOS'a yeniden bakmak, bunu tekrarlamak, fiilen OOS'a uyan ayarı seçmekle aynı şeydir. Biçimsel olarak kullanılmamış veri olsa da, pratikte optimizasyonda kullanılmış olur. Bu bizim de düşebileceğimiz bir hatadır ve yalnızca prosedürle önlenebilir.

Walk-forward pencereleri nasıl kurulur

Walk-forward, "optimizasyon dönemi" ile hemen ardından gelen "doğrulama dönemi"ni tek bir pencere sayıp zamanda ileri kaydırarak tekrarlayan bir yöntemdir. Doğrulama dönemi her zaman optimizasyon döneminin gelecekte kalır ve birden fazla OOS elde edilir.

Pencere uzunluğunu belirleme ölçütü

Pencere uzunluğunu takvim yılına göre değil, işlem sayısına göre belirlemek daha güvenlidir. Doğrulama dönemine giren işlem çok azsa, kâr ya da zarar tesadüfen belirlenir. Pozisyon tutma süresi uzun ve işlem sıklığı düşük mantıklarda doğrulama dönemini daha uzun tutmak gerekir.

Pencere pencere kontrol adımları

1. Doğrulama dönemleri çakışmayacak şekilde pencereleri sıralayın
2. Her pencerede optimizasyon yapın ve elde edilen parametreleri yalnızca hemen ardından gelen doğrulama dönemine uygulayın
3. Her doğrulama dönemi için kâr/zarar, PF, işlem sayısı ve maksimum drawdown değerlerini kaydedin
4. PF'si 1.0 ve üzeri kaç pencere olduğuna ve zararla biten pencerelerin hangi döneme denk geldiğine bakın
5. En çok kâr eden pencereyi çıkardığınızda kalanların toplamının hâlâ kârda olup olmadığını kontrol edin
6. Pencereden pencereye seçilen parametrelerin aşırı zıplayıp zıplamadığına bakın

Kontrolün özü üç noktada toplanır.

• Kârlı pencereler bir kısmında toplanmış mı
• Zararlı pencerelerdeki kayıp, kârlı pencerelerin kârına göre fazla büyük mü
• Komşu pencerelerde en iyi parametre aşırı değişiyor mu

Bize göre tüm pencerelerin kârlı olması gerekmez. Trend takipçi türde, yön olmayan dönemlerin pencerelerinde kaybetmek normaldir. Sorun edilmesi gereken, kaybeden pencerenin nedeninin açıklanamaması ve kaybın derinliğinin beklentiyi aşmasıdır.

Sınırlar ve dikkat edilecekler

İşlem sayısı yetersizse pencere anlam taşımaz

ATLAS backtest'inde 7,5 yıllık doğrulamada 1193 işlem var; birden fazla pencereye bölünse bile her pencerede makul sayıda işlem kalır. Buna karşılık ETHEREUM EA backtest'inde 7,5 yıllık doğrulamada 154 işlem var. Bu tür düşük frekanslı bir mantığı küçük pencerelere kesmek, pencere başına işlemi çok azaltır ve pencere bazında kâr/zarar neredeyse hiçbir karar dayanağı sunmaz. Pencereleri iri tutmak ya da pencere bazlı değerlendirmeyi yalnızca referans düzeyinde bırakmak dışında çare yoktur.

Yayımladığımız değerler tüm dönemin değerleridir

Gerçek ölçüm sıralamasında yer alan PF ve kazanma oranı, doğrulama döneminin tamamına ait değerlerdir. Pencere bazlı sonuçlar olmadığı için bunlarla tek başına aşırı optimizasyon olup olmadığı belirlenemez. Bu noktayı hesaba katarak okuyun.

Pencere tasarımının kendisi de optimize edilebilir

Pencere uzunluğunu ya da sayısını değiştirip sonucu iyi gösteren kombinasyonu seçerseniz, bu da aşırı optimizasyondur. Pencere tasarımı doğrulamayı çalıştırmadan önce belirlenmeli ve sonradan oynanmamalıdır. Dışarıdan bakıldığında bu varsayımın korunup korunmadığını teyit etmenin neredeyse hiçbir yolu yoktur.

Yine de gelecek bilinmez

Walk-forward'dan geçmek, geçmişte hiç yaşanmamış piyasa koşullarına karşı koruma sağlamaz. İşlettiğimiz demo hesaptaki forward testte de zararda olan birden fazla EA var. Bunlar gerçek hesap değil demo hesap sonuçlarıdır ve başlangıçtan bu yana geçen süre kısadır; iyi sonuçlar için de kötü sonuçlar için de henüz hüküm verilecek aşamada değiliz. Doğrulama yöntemleri isabetsizliği azaltan bir araçtır, isabeti vaat etmez.

Özet

• Sabit IS/OOS bölmesinde sonuç, bölme noktasına ve OOS'u kaç kez gözden geçirdiğinize bağlıdır
• Walk-forward, birden fazla doğrulama dönemi oluşturup ileri kaydırarak kontrol etme yöntemidir
• Bakılacak şey toplam değil pencere bazlı kâr/zarardır; kârın dağılımı ve parametre istikrarı kontrol edilir
• İşlem sayısı düşük mantıklarda pencereye böldükçe karar kararsızlaşır
• Pencere tasarımı önceden sabitlenir; geçse bile gelecekteki performans bilinmez

Doğrulama yaklaşımımızı bilgi birikimi sayfamızda da derledik.