代表的な面接トピック

データサイエンス面接:情報漏洩(リーケージ)なしで時系列予測モデルを検証するには?

データ難しい
Offer.cc 編集チーム公開日 更新日

質問

200都市における2年間の日次乗車需要データがあり、毎週再学習を行い、向こう7日間を予測します。情報漏洩のないオフライン検証をどのように設計し、ベースラインと比較した上で、本番リリース可能かどうかをどのように判断しますか?

質問と適用シナリオ

200都市における2年間の日次乗車需要データがあります。本番ジョブは毎週月曜日に再学習を行い、各都市の向こう7日間を予測します。特徴量には、過去の需要、曜日、祝日、天気予報、計画された価格プロモーションなどが含まれます。チームはランダムな学習・検証分割を提案しており、全体のMAPEが最も低いモデルを選択したいと考えています。

情報漏洩(リーケージ)のないオフライン検証を設計してください。データ分割、特徴量の利用可能性、ベースライン、評価指標、都市間の集計、モデル選定、リリース判定基準(ローンチゲート)を網羅してください。2年間、200都市、7日間、毎週の再学習という条件は面接用の前提条件であり、業界の標準値ではありません。

この質問は、データサイエンス、機械学習、時系列予測の職種に適用されます。その核心は、過去の各予測起点において「真に何が分かっていたか」を再現することにあるため、カテゴリーは data です。

面接官が見ているポイント

第一に、候補者が本番環境の予測プロセスを評価プロトコルへと正しく落とし込めるかどうかです。優れた回答では、モデルの議論に入る前に、予測起点、予測ホライズン、再学習の頻度、学習ウィンドウのポリシーを明確に定めます。「時系列順に分割する」だけでは不十分です。

第二に、候補者がデータ分割以外のリーケージを発見できるかどうかです。未来の情報は、データ全体を用いたスケーリング、起点をまたぐローリングウィンドウ、修正後データ、確定した実測天気、未承認のプロモーション、全日付で適合させたターゲットエンコーディングなどを通じて混入する可能性があります。

第三に、評価指標がビジネス上の意思決定に対応しているかどうかです。単一の集計値では、先のホライズンでの精度低下、需要の少ない都市での脆弱さ、持続的なバイアス、誤ってキャリブレーションされた予測区間などが見過ごされる可能性があります。優れた回答では、ホライズン別、都市セグメント別、時間フォールド別に結果を保持し、モデルの横にシンプルなベースラインを並べます。

第四に、候補者がハイパーパラメータチューニングと最終評価を明確に区別できるかどうかです。ローリング検証でモデルと閾値を選定し、選定に一切影響を与えていない最後の連続した期間で、選ばれたパイプラインの性能を評価します。モデルを変更しながらそのホールドアウトを繰り返し確認すると、それは単なる検証セットへと成り下がってしまいます。

回答前に確認すべき質問

  • 実際の予測起点はいつですか? 月曜日の06:00実行の場合、その時点のデータで凍結する必要があります。日次のローリング予測では起点が異なり、再学習コストも変わります。
  • 7日間の推移はダイレクト予測ですか、それとも1日ごとの再帰的予測ですか? この戦略によって特徴量生成が変わり、ホライズン1から7までを個別に評価する必要があります。
  • 起点時点で判明している将来の共変量はどれですか? カレンダー情報は通常既知です。天気予報は利用可能ですが、実測の天気は利用できません。承認および公開済みのプロモーションのみが対象となります。
  • 正解ラベルはいつ確定しますか? 乗車実績の確定に2日の遅延がある場合、学習には同等のギャップを設けるか、時点ごとのスナップショット(point-in-time snapshots)が必要です。
  • 過大予測と過小予測のコストは等しいですか? キャパシティプランニングでは、供給不足と余剰キャパシティのコストが非対称になる場合があり、MAE単体では表現しきれません。
  • すべての都市は均等に重要ですか? 都市ごとのマクロ平均はカバレッジを測定し、需要ボリュームによる重み付けは全体的な影響を測定します。どちらか一方で代用することはできません。
  • 本番環境ではどれだけの過去データを使用しますか? 固定ウィンドウは構造変化に適応しやすい一方、安定した年次季節性を捉えるにはより長い履歴が必要になる場合があります。

