किसी मॉडल के लिए batch scoring और real time inference के बीच आप कैसे तय करते हैं?

freshness और request की बनावट से तय कीजिए। अगर features और आबादी पहले से पता हों और predictions घंटों तक वैध रहती हों, तो batch में पहले से गणना कर लीजिए और lookup table से serve कीजिए, जो सरल, सस्ता और कहीं ज्यादा भरोसेमंद है। real time तब चुनिए जब features मौजूदा request पर निर्भर हों, entity सेट की कोई सीमा न हो, या बासीपन फैसले को सचमुच नुकसान पहुंचाता हो।

मैं दो सवालों से शुरू करता हूं: prediction कितनी बासी हो सकती है, और क्या मुझे पहले से पता है कि मैं किसे score कर रहा हूं। मौजूदा ग्राहकों पर हफ्तेवार churn score जैसी किसी चीज में दोनों जवाब batch के पक्ष में हैं। मैं एक nightly job चलाता हूं, scores एक table में लिखता हूं, और serving एक primary key lookup बन जाती है जो लगभग फेल हो ही नहीं सकती। request वाले रास्ते पर कोई accelerator नहीं, कोई cold start नहीं, और अगर job टूटे तो भी कल के scores मेरे पास हैं, जो timeout से कहीं नरम नाकामी है। real time तब अपनी जगह कमाती है जब features खुद request से आते हों, जैसे यूजर ने अभी क्या टाइप किया या उसकी cart में अभी क्या है, या जब entity अभी मौजूद ही न हो, जैसे बिल्कुल नया session। मैंने जो ज्यादातर सिस्टम बनाए वे hybrid ही निकले: भारी aggregates batch में निकालकर cache किए, request के वक्त गिनी चुनी live signals के साथ join किए, फिर score किया। इससे online रास्ता सस्ता रहता है और सिस्टम अभी अभी हुई बात पर भी प्रतिक्रिया देता है। जो गलती मैं टालने की कोशिश करता हूं वह है सिर्फ बेहतर दिखने वाले आर्किटेक्चर डायग्राम के लिए real time चुन लेना, जबकि नीचे कोई उस freshness का इस्तेमाल ही नहीं करता।