Тест, свързан с ръководство · трудно Ниво
Тест за изкривяване на онлайн и офлайн обслужване на функции
Упражнявайте се в идентифицирането на несъответствията при показване на функции, изтичане в даден момент и свежест между исторически данни за обучение и заявки на живо.
Въпрос 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