実験追跡ツールの構築方法[Neptuneのエンジニアの学びから]

'Building Experiment Tracking Tool [Inspired by Neptune Engineer's Learning]'

あなたのチームのMLOpsエンジニアとして、MLプラットフォームに機能を追加したり、データサイエンティストが使用するためのスタンドアロンツールを構築することで、データサイエンティストのワークフローを改善することが多いです。

実験の追跡はそのような機能の一つです。そして、この記事を読んでいるということは、サポートしているデータサイエンティストが助けを求めてきた可能性があります。実行される実験はスケーリングし、ますます複雑になっており、実験の追跡と再現性の確保が難しくなっています。

実験管理ツールを構築することで、データサイエンティストをサポートすることができます。

1
異なるプロジェクト間での実験の追跡を行うこと
2
実験に関連するメタデータを保存すること
3
結果を再現し比較すること
4
チームメンバーと結果を共有すること
5
または実験の出力を下流システムに送信すること

この記事は、過去5年間で最も人気のある実験トラッカーの構築とメンテナンスから学んだことの要約です。

neptune.aiのPiotr Łusakowski（アーキテクト）、Adam Nieżurawski（バックエンドテクニカルリード）などのエンジニアからの洞察に基づいて、以下のことを学ぶことができます。

実験追跡ツールの要件を開発する方法
理想的な実験追跡ツールのコンポーネントと、それらが要件を満たす方法
実験追跡ツールのバックエンドレイヤーを設計する方法
実験追跡ツールの構築における技術的な考慮事項

このガイドの重点は、チームに適したツールを構築するための必要な基礎を提供することです。この記事では、実験追跡ツールの技術的な考慮事項やコードの記述については説明しません。

私たちは基礎に焦点を当てることで、書かれたコードは1週間後には重要ではなく、ツールもおそらく6ヶ月後には忘れられる可能性があるためです。

実験追跡ツールの要件を開発する

開発側では、実験追跡ツールを構築する際に解決するべき3つの主要な問題があります。

データサイエンティストがデータとモデルの起源からメタデータとアーティファクトの系譜を処理する支援。
データサイエンティストが実験のパフォーマンスをモニタリングし、効果的な意思決定とデバッグを行うためのインターフェースを提供する。
データサイエンティストがMLプロジェクトの進捗状況を追跡するためのプラットフォームを提供する。

データとモデルの起源からのメタデータとアーティファクトの系譜の処理

実験追跡ツールは、データサイエンティストが実験のアーティファクトの系譜を追跡し、結果のメタデータを保存し、管理するのに役立ちます。実験のデータとモデルの起源がどこから来たかを特定できるようにすることで、データサイエンティストは実験のイベントとそれに至ったプロセスを探索することができます。

これにより、以下の2つの重要な利点が得られます。

再現性: データサイエンティストが実行するすべての実験を再現可能にすること。
説明可能性: 実験結果を説明できるようにすること。

再現可能な実験結果を確保する

実験の結果は再現性が高くなければなりません。これにより、データサイエンティストはお互いや他のチームとの協力がしやすくなり、良いワークフローを作ることができます。再現性を実現するためには、実験のメタデータ（パラメータ、結果、設定ファイル、モデルおよびデータのバージョンなど）、コードの変更、データサイエンティストのトレーニング環境（またはインフラストラクチャ）の設定を追跡するコンポーネントを構築する必要があります。

データのエンドツーエンドのトレーサビリティとトラッキングがなければ、データサイエンティストはモデルを再現したり、エラーやパイプラインを修正することがほとんど不可能です。

ユーザーは、実験の実施方法とその結果に直接影響を与えるモデル開発のコードベース（データ処理コード、パイプラインコード、ユーティリティスクリプトなど）の変更を追跡できる必要があります。

データサイエンティストが実験結果を説明できるようにする

データサイエンティストが期待されるパフォーマンス要件を満たす実験を実施しモデルを構築する際、彼らはまた、なぜモデルが特定の予測を行うのかを判断するために結果を理解する必要があります。もちろん、これはすべての状況で真実ではありませんが、モデルが予測を行う方法と理由を理解する必要がある場合、「説明可能性」は重要になります。

