ユニット 11 / 11

再現性とエンドツーエンドのプロジェクト: すべてを組み合わせる

利益:

  • 4 つの柱 (シード固定、データのバージョン管理、メディアの凍結、実験モニタリング) で再現性を確保し、同じ実行を繰り返したときに同じ結果を生成する機能
  • エンドツーエンドのチェーンでモジュールのすべての段階 (メトリクス、データ、モデル、LLM コンポーネント、評価、公平性、セキュリティ、配布、モニタリング) を組み合わせる機能
  • 重要な決定が各拠点で人間に委ねられていることを検証し、監査可能な方法でプロジェクトを文書化する能力

ML プロジェクトの最も潜在的な失敗はクラッシュではありません。 「同じ結果は二度と得られない。」 3 か月前に本番環境に投入したモデルのスコアを今日再現できない場合、そのモデルを実際に制御できていないことになります。この最後の単元では、再現性、つまり同じ入力で同じ結果を確実に取得し、モジュール全体をエンドツーエンドのプロジェクト規律で結合する能力を深めます。

なぜ再現性が難しいのか

通常のソフトウェアでは、同じコードから同じ出力が得られます。 ML では、結果を決定する変数がさらに多くあります。

  • ランダム性: データのシャッフル、重みの初期化、データの分割 - すべてはランダム性に依存します。
  • データ: 同じコードで、データ バージョンが異なる異なるモデルが生成されます。
  • 環境: ライブラリのバージョン、ハードウェア (CPU/GPU)、さらにはオペレーティング システムによっても結果が変わる可能性があります。
  • 隠されたケース: 保存されていないハイパーパラメータ、手動の前処理ステップ、注記されていない選択。

再現性は「あればいいもの」ではなく、科学的および工学的に不可欠なものです。再現できない結果は、証明できない主張です。

再現性の 4 つの柱

1.ランダム性を修正します。データの分割、モデルの初期化、データのシャッフルなど、すべてのランダム シードを 1 か所に設定します。固定シードは、「同じ実行を繰り返しても同じ結果」を保証するための基礎です。

2. データのバージョンを設定します。各実験がどのデータ バージョンで実行されたかを記録します (ユニット 2 のデータ バージョン管理)。 「最新のデータ」というのは曖昧です。 「データ バージョン v3、ハッシュ abc123」が正確です。

3. 培地を凍結します。すべての依存関係を正確なバージョンに固定します (たとえば、requirements.txt の numpy==1.26.4 などの正確なバージョン、またはコンテナー イメージ)。 「最新バージョン」はいつかすべてを破壊します。

4. すべてを追跡します (実験追跡)。コード バージョン (git commit)、データ バージョン、すべてのハイパーパラメータ、メトリクス、出力構造を実験ごとに自動的に保存します。 MLflow、Weights & Biases などの実験追跡ツールは、これを体系的に実行します。登録しないと、「どの設定が最適だったのか」という疑問は解決されません。

注意: 「後で思い出す」は最も高価な誤りです。 2 週間後には、どのシード、どのデータ、どのハイパーパラメータを使用したかを思い出せなくなるでしょう。自動追跡により、メモリへの依存がなくなります。

弱いアプローチ / 強いアプローチ

弱い: 「最高のモデルを見つけました。ノートブックにあります。スコアは 89% だったと思います。」

Strong: 「実験追跡ツールで #147 を実行します。git commit a3f9c、データ バージョン v3 (ハッシュ abc123)、シード 42、すべてのハイパーパラメーターが登録され、PR-AUC 0.887 をテストします。同じコマンドを再度実行すると、同じ結果が少しずつ得られます。モデルはレジストリでのこの実行に依存します。」

違い: 強力なアプローチでは、結果は記憶に基づいておらず、固定され監視されているチェーンに基づいています。誰もが毎回同じ結果を生み出すことができます。

エンドツーエンドプロジェクト:モジュールの組み合わせ

