教師データのためのログ設計

# 教師データのためのログ設計 ## 定義教師データのためのログ設計とは、機械学習の教師データが最終的にはシステムのログ(Webサーバーのアプリケーションログ、ユーザーの行動ログなど)から作られるという前提のもと、DBのデータと違ってスキーマを持たず記録し損ねた情報を事後に取得できないログの特性を踏まえて、サービス設計の段階からあらかじめ何をログに残すかを検討しておく取り組みである。『仕事ではじめる機械学習』第4章は、特徴量や教師データに使える情報を「ユーザー情報」「コンテンツ情報」「ユーザー行動ログ」の3種に大別し、特にユーザー行動ログはコンバージョンに繋がる情報を含みやすく教師データになりやすいため、収集の設計を丁寧に行うべきだとする。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 4 システムに機械学習を組み込む]] §4.3.1) ログの保持先としては分散RDBMS/データウェアハウス、Hadoop の HDFS、クラウドオブジェクトストレージの3種が挙げられ、いずれの場合もSQLで前処理なしにデータへアクセスできるようにしておくことが共通して推奨される。特徴量エンジニアリングは試行錯誤が前提であり、ログにない情報を後から作る工夫をするより、あらかじめログに仕込んでおくほうが簡単である。(Source: 同 §4.3.2, §4.3.3) ログ設計で失敗しやすい典型例として、(1) 表示されたがクリックされなかったといった「ネガティブなデータ」の破棄、(2) マスタデータの変更履歴の欠落、(3) サービスの機能追加・仕様変更によるログ形式の変化、の3つが挙げられる。(1)(2)はいずれも、システム開発・運用をする人と分析をする人が分かれている場合に起こりやすい。(3)への対処は、古い特徴量のモデルを使い続ける・過去分をバックフィルして新しい特徴量のモデルに切り替える・両者をアンサンブルする、の3択があり、精度面ではアンサンブルが有利だが管理する複雑性が増す。(Source: 同 §4.3.3) ## 広告配信ログに固有の4つの困難(12章) 第12章(オンライン広告における機械学習)は、CTR予測([[CTR予測]])の学習データである広告配信ログに固有の、4章とは異なる種類の困難を4点扱う。 - **フィードバックループ**: オンライン広告は配信後に観測したレスポンス実績が目的変数となるためアノテーションが不要な一方、得られる学習データはシステムが実際に選んだアクション(広告)に対するレスポンスに限られる。選んだ回数の多い広告のデータほど多く、逆は少なくなり、オークションの勝ちやすさ・負けやすさによっても偏りが生じる。この設定で生成されるデータはLogged Bandit Feedbackと呼ばれ、対処には出現頻度を傾向スコアとして使う学習時のバイアス補正、または選択回数が少なすぎるアクションを意図的に選ぶ探索方策が使われる。(§12.4.1、詳細は[[多腕バンディット]]を参照) - **不均衡データ**: バナー広告のクリックは非常に稀な事象で、正例が1%に満たないことが多い。このまま学習に使うとモデルの性能が悪化するため、正例と負例の数が同じになるまで負例をサンプリングして減らすNegative Down Samplingが使われる。前処理・訓練の計算コストを大幅に削減できる利点がある(数億レコード→100万件程度まで減らせば1台のマシンで訓練できる)一方、モデルの出力確率 $p$ はダウンサンプリング後の分布に基づくため、ダウンサンプリング率の逆数 $r^{-1}$ を用いて $p_{calib} = \dfrac{p}{p + (1-p)r^{-1}}$ という式で元の確率にキャリブレーションし直す必要がある。(§12.4.2) - **カーディナリティの大きなカテゴリ変数**: site domain・device modelなど、出現する値のパターンが数千〜数万にもなるカテゴリ変数が学習データの大半を占める。One-Hot Encoding+L1正則化というナイーブな手段は、出現回数の少ないカテゴリ値の推定パラメータの分散が大きくなる問題と、前処理後の次元数がカーディナリティ分だけ増える問題を抱える。代わりに、予測タスクを学習する際にニューラルネットでカテゴリ変数の埋め込み表現を学習するEntity Embeddingsが近年採用されており、学習した埋め込み表現はニューラルネット以外のアルゴリズムでも利用できるため、推論APIの制約でニューラルネットが使えない場合にも役立つ。(§12.4.3) - **打ち切りデータ**: 広告表示後に即座に結果が得られるクリックと異なり、コンバージョンは受け取るまで数日〜数週間かかることがある。この間、通知が届いていないレコードは「まだ結果が出ていない」のか「負例」なのか区別がつかない打ち切りデータとなる。これを考慮せず前処理をすると、通知が遅れているレコードをすべて負例として扱ってしまい予測が下にずれる。対処には、観測遅れ時間の分布から傾向スコアを求めてレコードごとにsample weight補正をする方法がある。(§12.4.4) ## 横断的知見 - 第5章(学習のためのリソースを収集する)は「教師データを作るのは誰か」という観点から、公開データセット活用・開発者自身の作成・同僚や友人への依頼・クラウドソーシング・サービスへの組み込みの5手段を扱う([[教師データ収集手段の選択]])。本ページが扱うログ設計は、この5手段のうち最初に挙がる「サービスのログ取得の仕組みからの完全自動抽出」という出力ラベル付与方式(第5章§5.1)の上流にあたる。良いログ設計をしておくほど自動抽出でまかなえる範囲が広がり、残りを開発者自身の作成やクラウドソーシングといった人手を介した手段に頼る割合を減らせるという関係になる。逆に、ログだけでは自動抽出できない出力(人の判断を要するカテゴリ分類など)は、第5章が扱う人手を介した収集手段が必要になる。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 4 システムに機械学習を組み込む]] §4.3, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 5 学習のためのリソースを収集する]] §5.1) - **4章が挙げる汎用的な失敗パターン(ネガティブデータの破棄・マスタ変更履歴の欠落・ログ形式の変化)は「ログ設計・運用の過失」に起因するのに対し、12章が挙げる広告配信ログ特有の4つの困難は、正しく設計・運用されたログでも構造的に避けられない**: 4章§4.3.3の3つの失敗例は、いずれも「本来記録すべきものを記録し損ねた」「開発と分析の担当が分かれていて連携が漏れた」という運用上の落とし穴であり、事前の設計・チェックで防止できる余地がある。これに対し12章§12.4が挙げるフィードバックループ・不均衡データ・高カーディナリティ・打ち切りデータの4点は、広告配信というドメインの構造そのもの(システムが選んだ広告にしかレスポンスが観測されない、クリックは稀にしか起きない、広告枠の属性の種類が膨大、コンバージョンの確定に時間差がある)に起因し、どれだけログ設計を丁寧に行っても発生する。両者を合わせると、教師データのためのログ設計という取り組みには「事前の設計で防げる失敗」と「ドメイン構造上避けられず統計的な補正が必要な困難」という2層があることが見える。前者は4章のチェックリスト的な注意で対処し、後者は12章のような傾向スコア補正・Negative Down Sampling+キャリブレーション・埋め込み表現・sample weight補正といった統計的な技法で対処する必要がある。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 4 システムに機械学習を組み込む]] §4.3.3, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]] §12.4) - **12章のフィードバックループは、4章の「ネガティブなデータの破棄」という失敗パターンの、統計的に不可避な形での再来である**: 4章はネガティブなデータ(表示されたがクリックされなかった等)を捨ててしまう運用上のミスを戒めるが、12章のフィードバックループはネガティブなデータそのものは残っていても、システムが選ばなかったアクション(広告)についてはポジティブ・ネガティブいずれのデータも原理的に存在しないという、より根の深い欠落を示す。前者はログ設計を直せば解決するが、後者は[[多腕バンディット]]が扱う探索の問題そのものであり、ログ設計だけでは解決できずシステムの行動方策(意図的な探索)にまで踏み込む必要がある。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 4 システムに機械学習を組み込む]] §4.3.3, [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]] §12.4.1) - **「ログからのラベル自動抽出」という第5章の第1の手段は、独立した別書『信頼性の高い機械学習』第4章でも同じ仕組みが別の語彙(データ取り込みシステム)で裏付けられる**: 『仕事ではじめる機械学習』第5章§5.1が「サービスのログ取得の仕組みからの完全自動抽出」を教師データ付与の最初の方式として挙げるのに対し、『信頼性の高い機械学習』第4章§4.1.3.1は、架空のオンライン小売店YarnItの商品推薦モデルを例に、提案ログと注文を結びつけられる限り「特徴量とラベルを同時に、データ取り込みシステムが生成できる」と述べ、この場合のラベルは人間が手で付けたラベルより一貫性・正確性が高いことが多いとする(同 §4.2)。異なる書籍・異なる架空の題材(前者は具体的なシステムを特定しない一般論、後者はYarnItという小売サイトの推薦システム)が独立に「ログを正しく設計・接続しておけば、人手を介さずラベルを取得できる」という同じ結論に至っている点は、本 concept の中心主張の裏付けとして重要である。ただし『信頼性の高い機械学習』はこのようなログ由来ラベルを「特徴量ストア」(([[特徴量ストア]]))という具体的な保存先まで踏み込んで位置づけており、ログ設計と保存基盤の接続という点で『仕事ではじめる機械学習』より一歩具体的である。(Source: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 5 学習のためのリソースを収集する]] §5.1, [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]] §4.1.3.1, §4.2) ## 未解決の問い - 第6章の継続的トレーニング(6.4.2「定期的なテスト」)は、ログ形式の変化(§4.3.3の選択肢3種: 旧モデル維持/バックフィル/アンサンブル)への対処をどう自動化・運用化するか。 - ネガティブなデータやマスタ変更履歴の欠落は「実際にあった例」として語られるが、これらを事前に防ぐためのログ設計チェックリストのようなものは本書の他章や外部ソースに存在するか。 - 12章の打ち切りデータ対処(観測遅れ時間の分布からの傾向スコア補正)は生存時間分析の手法群と重なるはずだが、本ソースは安井[20b]を参照するのみで具体的な推定手順には立ち入らない。この推定手順の詳細は他ソースでの補完が必要。 - 「事前に防げる失敗」(4章)と「ドメイン構造上避けられない困難」(12章)の2層という整理は本ページの解釈であり、両章とも明示的にこの2分類を述べているわけではない。この整理が他のドメイン(広告配信以外)のログ設計にも一般化できるかは未検証。 ## 関連 - ソース: [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 4 システムに機械学習を組み込む]] / [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 5 学習のためのリソースを収集する]] / [[@2021__OReillyJapan__仕事ではじめる機械学習 - Chapter 12 オンライン広告における機械学習]](広告配信ログ特有の4つの困難) / [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 4 特徴量と訓練データ]](データ取り込みシステムによるラベル自動生成) - 概念: [[機械学習システムの設計パターン]] / [[教師データ収集手段の選択]] / [[CTR予測]](広告配信ログを学習データに使うモデル) / [[多腕バンディット]](フィードバックループ=Logged Bandit Feedbackの理論的背景) / [[特徴量ストア]](ログから生成した特徴量・ラベルの保存先) - 実体: [[Apache Kafka]] / [[Apache Spark]] / [[YarnIt]] ## 出典 - 有賀康顕・中山心太・西林孝, 『仕事ではじめる機械学習第2版』, オライリー・ジャパン, 2021, 第4章 §4.3, 第12章 §12.4. - Cathy Chen ほか, 『信頼性の高い機械学習 ―SRE 原則を活用した MLOps』, オライリー・ジャパン, 2024, 4 章 §4.1.3.1, §4.2.