モデルが予測を行う方法や理由を理解する必要がある場合、実験データの出どころ（系譜）、データの処理方法、実験の実行に使用したパラメータ、そしてもちろん、実験の結果を追跡できなければ、彼らのワークフローに説明可能性を追加することはできません。

実験追跡ツールは、データサイエンティストが以下のことができるようにする必要があります：

他の人の実験を調査し、自分の実験を簡単に共有する。
作成された実験の振る舞いを比較する。
望ましくないバイアスやその他の問題のために、すべての実験を追跡および監査する。
トレーニングデータ、コード、またはパラメータが欠落している実験をデバッグおよび比較する。

説明可能性が不可欠なもう1つの理由は、法的なコンプライアンスです。たとえば、GDPRは組織がデータセットに関するメタデータを収集し追跡し、実験から得られたモデルの動作方法を文書化および報告することを要求しています。

効果的な意思決定のための実験のパフォーマンスを監視および評価する

ほとんどの場合、異なるデータセットのバージョンやパラメータで実行された実験の結果を比較することは合理的です。実験追跡ソリューションは、データサイエンティストがモデルパラメータの変更が実験に与える影響を測定するのに役立ちます。彼らは異なるデータバージョンでモデルのパフォーマンスがどのように変化するかを見ることができます。

もちろん、これは堅牢で高性能な機械学習モデルを構築するために役立ちます。トレーニングされたモデル（またはモデル）が未知のデータに適用できることを監視および評価しない限り、データサイエンスチームは確信を持つことができません。データサイエンスチームは、この情報を使用して、最適なモデル、パラメータ、およびパフォーマンス指標を選択することができます。

機械学習プロジェクトの進捗状況を追跡する

実験追跡ソリューションを使用すると、データサイエンスチームや他の関係者はプロジェクトの進捗状況をチェックし、予想されるパフォーマンス要件に向かっているかどうかを確認することができます。

機能要件と非機能要件

ソフトウェアツールの効果的な要件を開発するには、多くの考えが必要です。まず、ビジネスと製品使用に関連する要件を特定する必要があります。次に、要件を明確にし、分析し、テストし、ソフトウェア開発ライフサイクル全体で管理する必要があります。

ユーザーストーリーの作成、分析、および要件の検証は、それぞれ独自の記事に値する要件開発の一部です。このセクションでは、実験追跡ツールの要件開発の最も重要な機能要件と非機能要件の概要を提供します。

ユーザーの理解

チームの構造と組織の設定に応じて、実験追跡ツールを必要とする異なるユーザーがいるかもしれません。しかし、理想的には、データサイエンティストが実験追跡ツールのユーザーであることが望ましいです。大まかに言えば、データサイエンティストが実験追跡ツールで行いたい作業は次のとおりです：

モデルのトレーニング実行をリアルタイムで表示：リモートサーバーやコンピュータから離れた場所でモデルのトレーニングを実行する際、実行が失敗した場合にすばやく対応したり、実行が完了した場合に結果を分析したりするため、モデルのトレーニング実行をリアルタイムで表示したいと思います。
すべてのモデルのトレーニングメタデータを一か所で表示：チームでプロジェクトに取り組んでいる場合や個人で作業している場合でも、すべてのモデルビルディングメタデータを1か所にまとめて表示することで、必要な時にすばやく最適なモデルメタデータを見つけることができ、常にその場所にあるという保証を得たいと思います。
モデルのトレーニング実行を比較：トレーニングされたモデルの異なるバージョンがある場合、モデルを比較し、最も優れたパフォーマンスを示したモデルや動作したパラメータ、異なる入力/出力を確認したいと思います。

機能要件

前のセクションで、実験追跡ツールで解決する問題について学びました。これらは、機能的な実験追跡ツールを構築するための作業です。

実験追跡ソフトウェアの設計を開始するには、理想的な実験追跡ツールが行うべき機能要件を開発する必要があります。以下の表に、ユーザーが行うべき作業に基づいて必要性を示し、その結果の機能がどのようになるかを示しました。

必要	機能
エコシステム内のツールとのシームレスな統合。	実験（モデルトレーニングとデータツール）に活用しているMLフレームワークとの統合。
	ワークフローオーケストレータとCI/CDツールとの統合（スタックがこのレベルの場合）。
