हमने सेव किया हुआ बैकटेस्ट फिर चलाया और इक्विटी कर्व अलग निकला। रणनीति का वही कोड, वही तारीख़ों की सीमा, वही सिंबल। अंतिम बैलेंस में 1.8% का अंतर था और 3 ट्रेड एक बार खिसक गए थे।
शोध के नतीजे पर भरोसा करना मुश्किल बनाने के लिए इतना काफ़ी है। अगर कोई सहकर्मी, आपका भविष्य का रूप या पेपर ट्रेडिंग सेवा रन को दोहरा नहीं सकती, तो आप नहीं जान सकते कि किसी बदलाव से रणनीति बेहतर हुई या सिर्फ़ प्रयोग बदल गया। बदलाव का स्रोत खोजने के लिए हमने ये कदम उठाए।
दिन 1: हमने लिखा कि “वही रन” किसे कहेंगे
हमारी पहली गलती थी रणनीति की फ़ाइल को ही पूरा प्रयोग मान लेना। ऐसा नहीं था। रन इनपुट डेटा, इंजन संस्करण, कैलेंडर, इंस्ट्रूमेंट के मेटाडेटा और निष्पादन सेटिंग्स पर भी निर्भर था। कोड गणना के सिर्फ़ एक हिस्से का ब्यौरा देता था।
कुछ भी बदलने से पहले हमने रन मैनिफ़ेस्ट बनाया। उसमें रणनीति का commit, डेटा स्नैपशॉट पहचानकर्ता, तारीख़ों की सीमा, वेन्यू, शुल्क अनुसूची, फ़ंडिंग स्रोत, फ़िल मॉडल और सॉफ़्टवेयर संस्करण दर्ज किए। हमने बने हुए ऑर्डर और फ़िल भी सेव किए, क्योंकि सिर्फ़ इक्विटी कर्व से पता नहीं चलता कि 2 रन पहली बार कहाँ अलग हुए।
| आर्टिफ़ैक्ट | क्या दर्ज करें | यह क्यों मायने रखता है |
|---|---|---|
| मार्केट डेटा | स्नैपशॉट ID, स्कीमा संस्करण, समायोजन | डेटा प्रदाता पुराने इतिहास को सुधारते और कॉर्पोरेट कार्रवाइयों में संशोधन करते हैं |
| निष्पादन | शुल्क स्तर, फ़ंडिंग शृंखला, फ़िल और इम्पैक्ट सेटिंग्स | डिफ़ॉल्ट और खाते से जुड़ी मान्यताएँ नतीजे बदलती हैं |
| रनटाइम | कोड commit, इंजन और निर्भरता संस्करण | लाइब्रेरी क्रम, राउंडिंग या इंडिकेटर बदल सकती हैं |
| आउटपुट | ऑर्डर, फ़िल, पोज़िशन और मेट्रिक्स | दिखाता है कि रन कहाँ से असहमत होने लगते हैं |
दिन 2: हमने Sharpe नहीं, ट्रेडों की तुलना की
सारांश मेट्रिक्स ध्यान भटका रहे थे। दोनों रन का Sharpe लगभग एक जैसा था, लेकिन फ़िल लॉग में पहला अंतर फ़ंडिंग सेटलमेंट पर दिखा। एक रन ने सेटलमेंट टाइमस्टैम्प पर खुली पोज़िशन पर दर लागू की; दूसरे ने उस टाइमस्टैम्प के रीबैलेंस के बाद वाली पोज़िशन का इस्तेमाल किया।
रणनीति का कोड नहीं बदला था। इंजन में इवेंट का क्रम बदल गया था। एक छोटे संस्करण अपडेट ने क्रम को स्पष्ट कर दिया था, जबकि पहले यह इस बात पर निर्भर करता था कि 2 इवेंट संयोग से किस क्रम में आते हैं।
हमने रन के नियम स्पष्ट किए: पहले सेटलमेंट में लाई गई पोज़िशन पर फ़ंडिंग लागू करें, फिर उस टाइमस्टैम्प के लिए रणनीति के फ़ैसले प्रोसेस करें। यह सटीक नियम वेन्यू और इंजन के अनुसार अलग हो सकता है। इसे अस्पष्ट छोड़ना ही गड़बड़ी है।
दिन 3: “वही” डेटा फ़ाइल असल में अलग निकली
इवेंट का क्रम तय करने के बाद, बाकी अंतर कुछ इक्विटी ट्रेडों में केंद्रित थे। डेटा प्रदाता ने पुराने स्प्लिट समायोजन को सुधारा था। हमारी फ़ाइल का नाम और पंक्तियों की संख्या पहले जैसी ही थी, इसलिए वह अपरिवर्तित लग रही थी।
अब हम हर अपरिवर्तनीय डेटा स्नैपशॉट का फ़िंगरप्रिंट रखते हैं और उसके साथ समायोजन नीति भी दर्ज करते हैं। हैश बताता है कि बाइट बदले या नहीं; यह नहीं बताता कि क्यों बदले। इसलिए मैनिफ़ेस्ट में स्रोत, डेटा लेने का समय और रूपांतरण संस्करण भी शामिल हैं। संशोधित होते रहने वाले डेटा के लिए ये विवरण नतीजे का हिस्सा हैं।
दोहराए जा सकने वाले बैकटेस्ट को इस सवाल का जवाब देना चाहिए: “उसे अतीत का कौन-सा संस्करण दिखा था?”
दिन 4: हमें एक छिपी हुई डिफ़ॉल्ट सेटिंग मिली
आख़िरी अंतर यह था कि maker शुल्क 0 पर सेट था, क्योंकि रणनीति के config में वह फ़ील्ड शामिल नहीं थी। नए इंजन ने खाते का डिफ़ॉल्ट शुल्क लागू किया। उस एक डिफ़ॉल्ट ने सीमांत ट्रेडों को इतना बदला कि अंतिम बैलेंस के अंतर का बड़ा हिस्सा समझ में आ गया।
हमने आर्थिक रूप से अहम सेटिंग्स को स्पष्ट रूप से दर्ज किया और इंजन से कहा कि वह हल किया हुआ config रन रिकॉर्ड में प्रिंट करे। प्रयोग करते समय डिफ़ॉल्ट सुविधाजनक हैं। समय के साथ नतीजों की तुलना में वे कमज़ोर सबूत हैं।
अगली बार हम क्या छोड़ेंगे
पहले अलग हुए फ़िल को देखने से पहले हमने कुल मेट्रिक्स की तुलना में आधा दिन लगा दिया। शुरुआत वहाँ से न करें। दोनों इवेंट लॉग को टाइमस्टैम्प के अनुसार क्रम में लगाएँ और पहला अंतर खोजें; बाद के अंतर अक्सर उसी एक वजह से पैदा होते हैं।
हम यह सोच भी छोड़ देंगे कि सिर्फ़ कंटेनर इमेज से रन दोहराया जा सकता है। इससे सॉफ़्टवेयर वातावरण का बड़ा हिस्सा पिन हो जाता है, लेकिन बाहरी डेटा फ़ाइल, रनटाइम पर ली गई शुल्क अनुसूची या डेटा प्रदाता के संशोधित इतिहास का हिसाब नहीं रहता।
बैकटेस्ट बदलने पर दोनों रन के मैनिफ़ेस्ट और लॉग सुरक्षित रखें, फिर बदलाव के एक स्रोत को एक बार में ठीक करें। उपयोगी नतीजा सिर्फ़ ऐसा कर्व नहीं है जिसे फिर से बनाया जा सके। उपयोगी नतीजा वह रिकॉर्ड है जो बताता है कि इसे किस डेटा और किन मान्यताओं से बनाया गया, और अगला रन क्यों अलग हो सकता है।
← सभी पोस्ट
