Design Docs for ML【eugeneyan氏・和訳】

はじめに

こちらの記事はeugeneyan氏の "How to Write Design Docs for Machine Learning Systems"を読んでのアウトプットとなります．元の記事では機械学習システムの設計に関するDesign Docの重要性とその書き方について解説しています．新卒1年目（入社3ヶ月目）で機械学習モデルの構築のタスク等を任され，色々試行錯誤している中でeugeneyan氏のDesign Docの記事と出会い，現在はこれを参考にして機械学習モデルの構築を行っています．

Design Docとは

以下，Design Docs at Googleからの引用です．

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions.
<GPT4o訳>
Googleのソフトウェアエンジニアリング文化の重要な要素の1つは、ソフトウェア設計を定義するための設計文書の使用です。これらは比較的非公式な文書で、ソフトウェアシステムまたはアプリケーションの主な著者または著者たちが、コーディングプロジェクトに取り掛かる前に作成します。設計文書は、実装戦略の高レベルな概要と、設計上の主要な決定事項を文書化し、これらの決定を行う際に考慮されたトレードオフに重点を置いています。

次の場合に，eugeneyan氏はDesgin Doc for MLを書くと便利であると述べられています．

• 問題や解決策が曖昧であるか、十分に理解されていない（例：ブロックチェーン）
• 影響が大きい（例：顧客対応、他のサービスへの下流の影響）
• 実装の労力が大きい（例：数か月間に複数のチームが必要）

Design Docの目的（Why）と内容（What）

Design Docは，なぜするか（Why）と何をするか（What）を説明することから始める必要があると述べられています．具体的に，以下の5つを明確化するべきであると述べられています．

1.「なぜこの問題を解決すべきなのか？なぜ今なのか？」を明確化する
- 提案の動機を説明し，その重要性を読者に納得させる
- 顧客またはビジネス上のメリットは何なのかを明確化する
- 代替システムを構築する場合は，既存のシステムを改善してもうまくいかない理由を説明する
- 代替手段がある場合は，提案するシステムが優れている理由を説明する
2. 「成功基準は何なのか？」を明確化する
- 顧客エンゲージメントの向上，収益の増加，コストの削減などのビジネス目標の実現なのか
- 運用目標や新しい機能（モデルのロールバック機能，リアルタイムでの機能の提供など）として定義されることもある
3.「要件と制約は何なのか？」を明確化する
- 機能要件（プロジェクトを実現するために満たさなければならない要件）
- 推薦システムの場合: 5つ以上の推薦アイテムを持つアイテムや顧客の割合（Proportion of items or customers with >5 recommended items）
　-GPT曰く，推薦システムが5つ以上のアイテムを顧客に推薦するケースや，顧客が5つ以上の推薦アイテムを受け取る割合を指しており，これは推薦システムの性能や多様性を評価しているのではないかとのこと．
- 不正検出の場合: 誤検出の割合，または数の上限
- 自動分類: 人間によるレビューと承認を必要とする信頼性の低い予測の割合，または数の閾値
- 非機能要件/技術的要件（システムの動作特性や品質に関連する要件）
- これに関して，レイテンシが非常に高い場合などを除き，顧客が気づかない部分
- スループット，レイテンシ，セキュリティ，データプライバシー，コストなど
4. 「範囲内と範囲外は何であるか？」を明確化する
- 解決すべき問題によっては，一度に解決するには大きすぎる場合がある
- 妥当な時間内にリリースし，顧客からのフィードバックを得るには，規模を縮小する必要がある
- 範囲外と思うことは率直に伝えるべきである
- 時間と予算の制約を満たすために，技術的負債を負う必要も出てくる
- できるだけ早く技術的負債を返済する計画を立てる必要はある
5. 「私たちの環境に関する仮定と理解は何なのか？」を明確化する
- 推薦システムを構築する場合
- ユーザとアイテムの数はいくつなのか
- 1秒あたりのリクエストの予想数はどれくらいなのか

Design Docの作り方（How）

基の記事では，Design Docで方法（How）を扱う方法は，作成するMLシステムごとに大きく異なることを述べつつ，Desgin Docで考慮すべき事項のリストを「方法論」と「実装」が示されている．以下に記述することはチェックリスト/リファレンスとして役立つものであり，網羅的なものではないため，目標を達成するために必要なことは何でも記述すべきであるとのこと．Design Docの目的は，考えることを助け，フィードバックを得ることです．

方法論: データとMLで問題を解決する方法

1. 問題の説明
   • 問題をどのように捉えるかを宣言する
     • MLでは，同じ問題でもアプローチが異なる場合がある
     • 推薦システムの場合: コンテンツベースなのかCFベースなのか，item2itemなのかuser2itemなのか，候補生成とランキングのどちらに重点を置くのか
   • 解決しようとしている問題も明確化する
     • 推薦システムの場合: 代理問題（surrogate problem）を解決する必要がある
       • ユーザ評価を正確に予測する代理問題を解決することで，実際の推薦システムの目標（顧客満足度の向上など）に対して効果的な映画推薦につながると想定
2. データ
   • MLモデルのトレーニングに使用するデータとエンティティについて説明する
   • 顧客（人口統計），顧客イベント（クリック，購入），アイテム（メタデータ，テキストの説明，画像など）
   • データのプライバシーとセキュリティに関しては，実装でカバーする
