自動運転における機械学習の核となるのはモデルではなくパイプラインである

この記事はLeiphone.comから転載したものです。転載する場合は、Leiphone.com公式サイトにアクセスして許可を申請してください。

大学を卒業して最初の仕事を始めたとき、私は機械学習について多くのことを知っていると思っていました。私は Pinterest と Khan Academy で 2 回のインターンシップを経験し、そこで機械学習システムを構築しました。バークレーでの最後の年に、私はコンピューター ビジョンのためのディープラーニングの研究を始め、最初に人気を博したディープラーニング ライブラリの 1 つである Caffe に取り組みました。卒業後、私は自動運転車を専門とするCruiseという小さなスタートアップ企業に入社しました。現在私は Aquarium に勤務し、複数の企業が重要な社会問題を解決するためにディープラーニング モデルを導入できるよう支援しています。

長年にわたり、私は非常に優れたディープラーニングとコンピューター ビジョンのスタックを構築してきました。私がバークレーで研究をしていた頃と比べて、現在は実稼働アプリケーションでディープラーニングを使用する人が大幅に増えています。彼らが現在直面している問題の多くは、私が2016年にクルーズで直面したものと同じです。皆さんが苦労して学ばなくても済むように、本番環境でディープラーニングを実行することについて、皆さんと共有したい教訓がたくさんあります。

図1: 著者のチームは、自動車に搭載された最初の機械学習モデルを開発した

1 自動運転車へのMLモデルの導入のストーリー

まず、クルーズが車に初めて搭載した ML モデルについてお話しします。モデルを開発していくうちに、ワークフローは私が研究時代に使い慣れていたものと非常に似ているように感じました。私たちはオープンソース データでオープンソース モデルをトレーニングし、それを自社の製品ソフトウェア スタックに統合して、自動車に展開します。数週間の作業の後、最終的な PR をマージし、モデルを車で実行しました。

「任務完了！」私は心の中で思いました。次の火災へ移るべきです。私が知らなかったのは、本当の仕事はまだ始まったばかりだということだった。

モデルが本番環境に導入されると、QA チームはパフォーマンスの問題に気づき始めました。しかし、他のモデルを構築したり、他のタスクを実行したりする必要があったため、これらの問題にはすぐには対処しませんでした。 3 か月後にこれらの問題を調査したところ、最初のデプロイメント以降にコード ベースが変更されたため、トレーニング スクリプトと検証スクリプトがすべて壊れていることがわかりました。

1 週間の修正作業の後、過去数か月間の障害を調べたところ、モデルの生産実行中に観察された問題の多くは、モデル コードを変更するだけでは簡単に修正できないことがわかりました。オープンソース データに頼るのではなく、自社の車両から新しいデータを収集してラベル付けする必要がありました。つまり、プロセスに必要なすべてのツール、操作、インフラストラクチャを含むラベリング プロセスを確立する必要があります。

3 か月後、私たちは車からランダムに選んだデータでトレーニングした新しいモデルを実行しました。次に、独自のツールでマークします。しかし、単純な問題を解決し始めると、どのような変更が結果を生み出す可能性があるかについて、より識別力を高める必要があります。

問題の約 90% は、モデル アーキテクチャの徹底的な変更やハイパーパラメータの調整ではなく、困難なシナリオやまれなシナリオに対する慎重なデータ ラングリングによって解決されます。たとえば、雨の日（サンフランシスコでは珍しい）にはモデルのパフォーマンスが低下することがわかったので、雨の日のデータをさらにラベル付けし、新しいデータでモデルを再トレーニングしたところ、モデルのパフォーマンスが向上しました。ここでも、モデルは緑色のコーン（オレンジ色のコーンに比べてあまり一般的ではない）ではパフォーマンスが低いことがわかったので、緑色のコーンのデータを収集して同じプロセスを実行したところ、モデルのパフォーマンスが向上しました。

こうした種類の問題を迅速に特定して解決するためのプロセスを確立する必要があります。

モデルのバージョン 1.0 を組み立てるのに数週間かかり、モデルの新しい改良バージョンを発売するのにさらに 6 か月かかりました。私たちはさまざまな面（より優れたラベリング インフラストラクチャ、クラウド データ処理、トレーニング インフラストラクチャ、デプロイメントの監視）でますます取り組んでおり、月単位から週単位でモデルを再トレーニングして再デプロイメントできるようになりました。

より多くのモデル パイプラインをゼロから構築し、改善に取り組むうちに、いくつかの共通のテーマが見えてきました。学んだことを新しいパイプラインに適用し、より優れたモデルをより速く、より少ない労力で実行することが容易になりました。

