22 अक्टूबर 2026 · डेटा

डेटा वेंडर का इतिहास बदलने पर हमने बैकटेस्ट फिर से बनाया

डेटा वेंडर का इतिहास बदलने पर हमने बैकटेस्ट फिर से बनाया

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

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

सोमवार: दोबारा चलाने पर नतीजा अलग था

पहला सुराग एक लिक्विड स्पॉट पेयर में छोटा-सा अंतर था। हमारी मूल बार में उच्चतम कीमत 62,418 थी। दोबारा चलाने पर 62,431 दिखी। यह अंतर मामूली लगा, जब तक हमने रणनीति की एंट्री की जाँच नहीं की: उसका थ्रेशोल्ड इन दोनों कीमतों के बीच था। कुछ बदली हुई बार का मतलब था अलग सिग्नल, और फिर कई दिन बाद अलग पोज़िशन।

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

डेटा का ऐसा व्यवहार आम है। एक्सचेंज रिकॉर्ड ठीक करते हैं; वेंडर छूटे हुए डेटा भरते हैं, गलत प्रिंट सुधारते हैं और एग्रीगेशन के नियम बदलते हैं। “जनवरी का डेटा” माँगने पर मार्च में अलग जवाब मिल सकता है।

मंगलवार: पता चला कि रसीद कहाँ गायब थी

हमने रन रिकॉर्ड में वेंडर का नाम, सिंबल और तारीख़ की सीमा दर्ज की थी। जवाब या हर इनपुट पार्टिशन का कंटेंट हैश दर्ज नहीं किया था। यानी हम यह साबित कर सकते थे कि हमने क्या माँगा था, लेकिन यह नहीं कि वेंडर ने कौन-से बाइट लौटाए थे।

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

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

हमने मान लिया था कि “वही क्वेरी” का मतलब “वही डेटा” है। इस धारणा से प्रयोग असलियत से ज़्यादा पुनरुत्पादनीय लगा।

बुधवार: सुधार ने कहानी बदल दी

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

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

गुरुवार: हमने रिसर्च रिकॉर्ड बदला

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

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

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

शुक्रवार: अगली बार हम क्या छोड़ेंगे

हम सिर्फ़ मुख्य मेट्रिक्स की तुलना करना छोड़ देंगे। Sharpe में बदलाव बताता है कि कुछ बदला है; यह नहीं बताता कि वजह क्या थी। पहले पंक्तियों की संख्या और पार्टिशन हैश देखें, फिर पता लगाएँ कि इनपुट की पहली अलग तारीख़ कौन-सी है। उसके बाद इसी क्रम में ट्रांसफ़ॉर्म की गई पंक्तियों, सिग्नल, ऑर्डर और फिल की तुलना करें।

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

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

मार्केट डेटाबैकटेस्टिंगडेटा इंजीनियरिंगपुनरुत्पादनीयता
साझा करेंXLinkedInFacebookRedditHacker NewsWhatsAppTelegramEmail
← सभी पोस्ट