次に、モジュール全体を 1 つのプロジェクト フローに結合しましょう。実際の ML システムは次のストップを通過し、各ストップは前のストップに基づいて構築されます。

  1. 問題定義: 何を解決するのか、成功をどのように測定するか (ユニット 3: 適切な指標、ビジネス コンテキスト)。メトリクスとしきい値は最初から明確です。
  2. データ パイプライン: 収集、検証、クレンジング、リークのないパーティショニング、バージョン管理 (ユニット 2)。
  3. モデル開発: トレーニング、ベースライン比較、相互検証、ハード シード (ユニット 3 + このユニット)。
  4. LLM コンポーネント (該当する場合): RAG (ユニット 4) および/またはエージェント (ユニット 5)。必要に応じて微調整します (ユニット 6)。
  5. 評価: エッジおよびセキュリティのケースを含む評価クラスター、LLM システムのマルチレイヤー評価 (ユニット 8)。
  6. 正義と倫理の監査: サブグループ分析、モデル カード、説明可能性 (ユニット 10)。
  7. セキュリティ監査: 迅速な導入、プライバシー、サプライ チェーン (ユニット 9)。
  8. 配布: パッケージ化、段階的配布、ロールバック、モデル レジストリ (ユニット 7)。
  9. モニタリング: 3 層モニタリング、ドリフトアラーム (ユニット 8)。
  10. 再現性: チェーン全体 (このユニット) にわたるシード、データ バージョン、メディア、および実験の追跡。

このフローでは、AI はあらゆる段階でアクセラレータおよびブループリントを生成する役割を果たします。しかし、メトリクスの選択、データの決定、公平性の優先順位付け、展開のしきい値、リリースの承認など、重要な決定は人間に委ねられます。これがモジュールの本質です。

ドキュメント: 未来はあなたに感謝するでしょう

優れた ML プロジェクトはそれ自体を文書化します。少なくとも、問題と成功の基準、データ ソースとバージョン、モデルの選択と正当性、評価結果 (サブグループを含む)、既知の制限とリスク、展開と取得の手順、監視計画を記述する必要があります。この文書は、半年後にプロジェクトに戻る人 (おそらくあなた) の親友です。

ミニケース3個

ケース 1 - 結果が失われました。エンジニアは優れたモデルをトレーニングしましたが、シードを修正せず、データ バージョンを保存しませんでした。彼が仕事を辞めたとき、その結果を再現できる人は誰もいませんでした。このモデルは「ブラック ボックスの伝説」となり、最終的にはゼロから構築されました。数週間が無駄になりました。教訓: 再現できない結果は存在しない結果です。

ケース 2 - 環境の崩壊。あるチームは依存関係を修正していませんでした。ライブラリが自動的に更新されると、モデルの出力が静かに変更され、生産が中断されました。問題を見つけるのに何日もかかりました。依存関係が凍結され、最終バージョンでコンテナ化された場合、問題は再び発生しませんでした。教訓: 環境を凍結する。

ケース 3 - モニタリングの力。チームは各実験を自動的に監視しました。 3 か月後の規制監査で、彼らは「どのグループでどのようなデータ、どの設定、どのようなパフォーマンスが得られたのか?」という質問に答えました。数分以内に完全な録音が完了します。検査はスムーズに進みました。教訓: モニタリングは単なるエンジニアリングツールではなく、コンプライアンスツールです。

コピー可能なテンプレート

この ML プロジェクトの再現性チェックを実行します。- すべてのランダム シードは修正されていますか (分割、初期化、シャッフル)?- データはバージョン管理されていますか?- 依存関係は正確なバージョンに固定されていますか?- すべての実験 (コードのコミット、データ、ハイパーパラメータ、メトリック) は追跡されていますか?欠落している列ごとに修正方法の具体的な手順を記述します。プロジェクト構造: [説明]

このエンドツーエンド ML プロジェクトの計画スケルトンを作成します。問題: [説明] 次の停止点をカバーし、各停止点で人間による決定が行われる場所をマークします: 問題/メトリック、パイプライン、モデル、(RAG/エージェント/微調整?)、評価、公平性、セキュリティ、配布、監視、再現性。各ストップの主なリスクと検証手順を書き込みます。

