ガイド連動クイズ · ハード レベル

オンラインとオフラインの機能提供の偏りに関するクイズ

機能提供のスキュー、ポイントインタイムの漏洩、および履歴トレーニング データと実際のリクエストの間の鮮度の不一致を特定する練習をします。

質問 1 の 8

トレーニング/サービスのスキューとは何ですか?

すべての質問をプレビューする8 質問

クイズに答えると、答えと解説が表示されます。

  1. トレーニング/サービスのスキューとは何ですか?
    • モデルが GPU でトレーニングされているが、CPU で提供される場合
    • モデルが大きすぎてメモリに収まらない場合
    • トレーニング中にオフラインで計算された特徴が、本番環境でオンラインで提供される特徴と異なる場合
    • トレーニングに予想以上に時間がかかる場合
  2. 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
  3. 実稼働環境で崩壊するオフライン精度の膨張の典型的な原因は次のうちどれですか?
    • トレーニング例の使用が少なすぎます
    • サービングよりも速いマシンでトレーニングする
    • フィーチャをデータベースに保存する
    • データ漏洩。トレーニングでは、予測時には利用できない情報が使用されます。
  4. 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
  5. 「過去 1 時間の注文」などのキャッシュされたオンライン機能がスキュー リスクになるのはなぜですか?
    • キャッシュされた値は古くなり、トレーニングで使用された新たに計算された値と一致しなくなる可能性があります
    • キャッシュによりモデルの精度が常に向上します
    • キャッシュにより、オフラインでの特徴の計算が不可能になります
    • キャッシュされたフィーチャを数値にすることはできません
  6. 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
  7. 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
  8. 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