メタデータのロギングに複数のデータ型のサポート。	整数、浮動小数点数、文字列などの単純なデータ型の記録。
	浮動小数点数、文字列、画像、ファイル、ファイルディレクトリのシリーズなどの複雑なデータ型の記録。
記録されたメタデータの使用（プログラムとUI経由）。	実行の一覧と実行の詳細を表示できるようにします。トレーニングに使用されたデータバージョン、モデルパラメータ、パフォーマンスメトリクス、アーティファクト、所有者、期間、作成日時など。
	属性によって実験をソートおよびフィルタリングすることができます。たとえば、データセットYのバージョンXでトレーニングされ、精度が0.93以上の実行のみを表示し、作成者でグループ化し、作成日時で並べ替えるようにしたい場合です。
	異なるパラメータ、モデルアーキテクチャ、データセットがモデルの精度、トレーニングのコスト、およびハードウェアの利用にどのように影響するかを比較します。

非機能要件

実験追跡ツールの非機能要件には、次のものが含まれます：

品質	説明
信頼性	実験追跡ツールがトレーニングジョブを破壊しないようにしたいです。それは高額な費用がかかることもあり、もちろん取引が成立しないでしょう。
パフォーマンス	APIと統合は低遅延である必要があります。トレーニングジョブとMLパイプラインが遅くならず（費用がかかるため）、スムーズに動作します。
効率性	アーキテクチャとテクノロジーは、費用対効果を最適化する必要があります。ユーザーは多くの実験を実行し、追跡することができるため、コストがすぐに膨らむ可能性があります。
スケーラビリティ	機械学習は組織内でますます重要になるでしょう。1人のデータサイエンティストが使用しているだけの初期段階のショートカットによってシステムを書き直す必要がある状況になりたくありません。
頑強性	以下をサポートする柔軟なデータモデルが必要です：チームのサイズと構造の変動（単一のデータサイエンティストのみ、またはデータサイエンティスト1人、機械学習エンジニア4人、DevOpsエンジニア2人などのチーム）。さまざまなワークフロー、ユーザーが追跡したい内容を決定できるようにします。一部のユーザーはトレーニング後のフェーズのみを追跡します。他のユーザーはデータ変換のパイプライン全体を追跡したいと考えるかもしれません。また、モデルを本番環境で監視するユーザーもいます。常に変化する環境 – データモデルは、エコシステムの新しいMLフレームワークとツールすべてをサポートできる必要があります。そうでないと、統合はすぐにハッキリとしたものになり、保守が難しくなる可能性があります。

外部統合の要件：ソフトウェアが実験に使用するデータセットに関するメタデータを収集できるようにするために、統合を設定する必要があります。

実験追跡システムのアーキテクチャ

理想的な実験追跡システムには3つのレイヤーがあります：

1
フロントエンド/UI。
2
バックエンド。
3
クライアントライブラリ（API / エコシステム統合）。

これらのコンポーネントが何をするのか、なぜそれらが必要なのかを理解したら、実験トラッキングのニーズに合わせたシステムを構築することができます。

実験システムのフロントエンドレイヤーの構築

フロントエンドはほとんどのユーザーリクエストをインターセプトし、バックエンドサーバーに送信して実験トラッキングロジックを実行します。リクエストとレスポンスのほとんどはフロントエンドレイヤーを経由する必要があるため、多くのトラフィックを受けるため、最高の同時実行レベルを処理できる必要があります。

フロントエンドレイヤーは、実行する実験を視覚化し、対話する方法でもあります。実験トラッキングシステムのフロントエンドの最も重要な部分は何ですか？

実験メタデータの視覚化

データサイエンスの多くの実験は、データの視覚化からトレーニング済みモデルとそのパフォーマンスのリアルタイムモニタリングまでを扱います。フロントエンドレイヤーは、シンプルな文字列から埋め込まれたJupyterノートブック、ソースコード、ビデオ、カスタムレポートまで、あらゆる種類の実験メタデータを表示できる必要があります。

数百の実行とその属性の表示

