構築は簡単だが、維持は難しい! Googleの機械学習システムの苦い教訓

[[279958]]

2014年、機械学習の背後に隠れた高い技術的負債を調査したGoogleの論文が話題になりました。今日、この論文は再び、有名なテクノロジーコミュニティ HackerNews の見出しを飾りました。 4年が経過して、人工知能は新たな春を迎えたようですが、機械学習の研究者を悩ませる問題は依然として似ています。

この記事の著者は、本番環境で機械学習システムを使用する開発者や保守担当者に、この論文が実用的な提案を提供できることを願っています。著者らは、機械学習システムをゼロから構築するのは比較的簡単だが、その後の改善は予想外に難しい場合があると警告している。この記事を読むと、読者は、そこに書かれている経験が、著者が Google 在職中に苦労して蓄積してきたものから来ていることをはっきりと感じるでしょう。

AI Frontline では、この古典的な記事をレビューします。記事内の経験の一部は、「機械学習に関連しているからといって、優れたソフトウェア エンジニアリングのプラクティスを完全に放棄できるわけではない」と強調しており、コンテンツの一部は機械学習に特有の一般的な落とし穴に属しています。 「X+AI」ビジネスの構築を目指すすべてのスタートアップが直面する潜在的な課題を考えると、この記事のアドバイスは検討する価値があります。

この記事で言及されている機械学習システムによってもたらされる技術的負債の主なカテゴリには、情報の隠蔽と変更の封じ込めによって引き起こされる課題、グルーコードと構成、そして常に変化する外部世界と分析モデルの結論によって引き起こされるこの世界の理解の偏差が含まれます。

この記事から得られる最も重要な洞察の 1 つは、技術的負債はエンジニアや研究者が注意を払う必要がある問題であるということです。システムの複雑さを大幅に増大させることを犠牲にしてソリューションを研究するのは、明らかに賢明なアプローチではありません。一見無害なデータ依存関係を 1 つまたは 2 つ追加するだけでも、開発の進行が遅くなる可能性があります。技術的負債の削減は新しい定理を証明することほどエキサイティングではありませんが、それでも強力なイノベーションの重要な推進力となります。実際、複雑な機械学習システムのための包括的かつエレガントなソリューションを開発することは、実用上非常に重要なタスクです。

情報の隠蔽と変更のカプセル化

…機械学習モデルは複雑に絡み合った状態を作り出す機械であり、それを改善する作業を効果的に分離することは不可能です。デモンストレーションとして、E がモデルで特徴 x1、...Xn を使用するとします。x1 の値の入力分布を変更すると、その重要度、重み、または残りの特徴がすべて変更される可能性があります。これは、モデルがバッチ モードで完全に再トレーニングされるか、オンライン方式で段階的に適応されるかに関係なく当てはまります。新しい機能 xn+1 を追加したり、機能 xj を削除したりすると、同様の変更が発生する可能性があります。真に独立した入力はありません。シェパードはこれを CACE 原則と呼んでいます。つまり、何かが変わるとすべてが変わるということです。

事前確率の重要性を理解していれば、機械学習を使って証明を繰り返す必要はありません。したがって、モデルは巨大なミキシング マシンのようなもので、大量の情報を投入して結果を取得しますが、入力のさまざまな変化に対する感度を予測することは難しく、影響を分離することはほぼ不可能です。このような難しい問題に直面して私たちは何をすべきでしょうか?万能の解決策はありませんが、著者らは役立つかもしれない 3 つの戦略を提案しています。

1. モデルを分離し、代わりに全体的な結論を提供することができます。しかし、エンタングルメントの問題はどのモデルでも依然として存在します。さらに、「規模が大きい場合、この戦略を長期的に維持することは困難になる可能性があります。」
2. モデルによって予測される動作を深く理解するための方法を開発します。たとえば、より多くの視覚化ツールを提供するなどして、モデルのブラック ボックス化を軽減するための投資を行う必要があります。さらに、機械学習モデルによる決定を（規制目的であっても）説明する能力がビジネスモデルの重要な部分となっている企業をいくつか話しました。したがって、この点についてのニーズと実装方法について真剣に検討してください。
3. より洗練された正規化手法を使用して、トレーニングで使用される目的関数がパフォーマンス予測コストの増加を反映するようにします。 「このアプローチはうまくいくかもしれないが、あくまでも可能性に過ぎない。さらに、システムの複雑さが増し、負債が増える可能性があり、絡み合いを減らすという当初の目的から外れてしまう。」

