आपके बैकटेस्ट को डेटा स्नैपशॉट नहीं, डेटा बदलाव लॉग चाहिए

भरोसेमंद बैकटेस्ट के लिए बाज़ार डेटा का स्थिर स्नैपशॉट काफ़ी नहीं है। उससे वही नतीजा दोबारा मिल सकता है, लेकिन यह छिपा रह सकता है कि वेंडर ने उस नतीजे के लिए इस्तेमाल हुए इनपुट बदल दिए थे।

स्नैपशॉट रखें। साथ ही बदलावों का ऐसा लॉग रखें जो बता सके कि क्या बदला, कब बदला और क्या उससे रणनीति पर असर पड़ा। यह खास तौर पर तब अहम है जब आपके रिसर्च में सुधारे गए ट्रेड, संशोधित फ़ंडामेंटल्स, दोबारा बनाए गए फंडिंग डेटा या वेंडर का चुपचाप ताज़ा किया गया इतिहास इस्तेमाल होता हो।

दोहराने योग्य बैकटेस्ट भी आपको गुमराह कैसे कर सकता है?

मान लीजिए कि आप सोमवार को पाँच साल के प्रति-घंटे वाले बार डाउनलोड करते हैं और एक रणनीति चलाते हैं। शुक्रवार तक वेंडर किसी खराब ट्रेड को सुधार चुका है, कॉरपोरेट ऐक्शन समायोजित कर चुका है या कोई खाली अवधि भर चुका है। आपकी सेव की हुई फ़ाइल से सोमवार वाला नतीजा अब भी बिल्कुल वैसा ही मिलता है। यह दोहराने योग्य है। लेकिन अगर आप वेंडर के मौजूदा इतिहास से दोबारा चलाएँ, तो नतीजा अलग आ सकता है और आपके पास यह जानने का कोई रिकॉर्ड नहीं होगा कि ऐसा क्यों हुआ।

समस्या केवल बड़े सुधारों तक सीमित नहीं है। ऊँची कीमत का एक बदला हुआ मान स्टॉप ट्रिगर कर सकता है; संशोधित क्लोज़ किसी इंडिकेटर को उसकी सीमा के पार पहुँचा सकता है। बड़े यूनिवर्स में, किसी एक इंस्ट्रूमेंट का बदला हुआ इतिहास उसकी रैंक बदल सकता है और किसी दूसरी एसेट को पोर्टफ़ोलियो से बाहर कर सकता है। रणनीति का कोड और कॉन्फ़िगरेशन समान होने पर भी अंतिम Sharpe बदल सकता है।

फ़ाइल हैश आपको बताता है कि दो फ़ाइलें अलग हैं। यह नहीं बताता कि स्प्लिट समायोजन से 40 साल की कीमतें बदलीं, वेंडर ने तीन ट्रेड सुधारे या पार्सर ने खाली फ़ील्ड को शून्य में बदल दिया।

बाज़ार डेटा के बदलाव लॉग में क्या दर्ज होना चाहिए?

बदलावों को सबसे छोटी उपयोगी इकाई पर दर्ज करें और इतना संदर्भ रखें कि प्रभावित रिसर्च फिर से चलाया जा सके। बार फ़ीड के लिए आम तौर पर इंस्ट्रूमेंट, इंटरवल, घटना का समय, पुराने और नए मान, स्रोत और अपडेट दिखने का समय दर्ज करना चाहिए। वेंडर मूल पेलोड देता हो तो उसे सुरक्षित रखें।

बड़े डेटासेट के लिए अपरिवर्तनीय स्नैपशॉट और उनके चेकसम, स्रोत संस्करण तथा डेटा लेने के समय का संक्षिप्त मैनिफ़ेस्ट रखें। बदले हुए पार्टिशन के लिए पंक्ति-स्तर के अंतर जोड़ें। इससे व्यावहारिक संतुलन मिलता है: हर अपरिवर्तित पंक्ति को दूसरी ऑडिट टेबल में लिखे बिना भी पूरा डेटा फिर से चलाना संभव रहता है।

मैं कैसे मापूँ कि किसी सुधार से फ़र्क पड़ता है या नहीं?

बदली हुई पंक्तियाँ गिनने के बाद रुकें नहीं। पुराने और नए डेटा पर, समान कोड, पैरामीटर, फ़ीस और एक्ज़ीक्यूशन मान्यताओं के साथ प्रभावित रणनीति फिर से चलाएँ। फ़ैसलों और नतीजे तक पहुँचने के क्रम की तुलना करें।

1. अंतर के आधार पर प्रभावित इंस्ट्रूमेंट और घटना के समय पहचानें।
2. पता लगाएँ कि इन रिकॉर्ड का इस्तेमाल कौन से फ़ीचर, सिग्नल, ऑर्डर या पोर्टफ़ोलियो वेट करते हैं।
3. लुकबैक और खुली पोज़िशन की स्थिति समेत, सबसे छोटी वैध अवधि को फिर से चलाएँ।
4. ऑर्डर, फ़िल, एक्सपोज़र, टर्नओवर, ड्रॉडाउन और अंतिम प्रदर्शन की तुलना करें।

उदाहरण के लिए, वेंडर का कोई सुधार 1-minute high को $0.02 से बदलता है। इससे दस लाख पंक्तियाँ प्रभावित हो सकती हैं, फिर भी डेली मोमेंटम रणनीति पर कोई असर नहीं पड़ेगा। स्टॉप स्तर पर बार का एक सुधार ज़्यादा मायने रख सकता है। फ़ैसले पर असर मापें; बदले हुए रिकॉर्ड की गिनती उसका अच्छा अनुमान नहीं है।

इसकी लागत क्या है, और यह कब फ़ायदेमंद होता है?

बदलाव ट्रैक करने में स्टोरेज, डेटा इन्जेशन का काम और संचालन से जुड़े फ़ैसले लगते हैं। हो सकता है कि वेंडर स्थिर संस्करण उपलब्ध न कराएँ, और कुछ ऐतिहासिक फ़ीड बिना किसी साफ़ सुधार सूचना के समय-समय पर दोबारा तैयार की जाती हैं। जिस बदलाव पर आपकी नज़र ही न पड़े, उसे आप लॉग नहीं कर सकते।

वहाँ से शुरू करें जहाँ संशोधन रिसर्च के निष्कर्ष बदल सकते हैं: स्टॉप लॉजिक में इस्तेमाल होने वाले बार, कॉरपोरेट ऐक्शन के लिए समायोजित इक्विटी डेटा, उस समय के फ़ंडामेंटल्स और दोबारा बनाए जाने वाले फंडिंग या ओपन इंटरेस्ट सीरीज़। बड़े और स्थिर डेटासेट के लिए डेली मैनिफ़ेस्ट और पार्टिशन चेकसम काफ़ी हो सकते हैं। जहाँ अपडेट आम हों या ट्रेड के फ़ैसले अलग-अलग रिकॉर्ड पर निर्भर हों, वहाँ फ़ील्ड-स्तर के अंतर जोड़ें।

आलोचकों की यह बात सही है कि वेंडर के हर जवाब का पूरा और हमेशा के लिए रखा गया संग्रह महँगा हो सकता है, और फिर भी यह दर्ज करने में नाकाम रह सकता है कि स्रोत को उस समय क्या पता था। समाधान यह है कि ऑडिट को उन डेटा और फ़ैसलों तक सीमित रखें जो मायने रखते हैं, और कमियों का दस्तावेज़ बनाएँ। स्नैपशॉट आपको प्रयोग फिर से चलाने देता है। बदलाव लॉग आपको समझाता है कि प्रयोग का नतीजा क्यों बदला।