टाइम-सीरीज़ फ़ाउंडेशन मॉडल: क्या अब कस्टम ट्रेनिंग बेकार है?

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

टाइम-सीरीज़ फ़ाउंडेशन मॉडल असल में है क्या

LLM से तुलना उपयोगी है, लेकिन सिर्फ़ ऊपरी सतह से आगे जाकर देखने पर। एक बड़ा लैंग्वेज मॉडल टेक्स्ट के विशाल कॉर्पस पर प्री-ट्रेन होता है ताकि वह उन कामों और वाक्य-रचनाओं तक सामान्यीकरण कर सके जो उसने कभी देखी ही नहीं। टाइम-सीरीज़ फ़ाउंडेशन मॉडल (TSFM) यही काम लगातार सिग्नल्स के साथ करता है: उसे सीरीज़ के एक विशाल और विविध संग्रह पर प्री-ट्रेन किया जाता है, असली और सिंथेटिक दोनों, ताकि वह टेम्पोरल डेटा का बार-बार दोहराया जाने वाला व्याकरण सीख सके। ट्रेंड, सीज़नैलिटी, रेजीम शिफ़्ट, मीन रिवर्ज़न, और हर तरह का नॉइज़। जब आप उसे अपना सेंसर स्ट्रीम या बिक्री का इतिहास देते हैं, तो वह शुरू से कुछ नहीं सीखता; वह पहचानता है।

यही आख़िरी शब्द पूरी ट्रिक है, और इसी से वह बात समझ आती है जिसने मुझे पहली बार पढ़ते समय उलझा दिया था: जो मॉडल ज़्यादातर सिंथेटिक डेटा पर ट्रेन हुआ हो, वह असली डेटा पर ट्रेन किए गए मॉडलों को कैसे हरा सकता है? इसका जवाब है कि सिंथेटिक जनरेटर ऐसे प्रोसेस बनाने के लिए बनाए गए हैं जिनमें सुसंगत डायनामिक्स हों: ट्रेंड, सीज़नैलिटी और नॉइज़ का यथार्थवादी मेल, साथ ही सीरीज़ के बीच नॉनलिनियर डिपेंडेंसी। मॉडल टेम्पोरल व्यवहार कैसा दिख सकता है, इसका एक विशाल प्रायर सीख लेता है। आपकी असली सीरीज़, चाहे आपको वह कितनी भी अजीब लगती हो, लगभग निश्चित रूप से उन पैटर्न्स का कोई नया मेल है जिन्हें मॉडल लाखों बार देख चुका है।

Timestral की ट्रेनिंग रेसिपी इसे ठोस बनाती है। पहले, 8,192 टाइम स्टेप के कॉन्टेक्स्ट के साथ पूरी तरह सिंथेटिक डेटा पर बड़े पैमाने की प्री-ट्रेनिंग। फिर असली और सिंथेटिक डेटा के मिश्रण पर पोस्ट-ट्रेनिंग, जिसमें कॉन्टेक्स्ट को 32,768 स्टेप तक बढ़ाया जाता है। लक्ष्य फ़ंक्शन 21 क्वांटाइल पर pinball loss है, यानी मॉडल कोई एक पॉइंट एस्टिमेट नहीं देता, बल्कि पूरा अनिश्चितता वितरण देता है, ताकि आपको एक आत्मविश्वासी अकेली संख्या के बजाय ईमानदार एरर बार्स वाला फ़ोरकास्ट मिले।

अपने मानसिक मॉडल के लिए एक आर्किटेक्चरल डिटेल उधार लेने लायक है: Timestral वह तरीका इस्तेमाल करता है जिसे Mistral decoupled horizon forecasting कहता है। पहले के causal decoders, जैसे TimesFM, उन वैल्यूज़ को मास्क कर देते थे जिनका फ़ोरकास्ट करना होता है। यह सरल है, पर बर्बाद करने वाला भी, क्योंकि मास्क्ड वैल्यूज़ कॉन्टेक्स्ट के रूप में अदृश्य हो जाती हैं, यानी हर फ़ोरकास्ट बाद के फ़ोरकास्ट के इनपुट को कमज़ोर करता है। Timestral पूरा इतिहास सीक्वेंस में रखता है और सीखे हुए फ़ोरकास्ट टोकन जोड़ता है जो उस इतिहास को पढ़ते हैं। हर देखी गई वैल्यू एक साथ ट्रेनिंग टार्गेट और कॉन्टेक्स्ट दोनों का काम करती है। यह ऐसा छोटा स्ट्रक्चरल सुधार है जो सुनने में बड़ा नहीं लगता, पर बड़े पैमाने पर बहुत मायने रखता है।

