ML Strategy (1)
この週と次の週では機械学習プロジェクトを進めていくための戦略について説明する.
Why ML Strategy
MLプロジェクトを進めていくための戦略がなせ必要なのか?
モデルの精度が例えば90%であるとした時,それをさらに改善するためにどんなことをしたらより改善できるのか?という判断を適切に行えることはプロジェクトの効率や進捗に大きく影響する.
そのため,この週と次の週で話される戦略を理解し,活用することが大切になる.
Orthogonalization
日本語でOrthogonalizeationは直交という意味. 機械学習プロジェクトにおけるモデルの調律時に意識すると良い考え方として「Orthogonalization」がある.
これは,1度に1つのものを変えてみるということ.
まず調律においては,はじめに「教師データによりよくフィットするように」という点に絞って調律を行う.次に「バリデーションセットによりよくフィットするように」という点に絞って調律を行う.
同時に双方を満たすように調整するのではなく,それぞれ独立して調律を行うことが効率的な進め方につながる.この考え方をorthogolanizationという.
Single number evaluation metric
調律を行う際には,例えば分類制度や処理時間など,複数の指標を最適化しようとして調律すると行った戦略が考えられるが,より効率的な調律を進めるためには,1つの調律するための指標を決めてそれを追い求めるほうが効率が良い.
どのように1つの指標を決めるかについては後ほどの授業で述べるが,例えばF1Scoreなどがある.
Satisficing and Optimizing metric
モデルのパラメータのセットから,最適なものを見つけたい. その際に,複数のメトリクスがあると意思決定が難しいことがある.
例えば,(F1Score,処理時間)がA(90%, 80ms),B(92%, 95ms),C(95%, 1500ms)だとする. この時, F1Scoreだけに着目すると最適なのはCだが,処理時間の観点に着目すると最適なのはBとなる.
さらにメトリクスが増えて,N個になった時,適切な判断を下すのは難しい.
これをうまく扱うための方法として「1つを最適化対象として,他のN-1は制約条件とする」という考え方がある.
例えば,F1Scoreを最適化対象として,処理時間は制約条件とするような考え方である. 「処理時間は100ms以下であること」という制約を課し,その条件下でF1Scoreを最適化するものが良いパラメータセットであると考える.
すると先ほどの例は処理時間が制約条件に収まり,F1Scoreが最適なBがベストな選択であると判断できる.
Train/dev/test distributions
特にDevセットとテストセットについては,同様の発生源からデータを得るようにすることが大切になる. トレーニングセットを使い,パラメータを決めて学習したモデルを,Devセットで評価して,最適なパラメータに調整していく.その際に,Devセットとテストセットがかけ離れていると,その調整が全く意味をなさなくなってしまう. これを避けるためにも,Devセットとテストセットは同一の発生源からデータを取得できるように心がけるほうがいい.
Size of the dev and test sets
データ総量がそんなに大きくなかったこれまでの世界では,教師データとして総量の60%を,Devセットとして20%,テストセットとして20%を使うようなバランスが多かった.
近年,扱えるデータ量の増加に伴って,母数が増えたので,総量の20%をDevとテストセットに使う必要は必ずしもなくなった. 最近では98%を教師データとして使い,残り1%づつをDevセットやテストセットとして扱うケースもある.
さらに,テストセットは最終的なシステムのパフォーマンスを推定するためのものであり,最終的なシステムのパフォーマンスの推定が不要であれば,テストセットを用意しないという選択もありうる.
When to change dev/test/ sets and metrics
メトリクスがモデルの「良さ」を直接的に反映していないことがわかったら,メトリクスを変更する必要がある.
例えば,誤差1%で動くがミスした際に大きな事故がつながるAモデルと,誤差5%で動きミスしたとしても事故には繋がらないBモデルがあるとする.
メトリクスを誤差率にすると,モデルAの方が良いように見えるが,実際には事故が起きると様々な損害につながるため,メトリクスとしては誤差率だけでなく,事故の大きさのようなものも含むべきである.
このようなことが後から判明したら,そのタイミングでメトリクス自体を変更する必要がある.
Why human-level performance?
機械学習によるタスクの精度は近年向上してきており,人の能力と戦えるレベルに進化してきた. 分野によっては人の能力を超えるような成果も出始めている.
機械学習の分野では,人の能力に比べてモデルの精度がどの程度か?という問いが,重要な指標として扱われている. 機械学習のモデルの到達可能な最大精度を見積もるために,人の能力が活用できるからである.
到達可能な理想的な最大精度に達した際に残る誤差をBayesOptimalErrorと呼ぶ. 人のパターン認識力や識別力はとても高く,BayesOptimalErrorと人間の限界値は近しい.
そのため,モデルが到達可能な精度として,人の識別能力がBayesOptimalErrorを間接的に示す指標として扱われるのである.
さらに,別の観点からは,人の能力限界までは,人が教師データを作成できるので,学習に用いる教師データを増やすことが容易いということや,人の能力限界までは,モデルがどのような条件の時に失敗しやすいかを人が理解できるので,最適化しやすいため,人の能力限界までモデルの精度をあげることは,それ以上に引き上げることに比べるとやりやすい.
そのため,図1のような投資する時間とモデルの精度の関係が描ける.
Avoidable bias
過去の章で,モデルの性能を評価する指標としてバイアスとバリアンスについて考えた. 過去の章で説明したバイアスとバリアンスはHumanLevelError(≒BayesOptimalError)が0であるとして計算したもので,実際は異なる.
バイアスは教師データについての誤差率から,HumanLevelError率を引いた値として定義される.バリアンスは,バリデーションセットデータについての誤差率から教師データについての誤差率を引いた値として定義される.
例えば,HumanLevelErrorが1%で,教師データに対する誤差率が8%,バリデーションセットデータに対する誤差率が10%だとすると,バイアスが7%でバリアンスが2%なので,Highバイアスな状態であると言える. これが,HumanLeverErrorが7.5%のような場合は,バイアスが0.5%でバリアンスが2%なので,Highバリアンスな状態であると言える.
このように,HumanLevelErrorは誤差率の分析を行う上でも重要な指標となっている.
Undrstanding human-level performance
HumanLevelErrorとは具体的にどうやって計算したら良いのか? 例えば以下のような状態を考える.
Task:画像による骨折診断 * 一般的な人の誤差率:1% * 一般的な専門家の誤差率0.5% * エキスパートな専門家の誤差率0.4% * エキスパートな専門家のチームによる誤差率0.3%
この場合は,BayesOptimalErrorはエキスパートな専門家チームによる誤差率0.3%よりも低いと見積もるのが正しい.
Supassing human-level performance
近年では,分野によっては人の能力を超えるような成果が出始めている.
広告配信やレコメンドシステムなど,構造化されたデータを扱うようなタスクの場合に,モデルが人を超えることが増えてきている. 人は構造化データの処理があまり得意ではなく,機械はそれが得意だからである.
構造化されていないような,画像認識や音声認識などの分野においては,一般的には人の能力を超えることは難しいが,近年は扱えるデータ量が増えてきたこともあり,少しずつ人の能力を超えるモデルが出てきている.なので,モデルが人を超えることは不可能ではないので,チャレンジする価値がある.
Improving your model performance
ここまでの内容をまとめて,モデルのパフォーマンスを向上させて行くためのプロジェクトの進め方ガイドラインを示す.
教師データにフィットさせる
まずは,モデルを十分に教師データにフィットさせることを考える. これは,バイアスを下げることを意味する.
モデルのネットワークを大きく,深くしたりする必要があるかもしれないし,学習期間をもっと伸ばす必要があるかもしれない.学習を効率良く進めるために最適化アルゴリズムを変える必要があるかもしれないし,CNNやRNNなど別のネットワークアーキテクチャを試すべきかもしれない.
バリデーションセットにフィットさせる
十分に教師データにフィットしたら,次はバリデーションセットにフィットさせる. つまり,バリアンスを下げる.
もっともっとたくさんの教師データを集めて学習させることでこれが達成できるかもしれない. 正則化(L2正則化やDropOut)することで解決できるかもしれないし,データを水増しするためにデータ拡張を行う必要があるかもしれない. CNNやRNNなど別のアーキテクチャを選択することで解決できるかもしれない.
この2つのステップを,一度に片方にだけ集中して行い,反復させることで効率良くモデルが育って行く.