機械学習による実用アプリケーション構築② 第2章 計画の作成①
2章 計画の作成
MLと製品の進捗状況を追跡し、異なるMLの実装を比較するためのメトリクスについて説明 ベースラインを構築する方法を特定、モデリングの反復を計画
多くのMLプロジェクトでは製品メトリクスとモデルメトリクスが整合していなくて 初めから失敗に追い込まれていくの筆者は良く見てきた。
既存のリソースや問題の制約条件を活用して、実行可能な計画を構築するためのヒントを取り上げる。
2.1 成功度合いの測定
MLの場合、最初に構築するモデルは、製品の要求に対応できるもの中で最もシンプルなもの 結果を生成して、分析することがMLを進歩させる最も早い方法 多くの場合、ヒューリスティックなアプローチは特徴量を構築したり、MLに必要な要素を把握する際に 最も速い方法。ユーザのニーズの把握とか云々。 ほとんどの場合、MLを使わずに、始めることがML製品を構築する最も早い方法。
複数のアプローチがあった場合にどのアプローチがいいかを判断するためには共通のメトリクスが必要
- 製品メトリクス
- モデルメトリクス
- データの鮮度と分布の変化
- スピード
2.1.1 製品メトリクス
製品の目標に対して、その成功を判断するためのメトリクスを定義する必要がある。最も重要な指標。 他のすべてのメトリクスは製品メトリクスを改善するためのツールとして使う。
2.1.2 モデルメトリクス
製品が構築中でまだデプロイされていない場合は、製品メトリクスを測定することができない。 なので、進捗度合いを測るための別の指標が必要になる。 この指標は製品メトリクスや目標と高い相関がある必要がある。モデリングアプローチが異なれば使用するモデルメトリクスも異なる。 より製品メトリクスを向上させるためにモデリングアプローチ、メトリクスを変えることで早く目標が容易になる。
2.1.3 データの鮮度と分布の変化
初期のモデルパフォーマンスは重要だが、ユーザの行動が変化しても有用なモデルである必要がある。 ほとんどのモデルが学習データと同等のデータが入力されることを前提としており、 データが変化した場合にモデルも変化させないとパフォーマンスを維持することができなくなる。
案件によって、データの鮮度の重要性は変わる。 例えば古代語の翻訳案件はほとんどデータの比較的一定、検索エンジンはユーザの振舞いが頻繁に変わるので鮮度が重要になってくる
なので、各案件では、
- 再学習の頻度
- 学習にかかるコスト
- ビジネス上の問題に応じて、モデルを最新の状態に保つのか
を検討しておく必要がある
2.1.4 スピード
スピードを担保することでモデルは多くのユーザに同時に機能を提供できるようになる
求められるスピードはものによって変わる。 短い文書を翻訳するシステムではすぐに答えを得られることが求められる。 例えば、正確な診断をする医療診断システムの場合は、ある程度長時間かかっても問題がないかもしれない。
モデルの複雑さ（複雑になるほど処理時間のびる）や入力データの多さ、 システムのパフォーマンスの限界などはあらかじめ考えておく必要がある。
2.2 スコープと課題の推定
ＭＬのパフォーマンスは多くの場合モデルメトリクスで報告されるが、改善するためには製品メトリクスを念頭に置いて 進める必要がある。
2.1で説明した内容はそのプロジェクトが取り組む価値のあるプロジェクトかを判断したり、 現在の進捗を測るのに役立つ。
次はプロジェクトのスコープと期間を設定して、潜在的な障害を予測するための計画を概観するために、 問題の内容を良く理解する必要がある。
2.2.1 ドメインの専門知識を活用する
実用的なアプリケーションの大半は目新しいものは少ない。
- 解決しようとしている問題が現在どのように解決されているか → その分野の専門家から学ぶ
- データセットに基づいて手動で解決するとしたらどのように実行するか
を知ることがヒューリスティック
2.2.1.1 専門家から学ぶ
工場設備の予防保全システムを構築する場合、工場の管理者に連絡を取るなど。 類似した問題に相対している専門家が見つけられれば落とし穴が分かる。最も重要なのは、車輪の再発明を防ぐこと。
2.2.1.2 データの調査
モデリングをする前にデータを調査することは重要。 探索的データ分析（EDA）でデータの傾向を理解し、手動でラベリングを行うことで どのようなモデルがもっとも適しているのか、データ収集とラベル付けの戦略の明確なアイディアを持つことができるはず。
2.2.2 巨人の肩に立つ
だれかが既に同様の問題を解決しているのなら既存の結果を理解して再現するのがもっともはやい - 公開された類似のモデル - 類似データセット - その両方を使った実装 を探す。ただし、オープンソースの商用利用などの権利関係は確認する必要あり。
上記を使って説得力のあるPoCを実施する際に、どのようにすれば効率的に開始できるかを データとコードという二つの側面で考える
2.2.2.1 オープンデータ
必要なデータセットを直で見つけられるとは限らないが、 類似データセット（（必ずしも同じドメインでないが）MLの入力と出力が似ているデータセットのこと）を見つけられることはよくある。 例えば、画像の入力に対して、キャプションを出力するモデルとWEBサイトのスクリーンショットの入力からHTMLコードを生成するモデルは 類似性が高いので、流用できる可能性がある。
類似したデータセットで優れたパフォーマンスを持つモデルを構築できれば、 新しいデータ取集パイプラインを構築したり、既存のデータセットへのアクセスするよう利害関係者を説得することが容易になる。
無関係のデータセットでモデルを学習させることで、プロトタイプの作成とその結果の検証を迅速に行うことができる。 どのデータセットで始めるかが決まったら、次はモデル。
ゼロからパイプラインを構築したいという誘惑があるかもしれないが、先人の行ったことを観察することに価値がある。
2.2.2.2 オープンソースコード
既存のコードを検索することで２つの目的の達成を目指す。
- 誰かが同じようなモデリングする際に直面した課題を理解できること
- 与えられたデータセットの潜在的な問題を表面化させること
そのため、パイプラインと選択したデータセットを操作するコードの両方を探したほうがいい。 そして、見つけたあとにまず行うステップは、その結果を自分で再現すること
オンラインで見つけたコードは作者が主張している精度でモデルを学習できないことがあり再現性が保証されていないので要検証。
類似したコードをみつけるときは、問題を入力と出力の種類で抽象化して類似した問題に取り組むコードをみつける。 たとえば、画像からHTMLコードを生成するモデルの場合は、画像をシーケンスに変換するモデルを探す。
最後、データとコードをみつけたら、それらをまとめるステップに移る。
2.2.2.3 両者をまとめる
1. 同様のオープンソースモデルとそのモデルが学習したデータセット組み合わせて、学習結果を再現
2. 結果を再現後、ユースケースに近いデータセットに入れ替えて反復を開始
3. データセットと学習コードを統合後、定義したメトリクスを使ってモデルのパフォーマンスを測定し、チューニング