ज़ीरो-शॉट फ़ोरकास्टिंग: यह आपकी पर-सीरीज़ पाइपलाइन को क्यों हराता है

TSFM के पक्ष में सबसे मज़बूत दलील बेंचमार्क लीडरबोर्ड नहीं है, बल्कि असली फ़ोरकास्टिंग काम का आकार है। लगभग कोई भी एक ही सीरीज़ का फ़ोरकास्ट नहीं करता। आप दस हज़ार का करते हैं। एक रिटेलर हर SKU और हर स्टोर के लिए डिमांड का फ़ोरकास्ट करता है। एक प्लेटफ़ॉर्म टीम हर सर्विस और हर रीजन के लिए लेटेंसी का फ़ोरकास्ट करती है। एक औद्योगिक प्लांट में सैकड़ों एसेट्स पर हज़ारों सेंसर होते हैं। क्लासिक विकल्प सभी खराब हैं: हर सीरीज़ पर अलग ARIMA फ़िट करो और देखो कि उनमें से ज़्यादातर फ़ेल होते हैं क्योंकि हर सीरीज़ का इतिहास बहुत पतला है, या एक ग्लोबल gradient-boosted मॉडल ट्रेन करो और फ़ीचर इंजीनियरिंग व सीरीज़ के बीच स्केल के बेमेल में डूब जाओ।

TSFM इस दुविधा को सीधे किनारे कर देता है। एक चेकपॉइंट, हर सीरीज़ के लिए अलग फ़िटिंग नहीं, और क्रॉस-सीरीज़ ज्ञान प्री-ट्रेनिंग से ही भीतर बैठा होता है, न कि सिर्फ़ आपके डेटा से खोजा जाना पड़ता है। इसी वजह से जो प्रैक्टिशनर वाक़ई बड़े पैमाने पर फ़ोरकास्टिंग चलाते हैं, वे इन मॉडलों के सबसे कम संदेही होते हैं। उनका विकल्प कोई खूबसूरत, हाथ से ट्यून किया मॉडल नहीं है, बल्कि AutoARIMA जॉब्स का एक ढेर है जो घंटों लेता है और उन 5% अजीब सीरीज़ पर चुपचाप टूट जाता है जो सबसे ज़्यादा मायने रखती हैं।

दक्षता वाली बात मुझे सबसे ज़्यादा चौंकाने वाली लगी। Timestral का सबसे बड़ा मॉडल 209M पैरामीटर का है, जो LLM मानकों से बहुत छोटा है, और इनफ़रेंस के लिए उसे GPU की ज़रूरत नहीं पड़ती। एक सामान्य 8-थ्रेड सर्वर CPU पर, 15-मिनट के डेटा के तीन हफ़्तों से एक दिन आगे का फ़ोरकास्ट 5M मॉडल से 10 ms में और 209M से 140 ms में होता है। 123M मॉडल बड़े मॉडल के बेंचमार्क स्कोर के 0.2% के भीतर है, और लेटेंसी उसकी तीन-चौथाई है। यह वही चीज़ है जो लैंग्वेज मॉडल्स में भी हुई है, जहाँ दिलचस्प गतिविधि छोटे, तेज़ टियर्स की ओर खिसक गई है, वही डायनामिक जिसे मैंने flash-tier LLMs पर अपने लेख में कवर किया था: सुर्खियाँ फ़्रंटियर मॉडल बटोरता है, पर बिज़नेस को छोटा और कुशल मॉडल चलाता है।

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

कोवेरिएट्स असली फ़ीचर हैं, और असली पेच भी

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

Timestral का जवाब है covariate-aware attention, और इसका डिज़ाइन सुनने से ज़्यादा सिद्धांत-आधारित है। हर इनपुट सीरीज़ को एक भूमिका मिलती है: टार्गेट, केवल-अतीत कोवेरिएट, या ज्ञात-भविष्य कोवेरिएट। ज्ञात-भविष्य कोवेरिएट, जैसे प्रोडक्शन शेड्यूल, प्लांड शटडाउन और मौसम पूर्वानुमान, पूरी विंडो में दिखाई देते हैं, जबकि टार्गेट causal रहते हैं, और जानकारी सिर्फ़ कोवेरिएट्स से टार्गेट की ओर बहती है। आख़िरी बाधा ही सबसे अहम है: इसका मतलब है कि मॉडल अगले हफ़्ते के निर्धारित लोड बढ़ोतरी पर कंडीशन कर सकता है, बिना टार्गेट के अपने भविष्य को प्रेडिक्शन में लीक किए। कोवेरिएट्स के ज़रिए डेटा लीकेज फ़ोरकास्टिंग सिस्टम्स की सबसे क्लासिक चुप्पी वाली विफलताओं में से एक है, और अटेंशन मास्क में सूचना के प्रवाह की दिशा को ही बाँध देना इसे रोकने का साफ़ तरीका है।