30秒の回答フレームワーク

「本番環境から逆算し、ローリングオリジンによるバックテストを実行します。過去の各月曜日において、その時点で利用可能かつ確定しているデータのみを使用し、本番と同じ学習ウィンドウで学習し、向こう7日間を予測して前進させます。すべての変換、ラグ特徴量、チューニング決定は学習フォールド内でのみ適合させ、将来の実測天気を予報の代わりに使うことはしません。季節性ナイーブ(seasonal-naive)ベースラインと比較し、ホライズン1〜7別、都市別、時間フォールド別にMAE、バイアス、ビジネス損失をレポートします。パーセンテージ指標には明示的なゼロ処理を設けます。選定後は、手をつけていない最終ホールドアウト期間で一度だけ評価し、重要都市、ピーク週、区間カバレッジがあらかじめ定めた判定基準を満たした場合にのみリリースします。」

ステップごとの詳細解説

ステップ1:1回の本番実行を1つのバックテストフォールドとして扱う。

予測起点 t について、学習データには t 時点で利用可能かつラベルが確定しているレコードのみを含める必要があります。テスト区間は t+1 から t+7 です。起点を7日ずつ進めて週次再学習をシミュレートします。パイプラインが必要とする季節パターンを捉えるための十分な履歴がない初期の起点はスキップします。

拡大ウィンドウ(expanding window)は t までのすべての履歴を使用するため、データの有効活用につながる一方で古いレジームを引きずります。固定ウィンドウ(fixed window)はより速く適応しますが、年次季節性を破棄してしまう可能性があります。バックテストは意図した本番ポリシーを正確に再現しなければなりません。最終ホールドアウトの結果を見てからポリシーを選択すると、ホールドアウトが汚染されます。

ステップ2:特徴量利用可能性の規約を定義する。

各特徴量について、イベント発生日時、システム利用可能日時、データ修正ポリシー、欠損値の挙動を記録します。各起点で利用可能だったスナップショットを再構築します。

  • 1日前のラグは t 以前のものであり、7日間の移動平均が t をまたいではいけません。
  • スケーリング、補完、エンコーディング、特徴量選択、ターゲット変換は、そのフォールドの学習データのみで適合させます。
  • t 時点で公開されていた天気予報を使用し、その後に確定した実測天気は使用しません。
  • 将来のプロモーション特徴量には、t 時点で確定していた計画のみを含めます。
  • ラベルの確定に2日かかる場合は、学習期間を t-2 で終了するか、同等のギャップを設けます。

実行可能なチェックとして、学習データの全セルに対して available_at <= t を検証し、起点以降の生レコードをすべて削除した後に特徴量を再生成し、保存されたスナップショットから複数の起点について再現テストを行います。利用できない未来のデータを削除した際に過去の予測値が変化する場合、リーケージまたは再現不能な依存関係が存在することを示しています。

ステップ3:安易に上回れないベースラインを設定する。

最低限、前週の同じ曜日を使用する季節性ナイーブ予測と比較します。年次季節性が十分に安定している場合は、前年同期のベースラインも追加します。複雑なモデルがコストに見合うと認められるのは、同一の起点、利用可能特徴量、スコアリング対象行において一貫して勝利する場合のみです。不自然に大きな精度向上がある場合は、喜ぶ前に時間の整合性とリーケージの監査を行うべきです。

ステップ4:指標をビジネス損失のコストに対応させる。

一般的な絶対誤差にはMAE、大きな外れ値を検出するにはRMSE、持続的な過大・過小予測を明らかにするには符号付き平均誤差を使用します。MAPEは0で未定義となり、0付近で不安定になるため、単一の指標とすることはできません。スケールの異なる比較には、学習フォールドから計算された季節性ナイーブ誤差で正規化したMASEを使用できます。WAPEは全体計画に役立ちますが、取扱量の多い都市の影響を強く受けます。