3. 技術
   • 試す/試した機械学習テクニックの概要を説明
   • 比較のためのベースラインを含める
   • データのクリーニング方法，データの準備方法，特徴量エンジニアリングの方法
   • 必須ではないが，Desgin Docの読者があなたの作業を実装/再現できるように十分な詳細を説明するべきである
4. 検証と実験
   • オフラインでモデルを評価する方法を説明する
     -データの分割方法
     - eugeneyan氏の経験則から，ほとんどの場合，時間ベースの分割を使用しても問題ないらしい
     • 評価メトリックの選択と，それが本番環境に適したメトリックであると考える理由
     • A/BテストのTreatment群とControl群の割り当て方法
5. Human-in-the-loop
   • システムに人間の介入をどのように組み込むかを示す
     • 推薦システムの場合: 特定の製品カテゴリがホームページに表示されないようにするルールの実装，顧客が推薦アイテムから自分自身を除外したい場合に除外するルールの実装

実装: システムの構築と運用方法

非機能/技術要件をリストしており，エンジニアリングに重きを置いているが，全ての要件に対処する必要はありません．疑問がある場合は，エンジニアに相談すると良いとのことです．

1. 高レベルの設計
   • システムコンテキスト図やデータフロー図などで可視化から始めるのが良いとのこと
   • データストアやパイプライン（データ準備，特徴量エンジニアリング，トレーニングなど），サービングなどの主要コンポーネントが，相互にどのように作用するかを示す．
     • eugeneyan氏は，生データがどのように変換され，モデルのトレーニングに使用されるか，またサービングにおけるモデルの入力と出力を示すためにデータフロー図をよく利用されるらしい
2. インフラ+スケーラビリティ
   • インフラのオプションを簡単にリストし，最終的な選択を示す．
     • オンプレミス，クラウド，またはその両方の組み合わせなのか
     • インフラの選択がスケーラビリティにどのような影響を与えるか
3. パフォーマンス（スループット×レイテンシ）
   • スループット（1秒あたりのリクエスト数），レイテンシ（x ms @ p99）に関する要件に対処し，パフォーマンスを向上させる方法をリストする
4. セキュリティ
   • アプリケーションを保護し，ユーザと受信リクエストを認証する方法を指定する
5. データのプライバシー
   • 顧客データのプライバシーをどのように保護し，確保するか
   • MLモデルは個人を特定できる情報を学習するか？その場合はモデル内でどのように保存，処理，使用されるかを詳しく説明する
   • システムが自国のデータ保持および削除ポリシーに準拠する方法についても説明する
6. 監視+アラーム
   • システムパフォーマンス（スループット，レイテンシ，エラー率など）を監視する方法を詳しく説明する
7. コスト
   • システムの運用コストが，システムによって生み出される収益を上回っては意味がない
   • システムを構築するには何人のエンジニアとサイエンティストが必要で，その期間はどれくらいなのか
8. 統合ポイント
   • ダウンストリームサービスがエンドポイントをどのように使用し，対話するかを定義する
   • API仕様がどのようになっているか，および予想される入力データと出力データを共有する
9. リスクと不確実性
   • リスク（既知の未知）と不確実性（未知の未知）をできる限り指摘する
10. その他の事項

検討したが却下した代替案を記載する

検討したが却下した代替案に関するセクションを含めると便利らしい．その却下された案の長所と短所，および却下決定の根拠をリストする．却下の決定は環境と要件に関する想定に基づいて行われるため，それを文書化することで，環境が変わった際に過去の決定を再検討するのに役立つ．

Design Docを2段階でレビューする

• 事前レビュー
  • 小グループからフィードバックを迅速に繰り返し求める（Design Doc執筆の一環として）
  • 事前レビューの段階では，Desgin Docはやや粗削りで，未解決の質問や検討するべき道筋が残っている可能性がある
    • それでも，レビュー担当者は，Design Docが未完成で流動的な状態からシステムの方向性を有意義に形作るフィードバックを提供できるため，早い段階で関与することを望んでいる
• レビュー
  • 事前レビューよりも正式なものとなり，上級技術者や意思決定者など，より多くの関係者が参加することになる
  • どのようなリスクや不確実性に対処する必要があるか？どのような決定を下す必要があるか？どのような支援が必要であるか？など，何を求めるかを明確化する
  • 事前レビューがうまく機能していれば，この段階で大幅な設計変更を行うことはそれほど多くないはずとのこと．

終わりに

eugeneyan氏の記事を読んで，Design Docの重要性や具体的な書き方について多くのことを学びました．新卒1年目で機械学習モデルの構築タスクを任され，不安を感じていましたが，Design Docを利用することで，問題の整理や解決策の明確化ができ，より効果的にプロジェクトを進められるようになりました．この記事を通じて，設計段階での深い考察と計画の重要性を改めて認識しました．これからもDesign Docを活用し，効果的なシステム設計を目指していきたいと思います．
また，個人だけ良ければ良しという話でもないと思うので，1年目ではありますが組織に文化を浸透できるようにしていきたいです．

引用（Special Thankyou）

@article{yan2021design,
title = {How to Write Design Docs for Machine Learning Systems},
author = {Yan, Ziyou},
journal = {eugeneyan.com},
year = {2021},
month = {Mar},
url = {https://eugeneyan.com/writing/ml-design-docs/}
}

関連リンク

• eugeneyan氏の提案するML用Design Docのテンプレート