2. 学習を繰り返し続ける

キャプション: さまざまな自動運転ディープラーニング チームが、モデル パイプラインで非常によく似た反復サイクルを持っています。上から下へ: Waymo、Cruise、Tesla。

以前は、機械学習は主にモデルに関するものだと思っていました。実際には、工業生産における機械学習は主に配管工事に関するものです。成功を予測する最良の方法の 1 つは、モデル パイプラインを効果的に反復処理できる能力です。これは単に素早く反復することを意味するのではなく、スマートに反復することも意味します。2 番目の部分は非常に重要です。そうしないと、パイプラインですぐに不良モデルが生成されます。

従来のソフトウェアのほとんどは、製品の要件が未知であり、適応を通じて発見する必要があるため、迅速な反復とアジャイル配信プロセスを重視しています。したがって、初期段階で不安定な仮定に基づいて詳細な計画を立てるのではなく、MVP を迅速に提供して反復する方がよいでしょう。

従来のソフトウェア要件が複雑であるのと同様に、機械学習システムが処理しなければならないデータ入力の範囲は実に広大です。通常のソフトウェア開発とは異なり、機械学習モデルの品質は、コードでの実装と、そのコードが依存するデータによって決まります。データへの依存は、機械学習モデルがデータセットの構築/キュレーションを通じて入力のドメインを「探索」できることを意味し、コードを変更することなく、タスクの要件を理解し、時間の経過とともにそれに適応することができます。

この機能を活用するには、機械学習では、データとコードの両方の反復を重視する継続的学習の概念が必要です。機械学習チームは次のことを行う必要があります。

• データやモデルのパフォーマンスの問題を発見する
• 問題の原因を診断する
• これらの問題を解決するには、データまたはモデルコードを変更します。
• 再トレーニング後にモデルが改善されたことを確認する
• 新しいモデルを展開して繰り返します

チームは少なくとも月に 1 回はこのサイクルを実行するようにしてください。うまくいっているなら、毎週やってみてもいいかもしれません。

大企業ではモデルの展開サイクルを 1 日もかからずに完了できますが、ほとんどのチームにとって、インフラストラクチャを迅速かつ自動的に構築することは困難です。これより少ない頻度でモデルを更新すると、コードの腐敗 (コードベースの変更によりモデル パイプラインが破損する) やデータ ドメイン シフト (運用中のモデルが時間の経過に伴うデータの変更に一般化できなくなる) が発生する可能性があります。

大企業ではモデルの展開サイクルを 1 日で完了できますが、ほとんどのチームにとって、インフラストラクチャを迅速かつ自動的に構築することは非常に困難です。これより少ない頻度でモデルを更新すると、コードの腐敗 (コードベースの変更によりモデル パイプラインが破損する) やデータ ドメイン シフト (運用中のモデルが時間の経過に伴うデータの変更に一般化できなくなる) が発生する可能性があります。

ただし、正しく実行すれば、チームは改善されたモデルを本番環境に展開する良いリズムをつかむことができます。

3. フィードバックループを作成する

モデルの不確実性の調整は、モデルが失敗する可能性があると思われる箇所にフラグを立てることができる、興味深い研究分野です。

モデルを効果的に反復するための重要な部分は、最も影響力のある問題の解決に重点を置くことです。モデルを改善するには、モデルの問題点を把握し、製品/ビジネスの優先順位に応じて問題を分類できる必要があります。フィードバック ループを作成する方法は多数ありますが、まずはエラーを見つけて分類することから始まります。

ドメイン固有のフィードバック ループを活用します。

利用可能な場合、これはモデルに関するフィードバックを得るための非常に強力かつ効果的な方法になります。たとえば、予測タスクでは、実際に何が起こったかの履歴データでトレーニングすることで、ラベル付けされたデータを「無料で」取得できるため、大量の新しいデータを継続的に供給して、新しい状況にかなり自動的に適応できます。

人間がモデルの出力を確認し、エラーが発生したときにフラグを立てることができるワークフローを設定します。

このアプローチは、多くのモデルにわたる推論でエラーを簡単に検出できる場合に特に役立ちます。これが起こる最も一般的な方法は、顧客がモデル出力のエラーに気づき、機械学習チームに苦情を申し立てる場合です。このチャネルを使用すると、顧客からのフィードバックを開発サイクルに直接組み込むことができるため、これを過小評価することはできません。チームは、顧客が見逃した可能性のあるモデル出力を人間が再確認することができます。オペレーターがベルトコンベア上でロボットが荷物を仕分けするのを見て、エラーが発生したことに気づいたときにボタンをクリックするところを想像してみてください。

