7 dk okuma
Giriş
Pine Script v6 backtest, bir alım-satım fikrinin geçmiş veride nasıl davranacağını ölçmek için güçlü bir başlangıçtır; fakat Strategy Tester ekranında görülen yüksek net kâr tek başına stratejinin gerçek piyasada aynı sonucu vereceğini göstermez. Pine stratejileri tarihsel ve gerçek zamanlı barlarda farklı hesaplama davranışlarına sahip olabilir, broker emulator emirlerin ne zaman ve hangi fiyat varsayımıyla dolduğunu simüle eder ve komisyon ile slippage hesaba katılmadığında sonuçlar olduğundan iyi görünebilir.
TradingView dokümantasyonuna göre stratejiler varsayılan olarak kapalı bar başına bir kez hesaplanır ve çoğu market emri sonraki uygun tick üzerinde doldurulur. calc_on_every_tick, calc_on_order_fills ve calc_on_every_history_tick gibi ayarlar bu davranışı değiştirebilir. Bu nedenle iyi bir backtest, yalnızca giriş/çıkış koşullarını değil, kodun çalışma modelini ve piyasa sürtünmelerini de test etmelidir.
Execution model, komisyon, slippage, risk yönetimi ve repaint kontrollerini içeren gerçekçi Pine Script v6 strateji testini çalışan örnek kod üzerinde inceleyebilirsiniz.
GitHub Projesini İncele →İçindekiler
- Pine Script v6 backtest execution modelini doğru okuyun
- Emirlerin ne zaman dolduğunu hesaba katın
- Komisyon ve slippage ekleyin
- Repaint ve lookahead kaynaklı yanılsamaları engelleyin
- Pozisyon boyutu ve risk metriklerini gerçekçi kurun
- Overfitting yerine sağlamlık testi yapın
- Backtest sonucunu forward test ile doğrulayın
- Sonuç
- Güvenilir Araştırma Kaynakları
1. Pine Script v6 Backtest Execution Modelini Doğru Okuyun
Pine Script kodu klasik bir uygulama gibi bir kez çalışıp bitmez; chart üzerindeki barlar boyunca tekrar tekrar yürütülür. Tarihsel barlarda stratejinin varsayılan davranışı bar kapanışında tek hesaplamadır. Gerçek zamanlı barda ise seçilen strategy ayarları hesaplama sıklığını değiştirebilir. Özellikle intrabar karar veren bir sistem geliştiriyorsanız tarihsel veride gördüğünüz davranış ile canlı bardaki davranışın birebir aynı olduğunu varsaymayın.
calc_on_every_tick veya order fill sonrasında yeniden hesaplama gibi seçenekler stratejiyi daha sık çalıştırabilir; ancak daha fazla hesaplama otomatik olarak daha gerçekçi sonuç anlamına gelmez. Kullanılan veri granülerliği ve broker emulator varsayımları hâlâ önemlidir. Stratejinin karar verdiği anı açık biçimde tanımlayın: bar kapanışı mı, intrabar fiyat hareketi mi, yoksa emir dolumu sonrası yeni bir karar mı?
2. Emirlerin Ne Zaman Dolduğunu Hesaba Katın
Bir koşulun oluştuğu bar ile emrin dolduğu an aynı şey değildir. TradingView broker emulator, stratejinin ürettiği emirleri belirli fill kurallarına göre simüle eder. Varsayılan kapalı-bar modelinde market emri çoğunlukla bir sonraki barın açılışında doldurulur. Bu ayrım özellikle hızlı hareket eden piyasalarda giriş fiyatını ve stop mesafesini ciddi biçimde değiştirebilir.
Limit, stop ve stop-limit emirlerinde de fiyatın seviyeye dokunması tek başına gerçek piyasadaki dolumu garanti etmez. Backtest raporunu yorumlarken emrin üretildiği fiyatı değil, simüle edilen fill fiyatını inceleyin. Çok hassas intrabar stratejilerde daha düşük timeframe verisi veya Bar Magnifier gibi platform özellikleri gerekebilir.
3. Komisyon ve Slippage Ekleyin
İşlem maliyeti sıfır kabul edilen backtest özellikle yüksek frekanslı veya düşük hedefli stratejilerde yanıltıcıdır. strategy() tanımındaki commission_type ve commission_value ayarlarıyla borsa veya broker maliyetine yakın bir komisyon modeli kurun. Ardından slippage parametresiyle piyasa emrinin teorik fiyattan daha kötü dolabileceğini simüle edin.
Buradaki amaç sonucu cezalandırmak değil, kırılgan stratejileri erkenden ayıklamaktır. Bir sistem küçük bir komisyon veya birkaç tick slippage eklendiğinde tamamen bozuluyorsa gerçek piyasada da sürtünmeye karşı hassas olacaktır. Farklı maliyet senaryolarıyla aynı stratejiyi yeniden çalıştırmak sağlamlık testi için basit ama etkili bir yöntemdir.
4. Repaint ve Lookahead Kaynaklı Yanılsamaları Engelleyin
Backtest sonuçlarını en fazla bozan hatalardan biri gelecekteki bilginin geçmişte varmış gibi kullanılmasıdır. Özellikle request.security ile üst timeframe verisi çekerken lookahead davranışını yanlış ayarlamak veya henüz kapanmamış barın değerini kesinleşmiş kabul etmek geçmiş grafikte kusursuz görünen ama canlıda değişen sinyaller üretebilir.
Sinyalin yalnızca doğrulanmış barlarda oluşmasını istiyorsanız barstate.isconfirmed gibi durumları tasarıma bilinçli biçimde dahil edin. Repaint her durumda hata değildir; bazı göstergeler gerçek zamanlı güncellenmek için doğal olarak değişir. Kritik nokta, backtest ile canlı kullanımın aynı bilgi setine dayanmasıdır.
5. Pozisyon Boyutu ve Risk Metriklerini Gerçekçi Kurun
Net profit tek başına kalite metriği değildir. Maximum drawdown, kazanma oranı, profit factor, ortalama işlem, ardışık kayıplar ve sermaye kullanımını birlikte değerlendirin. Pozisyon boyutunu sabit adet yerine sermaye yüzdesiyle yönetmek bazı sistemlerde daha anlamlı olabilir; ancak kaldıraç, minimum emir miktarı ve enstrüman özellikleri de modele yansıtılmalıdır.
Özellikle kripto ve vadeli piyasalarda yüzde bazlı performans ile gerçek parasal risk birbirinden ayrılmalıdır. Stop mesafesi genişledikçe aynı adetle işlem yapmak risk tutarını büyütür. Bu nedenle strateji testinin hedefi en yüksek kârı bulmak değil, kabul edilebilir drawdown içinde sürdürülebilir davranışı ölçmek olmalıdır.
6. Overfitting Yerine Sağlamlık Testi Yapın
Parametreleri geçmiş veriye sürekli optimize etmek, stratejiyi piyasa davranışını öğrenen bir modele değil geçmiş gürültüyü ezberleyen bir sisteme dönüştürebilir. Hareketli ortalama periyodu 47 olduğunda mükemmel, 45 veya 50 olduğunda kötü sonuç veriyorsa bu hassasiyet bir uyarıdır. İyi stratejiler genellikle yakın parametre bölgelerinde benzer davranış gösterir.
Veriyi geliştirme ve doğrulama dönemlerine ayırın. Farklı piyasa rejimleri, trend ve yatay dönemler, farklı semboller ve maliyet senaryolarında sonuçları karşılaştırın. Tek bir optimum nokta yerine geniş bir kararlı bölge aramak, gerçek piyasa değişimlerine karşı daha dayanıklı sistemler üretir.
7. Backtest Sonucunu Forward Test ile Doğrulayın
TradingView backtesting ile geçmiş davranışı, forward testing ile stratejinin gerçek zamanlı veri akışındaki davranışını gözlemlemeyi ayırır. Backtest sonrasında hemen gerçek sermayeye geçmek yerine paper trading veya yalnızca alert/log takibiyle forward test dönemi uygulayın. Böylece bar kapanışı, intrabar hesaplama, alert zamanı ve gerçek spread/slippage etkilerini gözlemleyebilirsiniz.
Forward test, geçmiş performansı kanıtlamaz; farklı bir soruyu cevaplar: Kod bugün beklediğiniz gibi çalışıyor mu? Backtest ile forward test arasında ciddi sinyal veya işlem farkları varsa önce execution model, repaint, timeframe verisi ve emir fill varsayımlarını inceleyin. Canlıya geçiş ancak bu farkların nedeni anlaşılır olduğunda değerlendirilmelidir.
Sonuç
Pine Script v6 backtest, strateji geliştirme sürecinin sonu değil ölçüm laboratuvarıdır. Gerçekçi bir test için execution model, emir fill zamanı, komisyon, slippage, repaint, pozisyon riski ve overfitting birlikte ele alınmalıdır. Ardından forward test ile kodun gerçek zamanlı davranışı doğrulanmalıdır. Bu yaklaşım kârlılık garantisi vermez; fakat yanıltıcı geçmiş sonuçlarına güvenme riskini ciddi biçimde azaltır ve algoritmik strateji geliştirmeyi daha mühendislik odaklı hale getirir.
Güvenilir Araştırma Kaynakları
TradingView Pine Script v6 - Execution model

