機械学習による実用アプリケーション構築⑧ 第5章 モデルの学習と評価①
MLは反復的なプロセス。以下のサイクルを回す。
第5章 最初のモデルの学習を行い、ベンチマークをつくる。次にパフォーマンスを詳細に分析し、改善方法の特定する方法について 第6章 モデルの素早い構築、デバック、時間のかかるエラーの回避方法について 第7章 MLエディタを例にした推奨モデルの構築方法
第5章 モデルの学習と評価
この章では、モデルの選択、評価、結果の分析、エラーの特定方法について解説。
5.1 最も単純で適切なモデル
可能なモデルを全て試して、ベンチマークを行いテストセットで良い結果が出たものを選ぶ → 各々パラメータを考えたり、計算時間かかるので× 最初に単純なモデルを見分ける方法を定義した後、データパターンとそれを活用するための適切なモデル選択について解説。
5.1.1 単純なモデル
単純なモデルとは → 実装が速くできて、わかりやすく、デプロイ可能なモデルのこと。
5.1.1.1 素早い実装
一般的に良く知られていて、複数のチュートリアルが存在し、困った際には誰かが支援してくれそうなモデルを選ぶ。 可能であれば、Kerasやscikit-learnなどの人気のあるライブラリのモデルを使う。実験的なGitHubリポジトリに飛びつくのをやめる。 なぜなら、データの処理と信頼性の高い結果が出るかわからないため。
5.1.1.2 理解しやすさ
モデルの説明可能性はモデルが行った予測の理由を知るための要素。 モデルが偏りを持ったものでないことを検証するときや、予測結果を改善するために何ができるかをユーザに説明するなどの時に役に立つ。
モデルが決定する際に依存している特徴量が特定できる場合は、特徴量の調整、削除か どのモデルがより良い選択ができるかを明確な見解を得られる。
ロジスティック回帰や決定木については説明がしやすい傾向が最初に試すモデルとして、 適している理由の１つ。
5.1.1.3 デプロイ可能性
どのモデルの学習を行うかを考える際にはデプロイできるかを常に考える必要がある。
- 学習済みのモデルが予測を行うのにどれくらい実行時間がかかるか。前処理、ネットワーク呼び出し、表示するための時間も含む
- 予想される同時利用ユーザ数のときの実行速度
- モデルの学習時間、学習頻度
5.1.1のまとめ
以下のような表を作成してモデルの評価を行う
5.1.2 パターンからモデルへ
初期データセットから識別したパターンと特徴量をモデル選択の指針とする。 ここではパターンとそれに対して適切なモデルについて説明する。
5.1.2.1 特徴量のスケール
多くのモデルではスケールが大きい特徴量ほどモデルに与える影響が大きくなる。 なので、各特徴量のスケールを正規化する必要がある。その一つがへ平均０分散１に揃える標準化。 もう一つの解決策はスケールが関係ない方法を用いること決定木、ランダムフォレスト、XGBoostなど
5.1.2.2 予測変数が特徴量と線形関係にある場合
予測するものが特徴量と線形関係にあり、適切な予測ができる考えた場合は、 連続値に対しては線形回帰、分類問題に関してはロジスティック回帰やナイーブベイズなどの線形モデルをつかうべき。
特徴量と予測変数がより複雑な関係絵である場合は、 非線形モデルの使用、特徴クロスの生成などが有用となる。
5.1.2.3 時間的性質を持つデータ
時系列の影響を受けるデータの場合この情報を自動的にエンコードできるモデルである必要がある。 ARIMAやRNNなどの統計モデルが有用
5.1.2.4 パターンの組み合わせデータ
画像や音声、文書などパターン領域に取り組む際には畳み込みニューラルネットワークが並進不変フィルタを学習する能力に 優れていることが証明されている。位置に関係なく画像内の局所的なパターンを抽出できることを意味している。
その他のML問題に対するモデル選択についてはscikit-learnが提供しているフローチャートが有用。
機械学習による実用アプリケーション構築⑦ 第4章 初期データセットの取得③
4.3.3 アルゴリズムとして振舞う
各クラスタ内のいくつかのデータポイントにモデルが生成すると思われるラベルを手作業で付与してみる。 アルゴリズムとして振舞ったことがなければ、その結果の品質を判断するのは困難。 自分でデータのラベル付けに時間をかけてみるとモデリングの作業がずっと簡単になるような傾向に気づくことが多々ある。
モデリングをする際は多くの仮定を置く必要があるので、その仮定を置くために、データポイントをとって調査することは 理にかなっている。
データセットに既にラベルが付いている場合でも、ラベルを付けてみるべき。 これによって、正しくラベルが抽出されているか、ラベルが正しく付与されているかをチェックできる。
このラベル付けを効率的に行うには、事前分析として各クラスタ内のいくつかのデータポイントへ ラベルを付けて、特徴量分布の各共通値を活用する。 そのための１つの方法として可視化ライブラリを用いてインタラクティブにデータを探索して見る。（本ではBokehを使っている） ラベルを付ける際はどのようなプロセスを経て決定したかを留意しておく。 これは傾向を特定して、モデルに役立つ特徴量を生成するのに役立つ。
4.3.4 データの傾向
しばらくデータにラベル付けをしていると通常は傾向がみえてくる。 その際に、データに偏った傾向、例えば、特定の言語は否定的なものしかツイート収集されていないなどのデータ分析するにあたり、 ネガティブな傾向が見えてきても絶望することはない。 → 学習データの精度を不自然に上げてしまい、パフォーマンスの悪いモデルを本番投入することを避けられる発見だから。
多くの場合、偏ったサンプルに対する最善の策は追加でデータを収集することになる。
傾向を特定できたら、次はそれを利用する。 多くの場合、傾向を特徴づける特徴量を作成するか、簡単に活用できるモデルを使用するかのいずれかの方法をとることになる。
4.4 特徴量とモデルの情報をデータから取り出す
データから発見した傾向を把握するのに役立つ特徴量をどのように生成するか
4.4.1 パターンから特徴量を構築
MLの目的=統計学習アルゴリズムを用いてデータのパターンを活用すること パターンの中には活用するのが容易なものとそうでないものがある。
MLを実用的にするためにはモデルが有用なパターンを識別するのに役立つ特徴量を追加する必要がある。 たとえば、季節性は特定の特徴量生成から利益を得る一般的な傾向。だが、日付の表現方法はほとんどのモデルが 数値入力しか受け取れないため、特徴量を作ってやる必要がある。
4.4.1.1 生の日付
数値ではないので扱いにくい
4.4.1.2 曜日と月日の抽出
日付に入っているデータをそれぞれ別カラムに収める
4.4.1.3 特徴量クロス
特徴量クロスは２つ以上の特徴量を単純に掛け合わせることで生成される特徴量。 特徴量の非線形な組み合わせを導入することで各データの識別が容易になる。
たとえば、曜日（１～７で数値化したもの）と月の日付の特徴量クロスをした値を 用いると月の最後の週末が識別しやすくなる。
4.4.1.4 モデルに答えを与える
ある特徴量の値の組み合わせが予測可能であることが事実であるとわかっている場合、 この組み合わせとなる場合とそうでない場合の2値の特徴量を作成することができる。
月の後半2回の週末のみ１を設定してそれ以外を０にするなど。 過去2週間の週末が予想通りであれば、モデルは単純にこの機能を活用することを学習して、 より正確な予測ができるようになる。
ML製品を構築する場合は複雑な作業で苦戦する作業よりも簡単な作業で機能するモデルの方が 優れているので、答えが分かっているのであれば、簡単な作業へ変更した方がよい。
一般的に有用な特徴量を生成する最良の方法は、これまでに紹介した方法で データを調べて、モデルにパターンを学習させる最も簡単な方法は何かを自問すること。
機械学習による実用アプリケーション構築⑥ 第4章 初期データセットの取得②
4.3 データの傾向を見つけるためのラベル
データセットの傾向を特定するのは、品質だけでなく、モデル構造を予め予測するための作業。
このために、データを異なるクラスタに分離して各クラスタの共通点を抽出する。 まずは、データセットの要約統計量を生成し、データセットを手早く探索する方法を確認する。
4.3.1 要約統計量
データセットを確認する場合は、一般的にはまず各特徴量の要約統計量を確認することから始める。 → クラスを分離する簡単な方法を特定するのに役立つ。
クラス間の分布がどのように異なるかを特定しておくとMLのモデリング作業が容易になる。
例えば、ツイートが肯定的か、否定的かを予測する場合に、 各ツイートに含まれる単語数の平均を数えることから始めて、そのヒストグラムをプロットしてみると 肯定的なツイートの方が、否定的なツイートよりも短いか長いかが分かれば単語長を予測因子として追加する などの行動がとれるようになる。
分布が分かれているとクラスを分離する特徴量として有用
4.3.2 効率的なデータ探索とラベル付け
データを直感的に理解するためには時間をかけて個々のデータポイントを調べる必要がある。 ただ、ランダムにデータセットのポイントを調べるのは非効率。このセクションでは、可視化を効率的に行う方法を説明。
ベクトル化 → 次元削減 → クラスタリング の順に行う
データに基づいてクラスタリングした後に各クラスタを個別に調べて クラスタ間の類似点、相違点を調べることはデータセットの構造を特定する優れた方法。
このときに注意するポイント
- データセットをいくつのクラスタに分けるか
- それぞれのクラスタがどのように異なっていると考えられるか。どのような点からそのように考えられるか。
- 他のクラスタよりもはるかに密度が高いクラスタがあるか、もしある場合はモデルは疎の領域でうまく働かない可能性がある。
- すべてのクラスタはモデル化が難しいと思われるデータを表しているか
密度が高いところに関してはデータや特徴量で分離してあげられれば、問題を軽減できる
4.3.2.1 ベクトル化
表形式データ
- 連続的な特徴量：共通の尺度に正規化。標準化やMINMAXNormalizationなど
- カテゴリ特徴量：ワンホットエンコーディング
- 日付などの複雑な特徴量：顕著な特徴を捉えたいくつかの数値特徴に変換される必要がある。 年や日や曜日を抽出してカラムを追加するなど
テキストデータ
- カウントベクトル（単語の登場回数のカウント数） これは単純に単語をカウントするだけなので、単語の順序などは考慮されていない
- 概念化の類似性を加味したベクトル（word2vecなど） どの単語が類似した文脈で出現する傾向があるかを学習する
画像データ
画像データはすでにベクトル化されている。テンソルと呼ばれる多次元の数値配列。 事前学習済みのニューラルネットワークを用いることでより高い表現力を持つベクトルを利用することができる。（転移学習） 少数のデータセットのパフォーマンスを上げるときには特に有用。ただし、事前学習モデルに偏りが生じている場合もあるので、 留意が必要
各データ形式のベクトル化したものをさらに類似したデータポイントをグループ化することでデータセットの傾向をより迅速に確認できる
4.3.2.2 次元削減
アルゴリズムにはベクトル表現が必要だが、一般的に2次元以上であることが多いので可視化することは難しい 仮に14次元を表現するにはどうするか？
より低次元変換（3次元とか）して14次元の情報をできる限り持たせてあげるのが次善の策になる。 t-SNEやUMAPなどを用いると高次元データを2次元平面で表現することが可能になる。
これらの射影はデータパターンのヒントや調査のきっかけにできる。
データをベクトル化してプロット → 類似したデータポイントのグループを体系的に識別 → それぞれを調査
4.3.2.3 クラスタリング
データセットの検査をするための分類やモデルのパフォーマンスを分析する際でもクラスタリングは中核となるツール 次元削減と同様に問題点や興味深いデータポイントを明らかにするための追加の方法としてクラスタリングを使用する。
実際とる方法としてはK－Meansなどの単純なアルゴリズムをいくつか試して、 いいパフォーマンスを示すクラスタ数やハイパーパラメータなどを微調整すること。
パフォーマンスは
- データの可視化
- エルボー法
- シルエットプロット
のような方法を組み合わるだけで十分。データを完全に分類するのが目的ではなく、 モデルに対して問題のある領域を特定するのが目的のため。
クラスタを作成したら各クラスタを調べてそれぞれのデータ傾向を特定する。 そのためにクラスタ毎にいくつかのポイントを選択して、モデルが生成するだろうラベルを付与することを実行する。 次のセクションでその方法について説明。
機械学習による実用アプリケーション構築⑤ 第4章 初期データセットの取得①
第4章 初期データセットの取得
この章では
- データセットの品質を効率的に判断する方法
- データをベクトル化する方法
- ベクトル化したデータを用いたラベル付けと検査
をより効率的に行う方法について説明
4.1 データセットの反復処理
ML製品を素早く構築するためにはモデル構築と評価を迅速に行う必要がある。
データの収集、準備、ラベル付けはモデリングと同様の反復プロセス
ML研究ではデータは不変だが、製品で使うMLは製品を作るツールの一つ。 データセットを定期的に更新して補強することが作業の大部分を占めることがよくある。 データは新しいモデルを開発するための最高のインスピレーションの源。 物事がうまくいかないときにその答えを求める最初の場所になる。
4.1.1 データサイエンスの実践
データを扱うことはモデルで遊ぶ前に取り組むべき雑用 → ×
モデルは既存のデータから傾向やパターンを抽出するための手段。
なので、データにモデルが活用できるほどの十分な予測可能なパターン含まれているか、
そして、明確な偏りがないかを含んでいないかを確認することは
データサイエンティストの基本的な仕事になる。
4.2 初めてのデータセット探索
目標：真の目的に先立つ予備的な結果を抽出するための簡単なデータセットを取得すること
4.2.1 効率的に小さく始める
データが多いほど良いモデルを作ることができる場合がほとんどだが、可能な限り大きなデータセットから始めるという意味ではない。
プロジェクトを始める前に小さなデータセットをし追うすることで、データを簡単に調査して理解し、より適切なモデルを作る方法を掴むことができる。 戦略を決めてデータを大きくしていく。
テラバイト単位を超えるデータがクラスタで保存されているような環境では、 データを一様にサンプリングしてローカルマシンのメモリに収まる程度のサブセットを抽出することから始める必要がある。 例えば、家の前を走る車を特定するプロジェクトでは、数十枚程度の車の画像から始めるなど。
このあたりの収集と分析は必要かつ初期段階のスピードアップにつながる
ほとんどのエンジニアはモデルのインパクトを過大評価しがち データ作業を過少評価してる。むしろ、データの調査に時間をかけるべき。
4.2.2 洞察と製品
分析のためのデータ探査と製品開発のためのデータ探査は異なる。 分析のためのデータ探査：傾向から洞察を生み出す 製品開発のためのデータ探査：傾向を利用して機能を構築する
例えば、製品開発のデータ探査 不正ログインの予測をするには不正ログインの季節性に気づくことが最初のステップ 次に季節的な傾向から収集したデータに基づいて学習させる頻度を決める。
製品開発のデータ探査では、学習データのパターンと本番で入ってくるデータのパターンが似ていることを想定する必要がある。 そして、違いがある場合は定量的にそれを把握する必要がある。
しかし、傾向を見る前にまずデータの品質を評価する必要がある。
4.2.3 データ品質規範
データセットには独自の偏りや特異性がある。全てを網羅することはできないが、 データセットに最初にアクセスする際に注意を払うべき内容について紹介する。
4.2.3.1 データフォーマット
入力と出力が明確になるようにすでにフォーマットかされているのか、追加の前処理やラベル付けが必要か
4.2.3.2 データ品質
データの品質が低下する原因
- 値の欠落
- 正確さの不足（ラベル、自然言語処理ならスペルの誤りなど）
- データ破損
など、品質を正確に把握するとMLのパフォーマンスレベルや使用する特徴量、モデル選択が容易になる。 これらを事前に知っているとラベルが欠落している場合は、ラベルを手動でつける、弱いラベルを見つけるなどの 対応ができる。
4.2.3.3 データ量と分布
十分なデータ量があるかどうか、特徴量の値域が妥当かどうかを確認。 クラスタ間でデータを推定する場合など、各クラスタに含まれるデータに偏りがないかなど。
データ品質規範の例
| 品質 | フォーマット | データ量と分布 |
|---|---|---|
| 関連するフィールドが空になることはないか | データの前処理ステップ数 | データ数はどれくらいか |
| 測定誤差の可能性はあるか | 本番環境でも前処理可能か | １クラスあたりのデータ数、欠落 |
機械学習による実用アプリケーション構築④ 第3章 最初のエンドツーエンドパイプライン構築
モデルの調査、学習、評価は時間がかかってコストも大。 ⇒ リスクをできる限り減らすために取り組むべき最優先事項を特定する必要がある。
実装の際に重要なのは、できるだけ早く実用最小限の製品に到達する必要がある。 この第3章、第4章では、パイプラインの実装と評価に焦点を当てる。
第３章: アプリケーションの構造と足場をいかにつくるか 第４章: 初期データセットの収集と検査について
3章 最初のエンドツーエンドパイプライン構築
いかに初期のプロトタイプを構築するか。
3.1 最もシンプルな足場
おおまかに「学習」と「推論」の2種類のパイプラインがあるが、
プロトタイプを作る際には、まず「推論」の」パイプラインから始める。
これにより ユーザがモデル出力をどのように扱うかを確認し、モデルの学習を効率的に行うための情報を収集する。 学習パートについては無視して、ルールベースや経験則に基づいて開始する。一見不必要なパートに見えるが、 問題と向き合い、最善の初期仮説を立てるために必ず必要なステップ。 データをモデル化する最良の方法に関するか仮説の構築、検証、更新は、 最初のモデルより前に始まる反復モデル構築プロセスの中核になる。
簡単に初期仮説ができたら、データを収集して前処理を実行し、ルールを適用して結果を返すパイプラインを作成する。 MLを組み込む予定のアプリに関してもシンプルな機能版を作っておく。
3.2 MLエディタのプロトタイプ
今回事例として扱うMLエディタは一般的な編集上の提案を活用して良い質問、良くない質問の原因について ルールを複数作って、その結果をユーザに返す。
最小限の機能を持つMLエディタは以下の４つの関数で構成される
input_text = parse_arguments() #データの入力 processed = clean_input(input_text) #データのクリーニング tokenized_sentences = prerprocess_input(processed) #データの前処理 suggestion = get_suggestions(tokenized_sentences) #結果の出力
各関数の内容について構築し、出力が出せるようになると、 テストと反復処理が実行できるようになる。
3.3 ワークフローのテスト
プロトタイプを構築すると問題の組み立て方と提案した解決策の有用性について仮説の検証が可能になる。
ここでは、
- 最初のルールの客観的品質
- 出力が有用な方法で表示されているか
を確認する。
3.3.1 ユーザエクスペリエンス
まず、モデルの品質とは無関係に製品の使用満足度を調べる。 最終的に十分なパフォーマンスを持つモデルが得られると仮定した場合に、ユーザに結果を提示するための最も有用な方法かを考える。 掲示する結果が有用あるか。モデルの品質を高めても役に立たないのならゴミ。
3.3.2 モデリングの結果
早い段階で動作するプロトタイプを作ると、メトリクスを特定して反復できる。 そのためには、メトリクスが製品の成功を表すものである必要がある。 ユーザエクスペリエンスとモデルパフォーマンスの両方を検討するのは、最もインパクトのある側面に取り組んでいることを 確認するため。
3.3.2.1 インパクトボトルネックの確認
製品の見せ方とモデリングの結果の両方を確認する目的：次に取り組むべき課題を特定するため 取り組むべき課題が製品の領域なのか、モデリングの領域なのかを判断することが重要。
製品の領域の場合
例えば、結果が出た理由が必要なのに、確率しか返さない製品になっている場合は、結果が出た理由を表示するものに変える必要がある
モデリング領域の場合
学習データに偏りが生まれる、データにノイズが多く含まれるなどや過学習してしまう場合は、 モデリングを修正する必要がある。
機械学習による実用アプリケーション構築③ 第２章 計画の作成②
機械学習による実用アプリケーション構築では、 StackOver FlowなどのQAサイトに投稿する質問文を入力に対して より解答を得られる質問文を生成するシステム（MLエディタ）を例にして、MLプロジェクトの進め方を説明
2.3 MLエディタの計画
2.3.1 エディタの初期計画
まず、ヒューリスティックを実装することから始める。（機械学習を用いずに人手でやるとしたら） 完璧なデータセットは質問とその品質の評価。まずは類似したデータセットからより簡単に見つけられるものを探す。 QAコミュニティのひとつであるStackExchangeは匿名化されたデータダンプもあるため、最適。 これを利用して、初期モデルを構築し、質問から質問の賛成スコアを予測するモデルを作れる。 また、データセットを調べることでラベル付けのパターンも見つけられる。 テキスト分類のための多くのオープンソースモデルが存在する。⇒ https://oreil.ly/y6Qdp
2.3.2 常にシンプルなモデルから始める
完璧なモデルを最初にゼロから作るのはお勧めしない。 ⇒なぜなら、MLシステムは反復プロセスでモデルがなぜ失敗したかから掘り下げていくのが最も早く進歩する方法だから。 最初から複雑なモデルで始めるとそれが見えにくい。 モデルが失敗するのが速ければ速いほど反復のサイクルが早くなるからいい ⇒ 3部で説明
特定のモデリングアプローチがどの程度成功するかを事前に知ることは困難 ⇒ 着実に進めるためのヒントを次以降で示す。
2.4 定常的な進歩のために：シンプルに始める
多くのMLプロジェクトは初期のデータ収集とモデル構築の計画に依存して、定期的に更新を掛けていないので失敗する。 要件に対応できる最もシンプルなモデルから初めてEtoEのプロトタイプを構築して製品目標の観点から パフォーマンスを判断することが重要。
2.4.1 シンプルなパイプラインから始める
最初のデータセットで単純なモデルのパフォーマンスを確認することが取り組むべき作業を決定する最良の方法。 そのためにはデータを取り込んで結果を返すパイプラインを構築する必要がある。 ML問題では学習と推論の独立した２つのパイプラインが存在する。
このパイプラインは各ステップでモデルにより色々な懸念事項を考慮して作られるが全体的な構造には 基本的にあまり大きな違いが生じない。そのため、パイプラインを最初にEtoEで作成することに価値がある。
パイプライン構造には大きな違いはないが、データセットの構造によって機能自体に共通点がないことはよくある。
2.4.2 MLエディタのパイプライン
省略
2.5 まとめ
省略
機械学習による実用アプリケーション構築② 第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. データセットと学習コードを統合後、定義したメトリクスを使ってモデルのパフォーマンスを測定し、チューニング