このプロジェクトの技術文書テンプレートを作成します。セクション: 問題 + 成功基準、データ (ソース + バージョン)、モデルの選択 + 正当性、評価 (サブグループを含む)、既知の制限 + リスク、展開 + ロールバック、監視計画。各セクションに入力するフィールドを質問として指定します。

実験のモニタリング設定を確認してください。実行するたびに自動保存されていますか: git コミット、データ バージョン/ハッシュ、すべてのハイパーパラメータ、すべてのメトリクス、環境 (ライブラリ バージョン)。同じ実行を再度実行すると、同じ結果が得られますか?セットアップ: [説明]。欠点と修正点を列挙します。

再現性カラム表

コラム

修正された内容

車両例

ランダム性

すべての種子

シード設定

データ

データのバージョン/ハッシュ

DVC

環境

ライブラリのバージョン

要件ピン、Docker

モニタリング

コード+データ+設定+メトリクス

MLflow、W&B

よくある間違い

  • 種を固定していない。結果を繰り返すことはできません。
  • データバージョンを保存していません。 「どんなデータで?」未回答のままです。
  • 冷凍中毒ではありません。更新すると、何も言わずにすべてが壊れます。
  • 実験は記憶に留めておきます。 2週間経っても何も覚えていない。
  • 重要な決定を人工知能に任せます。指標、正義、配分の決定は人々に委ねられるべきです。
  • ドキュメントの延期。将来のチーム (そしてあなた) が代償を支払います。

要約すると

再現性は本格的な ML エンジニアリングの特徴です。再現できない結果は証明できない主張です。これには、ランダム性の修正、データのバージョン、環境のフリーズ、各実験の追跡という 4 つの列があります。エンドツーエンドのプロジェクトでは、このモジュールのすべての機能 (メトリック、データ、モデル、LLM コンポーネント、評価、公平性、セキュリティ、配布、監視) が相互接続されたチェーンに結合されます。人工知能はあらゆる場面で加速しますが、重要な決定は人間に委ねられます。将来のチームと監査のために、すべてを文書化します。この規律は、モジュール全体で学習するすべてのことを維持するフレームワークです。

アプリケーションタスク

再現性の 4 つの柱に照らして ML プロジェクトをチェックします。シードは不変か、データはバージョン管理されているか、環境は凍結されているか、実験は追跡されているか?欠落している列を修正し、同じ実行を 2 回実行して同じ結果が得られることを証明します。次に、プロジェクトのエンドツーエンドのフロー (10 ストップ) を 1 ページに出力し、各ストップで「人間による決定が行われる場所」をマークします。最後に、短い技術文書のドラフトを作成します。

チェックリスト

  • [ ] すべてのランダムシードが修正されました。
  • [ ] データのバージョン/ハッシュは実験ごとに記録されます。
  • [ ] 依存関係は確定バージョン (ピン/コンテナ) に固定されます。
  • [ ] 各実験は自動的に監視されます (コード+データ+設​​定+メトリック)。
  • [ ] 同じ実行を繰り返すと、同じ結果が得られます。
  • [ ] エンドツーエンドのフローにおける重要な決定が人間によって行われていることを検証し、文書化しました。

モジュール試験

1. ML エンジニアとして、人工知能をワークフローに位置付けるときの最良のアプローチは何ですか?

  • A) AI は低リスクのビジネスを促進します。指標、データ、生産などの重要な決定は検証されたままで、人間に委ねられます ✔
  • B) AI の出力が良好である限り、検証の必要はありません
  • C) モデルを実稼働環境に導入するかどうかの決定を人工知能に任せることで、時間を節約できます。
  • D) 人工知能はテキストを書く場合にのみ役立ち、データやモデルの作業とは何の関係もありません