कैटेगोरिकल कोवेरिएट्स को भी उचित व्यवहार मिलता है। मशीन की स्थिति, जैसे running, idle या under maintenance, को कैटेगरी के रूप में दिया जाता है, न कि किसी मनमाने इंटीजर में ठूँस दिया जाता है जो नकली क्रम थोप दे। जिसने भी किसी ट्री मॉडल को यह सीखते देखा हो कि "state 3" किसी तरह "state 2" से बड़ा है, वह इसकी कद्र करेगा।

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

बेंचमार्क, और अपने ही सिग्नल पर परखने की ज़रूरत क्यों

तीन मुख्य सार्वजनिक बेंचमार्क, GIFT-Eval, TIME और fev-bench, पर Timestral का 209M मॉडल, एक ही चेकपॉइंट और बिना एन्सेम्बलिंग के, प्री-ट्रेन्ड ज़ीरो-शॉट मॉडलों में पहले स्थान पर है। 28M मॉडल की रिपोर्ट के अनुसार Chronos-2 को हराता है, जो लगभग चार गुना बड़ा है। ये सच में मज़बूत नतीजे हैं, और परिवार के हर आकार का accuracy-versus-size Pareto front पर होना बताता है कि काम सिर्फ़ स्केल नहीं, बल्कि रेसिपी कर रही है।

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

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

शोर वाले डेटा पर हर मॉडल एक जैसा दिखता है। मॉडल तभी अलग होते हैं जब पकड़ने लायक असली सिग्नल होता है, इसलिए परीक्षण वहीं करें जहाँ सिग्नल है।

जहाँ क्लासिकल तरीके अब भी जीतते हैं

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

• आपको समीकरण चाहिए, सिर्फ़ आउटपुट नहीं। अगर आप ग्रिड ऑपरेटर या कंट्रोल इंजीनियर हैं, तो अक्सर आपको एक इंटरप्रेटेबल डायनामिकल मॉडल चाहिए, ऐसे पैरामीटर जिनका भौतिक अर्थ हो, जिन पर आप तर्क कर सकें, जिन्हें स्ट्रेस-टेस्ट कर सकें, और जिन्हें रेगुलेटर को दिखा सकें। TSFM एक ब्लैक बॉक्स है: y = F(x, params), कोई पढ़ने योग्य संरचना नहीं। फ़िट किया गया state-space या SINDy-शैली मॉडल आपको वह चीज़ देता है जो कोई न्यूरल नेट कभी नहीं देगा।
• आपके पास एक महत्वपूर्ण सीरीज़ है, जिसका इतिहास लंबा और समृद्ध है और डोमेन संरचना मज़बूत है। एक अच्छी तरह समझी गई सीरीज़, जैसे दशकों के डेटा वाला राष्ट्रीय बिजली लोड, डोमेन ज्ञान से बने खास मॉडल का हक़दार है। जब आपके पास सिर्फ़ एक समस्या हो और उसमें गहरी विशेषज्ञता हो, तो ज़ीरो-शॉट जनरलिटी बेकार जाती है।
• आपके कोवेरिएट्स हावी हैं और रिश्ते स्थिर व ज्ञात हैं। सही फ़ीचर्स पर एक लीनियर रिग्रेशन पारदर्शी, डीबग करने योग्य है, और जब समस्या की भौतिकी सच में लीनियर हो, तो उसे हराना मुश्किल है। बिना फ़ायदे के जटिलता का बोझ मत उठाइए।
• आपको डिपेंडेंसी पर पूरा नियंत्रण चाहिए। Timestral एक संशोधित MIT लाइसेंस के तहत आता है जिसमें कुछ प्रतिबंध हैं, और अगर आपका फ़ोरकास्टिंग महत्वपूर्ण इन्फ़्रास्ट्रक्चर है, जैसे डे-अहेड ऊर्जा बाज़ार, तो विक्रेता के सर्वर या ऐसे लाइसेंस पर निर्भर होने से पहले गंभीरता से सोचना होगा जिसे आप पूरी तरह नियंत्रित न कर सकें। इसी स्थिति के लिए ओपन-वेट विकल्प और इन-हाउस मॉडल मौजूद हैं।
• आपके बैकटेस्टिंग के सख्त नियम हैं। प्री-ट्रेन्ड मॉडल के साथ आप कभी पूरी तरह निश्चित नहीं हो सकते कि आपकी बैकटेस्ट अवधि ट्रेनिंग कॉर्पस में नहीं थी, जब तक विक्रेता आपको ट्रेनिंग मिक्स पर नियंत्रण न दे। Mistral यह अपनी Forge पाइपलाइन के ज़रिए देता है, लेकिन मान लेने के बजाय इसकी जाँच करें।

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