人間がモデルの出力を確認し、エラーが発生したときにフラグを立てることができるワークフローを設定します。これは、人間によるレビューで多数のモデル推論におけるエラーを簡単に検出できる場合に特に適しています。これが起こる最も一般的な方法は、顧客がモデル出力のエラーに気づき、ML チームに苦情を申し立てる場合です。このチャネルにより、顧客からのフィードバックを開発サイクルに直接組み込むことができるため、これは強調しすぎることはありません。チームは、顧客が見逃した可能性のあるモデル出力を人間が再確認することができます。オペレーターがベルトコンベア上でロボットが荷物を仕分けするのを監視し、エラーに気付いたときにボタンをクリックする様子を想像してみてください。

モデルの実行頻度が高すぎて人間がレビューできない場合は、自動レビューの設定を検討してください。

これは、モデル出力に対して「健全性チェック」を簡単に記述できる場合に特に便利です。たとえば、LIDAR オブジェクト検出器と 2D 画像オブジェクト検出器が一致しない場合、またはフレーム間検出器が時間追跡システムと一致しない場合は、フラグを立てます。正常に動作すると、障害が発生した場所に関する多くの有用なフィードバックが提供されました。うまくいかない場合は、検査システムのエラーが明らかになるか、システムが間違っているケースがすべて見逃されるだけなので、リスクは非常に低く、報酬は大きいです。

最も一般的な（しかし難しい）解決策は、実行されるデータのモデルの不確実性を分析することです。

この簡単な例としては、本番環境で信頼性の低い出力を生成するモデルの例を見ることが挙げられます。これにより、モデルが実際に不確実であるが、100% 正確ではない場所が示されます。場合によっては、モデルが確実に間違っていることがあります。適切な推論を行うために利用できる情報が不足しているために、モデルが不確実になることがあります (例: 人間が理解するのが難しいノイズの多い入力データ)。これらの問題に対処するモデルは存在しますが、これは活発な研究分野です。

最後に、トレーニング セットに対するモデルのフィードバックを利用できます。

たとえば、モデルとそのトレーニング/検証データセット間の不一致 (つまり、損失が大きい例) を調べると、信頼性の高い障害または誤ったラベル付けが示されます。ニューラル ネットワーク埋め込み分析は、トレーニング/検証データセット内の障害モード パターンを理解する方法を提供し、トレーニング データセットと実稼働データセット内の元のデータ分布の違いを発見できます。

キャプション: ほとんどの人の時間は、典型的な再トレーニング サイクルから簡単に取り除かれます。たとえ、これによって機械の効率が低下するとしても、多くの手作業の苦痛が軽減されます。

反復を高速化することの主なポイントは、反復サイクルを完了するために必要な作業量を削減することです。ただし、物事を簡単にする方法は常に存在するため、何を改善するかを優先順位付けする必要があります。私は努力を、時計の時間と人間の時間という 2 つの方法で考えるのが好きです。

ウォールクロック時間とは、データの ETL、モデルのトレーニング、推論の実行、メトリックの計算など、特定のコンピューティング タスクを実行するために必要な時間を指します。ヒューマンタイムとは、手動で結果を確認したり、コマンドを実行したり、パイプラインの途中でスクリプトをトリガーしたりするなど、パイプラインを実行するために人間が積極的に介入する必要がある時間を指します。

たとえば、ステップ間でファイルを手動で移動して複数のスクリプトを手動で順番に実行する必要があることは非常に一般的ですが、無駄です。ざっと計算してみます。機械学習エンジニアの時給が 90 ドルで、スクリプトを手動で実行するのに 1 週​​間に 2 時間を無駄にしているとすると、1 人あたり年間 9,360 ドルにもなります。

複数のスクリプトと手動の中断を 1 つの完全に自動化されたスクリプトに組み合わせると、モデル パイプライン サイクルの実行がより速く簡単になり、多額のコストが節約され、機械学習エンジニアのストレスも軽減されます。

対照的に、クロックタイムは通常「合理的」である必要があります（例：一晩で完了する）。唯一の例外は、多くの実験を行っている機械学習エンジニアや、コストやスケーリングの制約が極端に厳しいエンジニアです。これは、実時間は通常、データのサイズとモデルの複雑さに比例するためです。ローカル処理から分散クラウド処理に移行すると、クロック時間が大幅に短縮されます。その後、問題の規模が大きくなるまでは、クラウドでの水平スケーリングによってほとんどのチームのほとんどの問題が解決される傾向があります。