分位点(quantile)予測の場合は、各分位点をピンボール損失(pinball loss)で評価し、実績のカバレッジをP90などの意図した水準と比較します。カバレッジは区間幅とセットで評価する必要があります。区間幅が極端に広い場合、カバレッジは良好でもキャパシティの意思決定には役に立ちません。

ステップ5:集約前に誤差の構造を保持する。

スコアリングされたすべての行に originhorizoncity、実績値、予測値を保持し、以下を報告します。

  1. 直近の精度が先のホライズンでの精度崩壊を隠さないよう、ホライズン1から7を個別に報告する。
  2. 都市ごとのマクロ平均と、ボリュームによる重み付け結果の両方を報告する。
  3. 平均値だけでなく、時間フォールドにわたる分布を報告する。
  4. ピーク期間、祝日、小規模都市、新規都市、異常気象の期間を個別に報告する。
  5. 都市内で同じ方向へのバイアスが連続していないかを報告する。

ステップ6:ローリングフォールド内で選定し、最終テストを確定する。

モデル、ウィンドウサイズ、ハイパーパラメータの選定には開発用のローリングフォールドを使用します。比較回数が多い場合は実験履歴を記録し、繰り返しの試行によって少数のフォールドのノイズに過学習しないようにします。パイプライン全体を確定(freeze)させた後、最終の連続する8〜12週間で一度だけ評価します。この期間も面接上の前提であり、季節性やサンプルサイズ要件に応じて調整すべきです。

リリース判定基準を事前に設定します。全体のビジネス損失が季節性ナイーブを上回ること、重要都市が許容性能低下の閾値を超えないこと、ホライズン7が許容範囲内であること、バイアスがキャパシティ許容値内に収まること、予測区間のカバレッジと幅が基準を満たすことなどです。平均で勝っていても重要な判定基準に落ちた場合は、全体ローンチを行わず、合格した都市のみにカナリアリリースするか、ベースラインを維持します。

ステップ7:プロトコルを本番監視に拡張する。

モデルバージョン、データスナップショット、予測起点、ホライズン別予測、特徴量バージョンをログに記録します。ラベルが確定したら同じ指標をバックフィルし、バックテスト時の分布と比較します。データの利用可能性、欠損率、符号付きバイアス、ホライズン別誤差、ベースラインとの差分を監視します。レジームシフト(構造変化)が発生した場合は、頻繁な再学習だけで解決すると過信せず、学習ウィンドウのポリシーを再評価します。

質の高い模範解答

「過去の一連の起点において、本番の1回の実行を再現します。ジョブが月曜日の06:00に再学習し、7日分を一度に出力する場合、各フォールドはその時点でラベルが確定し利用可能なデータのみを参照し、本番と同じウィンドウで学習し、続く7日間を予測します。ラベルの確定に2日かかる場合、学習は起点の2日前に終了させます。天気は当時利用可能だった予報バージョンを使用し、確定した実測値は決して使用しません。

すべての変換処理はフォールド内で実行します。スケーラー、補完器、エンコーダー、特徴量選択は学習行のみで適合させ、ラグや移動平均は起点より先を含まないようにします。また、起点以降の生データを削除して特徴量を再生成し、過去の予測値が変わらないことを検証します。

最初の比較対象は、前週の同じ曜日を用いた季節性ナイーブ予測です。都市別、起点別、ホライズン別に結果を保持し、MAE、RMSE、符号付きバイアス、ビジネスコストを報告します。都市の集計には均等重み付けとボリューム重み付けの両方を適用します。MAPEはゼロ値で破綻するため、単独では使用しません。分位点予測には、ピンボール損失、ホライズン別カバレッジ、区間幅を追加します。

