গাইড লিঙ্ক ক্যুইজ · কঠিন স্তর
অনলাইন এবং অফলাইন বৈশিষ্ট্য পরিবেশন Skew কুইজ
ফিচার-সার্ভিং স্কু, পয়েন্ট-ইন-টাইম লিকেজ, এবং ঐতিহাসিক প্রশিক্ষণের ডেটা এবং লাইভ অনুরোধের মধ্যে সতেজতা অমিল চিহ্নিত করার অনুশীলন করুন।
প্রশ্ন 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