実行中、実行後に関連するプロパティとログされたメタデータを含めて実験の詳細を確認できるようにしたいです。このようなメタデータには、以下が含まれます：

使用されたアルゴリズム。
パフォーマンスメトリクスと結果。
実験の期間。
入力データセット。
実験の開始時刻。
実行の一意の識別子。
その他、必要と思われるプロパティ。

また、結果に基づいて実行を比較し、実験間での比較も行う必要があります。

ユースケースに重要であれば、これらの属性を使用して実験に説明可能性の特徴と属性を追加することもできます。そして、もちろん、このビューからモデルをプロモーションしたり、ダウンロードしたりすることもできるかもしれません。

状態の管理とパフォーマンスの最適化は、UIコンポーネントの中でも最も複雑な部分の2つです。数千の属性を持つ10の実行を比較することは、動的なチャートに表示する必要がある属性の多くがあるため、多くの頭痛を引き起こす可能性があります。VoAGIサイズのプロジェクトであっても、うまく行かないとブラウザが常にフリーズするかもしれません。

パフォーマンス以外にも、プロジェクトの属性のサブセットのみを表示したり、特定の属性で実行をグループ化したり、他の属性でソートしたり、ヒントと補完のあるフィルタクエリエディタを使用したりするなどのUIの調整も可能です。

システムのバックエンド

システムのバックエンドは、実験トラッキングソリューションのロジックをサポートします。このレイヤーでは、実験トラッキングドメインのルールをエンコードし、データの作成、保存、変更方法を決定します。

フロントエンドはこのレイヤーのクライアントの1つです。モデルレジストリ、データ品質モニタリングコンポーネントなどの他のクライアントも持つことができます。従来のソフトウェアと同様に、このレイヤーと次のセクションで学ぶAPIレイヤーにサービスを作成することが効果的です。

基本的な実験トラッキングツールでは、次の2つの主要なシステムバックエンドコンポーネントを実装する必要があります：

1
ユーザー、プロジェクト、およびワークスペースの登録。
2
実際のトラッキングコンポーネント。

ユーザー、プロジェクト、およびワークスペースの登録

このコンポーネントは、実験トラッキングツールのユーザーを管理し、実行する実験の活動を追跡するのに役立ちます。このコンポーネントが行う主な機能は次のとおりです：

認証と承認の処理。
プロジェクトの管理と権限設定。
プロジェクトまたはワークスペースごとのクォータ（秒間リクエスト数、ストレージ容量）。

どのような詳細な権限レベルを実装したいですか？細かい権限、カスタムロール、または粗い事前定義されたロールのいずれかを選択できます。

トラッキングコンポーネント

トラッキングコンポーネントは、実際の実験トラッキングロジックを実装する必要があります。以下に実装するべきいくつかの要素を示します：

属性の保存。
Blob と ファイルの保存。
シリーズの保存。
クエリエンジン。

属性の保存

実行には属性（パラメータ、メトリック、データサンプルなど）があり、そのようなデータを実行と関連付ける方法が必要です。これは属性の保存とデータの一般的な組織化が重要で、データの検索がユーザーにとって容易になります。もちろん、関係データベースがここで価値を持ちます。

一貫性のレベルはどれくらいですか？最終的な一貫性を受け入れることはできますか？それともAPI層のレイテンシを高くする代わりに強力な一貫性を持つことを希望しますか？

Blobとファイルの保存

一部の属性はデータベースのフィールドに簡単には収まらず、このためにデータモデルが必要になります。Blobの保存は非常に費用効果の高い解決策です。主な利点は、大量の非構造化データを保存できることです。ユーザーはソースコード、データサンプル（CSV、画像、ピクルされたデータフレームなど）、モデルの重み、設定ファイルなどを保存したい場合があります。この解決策は便利です。

ここで重要な考慮事項は、保存サービスの長期的な費用対効果と低レイテンシのアクセスです。

シリーズの保存

特に数値シリーズであるシリーズを保存する方法を決定する必要があります。ユースケースによっては、数十から数百万の要素を持つことがあります。ユーザーがUIでデータにアクセスできるようにする方法でそれらを保存することは挑戦です。また、多くのユースケースに十分な1,000の要素までサポートすることもできます。