偶発的な結合を探すもう 1 つの方法は、隠れたフィードバック ループを作成することです。これは、特に未申告の消費者の間で顕著です。システムは、宣言されていない消費者を通じて、モデリング出力の出力を単に消費しているだけであり、これらのプロセスの存在にはほとんど気づきません。モデルに影響を与える入力パラメータに関する情報に基づいて何らかのアクションが実行される場合、この隠れたフィードバック ループによって次のような問題が簡単に発生する可能性があります。

ニュースの見出しのクリックスルー予測システムでは、システム内のコンポーネントが見出しに使用するフォント サイズを「インテリジェントに」決定する役割を担っていると想像してください。このフォント サイズ モジュールがクリック率を入力信号として使用し始め、フォント サイズがユーザーのクリック傾向に影響を与える場合、フォント サイズにはクリック率によって追加された新しい隠れたフィードバック ループが含まれることになります。ご想像のとおり、このようなシステムでは、タイトルのフォント サイズの数が徐々に無限に増加します。

データ依存性の問題

…コードの依存関係は静的分析やリンクグラフなどの方法を通じて比較的簡単に識別できますが、データ依存関係の処理機能を備えた分析ツールはほとんどありません。その結果、大規模なデータ依存チェーンを解決できるソリューションを構築することが困難になる可能性があります。

たとえば、一部の入力信号は時間の経過とともに動作が変化します。 CACE 原則に従うと、これらの変更が改善の方向として採用されたとしても、結果を予測することは困難です。別の種類のデータ依存性は、モデル内の機能のセットであり、その一部は精度の向上が非常に限られています。十分に活用されていない依存関係を活用する方法は多数あります。これには、非推奨となったレガシー機能、組み合わせて追加された機能 (実際に機能した機能だけではなく)、または正確さを追求するために追加されたが複雑さへの影響を正当化できない機能が含まれます。定期的に機能を清掃することが非常に重要です。

たとえば、チームの合併後に、簡素化のために古い製品番号から新しい製品番号への変換が実行されると、両方のソリューション セットがシステムに組み込まれます。新しい製品には新しい番号が 1 つしか割り当てられませんが、古い製品には同時に 2 つの番号が割り当てられる場合があります。もちろん、機械学習アルゴリズムでは依存関係に古い番号も含められます。 1年後、誰かが古い数字が入力されたデータベース コードをクリーンアップしました。クリーンアップ後に古​​い番号が使用されなくなるため、この変更は回帰テストでは検出されません。これは明らかに機械学習システムのメンテナーにとって良いニュースではありません…

データの依存関係を理解するツールは、機能のクリーニングをスムーズに行うのに役立ちます。 Google のチームが自動化された機能管理ツールを構築しました。

このアプローチは導入以来、Google チームが四半期ごとに何千行もの機能関連コードを安全に削除し、バージョンやその他の問題を自動的に検証するのに役立っています。このシステムは、新しいモデルで廃止された機能や壊れた機能が誤って使用されることも効果的に防止します。

データ依存関係を管理するための最終的なアプローチは、既存のモデルを再利用するための「修正」メカニズムを組み込むことです。この方法では、初期結果をすぐに得ることができますが、一方で、将来の分析とモデルの改善にはより高いコストがかかります。

残りの95% (グルーコードと構成)

驚くべきことに、学術界は、ほとんどの機械学習システムでは、実際に「機械学習」を行っているのはコードのごく一部に過ぎないことに気づきました。実際、成熟したシステムでは、コードの最大 5% が機械学習を担当し、残りの 95% 以上のコードは単なる接着剤であり、元々扱いにくい API を再実装 (再利用ではない) することで改善することになります...