パイプラインの選定にはローリングフォールドを用い、最終的な連続期間は一度だけ評価に使用します。ローンチゲートはそのテスト前に固定します。全体でベースラインを上回ること、重要都市で許容できない性能低下がないこと、ホライズン7およびピーク週で合格すること、バイアスと区間キャリブレーションの要件を満たすことです。本番環境では起点とデータバージョンをログに記録し、ラベル確定後に同じ切り口で再現できるようにします。これにより、オフラインでの改善効果が実際に運用するシステムと正しく対応するようになります。」

よくある間違い

  • 日付をランダムにシャッフルする → 学習データがテスト日以降のメカニズムや特徴量統計を見てしまう → 本番の実行を再現するローリングオリジンを使用する。
  • 全データセットで特徴量生成とスケーリングを行う → 検証データが学習データに混入する → すべての変換をフォールドごとに適合させ、利用可能時間に基づいて特徴量を再現する。
  • 天気予報を確定した実測天気に置き換える → オフライン評価が本番では得られない情報を持ってしまう → 各時点で利用可能だった予報バージョンを保存して使用する。
  • 単一の集計MAPEのみを報告する → ゼロ値、小規模都市、遠いホライズンの問題が誤処理されるか隠蔽される → 絶対誤差、バイアス、ビジネス損失、セグメント別結果を組み合わせる。
  • 季節性ナイーブベースラインを省略する → モデルの複雑さに対する信頼性の高い増分ベンチマークが存在しない → 同一のフォールドおよびデータ行でベースラインを評価する。
  • 最終テスト結果を見てからモデルを変更する → ホールドアウトが選定プロセスに関与してしまう → 一度確定させ、失敗した場合は将来の新たなホールドアウトを待つ。
  • 平均で勝っているという理由だけで全体ローンチする → 高需要都市の結果が重要なサブグループの精度低下を覆い隠してしまう → サブグループ、ピーク、ホライズンごとのゲートを事前定義し、都市ごとにカナリアリリースを行う。

フォローアップ質問と回答

学習データに一度も登場したことがない都市をどのように評価しますか?

通常のローリングフォールドでは学習とテストに同じ都市が含まれるため、コールドスタートを評価できません。都市ホールドアウト(city-held-out)評価を追加します。共有モデルの学習時に一部の都市グループを完全に除外し、ローンチ時に真に利用可能な静的属性や短い履歴のみを使用します。履歴ゼロと短い履歴のケースを、地域ベースおよびグローバルベースのナイーブベースラインと個別に比較して報告します。

プロモーション期間が14日間で予測ホライズンが7日間の場合、ギャップは必要ですか?

ギャップは予測ホライズンの長さではなく、情報の利用可能性とラベルの重複に基づいて判断します。学習ラベルや集計値が起点から14日後までの結果を消費している場合は、切り詰めるか十分な分離間隔を設ける必要があります。プロモーション計画が起点前に確定しており、特徴量にその計画のみが含まれている場合は、14日間の期間自体がリーケージを引き起こすわけではありません。各フィールドについてタイムラインを描いて確認します。

新しいモデルが高需要都市でのみ改善した場合はどうしますか?

均等重み付けによる精度の変化と並べてボリューム重み付けの利益を示し、ビジネス要件を判定ゲートに変換します。高需要都市にのみ新モデルを導入し、その他の都市ではベースラインや階層型モデルを維持するという判断も妥当です。単一の加重平均だけでは、すべての都市が利益を得ている証明にはなりません。

オンラインの誤差がバックテストより大幅に悪化しています。最初に何を調査しますか?

まずは再現性から着手します。同一のモデル、予測起点、特徴量スナップショット、外生変数のバージョンを用いて予測を再構築できるか確認します。その上で、データの遅延や定義の変更、学習と推論時の変換の不一致(training-serving skew)、ベースラインも同様に悪化させているレジームシフト、モデル特有のドリフトを切り分けます。再学習、ウィンドウ短縮、ロールバック、新しい検証設計の選択を行う前に、プロトコルの不一致箇所を特定します。

公開情報ソース

関連する質問