23 अगस्त 2026 · शोध

आपके बैकटेस्ट में समय की समस्या है, जबकि हर टाइमस्टैम्प सही है

आपके बैकटेस्ट में समय की समस्या है, जबकि हर टाइमस्टैम्प सही है

बैकटेस्ट में समय से जुड़ी सबसे ख़तरनाक गड़बड़ी एकदम सही टाइमस्टैम्प ऑडिट के बाद भी बनी रह सकती है। दो इवेंट पर 10:00:00.000 दर्ज हो सकता है, फिर भी वे ऐसे क्रम में हुए हों जिसका अनुमान आपके सिम्युलेटर ने लगाया हो।

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

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

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

सिर्फ़ टाइमस्टैम्प के आधार पर पंक्तियाँ क्रमबद्ध करने से समान समय वाले इवेंट का क्रम चुनने का काम सिम्युलेटर पर छूट जाता है। फ़ाइल का क्रम, सिंबल का क्रम या डेटाबेस की क्वेरी योजना अनजाने में निष्पादन का नियम बन सकती है। अंतर्निहित डेटा वही रहने पर भी इक्विटी कर्व बदल सकता है।

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

बैकटेस्ट में कौन-कौन सी घड़ियाँ रखनी चाहिए?

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

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

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

समान समय वाले इवेंट का मॉडल कैसे बनाऊँ?

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

इसके बाद सिम्युलेटर में प्रोसेसिंग का नियम साफ़ तौर पर तय करें। हर इवेंट के लिए तय करें कि क्या वह रणनीति की जानकारी अपडेट कर सकता है, उपलब्ध लिक्विडिटी बदल सकता है, ऑर्डर ट्रिगर कर सकता है या ऑर्डर की पुष्टि कर सकता है। ये अलग-अलग कार्रवाइयाँ हैं; इन्हें “पंक्ति प्रोसेस करें” में समेटने से ही ऐसे फ़िल हो जाते हैं जो असल में संभव ही नहीं थे।

  1. सिर्फ़ वही बाज़ार जानकारी लागू करें जो रणनीति के निर्णय लेने के समय तक पहुँच चुकी हो।
  2. ऑर्डर बनाएँ, फिर उसे मॉडल में तय वेन्यू पर पहुँचने के समय तक आगे बढ़ाएँ।
  3. पहुँचने के बाद ही, उस ऑर्डर प्रकार के फ़िल संबंधी अनुमानों के मुताबिक, योग्य लिक्विडिटी के विरुद्ध निष्पादन की अनुमति दें।
  4. हर सिम्युलेटेड फ़िल के लिए इस्तेमाल किए गए इनपुट, इवेंट का क्रम और देरी दर्ज करें।

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

क्या पहुँचने के समय का डेटा न हो, तब भी मैं बैकटेस्ट पर भरोसा कर सकता हूँ?

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

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

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

इवेंट-आधारित बैकटेस्टिंगनिष्पादन मॉडलिंगबाज़ार डेटारणनीति शोध
साझा करेंXLinkedInFacebookRedditHacker NewsWhatsAppTelegramEmail
← सभी पोस्ट