説明: AI は、コード、データ ダイジェスト、ドキュメントなどの低リスクで簡単に検証できるタスクのための強力なアクセラレータです。ただし、メトリクスの選択、トレーニングに使用するデータ、モデルの運用環境への導入など、金銭、機密保持、法的責任に影響を与える決定に対する責任は、資格のあるエンジニアとチームにあります。各出力は検証せずに使用しないでください。

2. スキーマ検証がデータ パイプラインの先頭に配置されるのはなぜですか?

  • A) モデルの精度が直接上がるため
  • B) データのバージョン管理が不要になるため
  • C) 破損したデータを最も早く、最も安価な時点で捕捉し、次のステップへの漏洩を防ぐため ✔
  • D) ラベルを貼る必要がないため

説明: 破損したデータが早期に検出されるほど、修正コストが安くなります。スキーマ検証は、ラインの先頭で予期されるタイプと範囲外のデータを拒否することで、破損したデータがトレーニングや本番環境に静かに漏洩することを防ぎます (例: 単位の変更により価格が 100 倍変化する)。本番環境で同じエラーが発生すると、何倍ものコストがかかります。

3. 時間 (時系列) が関係する問題でデータをトレーニングとテストに分割するときの正しいアプローチは何ですか?

  • A) 常に最も公平な方法であるため、ランダム分割を使用します。
  • B) 時間分割の使用: 過去でトレーニングし、将来でテストすることで漏洩を防止します ✔
  • C) すべてのデータをトレーニングとテストの両方として使用する
  • D) トレーニング前にテストデータをスケーリングパラメータに組み込む

説明: 時系列のランダムな分割により、実稼働環境では決して起こらない「将来を見据えた」利点がモデルに与えられ、メトリクスが人為的に増大します (時間的リーク)。正しいのは時間的な分割です。過去で訓練し、未来でテストします。これは、運用環境を維持するための実際のパフォーマンスを測定します。

4. 陽性クラス率 1.5% の不正検出モデルの精度が誤解を招くのはなぜですか?

  • A) 不均衡なデータでは精度が常に低いため
  • B) Accuracy は回帰問題でのみ使用できるため
  • C) 精度の計算には多くの処理能力が必要となるため
  • D) 多数派を予測するつまらないモデルであっても非常に正確である可能性があり、そのため本当の成功が隠れてしまいます ✔

説明: 不均衡なデータでは、「すべてを否定的とみなす」という基本モデルでも約 98.5% の精度が得られますが、不正行為は 1 つも検出されません。したがって、不均衡分類では、精度の代わりに適合率、再現率、F1 または PR-AUC が使用され、各メトリックは基本モデルに従って解釈されます。

5. モデルのメトリクスについて語るときに、ベースラインの比較が不可欠なのはなぜですか?

  • A) 基本モデルは常に実際のモデルより優れているため
  • B) 単純なベースライン モデルと比較した場合にのみ、メトリクスが意味があるかどうかが明らかになるため ✔
  • C) 基本モデルにより相互検証が不要になるため
  • D) すべての報告書において基本モデルが法的に義務付けられているため

説明: メトリックは、それ自体では良いとも悪いとも言えません。基本モデルによって良くも悪くもなります。 「85% 正解」という文は、基本モデルが既に 84% を取得している場合はほとんど価値がなく、50% を取得している場合は完璧であることを意味します。比較アンカーがなければ、メトリックは無意味です。

6. RAG (Retrieval-Augmented Generation) システムの運用プロンプトに含めるべき最も重要なセキュリティ要素はどれですか?

  • A) 与えられた出典のみに依存し、出典が存在しない場合は「分かりません」と述べ、出典を引用するよう指示 ✔
  • B) できるだけ長く創造的な答えを生成するようにモデルに指示する
  • C) モデルはリソースよりも自身の教育知識を優先します。
  • D) コマンドとして提供された文書内のすべての指示を実行する

