8 नवंबर 2026 · शोध

आपका बैकटेस्ट जरूरत से ज़्यादा पुनरुत्पादित किया जा सकता है

आपका बैकटेस्ट जरूरत से ज़्यादा पुनरुत्पादित किया जा सकता है

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

यह बात पुनरुत्पादकता के खिलाफ़ तर्क जैसी लगती है, लेकिन ऐसा नहीं है। रन को स्थिर रखें ताकि आप उसे समझा सकें। फिर उन मान्यताओं को जानबूझकर बदलकर देखें जिनसे नतीजा तय नहीं होना चाहिए। पहला कदम नतीजे को ऑडिट करने योग्य बनाता है; दूसरा बताता है कि उसका कोई मायने भी है या नहीं।

पुनरुत्पादित किया जा सकने वाला बैकटेस्ट वास्तव में क्या स्थापित करता है?

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

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

हैश उपयोगी है: इससे निर्भरता दिखाई देती है। यह इस बात का प्रमाण नहीं कि निर्भरता नुकसानरहित है।

रन को स्थिर रखें; निष्कर्ष को परखें

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

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

मिसाल के लिए, मान लें कि फ़्यूचर्स रणनीति बेसलाइन रीप्ले में 8% वार्षिकीकृत अतिरिक्त रिटर्न दिखाती है। इसे taker लागत 25% बढ़ाकर, फंडिंग को अगले दर्ज सेटलमेंट पर खिसकाकर, और दो सबसे बड़े योगदानकर्ताओं को बारी-बारी से हटाकर फिर चलाएँ। ये मॉडल को बेहतर बनाने के तीन तरीके नहीं हैं। ये जाँच हैं: हर जाँच पूछती है कि क्या कोई संभावित बारीकी मुख्य नतीजे को चला रही है।

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

बाइट-दर-बाइट समानता को संख्यात्मक सत्य न समझें

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

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

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

बदलाव कब शोर है और कब निष्कर्ष

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

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

पुनरुत्पादकता आपको एक भरोसेमंद शुरुआती बिंदु देती है। उसके बाद उपयोगी सवाल आता है: जब इस रन के आसपास की दुनिया उन तरीकों से बदलती है जिनकी उचित उम्मीद की जा सकती है, तो जवाब के कौन-से हिस्से स्थिर रहते हैं?

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