残念ながら、一部のタスクを完全に自動化することは不可能です。ほぼすべての実稼働機械学習アプリケーションは教師あり学習タスクであり、そのほとんどはモデルに何をすべきかを指示するためにある程度の人間による操作に依存しています。一部の領域では、人間とコンピュータの相互作用は無料です (例: ソーシャル メディアの推奨ユース ケースや、直接的なユーザー フィードバックを多く得るその他のアプリケーション)。訓練を受けた放射線科医がトレーニング データ用に CT スキャンに「ラベル」を付ける場合など、人的時間は限られていたり、コストがかかったりする場合もあります。

いずれにしても、モデルの改善に必要な人的時間やその他のコストを最小限に抑えることが重要です。初期のチームはデータセットの管理を機械学習エンジニアに頼るかもしれませんが、機械学習の知識を持たない運用ユーザーまたはドメイン専門家にデータ管理の重労働を任せる方が経済的 (または、放射線科医の場合は必要) な場合が多くあります。この時点で、データセットのラベル付け、検査、改善、バージョン管理を行うための優れたソフトウェア ツールを使用して運用プロセスを確立することが重要になります。

5. MLエンジニアに訓練を奨励する

図 1: ML エンジニアが重量を持ち上げると、モデル学習の重量も増加します。

新しい分野や新しいユーザー グループをサポートするのに十分なツールを構築するには、多くの時間と労力がかかりますが、うまく行えば、その結果は十分に価値のあるものになります。 Cruise 社には、非常に賢い（怠け者と言う人もいる）エンジニアがいました。

エンジニアは、運用上のフィードバックとメタデータ クエリの組み合わせによって、モデルのパフォーマンスが低い部分からラベル付け用のデータを取得する反復ループを設定しました。その後、オフショア運用チームがデータにラベルを付け、トレーニング データセットの新しいバージョンに追加します。次に、エンジニアたちは、コンピューター上でスクリプトを実行し、新しく追加されたデータに基づいて単純なモデルを自動的に再トレーニングして検証する一連のクラウド タスクを開始できるインフラストラクチャをセットアップしました。

毎週、再トレーニング スクリプトを実行します。その後、モデルたちがトレーニングして自らを検証している間に、彼女たちはジムへ行きました。数時間のトレーニングと夕食の後、彼らは結果を確認するために戻ってきました。同様に、新しく改善されたデータはモデルの改善につながり、すべてが理にかなっていることを確認するために簡単な二重チェックを行った後、新しいモデルを生産に出荷し、車の運転性が向上します。その後、彼らは 1 週間かけてインフラストラクチャを改善し、新しいモデル アーキテクチャを実験し、新しいモデル パイプラインを構築しました。このエンジニアは四半期末に昇進しただけでなく、体調も良好でした。

6 結論

要約すると、調査とプロトタイピングの段階では、モデルの構築と公開に重点が置かれます。ただし、システムが本番環境に移行すると、最小限の労力で改良されたモデルを定期的にリリースできるシステムを構築することが中心的なタスクになります。上手になればなるほど、より多くのモデルを構築できるようになります。

これを実現するには、次の点に重点を置く必要があります。

• モデル パイプラインを定期的に実行し、以前よりも優れたモデルの出荷に注力します。毎週またはそれ以下の頻度で、新しく改良されたモデルを生産に導入しましょう。
• モデル出力から開発プロセスまでの適切なフィードバック ループを確立します。モデルの成果が芳しくない例を見つけて、その例をトレーニング データセットに追加します。
• パイプライン内の特に負担の大きいタスクを自動化し、チーム メンバーが専門分野に集中できるチーム構造を確立します。テスラのアンドレイ・カルパシー氏は、理想的な最終状態を「ホリデーアクション」と呼んでいます。 ML エンジニアをジムに通わせ、ML パイプラインに重労働を任せるワークフローを構築することをお勧めします。

最後に、私の経験では、モデルのパフォーマンスに関する問題の大部分はデータを使用して解決できますが、一部の問題はモデル コードを変更することによってのみ解決できることを強調しておくことが重要です。

これらの変更は、多くの場合、現在のモデル アーキテクチャに非常に固有のものです。たとえば、数年間画像オブジェクト検出器に取り組んだ後、特定の方向比に対する最適な事前ボックスの割り当てや、小さなオブジェクトの特徴マップ解像度の向上について心配することに多くの時間を費やしました。

しかし、Transformer はさまざまなディープラーニング タスクの汎用モデル アーキテクチャ タイプとして有望であることが示されているため、これらの手法の多くは関連性が低くなり、機械学習開発の焦点はデータセットの改善へとさらにシフトしていくのではないかと考えています。