重要な考慮事項は次のとおりです：

1
長期的な保存の費用対効果。
2
機能のトレードオフ。
3
相対的な実装のシンプルさ。

クエリエンジン

非常に異なる構造を持つ実行をフィルタリングする機能を追加する必要もあります。これは、この種のクエリを効果的に処理できる堅牢なデータベースエンジンが必要です。一般的な関係データベースではデータ量が少ない場合に効果的に処理することができません。代替として、フィルタリングまたはグループ化できる実験属性の数を厳しく制限することができます。より低レベルに進むと、いくつかのデータベースのハックやトリックを使って問題を解決することができます。

重要な考慮事項は、ユーザーがフィルタリング、ソート、グループ化できる属性の数と実装のシンプルさとのトレードオフです。

クライアントライブラリ（APIとエコシステムの統合）

高レベルでは、API層はクライアントが特定の操作を公開するサービスやAPIエンドポイントを知らなくても済むようにするために使用されます。これは非常に便利です。バックエンドレイヤーと同じように何も変更せずに実行するか、ロジックを実行するべきではありません。代わりに、構成したサービスエンドポイントとAPI操作を公開する標準のプロキシインターフェースを提供する必要があります。

実験トラッキングツールを構築する場合、生の（ネイティブの）APIだけでは十分ではありません。ソリューションがユーザーによって使用されるためには、ユーザーのコードとシームレスに統合する必要があります。API層を最初に定義すると、API契約が変更されない限り、クライアントは最小限、もしくは全く変更する必要がありません。

これは実際には、（可能ならPythonを使用した）ライブラリがバックエンドサーバーとの通信を処理することを意味します。リトライやバックオフの処理を行い、データの耐久性のために永続的であり、ユーザーのモデルトレーニングプロセスが遅くならないように非同期キューを実装することが望ましいです。

実験トラッキングツールはデータ、トレーニング、およびモデルのプロモーションツールなどとも連携する必要があるため、API層はMLおよびデータエコシステムのツールと統合する必要があります。

MLおよびデータエコシステムは進化するため、統合を構築するだけでは終わりません。統合は、統合が動作するツールの新しいバージョンでテストされ、APIが非推奨になるか、より頻繁に変更されるときに更新する必要があります。また、ユーザーに変更を強制することなく、統合のレガシーバージョンにユーザーを誘導することで、これを解決することもできます。

実験トラッキングソフトウェアアーキテクチャ（バックエンド）の考慮事項

実験トラッキングシステムの構造を構築し、正しく構築しているかどうかを評価することは重要な部分です。これは、確立した要件に基づいて高レベルのアーキテクチャを開発することを意味します。

アーキテクチャの設計では、分析したレイヤーとコンポーネントが層状のアーキテクチャでどのように組み合わされるかを示すべきです。 “層状アーキテクチャ” とは、フロントエンドアーキテクチャをバックエンドアーキテクチャと区別することを意味します。この記事では、実験トラッキングのロジックがエンコードされるバックエンドアーキテクチャの考慮事項に焦点を当てています。

バックエンドアーキテクチャを理解したら、ドメイン駆動設計の原則に従ってフロントエンドアーキテクチャを構築することもできます。

バックエンドアーキテクチャレイヤー

システムのアーキテクチャを構築するためには、構造をできるだけシンプルかつ効率的にするためのソフトウェアアーキテクチャの原則に従う必要があります。その原則の1つは、モジュール性を説明します。ソフトウェアがモジュール化されて、ソースコードをすばやく理解できるようにし、システムの構築時間を節約し、技術的な負債を可能な限り減らすことが目標です。

実験の追跡をするためのツールはほぼ確実に進化するでしょうから、最初のアーキテクチャを開発する際は、大まかでただ動作するものになるでしょう。アーキテクチャは時間の経過とともに変化するため、メンテナンスや新機能の追加に時間を節約するために一貫したデザインパターンに従う必要があります。

以下は、要件とリストアップされたコンポーネントを考慮に入れた基本的な実験トラッキングソリューションのバックエンドアーキテクチャレイヤーの例です:

前述のパーツを使用して、アーキテクチャ内の異なるモジュールを見つけ、それらがどのように連携するかを確認できます。