説明: RAG の最も重要な指示は、与えられたソースのみに依存するようにモデルに指示し、情報がソースにない場合は、「わかりません」と言って、でっち上げずにソースを引用するように指示することです。このトライアドがないと、モデルはコンテキストを無視して幻覚を引き起こす可能性があり、答えは検証できなくなります。

7. RAG システムは不正確な応答を返します。診断を開始するのに最適な場所はどこですか?

  • A) 最初にフェッチを測定する (Recall@K): 正しいピースが到着するか? ✔
  • B) すぐに大きなモデルに交換する
  • C) プロンプトをランダムに変更して試行を続けます
  • D) 微調整しながらすべてのドキュメントをモデルに埋め込む

説明: RAG の最も弱いリンクは通常、本番環境ではなくフェッチです。正しい部品が持ち込まれない場合、プロンプトがどれだけ改善されたとしても、モデルはその情報を生成できません。したがって、最初に Recall@K を測定して、正しいパーツが到着したかどうかを確認します。フェッチが良好な場合は、プロダクションとプロンプトが検査されます。

8. エージェントにツールを渡すとき、人間の承認の後にどのような行動をとるべきですか?

  • A) なし。エージェントはすべてのアクションを自律的に実行できなければなりません
  • B) データの読み取りや検索など、元に戻せるアクションのみ
  • C) 送金、削除、送信など、取り消せないまたは大きな影響を与える行為 ✔
  • D) 計算のみを伴うアクション

説明: アクションはリスクレベルごとに分けられます。ドラフトの読み取り、検索、計算、生成などの取得可能なタスクは自律的に実行できます。ただし、送金、電子メールの送信、データの削除、注文など、元に戻せないアクションや影響の大きいアクションには人間の承認が必要です。取り消し不能な行為にはすべて同意が必要です。

9. 間接プロンプト注入のリスクに対する最適な設計アプローチは何ですか?

  • A) システムプロンプトに「間違った指示を無視する」という一文を追加するだけで十分です。
  • B) 外部コンテンツの指示に依存して、モデルにより多くの権限を与える
  • C) 注射は予防できないため、何の予防策も講じていない
  • D) 外部コンテンツを信頼性の低いデータとして分離し、最小限の権限、承認、出力制御による多層防御を確立する ✔

説明: Web ページ、ドキュメント、電子メールなど、エージェントまたは RAG によって処理される外部コンテンツは信頼できないデータであり、秘密の指示が含まれている可能性があります。正しいアプローチは多層防御です。明確な区切り文字を使用して外部コンテンツを「コマンドではなくデータ」として分離し、最小限の承認を適用し、不可逆的なアクションを人間の承認に結び付け、出力を監査します。たった 1 行の指示だけでは十分ではありません。

10. 問題を微調整と RAG のどちらで解決するかを決定するときの主な違いは何ですか?

  • A) 情報の問題は RAG でよりよく解決でき、動作/形式の問題は微調整でよりよく解決できます ✔
  • B) すべての問題は常に微調整によって解決されるべきです
  • C) RAG はコード生成のみに使用され、微調整は変換のみに使用されます。
  • D) 微調整はいつでも RAG よりも安価かつ迅速に更新できます

説明: 微調整はモデルに新しい情報を教えるのに弱く、危険です。しかし、指導行動、形式、口調、スタイルにおいては強力です。 「モデル会社は私たちのデータを知らない」は情報の問題であり、RAG に属します。 「モデルを常に厳密な形式で出力させる」は動作上の問題であり、微調整の対象となります。さらに、微調整する前に、プロンプトショットと数ショットを消費する必要があります。

11. 新しいモデルを実稼働環境に導入する際に、安全に導入するために必須なのはどれですか?

  • A) モデルのテストが良好な場合は、100% のトラフィックに対して直接オープンします。
  • B) 導入後に監視をまったく設定していない
  • C) 段階的な導入 (シャドウ/カナリア) と事前テストされたロールバック計画 ✔
  • D) 評価しきい値を満たしていない場合でもモデルを公開する

