データと特徴量

教師あり学習のモデルは、ラベル（正解）以上には賢くなれません。ラベルが揺れていれば、モデルも揺れます。データを集めるときは、量より先にラベルの質を確保します。

ラベル付けの指示と品質管理：

• 指示書（ガイドライン）を作る：判断の基準と、迷う例（境界の例）を具体的に書きます。「スパムとは何か」を人によって違うまま付けると、モデルは何を学べばよいか分かりません。
• 同じデータを複数人で付ける：一部（例：1割）を2〜3人で重ねて付け、一致率（カッパ係数など）を測ります。一致しないところは、指示書が曖昧な場所です。
• 正解が分かっている問題を混ぜる：作業者の品質を確かめ、低い人の分を見直します。
• バイアスに注意：作業者の思い込みや、特定の種類のデータだけ集めたことによる偏りは、そのままモデルに入ります。
• ラベルの代わりに行動を使う：クリック・購入・解約などの記録をラベルにできれば、人手が要りません。ただし「表示されなかったものはクリックされない」など、集め方による偏りがあります。

能動学習（active learning）：全部にラベルを付けるのではなく、モデルが一番迷っているデータ（確率が 0.5 付近など）を選んで人に付けてもらう方法です。すでに自信を持って当てられるデータにラベルを足しても学びは少ないので、同じ作業量でより効果が上がります。「学習 → 迷うデータを選ぶ → ラベル付け → 再学習」をくり返します。最近は、LLM に下書きのラベルを付けさせて人が確認・修正する方法もよく使われます。

前処理は、生のデータをモデルが扱える形に整える作業です。何をするかはモデルによって違い、勾配ブースティングならほとんど要らず、線形モデルやニューラルネットでは結果を大きく左右します。

前処理は、scikit-learn の Pipeline のようにモデルと1つにまとめて保存し、学習と推論で同じものを使います。別々に書くと、学習と推論でずれる原因になります。

都道府県・商品 ID・端末の種類のようなカテゴリの列は、そのままでは数として扱えないので変換します。種類の数（カーディナリティ）によって向く方法が違います。

学習データに無かった新しい種類（新商品）は、推論で必ず出てきます。「その他」に寄せる、平均の値を使う、など扱いを決めておき、テストでも新しい種類の割合を確かめます。

モデルは、学習のときと推論のときで、同じ意味の入力をもらう前提で作られています。ところが、学習用の特徴量はデータサイエンティストが SQL で、推論用はアプリのエンジニアが別の言語で、と別々に作ると、集計の期間や欠損の扱いが少しずつずれます。すると、オフラインの評価はよいのに本番では精度が出ない、ということが起きます（training-serving skew）。

特徴量ストアは、このずれを防ぎ、作った特徴量をチームで使い回すための仕組みです。

特徴量ストアは、特徴量（モデルの入力にする値。例：「直近7日の購入回数」）を、1つの定義から作り、学習と推論の両方に配る仕組みです。学習用には過去の大量のデータ（オフラインのストア。データウェアハウスなど）、推論用には最新の値をすぐ返す保存先（オンラインのストア。Redis などの KVS）を持ちます。製品としては Feast などのオープンソースや、各クラウドのサービスがあります。

小さなチームなら、最初から製品を入れる必要はありません。特徴量を作る SQL や関数を1か所にまとめ、学習と推論で共有するだけでも、多くのずれを防げます。

下の「ブラウザで試す」の図は推論 API の流れで、特徴量ストアの役割は「特徴量を取得」の手順にあたります。アプリからの依頼を受けた推論サーバーが、オンラインのストア（Redis など）から、学習時と同じ定義の特徴量を取ってから計算します。オフラインのストアや学習データを作る側は図には出てこないので、上の表と構成図で補ってください。

training-serving skew（学習と推論のずれ）：学習のときは Python と SQL で、推論のときはアプリのコードで特徴量を作り直すと、細かいところがずれます。たとえば「7日」に今日を含むか、欠損値を 0 にするか平均にするか、タイムゾーンが違う、などです。モデルは学習したときと違う入力を受け取り、エラーは出ないのに精度だけが落ちます。対策は次のとおりです。