アーキテクチャ上の考慮事項: 認証と認可を別々にする

アーキテクチャの中で、認証と認可が別々になっていることに気付いたかもしれません。異なるユーザーがいる場合、ユーザーは自分の資格情報を認証コンポーネントを通じて検証する必要があります。

ソフトウェア管理者は、認可コンポーネントを通じて各ユーザーの権限とアクセスレベルを管理できます。認証と認可の違いについては、この記事を参照してください。

ユーザー管理コンポーネントの「クオータ管理」部分は、ユーザーに利用可能なストレージ制限を管理するのに役立ちます。

実験トラッキングツールを構築する前に考慮すべき事項

全体的な価値を考えると、実験トラッキングソフトウェアを構築するために必要なことを最高のレベルで学びました。次に自然に浮かぶ疑問は、「実験トラッキングツールを構築する前にどのような考慮事項が必要ですか？」です。

まあ、それは愚かな質問かもしれませんし、おそらくあなたの組織の戦略的なソフトウェア、つまり中核製品が実験トラッキングツールでない場合には尋ねるものではないかもしれません。もし違う場合は、読み続けるべきです。

おそらく、このソフトウェア開発のジレンマはすでにおなじみです。構築するか、購入するか。実験トラッキングツールが組織のオペレーションソフトウェア（データと機械学習チームの定常業務をサポートするためのもの）である場合、この質問に答えるために重要な考慮事項は、組織の以下の成熟度レベルです:

経験
人材
リソース（時間とお金）

この決定を下す際に自分自身に問うべきいくつかの質問を見てみましょう。

組織は過去に実験トラッキングツールを開発したことがありますか？

たとえば、組織が以前に実験トラッカーを開発したことがない場合、業界の標準、ベストプラクティス、セキュリティ、コンプライアンスについての理解を得るためには、時間と試行錯誤が必要です。特にエンジニアリングチームで「基盤」となるものが存在しない場合、一時しのぎのビルドは業界の基準や会社の期待には満たない可能性があります。

あなたと他の関係者は、会社が試行錯誤を余儀なくされることを許容できるか、それとも効果的で安全で信頼性の高い既製のソリューションが必要かを考慮する必要があります。

どのような人材が利用可能ですか？

もし製品やソフトウェアの会社である場合、すでに戦略的な製品に取り組んでいるソフトウェア開発者がいる可能性があります。内部の開発者のスキルを実験トラッキングツールの構築に割くことの機会費用を考慮する必要があります。代わりに、彼らのスキルを主力製品の改善に活用することができます。

社内で実験トラッカーを開発することは、製品の改善やMLチームの効率向上に大きく寄与する可能性があります。しかし、それには開発者のスキルと時間が他のより意義のある差別化要素の構築から取られる可能性があり、時間と労力の浪費にもなり得ます。

開発するためのコストはいくらかかりますか？

社内で実験トラッカーを開発する際のコストは、主に保守コストです。ソフトウェアを最新の状態に保つためのコスト、バグ修正や新機能の追加にかかるコストを組織は負担できるでしょうか？

予算には、ツールの稼働に必要なインフラストラクチャの費用や、元の開発者が退職した場合に新しい人材を雇うための費用が含まれます。短期的な節約だけでなく、高額で時間のかかるソフトウェア開発プロジェクトの長期的な影響についても考えてください。

保守コストを下げる大きな要素は、高額な予期せぬ費用が一度に発生する可能性を減らすことです。言い換えれば、一般的な保守コストと同様に、何かを構築する必要があるか外部委託するかを決定するソフトウェアライフサイクルの早い段階でリスクを管理するのが最適な時期です。

実験トラッキングツールの開発にはどれくらいの時間がかかりますか？

機会費用を考慮する必要があります。例えば、カスタムツールを作るのに2ヶ月かかる場合、その時間に他に何を構築できますか？トラッキングコンポーネントの実装に2ヶ月以上かかりますか？POCから最終的な安定版リリースまでツールを構築するためにどれくらいの開発サイクルが必要ですか？