説明: 新しいモデルをすべてのトラフィックに対して直接開くのは危険です。それが間違っていれば、全員が影響を受けます。正しいのは、これは段階的なディストリビューション (シャドウ、カナリア) であり、すべてのディストリビューションにはテスト済みのロールバック プランがあるということです。クローバック計画がなければ配布は完了しません。数分以内に以前のバージョンに戻すことができるため、実稼働環境でモデルが予期しない動作をした場合にユーザーを保護できます。

12. ML モデルは本番環境で「静かに」失敗する可能性はありますか?また、これを検出する方法は何ですか?

  • A) モデルが崩壊します。サーバーログにはこれが示されています
  • B) 間違いを犯すことなく、間違った予測を立てることによって。 ✔ 運用、入力、出力の階層的なモニタリングをキャプチャします。
  • C) モデルは決して静かに失敗することはなく、常に警告を発します
  • D) レイテンシを監視するだけで、劣化を検出するのに十分です

説明: モデルは、クラッシュしたりエラーが発生したりすることなく、単に間違った予測を生成するだけで失敗する可能性があります。この主な理由は、データのドリフトとコンセプトのドリフトです。運用指標 (レイテンシー、エラー率) を監視するだけでは十分ではありません。入力分布と出力/予測分布も監視する必要があります。入力ドリフトにより、実際の結果が遅れた場合に早期に警​​告が発せられます。

13. LLM システムを評価するために LLM をジャッジとして使用する場合に重要な原則は何ですか?

  • A) LLM 審判は常に正しいため、人間による検証は不要です
  • B) 審判は解答の長さのみに基づいて決定を下さなければなりません。
  • C) 審判を使用する場合、ルールに基づくコントロールと人間による評価は完全に放棄されるべきである
  • D) 審査員のスコアは信頼できる前に、人間がラベルを付けたサンプルで校正し、その偏りを測定する必要があります ✔

説明: LLM 審判員もモデルです。それは幻覚的であったり、偏見(長くて自信に満ちた答えを好む)であったり、一貫性がなかったりする可能性があります。したがって、審査員のスコアは、人間がラベルを付けたサンプルを使用して校正する必要があり、本番の決定が行われる前に、その系統的な偏りを測定する必要があります。検証されていない審判が誤った自信を与える。

14. モデルのバイアスを評価する際に全体的な精度を見ることが不十分なのはなぜですか?

  • A) 常に最悪のグループのパフォーマンスを反映しているため、全体的な精度は十分です。
  • B) 全体的な精度だけでは、サブグループ間の体系的な違い (隠れた差別) がわかりにくくなる可能性があるため不十分です ✔
  • C) 精度はバイアスとは何の関係もない指標であるため
  • D) バイアスはモデルのみから生じ、データとは何の関係もありません。

説明: 全体的な精度により、サブグループ間の系統的な違いが曖昧になる可能性があります。たとえば、全体の精度は 88% ですが、あるグループでは再現率が 91%、別のグループでは 67% になる可能性があります。モデルは体系的にそのグループを見逃します。したがって、モデルはサブグループ (人口統計/セグメント) に基づいて評価される必要があり、どの正義の定義を優先するかは利害関係者とともに決定される必要があります。

15. ML 結果を再現するには、どの 4 つのことを一緒に修正する必要がありますか?

  • A) モデル名、サイズ、価格、発売日のみ
  • B) GPU ブランドとインターネット速度のみ
  • C) モデルの最終精度スコアのみ。残りはメモリに保存できます
  • D) ランダム性シード、データ バージョン、環境 (依存関係バージョン)、および実験の追跡 ✔

説明: 再現性は、ランダム性シードの修正、データのバージョン管理 (バージョン/ハッシュ)、環境の凍結 (正確なライブラリ バージョン/コンテナ)、各実験の追跡 (コードのコミット、データ、ハイパーパラメータ、メトリック) の 4 つの柱によって実現されます。このチェーンがなければ、同じ結果を再現することはできません。再現不可能な結果とは、証明できない主張のことです。