गाइड से जुड़ी प्रश्नोत्तरी · कठिन स्तर
ऑनलाइन और ऑफलाइन फ़ीचर सर्विंग स्क्यू क्विज़
ऐतिहासिक प्रशिक्षण डेटा और लाइव अनुरोधों के बीच फीचर-सर्विंग तिरछा, पॉइंट-इन-टाइम लीकेज और ताजगी बेमेल की पहचान करने का अभ्यास करें।
प्रश्न 1 का 8
ट्रेनिंग/सर्विंग स्क्यू क्या है?
प्रत्येक प्रश्न का पूर्वावलोकन करें8 प्रश्न
जैसे ही आप प्रश्नोत्तरी लेते हैं उत्तर और स्पष्टीकरण दिखाई देते हैं।
- ट्रेनिंग/सर्विंग स्क्यू क्या है?
- जब किसी मॉडल को GPU पर प्रशिक्षित किया जाता है लेकिन उसे CPU पर परोसा जाता है
- जब कोई मॉडल मेमोरी में फिट होने के लिए बहुत बड़ा हो
- जब प्रशिक्षण के दौरान ऑफ़लाइन गणना की गई सुविधाएँ उत्पादन में ऑनलाइन परोसी गई सुविधाओं से भिन्न होती हैं
- जब प्रशिक्षण में अपेक्षा से अधिक समय लगता है
- When building a historical training row, which feature timestamps should a point-in-time join allow?
- Values available at or before that row’s prediction time
- Values recorded only after the outcome
- The latest values regardless of historical time
- Only values from the next calendar month
- निम्नलिखित में से कौन-सा ऑफ़लाइन सटीकता में वृद्धि का एक क्लासिक कारण है जो उत्पादन में गिरावट का कारण बनता है?
- बहुत कम प्रशिक्षण उदाहरणों का उपयोग करना
- सेवा देने की तुलना में तेज़ मशीन पर प्रशिक्षण
- डेटाबेस में सुविधाओं को संग्रहीत करना
- डेटा रिसाव, जहां प्रशिक्षण पूर्वानुमान के समय उपलब्ध नहीं होने वाली जानकारी का उपयोग करता है
- A logged live feature distribution differs from training. What should the feature-serving team infer first?
- The serving code is certainly defective
- There is a mismatch to investigate; it may be drift or serving skew
- The feature has no predictive value
- The model must be running on different hardware
- 'अंतिम घंटे में ऑर्डर' जैसी कैश्ड ऑनलाइन सुविधा एक विषम जोखिम क्यों है?
- कैश्ड मान पुराना हो सकता है और प्रशिक्षण में उपयोग किए गए ताज़ा गणना किए गए मान से मेल नहीं खा सकता है
- कैशिंग हमेशा मॉडल सटीकता में सुधार करती है
- कैशिंग से सुविधा की ऑफ़लाइन गणना करना असंभव हो जाता है
- कैश्ड विशेषताएँ संख्यात्मक नहीं हो सकतीं
- Why share one feature definition across batch training and online serving?
- To guarantee every cached value is fresh
- To eliminate changes in incoming populations
- To make timestamp checks unnecessary
- To reduce differences caused by separate transformation implementations
- A transaction model uses a chargeback flag recorded days after purchase. Why is its offline feature join invalid?
- The flag is categorical rather than numerical
- The flag was unavailable when the purchase prediction was made
- Chargeback flags cannot be stored historically
- Only GPU models may use transaction features
- Training recomputes a one-hour order count, but serving reads a ten-minute-old cached count. Which check targets this skew?
- Increase the number of model parameters
- Remove all timestamps from the feature store
- Compare counts for matching entities and times while recording cache freshness
- Switch both paths to a different programming language