効果的なマシンラーニングチーム

第5章 自動テスト 自動テスト：物事を壊さずに速く進める

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ダナ がデスクに座ったところだ。フレッシュなコーヒーの香りが彼女の周りのスペースに充満している。彼女とチームのジュニア・データ・サイエンティストは、昨日キックオフしたユーザ・ストーリーを続けている。

彼らは必要な変更を加え、テストを実行するコマンドを実行した。このテストスイートは、コードベース全体が期待通りに動作していることを確認するのに役立った。20秒後、彼らのターミナルには緑色のダッシュが表示された。

ターミナルが真っ赤になることもあった。失敗したテストもあったが、それはそれでいいのだ。失敗したテストは、彼らが深いウサギの穴に落ちそうになっているところをとらえ、数歩後ろにさかのぼることで簡単に立ち直る手助けをしてくれた。テストは緑に戻り、彼らはもう1度挑戦した。

緑でも赤でも、テストはコード変更に対する素早いフィードバックを与えてくれた。テストは彼らに自信を与え、正しい方向に進んでいるかどうかを教えてくれたり、間違った方向に進んでいるときには止めてくれたりする。コードをテストするために、面倒な手動ステップのシーケンスに従う必要はなかった。テストが失敗したとき、失敗の原因となりうる変更はほんのわずかであり、何時間もかけて容疑者の候補をソートする必要はなかった。

モデルのトレーニングが必要になったとき、彼らはクラウド上でトレーニングを開始するコマンドを実行し、実験追跡ダッシュボードが更新されたメトリックと説明可能性の可視化で照らされ、正しい軌道に乗っているかどうかを知らせてくれた。彼らは、ストーリーが完了するまで、適度なサイズのgitコミットとプッシュ（CIパイプライン上で自動化されたモデルテストをトリガーする）を行いながら、着実なステップで反復を繰り返した。

認知的負荷は管理可能なままだった。何をすべきかを明確にし、一歩ずつ着実に仕事をこなしていった。

ML製品やシステムは、テスト不足になりがちであることがよく発見される。自動テストの欠如は、技術的負債の最も一般的なタイプの1つであり、ML担当者が変更を加えようとするたびに利息を支払わなければならない。自動テストがなければ、ML担当者は手動テストや、手動テストの隙間をすり抜けたエラーによる本番インシデントの解決に膨大な時間を浪費することになる。これは、価値ある仕事への能力を低下させるだけでなく、バグやエラー、性能不足のモデルが実世界でユーザの手に渡る可能性を残すことになる。このような製品の欠陥は、ML製品の構築に費やした数カ月、数年の努力を水の泡にする可能性がある。

とはいえ、MLの実務家にとってテストは目新しいものではない。しかし、自動化された手段ではなく、手動で行うことが多い。もしあなたが、モデルの品質やコードの変更を手作業でテストすることに、必要以上の時間を費やしているのであれば、この章を読んでほしい。MLソリューションの包括的な自動テストを作成するための実践的なテクニックを紹介する。

この章では、その詳細を説明する：

• 特にMLシステムにおいて、手作業によるテストには困難が伴う。

• 自動テストの利点と、ML実務者が信頼性と保守性の高いシステムを作成するのに役立つ方法。

• 包括的な自動テスト戦略の構成要素は、ソフトウェアテストとモデルテストの2つに分類される。

この章では、自動テストの「なぜ（why）」と「何を（what）」（例えば、どのようなテストを書くべきか？ ...