ここで解決する必要がある問題は、多くの機械学習ライブラリが独立した成果物としてパッケージ化されており、間違いなく多くのグルーコード（Java から R または matlab への変換など）が導入されることです。より広範なシステム アーキテクチャ内で適切なリソース オプションが見つからない場合は、アルゴリズム (コードの 5%) を再実装する方が合理的であり、グルー コードの量を削減できる可能性があります。

関連する問題として、パイプライン ジャングル、つまり過度に複雑なデータ準備パイプラインがあります。

パイプライン ジャングル問題を回避するには、データの収集方法と機能の抽出方法を包括的に検討するしかありません。パイプジャングルを一掃し、クリーンアップ方法をゼロから設計することは、確かにエンジニアリング設計への大きな投資ですが、継続的なコストを大幅に削減し、さらなるイノベーション活動を加速させることもできます。

グルーコードとパイプラインジャングル問題によってシステムが固定化されると、多くの人は実稼働コード内の実験的なコードパスを微調整して追加の実験を実行したくなります。これは確かに便利ですが、頻度が高すぎると、より大きな混乱を引き起こすだけです。

典型的な例として、Google は最近、重要な機械学習システムをクリーンアップしたところ、未使用の実験的なコード行が数万行見つかった。より厳密な API で書き直された後、この「レガシー」の部分は、作業負荷、生産リスク、および制御システムの複雑さを大幅に削減し、新しいアルゴリズムの実験への道を開きます。

セクションの最後では、「構成は、現実世界の乱雑さが美しいアルゴリズムに干渉する手段となることがよくあります。」

次の例を考えてみましょう。機能 A では、9 月 14 日から 9 月 17 日の間に記録エラーが発生しました。機能 B は 10 月 7 日まで正式にリリースされませんでした。レコード形式が変更されたため、11 月 1 日以前のデータと 11 月 1 日以降のデータでは、特性 C を計算するために使用されるコードを変更する必要があります。機能 D は本番環境では使用されない為、ライブ調整におけるモデルクエリでは D' と D" を使用する必要があります。機能 Z を使用する場合、トレーニング関連のすべてのタスクは追加のメモリ割り当てを取得する必要があります。そうしないと、トレーニング効率が大幅に低下します。最後に、機能 Q はレイテンシ制約により機能 R を除外します。このような混乱により、構成を正しく変更することが難しくなり、推論も困難になります。さらに、構成エラーは、時間の大幅な損失、コンピューティングリソースの損失、本番環境の問題など、コストがかかる可能性があります。

構成の変更はコードの変更と同様に慎重に扱い、ピアレビューの対象となる必要があります。

世界は他にどんな変化をもたらすでしょうか?

経験上、外界が安定したままでいることはめったにありません。実際、現実世界の変化の性質は、機械学習における技術的負債の主な原因です。

決定しきい値（広告を表示するかしないかなど）を手動で設定するのではなく、既存の検証データを評価してしきい値を見つけることを検討してください。また、因果関係が不明瞭な相関関係のある特徴も問題を引き起こす可能性があります。

これは大きな問題ではないようです。2 つの特徴が常に相関しているが、そのうちの 1 つだけが真に因果関係にある場合、両方の特徴を評価し、共通の現象を観察することで結論を導き出すことができるようです。しかし、外界におけるこれら 2 つの特徴の共生が突然失われた場合、予測される動作は劇的に変化する可能性があります。相関効果を区別するための包括的な機械学習戦略も、私たちの議論の範囲を超えています。[Bottou 2013]は、この点に関して優れたアドバイスと参考文献を提供しています。この記事の焦点に沿って、非因果関係も隠れた負債のもう一つの原因であることに注目します。

最後に、システムのリアルタイム監視が重要です。この論文では、予測バイアスを測定し、システムが実行したアクションの数が一定のしきい値を超えた場合にアラートを発行することを提案しています。

意図したとおりに動作するシステムでは、予測ラベルの分布は通常、観測ラベルの分布と同一になるはずです。これは、単一のヌル モデル (つまり、入力機能を考慮せずに平均ラベル発生を直接予測する) で満たすことができるため、大規模なテストは必要ありません。しかし、この単純なアプローチは驚くほど良い結果をもたらし、そのような指標の変化は注意を要する重要な問題を示すことが多いのです…