बैकटेस्ट ने 20% वार्षिकीकृत रिटर्न दिया। इसमें 8 साल का डेटा, 1,640 ट्रेड और एक साफ़ वॉक-फ़ॉरवर्ड विभाजन था। फिर हमने वेंडर के मौजूदा इतिहास की जगह उस समय दर्ज मान रखे, और एज घटकर 3% रह गया।
हैरानी की बात मूल रिटर्न नहीं था। बात उन 17 प्रतिशत अंकों की थी जो संशोधित डेटा पर निर्भर थे। इस तरह की बाद की जानकारी आर्थिक घोषणाओं, कंपनी के बुनियादी आँकड़ों, इंडेक्स की सदस्यता और यहाँ तक कि बाज़ार के सामान्य दिखने वाले फ़ील्ड में भी छिपी हो सकती है। ऐतिहासिक डेटा बताता है कि स्रोत आज क्या कहता है। पॉइंट-इन-टाइम डेटासेट बताता है कि आपकी रणनीति उस समय क्या जान सकती थी।
घटना के बाद ऐतिहासिक डेटा क्यों बदल सकता है?
कुछ मान पहले अनुमान होते हैं और बाद में सुधारे जाते हैं। शुक्रवार को जारी हुआ कोई आर्थिक आँकड़ा अगले महीने संशोधित हो सकता है। कोई कंपनी आय के आँकड़े फिर से जारी कर सकती है। डेटा वेंडर गलत प्रिंट ठीक कर सकता है, छूटा हुआ अंतराल भर सकता है या शुरुआती मान की जगह अंतिम मान रख सकता है। जो डेटाबेस केवल नवीनतम मान रखता है, उसमें ये सारे बदलाव ऐसे दिखते हैं मानो वे हमेशा से सही थे।
यह तब मायने रखता है जब कोई रणनीति रिपोर्ट किए गए राजस्व के आधार पर कंपनियों की रैंकिंग करती है या तय डेटा रिलीज़ के बाद बाज़ार में ट्रेड करती है। अगर उसे सुधरा हुआ आँकड़ा महीनों पहले दिखता है, तो बैकटेस्ट ने उसे ऐसी जानकारी दे दी है जो निर्णय के समय बाज़ार में उपलब्ध नहीं थी। सिग्नल की गणना बिल्कुल सही हो सकती है; फिर भी उसका इनपुट इतिहास के गलत संस्करण से आया है।
यहाँ एक आम जाल है: date नाम वाला फ़ील्ड अक्सर उस अवधि को बताता है जिसे कोई मान कवर करता है, न कि वह समय जब वह उपलब्ध हुआ। 31 मार्च के चिह्न वाला तिमाही राजस्व रिकॉर्ड शायद मई तक प्रकाशित ही न हुआ हो। यह लेबल कारोबारी अवधि के बारे में है, रणनीति को उपलब्ध जानकारी के बारे में नहीं।
बैकटेस्ट में कौन-सा टाइमस्टैम्प इस्तेमाल करना चाहिए?
मान की प्रभावी अवधि और उसकी उपलब्धता का समय अलग-अलग दर्ज करें। जहाँ संभव हो, प्रकाशन का समय और डेटा ग्रहण करने का समय भी रखें। रणनीति किसी मान का उपयोग उसके प्रकाशित होने और सिस्टम तक पहुँचने के बाद ही कर सकती है; अगर इन समयों में अंतर हो, तो सतर्कतापूर्ण रीप्ले के लिए बाद वाला समय लें।
| टाइमस्टैम्प | यह क्या बताता है | यह कैसे मदद करता है |
|---|---|---|
| प्रभावी समय | वह अवधि या घटना जिससे मान संबंधित है | अवलोकनों को मापी जा रही चीज़ के आधार पर समूहित करता है |
| प्रकाशन समय | स्रोत ने यह संस्करण कब जारी किया | रिलीज़ को उसके अस्तित्व में आने से पहले दिखने से रोकता है |
| डेटा ग्रहण समय | आपके सिस्टम को यह संस्करण कब मिला | डिलीवरी में देरी और देर से हुए बैकफ़िल दर्ज करता है |
उदाहरण के लिए, मान लें कि किसी कंपनी की तिमाही बिक्री जनवरी से मार्च तक की अवधि की है, 8 मई को Eastern समय के अनुसार 16:15 पर रिपोर्ट होती है, और 16:17 पर आपके शोध स्टोर तक पहुँचती है। 8 मई के क्लोज़ पर निर्णय लेने वाली रणनीति उस रिपोर्ट का उपयोग नहीं कर सकती, क्योंकि क्लोज़ के समय उसका निर्णय 16:00 पर हुआ था। अगली सुबह निर्णय लेने वाली रणनीति कर सकती है। केवल तिमाही के अंत की तारीख से इनमें से किसी सवाल का जवाब नहीं मिलता।
मैं कैसे जाँचूँ कि नतीजे में संशोधनों की भूमिका है या नहीं?
एक ही रणनीति 2 बार चलाएँ: एक बार हर ऐतिहासिक निर्णय समय पर उपलब्ध डेटा संस्करण के साथ, और दूसरी बार नवीनतम संशोधित इतिहास के साथ। निष्पादन की मान्यताएँ, यूनिवर्स और कोड एक समान रखें। यह अंतर संशोधन-संवेदनशीलता का नतीजा है, किसी नई रणनीति की तुलना नहीं।
फिर देखें कि अंतर कहाँ से आ रहा है। क्या रिलीज़ वाले दिनों में प्रदर्शन बदलता है? क्या सबसे बड़े अंतर कुछ ऐसी कंपनियों में केंद्रित हैं जिनके आँकड़े दोबारा जारी हुए, या सुधारे गए अवलोकनों में? क्या रणनीति संबंधित प्रकाशन समय से पहले ट्रेड करती है? घटनाओं के स्तर पर किया गया एक छोटा ऑडिट अक्सर संचयी रिटर्न के एक और चार्ट से ज़्यादा समझा देता है।
ये आँकड़े उदाहरण हैं, कोई सार्वभौमिक कटौती नहीं। उपयोगी नतीजा आपकी अपनी रणनीति के लिए दोनों का जोड़ीदार परिणाम है, जहाँ तक संभव हो समान ट्रेड और लागतों के साथ। अगर संशोधित संस्करण बड़े अंतर से बेहतर है, तो मुख्य बैकटेस्ट नतीजे पर भरोसा करने से पहले पता करें कि कौन-से फ़ील्ड और तारीखें इस अंतर की वजह हैं।
पॉइंट-इन-टाइम डेटा ऑडिट में क्या दर्ज करना चाहिए?
उन फ़ील्ड से शुरू करें जिनका आपकी रणनीति वास्तव में उपयोग करती है। हर फ़ील्ड के लिए स्रोत, टाइमस्टैम्प का अर्थ, संशोधन नीति और पुराने संस्करण वापस पाने की सुविधा दर्ज करें। वेंडर से पूछें कि सुधार कैसे दिखाए जाते हैं: क्या पंक्तियाँ ओवरराइट होती हैं, नए संस्करण की पंक्तियाँ बनती हैं या अलग ऑडिट लॉग रखा जाता है। उत्पाद पेज पर “ऐतिहासिक” लिखे होने से इस सवाल का जवाब नहीं मिलता।
- हर संस्करण को उसके प्रकाशन समय या पहली उपलब्धता के टाइमस्टैम्प के साथ स्टोर करें।
- फ़ीचर्स को अवधि के लेबल से नहीं, उपलब्धता समय के आधार पर निर्णयों से जोड़ें।
- दोहराए जा सकने वाले रन के लिए एक स्थिर स्नैपशॉट या स्रोत संस्करण रखें।
- देर से आने वाले, संशोधित होने वाले या जिनका भरोसेमंद इतिहास उपलब्ध न हो, ऐसे मानों को चिह्नित करें।
और दायरा व्यावहारिक रखें। अगर आपकी रणनीति केवल एक्सचेंज ट्रेड और बार इस्तेमाल करती है, तो आर्थिक डेटा के संशोधन अप्रासंगिक हो सकते हैं। लेकिन बार में सुधार और वेंडर के बैकफ़िल फिर भी मायने रख सकते हैं, खासकर जब सिग्नल किसी कम तरल बाज़ार या सटीक घटना-अवधि पर निर्भर हो।
जब पॉइंट-इन-टाइम इतिहास उपलब्ध न हो
आज के मान को चुपचाप कल का मान न मानें। उस फ़ील्ड को सीमा के रूप में चिह्नित करें, ऐतिहासिक उपलब्धता पर निर्भर दावों से उसे बाहर रखें, या सतर्कतापूर्ण देरी लागू करके दिखाएँ कि नतीजा कितना बदलता है। देरी वाला प्रॉक्सी शोध के लिए उपयोगी हो सकता है, बशर्ते देरी स्पष्ट हो और नतीजे के साथ उसकी सीमा भी दर्ज हो।
बैकटेस्ट का काम उस समय मौजूद जानकारी के आधार पर निर्णय को फिर से तैयार करना है। अगर आपका डेटा केवल नवीनतम संस्करण दिखा सकता है, तो नतीजे की एक सीमा है: यह आज के पुनर्निर्मित इतिहास के आधार पर रणनीति को परख सकता है, लेकिन यह साबित नहीं कर सकता कि कोई ऐतिहासिक एजेंट वास्तव में क्या देख सकता था।
← सभी पोस्ट