大企業の一部であり、実験トラッカーを構築するために十分な開発サイクルがある場合、それは問題ではありません。しかし、それが特にあなたのユースケースに固有の問題でない場合はどうでしょうか？戦略的なソフトウェアの構築に集中できるように、スタックと統合できる市販のソリューションを選ぶ方が良いかもしれません。

標準的な実験管理ツールの必要な洗練度や機能の豊富さに十分な開発サイクルがあるとは考えにくいため、それに開発サイクルを割く価値があるかどうかは疑問です。

例えば、neptune.aiでは、過去5年間、ユーザーのモデル構築メタデータを管理し、実験を追跡するための堅牢なメタデータストアの構築に専念してきました。顧客やMLコミュニティから学び、製品をさまざまなユースケースとワークロードにわたって強固に改善してきました。

デザインとアーキテクチャの犠牲による高速なコーディングはほとんど常に間違った選択です。特にソフトウェアが運用されている場合は、良いアーキテクチャに焦点を当て、必要な機能を構築する時間が少ないためです。結局のところ、それは直接的に組織に影響を与えたり定義する戦略的なソフトウェアではありません。

最終的な考え

この記事ではかなり多くの内容をカバーしましたが、いくつかのキーポイントを要約しましょう。

実験トラッキングは集中的な活動です。適切なツールと自動化を使用することで、ユーザーフレンドリーかつ効率的になります。
実験トラッキングツールの効果的な要件を開発するには、ユーザーがソフトウェアをどのように活用し、データスタックやダウンストリームサービスとの統合方法を考慮する必要があります。基本的には、起動して実行するために必要な最低限の要件について考えることです。
実験トラッキングソフトウェアのバックエンド層は最も重要な層です。トラッキングコンポーネントとワークスペースレジストリを実装して、ユーザーセッションをスムーズに管理する必要があります。

実験トラッカーを構築する目的は、ユーザーが実験データを記録し、それらの実験を追跡し、安全に共同作業するためのコンポーネントを提供することです。もしオーバーヘッドのない状態でこれらを行えるなら、おそらくチームにとって有効なものを構築したと言えるでしょう。

ほとんどの場合、最初のバージョンを構築することは最初のステップに過ぎません。特にそれが組織のコアソフトウェアコンポーネントでない場合、新しい問題が増えるにつれて新機能を追加することは困難かもしれません。

あなたと関係するステークホルダーは、ユーザーのニーズや潜在的な業界標準に追従するためにリソースを割く価値を検討する必要があります。

次のステップ

では、次はどうするのでしょうか？構築に向けてワクワクしていますか？それとも市販のソリューションを利用する方が良いと思いますか？

私たちが検討したモデルレジストリプラットフォームの大部分は、モデルを格納するための特定の形式を想定していました。これは、実験ごとにモデルが次々と登場する形式でした。しかし、Stitch Fixの場合、モデルは線形のターゲティングパターンに従っていません。

それらは特定の地域、事業部門、実験などに適用可能であり、お互いとある程度互換性があります。これらの次元の簡単な管理は、データサイエンティストがモデルにアクセスする方法にとって重要でした。

— Elijah Ben Izzy と Stefan Krawczyk、「Deployment for Free;
A Machine Learning Platform for Stitch Fix’s Data Scientists」より

これは、なぜ既存のソリューションを使用せずにモデルレジストリを構築することに決めたのかについて、ステファン・クラウチクが話しているものです。同様の文脈で、既存のオープンソースまたは有料のソリューションでは特別なユーザー要件を満たさない場合を除いて、実験トラッキングツールの構築と維持は、開発者の時間と労力を最も効率的に使う方法ではないかもしれません。

より詳しく調査したいですか、それとも実験トラッカーの構築について話し合いたいですか？お気軽にご連絡ください。私たちは経験を交換することを楽しみにしています。

もちろん、モデルの構築をスキップして代わりに Neptune を使用することを決めた場合は、まずサインアップして試してみてください。ご質問がある場合はお気軽にお問い合わせください！

参考文献とリソース

DALEX と Neptune を使用した解釈可能で再現可能な機械学習モデル開発 – neptune.ai
ソフトウェアを購入するべきか、構築するべきか？ – YouTube

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!

ML Experiment Tracking

Was this article helpful?

93 out of 132 found this helpful