वह आर्किटेक्चर सवाल जिसे सब छोड़ देते हैं

TSFM लहर ने एक बात तय की है जिस पर और ध्यान मिलना चाहिए: ट्रांसफ़ॉर्मर निरंतर सिग्नल्स पर अच्छा काम करते हैं, और टोकनाइज़ेशन की समस्या उम्मीद से कम डरावनी निकली। इसकी ट्रिक patching है। हर टाइम स्टेप को टोकन मानने के बजाय (जिससे सीक्वेंस की लंबाई विस्फोटक हो जाती है) या कच्चे फ़्लोट्स को भोलेपन से एम्बेड करने के बजाय, आप सीरीज़ को patches में बाँटकर उन्हें एम्बेड करते हैं। Patch की लंबाई एक ट्यून करने योग्य नॉब बन जाती है, जो रिज़ोल्यूशन और कॉन्टेक्स्ट के बीच व्यापार करती है, ठीक वैसे ही जैसे LLM में vocabulary size। अगर आपने state-space models बनाम transformers की बहस को फ़ॉलो किया है, तो ध्यान देने वाली बात यह है कि अब तक के जीतने वाले TSFM ज़्यादातर attention-आधारित हैं। इनपुट रिप्रेज़ेंटेशन ठीक हो जाने पर टेम्पोरल डेटा की लंबी दूरी की संरचना attention के साथ अच्छी तरह मेल खाती दिखती है।

"सिंथेटिक-पहले" डेटा रणनीति को भी उतना ही श्रेय मिलना चाहिए। Timestral का ज़्यादातर ट्रेनिंग डेटा इकट्ठा नहीं, बल्कि जनरेट किया गया है: पहले सुसंगत डायनामिक्स वाले univariate प्रोसेस, फिर एक multivariate synthesizer जो उनके बीच नॉनलिनियर डिपेंडेंसी जोड़ता है। इससे टाइम-सीरीज़ ML को परेशान करती आई डेटा समस्या साफ़ तरीके से टल जाती है। सेंसर डेटा का कोई Common Crawl नहीं है, और जो मौजूद है वह बिखरा हुआ, मालिकाना और असंगत फ़ॉर्मेट में है। अगर सही inductive biases वाला सिंथेटिक डेटा इतना अच्छा ट्रांसफ़र होता है, तो यह पूरे सबफ़ील्ड की अर्थव्यवस्था बदल देता है। आपको दुनिया की टेलीमेट्री जमा करने की ज़रूरत नहीं; आपको अच्छे जनरेटर चाहिए।

फ़ोरकास्ट से सिस्टम तक

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

उसके ऊपर एक LLM एजेंट लगा दीजिए, और आपको वही वर्कफ़्लो मिलता है जिसकी रूपरेखा Mistral ने दी है: संख्यात्मक मॉडल एक पंप पर एनोमली फ़्लैग करता है, एजेंट सिग्नल्स की तुलना पिछली विफलताओं के embeddings से करता है, मेंटेनेंस रिकॉर्ड और ऑपरेटर नोट्स पर root-cause विश्लेषण शुरू करता है, और प्लांट मैनेजर को सिर्फ़ एक सूखा अलर्ट नहीं, बल्कि सबूत के साथ निदान देता है। चाहे आप इस खास विज़न को खरीदें या न खरीदें, दिशा सही है। यह वही पैटर्न है जो हमने डिसीज़न मॉडल्स के लिए constrained decoding में देखा था: तेज़, विशेषज्ञ मॉडल को उस काम के लिए लूप में रखें जिसमें वह अच्छा है, और सामान्य मॉडल को उसके चारों ओर ऑर्केस्ट्रेशन करने दें।

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