Bir backtest yıllıklandırılmış %20 getiri sağladı. 8 yıllık veri, 1,640 işlem ve temiz bir ileriye dönük test ayrımı kullandı. Sonra veri sağlayıcının güncel geçmiş verisini, o dönemde kaydedilmiş değerlerle değiştirdik; getiri avantajı %3’e düştü.
Şaşırtıcı olan ilk getiri değildi. Revize edilmiş verilere bağlı olan 17 yüzde puanlık farktı. Bu tür bir geriye dönük bilgi; ekonomik açıklamalarda, şirket finansallarında, endeks üyeliklerinde ve görünüşte basit piyasa alanlarında bile gizlenebilir. Geçmiş veriler, kaynağın bugün ne söylediğini gösterir. Zamanın noktasına göre veri ise stratejinizin o sırada neleri bilebileceğini gösterir.
Olaydan sonra geçmiş veriler neden değişebilir?
Bazı değerler önce tahmin olarak açıklanır, sonra düzeltilir. Cuma günü yayımlanan bir ekonomik istatistik, sonraki ay revize edilebilir. Bir şirket açıkladığı kazanç rakamını yeniden düzenleyebilir. Bir veri sağlayıcı hatalı bir fiyatı düzeltebilir, eksik bir aralığı doldurabilir ya da öncü bir değeri nihai değerle değiştirebilir. Yalnızca en güncel değeri saklayan bir veritabanı, tüm bu değişiklikleri sanki hep doğruymuş gibi gösterir.
Bu durum, strateji açıklanan gelire göre şirketleri sıraladığında veya planlı bir veri açıklamasının ardından piyasada işlem yaptığında önem kazanır. Düzeltilmiş sayıyı aylar öncesinden görebiliyorsa backtest, karar anında piyasada bulunmayan bilgiyi stratejiye vermiş demektir. Sinyal hesabı kusursuz olabilir; yine de yanlış geçmiş sürümündeki veriyi kullanıyordur.
Burada kolayca düşülebilecek bir tuzak var: date adlı bir alan, çoğu zaman değerin kapsadığı dönemi belirtir; ne zaman erişilebilir hâle geldiğini değil. 31 Mart tarihli bir çeyreklik gelir satırı, Mayıs’a kadar yayımlanmamış olabilir. Etiket, işletmenin dönemini anlatır; stratejinin bilgi kümesini değil.
Backtest hangi zaman damgasını kullanmalı?
Değerin geçerli olduğu dönemi ve erişilebilir olduğu zamanı ayrı ayrı izleyin. Mümkünse yayımlanma ve sisteme alınma zamanlarını da saklayın. Strateji bir değeri ancak yayımlandıktan ve sistem tarafından alındıktan sonra kullanabilir; bu zamanlar farklıysa, ihtiyatlı bir geriye dönük canlandırmada daha geç olanı esas alın.
| Zaman damgası | Tanımladığı şey | Ne işe yarar |
|---|---|---|
| Geçerlilik zamanı | Değerin ilgili olduğu dönem veya olay | Gözlemleri ölçülen unsura göre gruplar |
| Yayımlanma zamanı | Kaynağın bu sürümü yayımladığı zaman | Bir açıklamanın yayımlanmadan önce görünmesini önler |
| Sisteme alınma zamanı | Sisteminizin bu sürümü aldığı zaman | Teslimat gecikmelerini ve geçmişe dönük geç eklemeleri yakalar |
Örneğin, bir şirketin çeyreklik satışlarının Ocak-Mart dönemini kapsadığını, 8 Mayıs’ta Doğu Saatiyle 16:15’te açıklandığını ve araştırma veri deponuza 16:17’de ulaştığını varsayalım. 8 Mayıs kapanışında karar veren bir strateji bu raporu kullanamaz; çünkü kapanış anındaki kararı 16:00’da verilmiştir. Ertesi sabah karar veren bir strateji ise kullanabilir. Yalnızca çeyrek sonu tarihi bu iki soruyu da yanıtlamaz.
Sonucu revizyonların etkileyip etkilemediğini nasıl test ederim?
Aynı stratejiyi iki kez çalıştırın: birinde her tarihsel karar anında erişilebilir olan veri sürümünü, diğerinde ise en güncel revize edilmiş geçmiş veriyi kullanın. Gerçekleşme varsayımlarını, evreni ve kodu sabit tutun. Aradaki fark, yeni bir strateji karşılaştırması değil, revizyon duyarlılığı sonucudur.
Ardından farkın nereden kaynaklandığını inceleyin. Performans açıklama günlerinde değişiyor mu? En büyük farklar, yeniden düzenlenmiş birkaç şirketin veya düzeltilmiş gözlemlerin çevresinde mi yoğunlaşıyor? Strateji, ilgili açıklama saatinden önce işlem yapıyor mu? Olay düzeyinde küçük bir denetim çoğu zaman bir kümülatif getiri grafiğinden daha fazla açıklama sağlar.
Bu rakamlar örnektir; her durum için geçerli bir ceza oranı değildir. Faydalı olan, mümkün olduğunda aynı işlemleri ve maliyetleri koruyarak kendi stratejiniz için iki sonucu yan yana değerlendirmektir. Revize edilmiş sürüm çok daha iyi sonuç veriyorsa, manşet backtest’e güvenmeden önce hangi alan ve tarihlerin farkı yarattığını bulun.
Zamanın noktasına göre veri denetiminde neler kaydedilmeli?
Stratejinizin gerçekten kullandığı alanlarla başlayın. Her biri için kaynağı, zaman damgasının neyi ifade ettiğini, revizyon politikasını ve önceki sürümlere erişilip erişilemediğini belirleyin. Düzeltmelerin nasıl gösterildiğini veri sağlayıcıya sorun: üzerine yazılan satırlar, yeni sürüm satırları veya ayrı bir denetim kaydı. Ürün sayfasında “geçmiş veriler” yazması bu soruyu yanıtlamaz.
- Her sürümü yayımlanma veya ilk erişilebilir olma zaman damgasıyla saklayın.
- Özellikleri kararlara dönem etiketleriyle değil, erişilebilirlik zamanına göre bağlayın.
- Tekrarlanabilir çalışmalar için dondurulmuş bir anlık görüntü veya kaynak sürümü saklayın.
- Geç gelen, revize edilen veya güvenilir geçmişi bulunmayan değerleri işaretleyin.
Kapsamı uygulanabilir tutun. Stratejiniz yalnızca borsa işlemlerini ve mum verilerini kullanıyorsa ekonomik veri revizyonları önemsiz olabilir. Ancak özellikle sinyal ince işlem gören bir piyasaya veya hassas bir olay aralığına bağlıysa, mum düzeltmeleri ve veri sağlayıcıların geçmişe dönük eklemeleri yine de önem taşıyabilir.
Zamanın noktasına göre geçmiş veriye erişilemiyorsa
Bugünün değerini sessizce dünkü değer gibi kullanmayın. Alanı bir sınırlama olarak belirtin, geçmişte erişilebilir olmasına bağlı iddialardan çıkarın ya da ihtiyatlı bir gecikme uygulayıp sonucun ne kadar değiştiğini gösterin. Gecikmesi açıkça belirtilir ve bu sınırlama sonuçla birlikte sunulursa, gecikmeli bir yaklaşık değer araştırmada işe yarayabilir.
Backtest’in görevi, o sırada mevcut olan bilgi kümesini kullanarak bir kararı yeniden oluşturmaktır. Veriniz yalnızca en güncel sürümü gösterebiliyorsa, dürüst sonucun bir sınırı vardır: stratejiyi bugün yeniden oluşturulmuş geçmişe göre sınayabilir; ancak tarihsel bir işlem yapıcının tam olarak neleri görebildiğini ortaya koyamaz.
← Tüm yazılar
