Walk-forward Analysis

पीटर के पास ट्रेडिंग नियम के कई विकल्प हैं। वह हाल के अतीत में सबसे अच्छा चला विकल्प इस्तेमाल करना चाहता है। Walk-forward Analysis इस विचार को क्रम से दोहराता है: ज्ञात इतिहास से चुनना, अगली अवधि का परिणाम लिखना और फिर चुनना। QuantConnect ऐसे नियमित समायोजन का वर्णन करता है। इसलिए जाँच केवल किसी स्थिर विकल्प की नहीं, चुनने के तरीके की भी है। उम्मीदवार, कसौटी और अगली समीक्षा का समय पहले तय होने चाहिए। [1]

यदि पीटर ने पिछले लाभ के कारण कोई विकल्प चुना, तो वही लाभ उसके चुनाव को स्वतंत्र रूप से सही नहीं ठहराता। QuantConnect बताता है कि वह डेटा अब विकास का हिस्सा है। उचित सवाल है: चुनने के बाद विकल्प ने कैसा किया? वर्तमान परीक्षण अपना विजेता खुद नहीं चुन सकता। अवधि खत्म होने और परिणाम उपलब्ध होने के बाद पूर्वनिर्धारित प्रक्रिया उसे अगले चुनाव में इस्तेमाल कर सकती है। इससे पहले दर्ज निर्णय दोबारा नहीं लिखा जाता। [2]

चयन विंडो इतिहास का वह हिस्सा है जो अभी इस्तेमाल हो रहा है। खिसकती विंडो लंबाई स्थिर रखती है और पुराने डेटा छोड़ती जाती है; फैलती विंडो शुरुआती बिंदु रखकर नए अवलोकन जोड़ती है। scikit-learn का TimeSeriesSplit सामान्यतः प्रशिक्षण हिस्सा बढ़ाता है, लेकिन उसका आकार सीमित किया जा सकता है। लंबाई और अपडेट की आवृत्ति परीक्षण से पहले चुनें। दस्तावेज़ तुलनीय मापों के लिए समान अंतराल वाले अवलोकन माँगते हैं; अनियमित रिकॉर्ड में वास्तविक कैलेंडर अवधि भी जाँचें। [3]

मान लें अंतिम प्रशिक्षण अवलोकन का परिणाम अगले परीक्षण के दौरान जाकर पूरा होगा। चुनाव के समय वह अभी ज्ञात नहीं है। तालिका को समयक्रम में रखना इसे ठीक नहीं करता। TimeSeriesSplit का gap पैरामीटर प्रशिक्षण के अंत से कुछ अवलोकन हटाने देता है। आवश्यक अंतराल इनपुट उपलब्ध होने और परिणाम पूरा होने के समय से तय होना चाहिए, सबसे सुंदर रेखा से नहीं। उचित अंतराल भी पड़ोसी अवधियों की स्वतंत्रता साबित नहीं करता और सभी पक्षपात नहीं मिटाता। [3]

रिसाव सीधे ट्रेडिंग नियम में होना ज़रूरी नहीं। मानों का पैमाना बदलने वाला औसत पूरे डेटा से निकाला गया हो सकता है, जिसमें भविष्य का परीक्षण भी शामिल है। scikit-learn गायब मान भरने और इनपुट विशेषताएँ चुनने में भी यही खतरा बताता है। ऐसे रूपांतरणों की सेटिंग केवल प्रशिक्षण डेटा से सीखें और फिर परीक्षण पर लागू करें। हर कदम पर अलगाव दोहराएँ; पहले से बदली तालिका को बाद में बाँटने से रिसाव नहीं मिटता। डेटा का संस्करण और उपलब्धता का समय भी बचाकर रखें। [4]

अलग-अलग अवधि जाँचने के बाद परिणाम सही ढंग से जोड़ने पड़ते हैं। QuantConnect निष्पादन भाव और मात्रा के मॉडल समझाता है, जिनमें स्प्रेड और Slippage शामिल हो सकते हैं। फिर हमारे मूल्यांकन को सुसंगत लेखा चाहिए: विकास के लाभ परीक्षण खाते में न जोड़ें और मिलती-जुलती परीक्षण अवधियों को बिना समझाए कई बार न गिनें। विकल्प बदलते समय खुली पोज़िशन, पूँजी और बदलाव की लागत का हिसाब बताएँ। नीचे का उदाहरण हर अवधि के अंत में पोज़िशन बंद करके इसे सरल बनाता है। [5]

पीटर सुंदर परीक्षण परिणाम मिलने तक विंडो की लंबाई, उद्देश्य या उम्मीदवार बदल सकता है। तब उसने परीक्षण श्रृंखला भी विकास में इस्तेमाल कर ली। Bailey और सहलेखक एक ही डेटा पर बार-बार खोजने से मिलने वाली संयोगपूर्ण सफलताओं का अध्ययन करते हैं। सभी आज़माई प्रक्रियाएँ दर्ज करें और अब तक अप्रयुक्त इतिहास पर किसी अतिरिक्त जाँच को अलग दिखाएँ। समय में आगे बढ़ना अपने आप सांख्यिकीय गारंटी या पुराने डेटा से अत्यधिक मेल बैठाने की संभावना का अनुमान नहीं है। [6]

विंडो की सीमाएँ, उम्मीदवार, चयन अंक, वास्तविक चुनाव और अगली अवधि के लागत के बाद के परिणाम सुरक्षित रखें। कुल परिणाम के साथ घाटा, अवलोकनों की संख्या और समान शर्तों पर तुलना दें। अमेरिकी NFA याद दिलाता है कि काल्पनिक नतीजे वास्तविक नुकसान के समय तरलता, स्लिपेज और व्यवहार की हर समस्या नहीं दिखाते; उसके प्रचार नियम निर्धारित सदस्यों पर लागू हैं। छोटा घाटे वाला उदाहरण पूरी विधि को गलत नहीं साबित करता। वैसे ही सकारात्मक योग भविष्य की बढ़त का प्रमाण नहीं है। [7]