ディープラーニングには品質保証が必要、どうやって実現するか：ソフトウェア開発の一般的な品質保証プロセスとは大幅に異なる

開発者向けQ＆Aサイト「Stack Overflow」は、ディープラーニングの品質保証プロセスをどうやって構築するかを解説した。ディープラーニングでは、一般的なテスト手法の多くは適用できない。だが適切な手法でテストを行えば、ディープラーニングでより良い結果を出せるようになる。

[＠IT]

　ソフトウェアエンジニアのトビアス・クペック氏は2021年11月15日（米国時間）、開発者向けQ＆Aサイト「Stack Overflow」のブログに記事を寄稿し、ディープラーニングパイプラインのQA（品質保証）プロセス構築について解説した。

　ディープラーニングモデルには、一般的なテスト手法の多くは適用できないが、適切な手法でテストを行うことで、ディープラーニングパイプラインが良い結果を出せるようになるとしている。

ディープラーニングではなぜ品質保証が異なるのか

　通常のソフトウェア開発では、クラッシュしたときに障害を発見できる。最初の障害点はほとんどの場合、明確だ。

　だが、ディープラーニングモデルでは、障害点の候補がたくさんあり、特定が難しいこともある。このため、開発者が慣れ親しんだステップバイステップのデバッグ手法を使って障害点から徐々にバグを追い詰めることは困難だ。

　ディープラーニングモデルは複雑であり、依存関係を理解できないことがその背景にある。だが、アルゴリズムが複雑になり、デプロイされたソフトウェアの影響が大きくなればなるほど、より多くの品質チェックが必要にある。そのため、ディープラーニングプロジェクトを長期的に成功させるには、信頼性の高い品質保証プロセスが不可欠になる。

標準的なディープラーニングパイプライン（出典：Stack Overflow）

データがアルゴリズムの一部になっている

　ディープラーニングではトレーニングデータの役割が古典的なアルゴリズムにおけるデータ（データベース内の顧客データのような）の役割とは大きく異なる。トレーニングデータはアルゴリズムによって受動的に処理されるだけでなく、モデルのトレーニングに影響を与えることで、ソリューションを能動的に形成する。ディープラーニングパイプラインから良い出力を得ようとすれば、適切なデータが必要だ。

　トレーニングデータの品質保証プロセスの難しさは、扱わなければならないサンプルの量にある。そこでまず、サンプルデータセットを絞り込むため、サンプルの最低品質、異なるカテゴリーのバランス要件、サンプルの類似性スコアといった重要指標を定義する。データセットがどのようなものか、どのような問題が発生するのかを知るために、データの小さなサブセットを手動でスポットチェックすることから始めることが有効だ。

　何を探すべきかが分かれば、統計的手法を使って、データセット全体についての洞察を得ることができる。コードと同じように、データセットも開発プロセスの中で変化していくため、統計処理を自動化し、データセットからメタデータを繰り返し収集することが理にかなっている。これにより、時間の経過に伴う品質の変化を追跡、理解できる。

　また、前処理で問題が起こることもある。正しい有用なデータを準備するためのテストを行うには、ユニットテストを作成する。一部の操作については、処理を正しく元に戻せるかどうか、確認できる。

　このように、次のステップにデータを渡す前に、データパイプライン全体を検証する。

データ品質のチェックリスト
・重要な指標を定義する
・データのサブセットをスポットチェックする
・データセットの統計処理を自動化、変更を追跡する
・スクレイピングとラベリングから前処理までの完全なデータパイプラインを検証する

モデルを適切にトレーニングする

　ディープラーニングモデルを動かす際、最初は基本的なモデルアーキテクチャと安全な既定パラメーターがあれば、用が足りる。システムテストを自動化し、損失の削減、有効な出力、重みの更新の成功など、基本的なことをチェックする。その後、アーキテクチャの複雑さを増し、ハイパーパラメーターを調整し、より複雑なアルゴリズムを追加すればよい。最初から全てを実装してはならない。

　特に注意を払うべきなのが、指標の正しい計算だ。将来の判断とモデル選択は、それに基づくからだ。モデルにカスタム部分（非標準レイヤーや損失関数）がある場合は、ユニットテストを行うのが賢明だろう。

　一連のトレーニングの繰り返しから最適なモデルを選択するには、パフォーマンス指標を分析する必要がある。だが、独立したスモークテストを行えば、欠陥の特定に役立ち、結果の信頼性の向上や、モデルの正則化の改善につなげることができる。

　この検証ステップをトレーニングプロセスからできるだけ独立させることで（例えば、別の推論パイプラインを使うことで）、潜在的なバグを特定できる。この目的のためには、エッジケースや難しいサンプルを含む、手動で作成した個別のテストセットを使用する必要がある。

モデルトレーニングのチェックリスト
・基本的なモデルのセットアップから始めて、段階的に複雑さを増す
・メトリックの追加テストを含める
・モデルのカスタムパーツのユニットテストを実行する
・信頼性を高めるため、よく練られたテストセットで最終モデルを検証する

デプロイの失敗を回避する

　実際の問題を解決するには、モデルをデプロイする必要がある。多くの場合、推論環境やエンジンの見た目、動作は、トレーニング環境とは全く異なるものになる。デプロイされたシステムでは、入力の前処理が異なり、結果が使えなくなったり、悪化したりする可能性がある。

　また、一部のハードウェアは、出力を簡素化したり、計算精度が異なったりするかもしれない。そのため、ユースケースごとに個別のテストを行う必要がある。頻繁にデプロイして問題を迅速に発見する必要があるため、自動化が必要になる。

　本番環境にモデルを実装するには、CI/CD（継続的インテグレーション／継続的デリバリー）のための標準的なソフトウェアエンジニアリング原則が適用される。

展開をテストするためのチェックリスト
・モデルのエクスポートを自動化し、推論に必要なパラメーターを含める
・全てのデバイスタイプと構成で統合テストを実行する
・頻繁に展開し、別々のステージング環境で早期に展開する

パイプラインをテストする

　開発したパイプライングが実際に問題を解決することを確認するためには、実世界のデータから厳選したサンプルを用いて、最終的なエンドツーエンドのテストを行うとよい。この最終テストでは、問題設定に合わせて検証し、パイプライン全体が意図した通りに機能しているかどうかを継続的にチェックする必要がある。

　例えば、オブジェクト追跡の場合は、小さなビデオセットにラベルを付け、ターゲットデバイスでのカウントや追跡の精度をテストできる。テキスト感情分析の場合は、実世界のレビューを用いてテストすることで、潜在的な欠陥を発見できる。さらにシステムのユーザーに標準的なシナリオを聞いてみるなど、定性的な調査を試みることもできる。

最終的な品質チェック
・ターゲットプラットフォームで実際のデータを使用してエンドツーエンドのテストを実行する
・合成データや人工的なシナリオよりも実際のユースケースを優先する
・さまざまなソフトウェアリリースのテスト精度を追跡する
・予期しない入力といったエッジケースのテストを含める

パイプラインとイテレーションを使用する

　最後に、コードとデータの両方でバージョン管理を実行しなければならない。これにより、変更を記録し、起こり得る問題をデバッグできる。なお、データとアルゴリズムを同時に変更することは推奨されない。影響が追跡できなくなるためだ。

　パイプラインをセットアップし、テストと検証を行い、全てを自動化したら、実験の数を増やす。新しい手法を試し、最適なソリューションを見つける準備ができているからだ。プロセスの早い段階で失敗を特定し、結果を正しく検証できるので、自信を持って取り組むことができる。