• 特徴量の定義を1か所にまとめ、学習と推論で同じコード・同じ定義を使う（特徴量ストアの一番の役割）。
• 推論の時に使った特徴量をログに残し、それを次の学習に使う（ずれようがない）。
• 本番の特徴量の分布と、学習データの分布を定期的に比べる。

時点を正しく取る（point-in-time）：学習データを作るとき、各行の「予測した時点」で分かっていた値だけを結合する必要があります。3月1日の行に、今日時点の最新の「累計購入回数」を付けると未来の情報が混ざります（リーク）。特徴量ストアは、値ごとにいつの値かの時刻を持ち、「この時刻以前で最新の値」を結合する機能（point-in-time join）を持っています。自分で SQL を書く場合も同じ考え方で、時刻の条件を必ず付けます。

-- 各予測の行に、その時刻より前で最新の特徴量の値を付ける（考え方）
SELECT p.user_id, p.predicted_at, f.value
FROM predictions p
JOIN features f
  ON f.user_id = p.user_id
 AND f.updated_at = (SELECT MAX(f2.updated_at) FROM features f2
                     WHERE f2.user_id = p.user_id
                       AND f2.updated_at <= p.predicted_at);

表形式のデータの特徴量の多くは、SQL の集計で作れます。データは DB やデータウェアハウスにあるので、そこで集計してから取り出すほうが速く、定義も共有しやすくなります。大事なのは、基準日（予測する時点）より前のデータだけを使うことです。下の DB ラボで、同じ SQL を MariaDB・PostgreSQL・SQLite で試せます。

行をまとめずに、「同じユーザーのこれまでの注文の回数」「直前 3 回の平均」のような値を各行に付けられます。

SELECT id, ordered_at, total,
  -- この注文より前の注文の回数
  COUNT(*) OVER (PARTITION BY user_id ORDER BY ordered_at
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS past_orders,
  -- 直前 3 回の平均金額
  AVG(total) OVER (PARTITION BY user_id ORDER BY ordered_at
    ROWS BETWEEN 3 PRECEDING AND 1 PRECEDING) AS avg_last3
FROM orders
WHERE user_id = 7
ORDER BY ordered_at;

集計する範囲（フレーム）を … AND 1 PRECEDING で終わらせ、「今の行を含めない」ようにしているのがポイントです。

「6月1日の時点で、翌月に買うか」を予測するなら、特徴量は 6月1日より前の注文だけで作り、ラベルは 6月の注文から作ります。結合の条件に日付を入れるのが、リークを防ぐ基本の形です。

SELECT u.id AS user_id,
  COUNT(o.id) AS orders_before,
  COALESCE(SUM(o.total), 0) AS spent_before,
  CASE WHEN EXISTS (SELECT 1 FROM orders f
         WHERE f.user_id = u.id
           AND f.ordered_at >= '2025-06-01' AND f.ordered_at < '2025-07-01')
       THEN 1 ELSE 0 END AS bought_next_month
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id AND o.ordered_at < '2025-06-01'
GROUP BY u.id;

この SQL は、SQL での特徴量づくりの DB ラボ（MariaDB・PostgreSQL・SQLite）で試せます。

ランダムに分けると、実行するたびに分け方が変わって再現できません。ユーザー ID から計算した値で分けると、何度実行しても、データが増えても、同じユーザーは同じ側に入ります。下の例は、ID に大きな数を掛けて混ぜてから 10 で割った余りを使う、どの DB でも動く簡単な方法です（MD5 などのハッシュ関数を使う方法もありますが、関数の名前が DB によって違います）。

SELECT CASE WHEN (user_id * 2654435761) % 10 < 8 THEN 'train' ELSE 'test' END AS split,
  COUNT(DISTINCT user_id) AS users, COUNT(*) AS rows_
FROM orders
GROUP BY 1;

ユーザー単位で分けるので、同じユーザーが学習と評価の両方に入るリークも防げます。時間で変わる問題では、これに加えて時間でも分けます。

この SQL は、SQL での特徴量づくりの DB ラボ（MariaDB・PostgreSQL・SQLite）で試せます。