10 Kasım 2026 · veri

Backtestinizin Yalnızca Veri Anlık Görüntüsüne Değil, Veri Değişiklik Günlüğüne İhtiyacı Var

Backtestinizin Yalnızca Veri Anlık Görüntüsüne Değil, Veri Değişiklik Günlüğüne İhtiyacı Var

Dondurulmuş bir piyasa verisi anlık görüntüsü, backtesti güvenilir kılmaya yetmez. Aynı sonucu yeniden üretebilir, ancak bu sonucu doğuran girdilerin sağlayıcı tarafından değiştirilmiş olduğunu gizleyebilir.

Anlık görüntüyü saklayın. Ardından neyin, ne zaman değiştiğini ve bunun stratejiyi etkileyip etkilemediğini gösterecek bir değişiklik günlüğü tutun. Araştırmanız düzeltilmiş işlemler, güncellenmiş temel veriler, yeniden oluşturulmuş fonlama verileri veya sağlayıcının sessizce yenilediği geçmiş verileri kullanıyorsa bu özellikle önemlidir.

Tekrarlanabilir bir backtest neden yine de yanıltıcı olabilir?

Pazartesi günü 5 yıllık saatlik bar verisini indirip bir strateji çalıştırdığınızı düşünün. Cuma günü sağlayıcı hatalı bir işlemi düzeltmiş, kurumsal bir aksiyonu ayarlamış ya da bir veri boşluğunu doldurmuş olsun. Kaydettiğiniz dosya pazartesi günkü sonucu hâlâ eksiksiz biçimde üretir. Bu tekrarlanabilirliktir. Ancak sağlayıcının güncel geçmiş verileriyle yeniden çalıştırırsanız farklı bir sonuç alabilir ve nedenini açıklayacak bir kaydınız olmayabilir.

Sorun yalnızca büyük düzeltmelerle sınırlı değildir. Değiştirilen tek bir tepe değeri stop emrini tetikleyebilir; güncellenen bir kapanış fiyatı göstergenin eşiği aşmasına neden olabilir. Geniş bir varlık evreninde, tek bir sembolün geçmişi değişince sıralaması değişebilir ve başka bir varlık portföy dışına itilebilir. Strateji kodu ve yapılandırması aynı olsa bile nihai Sharpe değeri kayabilir.

Dosya özeti, iki dosyanın farklı olduğunu söyler. Farkın 40 yıllık fiyatı değiştiren bir bölünme düzeltmesinden, sağlayıcının düzelttiği üç işlemden ya da ayrıştırıcının boş bir alanı sıfıra çevirmesinden kaynaklandığını söylemez.

Piyasa verisi değişiklik günlüğünde neler bulunmalı?

Değişiklikleri, etkilenen araştırmayı yeniden oynatmaya yetecek bağlamla, yararlı olan en küçük birimde kaydedin. Bar akışı için bu genellikle enstrüman, aralık, olay zamanı, önceki ve yeni değerler, kaynak ve güncellemeyi gözlemlediğiniz zaman demektir. Sağlayıcı özgün yükü sunuyorsa onu da saklayın.

Kaydedilecek bilgiNeden saklanmalıÖrnek
Kaynak sürümü veya verinin alınma zamanıKullanılan sağlayıcı durumunu belirlerAnlık görüntü 2026-11-02 08:15 UTC'de alındı
Değişen alan ve eski/yeni değerlerGerçekte neyin değiştiğini gösterirETHUSDT 1h tepe: 3,412.10 → 3,418.60
Değişiklik sınıflandırmasıDüzeltmeleri dönüşümlerden ayırırGeç gelen işlem düzeltmesi, bölünme ayarlaması, geriye dönük veri doldurma
İşlem hattı ve şema sürümüKaynak düzenlemelerini kendi işlemlerinizden ayırırNormalizer v7, ayarlanmış bar şeması v3

Büyük veri kümeleri için değiştirilemez anlık görüntüler ile bunların sağlama toplamlarını, kaynak sürümlerini ve alınma zamanlarını içeren kısa bir manifest saklayın. Değişen bölümler için satır düzeyinde farklar ekleyin. Böylece pratik bir denge sağlarsınız: değişmeyen her satırı ikinci bir denetim tablosuna yazmadan, veriyi bütünüyle yeniden oynatmak mümkün olur.

Bir düzeltmenin önemli olup olmadığını nasıl ölçerim?

Değişen satırları saymakla yetinmeyin. Etkilenen stratejiyi eski ve yeni verilerle; aynı kod, parametreler, ücretler ve yürütme varsayımları altında yeniden çalıştırın. Kararları ve sonuca giden yolu karşılaştırın.

  1. Farklardan etkilenen enstrümanları ve olay zamanlarını belirleyin.
  2. Bu kayıtları kullanan özellikleri, sinyalleri, emirleri veya portföy ağırlıklarını bulun.
  3. Gerekli tüm geriye bakış dönemini ve açık pozisyon durumunu kapsayacak en küçük geçerli zaman aralığını yeniden oynatın.
  4. Emirleri, gerçekleşmeleri, pozisyon büyüklüğünü, devir hızını, düşüşü ve nihai performansı karşılaştırın.

Örneğin, 1 dakikalık tepe değerini $0.02 değiştiren bir sağlayıcı düzeltmesi bir milyon satıra dokunabilir, ancak günlük momentum stratejisini hiç etkilemeyebilir. Stop seviyesindeki tek bir düzeltilmiş bar ise önemli olabilir. Karar üzerindeki etkiyi ölçün; değişen kayıt sayısı bunun için zayıf bir göstergedir.

Şu iki soruyu ayrı tutun: “Kaydettiğim verilerle sonucu yeniden üretebilir miyim?” ve “Bu veri sürümü o sırada stratejinin kullanımına açık olur muydu?” Değişiklik günlüğü her iki soruyu yanıtlamaya yardımcı olur, ancak ikinci soru için ayrıca belirli bir andaki kullanılabilirlik kayıtları gerekir.

Bunun maliyeti nedir ve ne zaman değer?

Değişiklik takibi depolama, veri alımı işi ve operasyonel kararlar gerektirir. Sağlayıcılar kararlı sürümler sunmayabilir; bazı geçmiş veri akışları da açık bir düzeltme bildirimi olmadan düzenli olarak yeniden oluşturulur. Hiç gözlemlemediğiniz bir değişikliği kaydedemezsiniz.

Araştırma sonuçlarını değiştirebilecek verilerden başlayın: stop mantığında kullanılan barlar, kurumsal aksiyonlara göre düzeltilmiş hisse senetleri, belirli bir andaki temel veriler ve yeniden oluşturulan fonlama veya açık pozisyon serileri. Geniş ve istikrarlı veri kümeleri için günlük bir manifest ve bölüm sağlama toplamları yeterli olabilir. Güncellemelerin sık olduğu veya işlem kararlarının tek tek kayıtlara duyarlı olduğu yerlerde alan düzeyinde farklar ekleyin.

Her sağlayıcı yanıtının eksiksiz ve kalıcı bir arşivini tutmanın pahalılaşabileceği ve kaynağın o sırada ne bildiğini yine de gösteremeyebileceği yönündeki eleştiri haklıdır. Çözüm, denetimi önemli verilere ve kararlara göre kapsamlandırmak ve boşlukları belgelemektir. Anlık görüntü bir deneyi yeniden çalıştırmanızı sağlar. Değişiklik günlüğü ise deneyin sonucunun neden değiştiğini açıklamanıza yardımcı olur.

veri mühendisliğibacktesttekrarlanabilirlikkantitatif araştırma
← Tüm yazılar