ベストプラクティスを実際のデザインパターンに抽象化することはできますか?機械学習

機械学習におけるデザインパターン

定義上、デザイン パターンは一般的な問題に対する再利用可能なソリューションです。ソフトウェア エンジニアリングにおいて、この概念は 1987 年に Beck と Cunningham がプログラミングに適用し始めたときに遡ります。 2000 年代までに、デザイン パターン (特に OOP 指向の SOLID 設計原則) はプログラマーの間で常識と見なされるようになりました。 15 年が経ち、私たちはソフトウェア 2.0 の時代に入りました。機械学習モデルが、ますます多くのコード箇所で従来の関数に取って代わり始めています。今日、私たちはソフトウェアを、従来のコード、機械学習モデル、および基礎となるデータの融合であると考えています。この融合には、これらのコンポーネントをシームレスに統合する必要がありますが、これらの分野の歴史や進化はそれぞれ異なるため、これは必ずしも容易な作業ではありません。

今日、私たちはソフトウェアを、従来のコード、機械学習モデル、および基礎となるデータの融合であると考えています。

しかし、デザイン パターンはまだ、この新しい時代の課題に対応できるほど拡張されていません。ソフトウェア 2.0 では、コード レベルだけでなく、問題の定義、データ表現、トレーニング方法、スケーリング、AI 対応システム設計の倫理においても共通の課題が発生します。これにより、機械学習のアンチパターンを実践するための肥沃な土壌が生まれます。残念なことに、今日では、ブログ投稿やカンファレンスでも、アンチパターン、つまり状況を改善すると考えられて実際には状況を悪化させる慣行が採用されることがあります。アンチパターンにはスキルが必要であるため、実践者はそれを認識していないことがよくあります。そこで、以下では、一般的な ML の課題の例を 2 つ挙げますが、デザイン パターンから始めるのではなく、まずその解決策のアンチパターンを紹介します。

モデルは評価指標で低いパフォーマンスを示している

一般的なシナリオでは、エンジニアはデータを収集、クリーニング、準備した後、最初のモデルをトレーニングし、そのモデルがテスト データに対して低いパフォーマンスを示すことを発見します。一般的なアンチパターンは、最初のモデルをより複雑なモデル (通常は勾配ブースティング ツリーなど) に置き換えて、その方法でパフォーマンスの向上を期待することです。このアンチパターンのバリエーションでは、モデルの平均化などにより複数のモデルを組み合わせることで、この手順に従うことができます。

これらのアプローチの問題点は、問題の一部、つまりモデルのみに焦点を当て、モデルの複雑さを増すことで問題を解決しようとすることです。このステップでは、過剰適合の大きなリスクを受け入れざるを得なくなり、解釈可能性と引き換えに予測力が追加されます。この選択による副作用を軽減する効果的な方法（LIME など）はありますが、完全に排除することはできません。

デザインパターンはエラー分析です。実際には、これは、さまざまなテスト セットでのモデルの適合性を評価することによって、またはモデルが間違っている個々のケースを調べることによって、モデルがどこで間違っているかを確認することを意味します。 「ゴミを入れればゴミが出る」ということわざを聞いたことがあると思いますが、データに多少の矛盾があってもこれが真実だと気づく人はほとんどいません。ラベルは異なる評価者から提供される場合があり、評価者ごとにラベル付けガイドラインの解釈が若干異なります。おそらく、データの収集方法は時間の経過とともに変化したのでしょう。エラー分析は、小さなデータの問題に特に効果的です。しかし、ビッグデータの状況の大部分では、ロングテールイベント（入学試験を通じて希少な才能を特定するなど）も扱っていることも忘れてはなりません。

エラー分析の真の力は、それを適用することで解釈可能性や過剰適合のリスクを犠牲にすることなく、実際にそれを適用するだけでデータの分布に関する重要な知識を得ることができるという事実から生まれます。さらに、エラー分析により、モデル中心のソリューション (より複雑なモデルなど) とデータ中心のソリューション (追加のクリーニング手順など) を選択できるようになります。

導入されたモデルのパフォーマンスは時間の経過とともに低下する

このモデルは広範囲に検証され、実稼働環境に導入されています。ユーザーは満足し、肯定的なフィードバックをくれました。そして、1 か月後、四半期後、または 1 年後には、予測の欠陥に関する報告が行われます。これは多くの場合、モデルが学習した入力と出力の接続が時間の経過とともに変化する、コンセプトドリフトの現れです。この種の概念ドリフトは、一部の分野ではよく知られていますが (単語の意味論、スパム検出器)、「概念」ドリフトはどの分野でも発生する可能性があります。たとえば、マスクや社会的距離の規制は、これまで導入されてきた多くのコンピューター ビジョン モデルにも課題をもたらしました。

よくあるアンチパターンは、これらの例をノイズに帰し、時間の経過とともに状況が安定することを期待することです。これは、行動の欠如を意味するだけでなく、不正確な帰属も含まれますが、これは通常、データ駆動型のビジネスでは避けるべきことです。もう少し良いアンチパターンは、レポートに反応して、すぐに再トレーニングし、新しいモデルを展開することです。これは、チームがアジャイル ソフトウェア開発の原則に従っていると想定し、変更に迅速に対応することを選択した場合でも、アンチパターンになります。問題は、この解決策は症状には対処しますが、システム設計の欠陥は修正されないことです。

設計パターンはパフォーマンスを継続的に評価するもので、ドリフトが発生することを想定しているため、できるだけ早くそれに気付くようにシステムを設計します。これは反応速度ではなく検出速度に重点が置かれているため、まったく異なるアプローチです。これにより、システム全体のプロセスがより制御され、あらゆる反応の優先順位をより柔軟に決定できるようになります。継続的な評価とは、少量の新しいデータセットの真実を継続的に生成するためのプロセスとツールを確立することを意味します。ほとんどの場合、これには手動でのラベル付けが含まれ、多くの場合クラウドソーシング サービスが使用されます。ただし、場合によっては、他のより洗練された方法を使用することもできますが、展開環境では、モデルとデバイスのグラウンド トゥルース ラベルを生成することは現実的ではありません。たとえば、自律走行車の開発では、1 つのセンサー (LiDAR など) からの入力を使用して、別のセンサー (カメラなど) のグラウンド トゥルースを生成できます。

機械学習のためのSOLID設計原則

私がデザイン パターンについて書いている理由は、この分野が成熟度に達し、ベスト プラクティスを共有するだけでなく、それを実際のデザイン パターンに抽象化できるようになったからです。幸いなことに、この作業はすでに複数のグループによって開始されています。実際、このテーマに関する2冊の本が最近出版されました[1]、[2]。楽しく読みましたが、私たちは正しい方向に進んでいるものの、ML 実践者にとっての SOLID 設計原則を実現するにはまだ数歩の道のりがあると感じています。基礎はすでに理解されており、今日の AI 対応製品の構築に使用されていますが、デザイン パターンとアンチパターンの取り組みは、ソフトウェア 2.0 時代に向けた重要なステップであると私は考えています。