Artifacts について
アーティファクトとは、ギリシャの アンフォラ のように、プロセスの出力として生成されたオブジェクトのことです。 ML において、最も重要なアーティファクトは datasets(データセット)と models(モデル)です。 そして、コロラドの十字架 のように、これらの重要なアーティファクトはしかるべき場所に保管されるべきです。 つまり、あなたやあなたのチーム、そして ML コミュニティ全体がそれらから学べるように、カタログ化され整理されている必要があります。 結局のところ、トレーニングを追跡しない者は、同じ失敗を繰り返す運命にあるのです。 Artifacts API を使用すると、W&BRun の出力として Artifact をログに記録したり、Run の入力として Artifact を使用したりできます。以下の図は、トレーニングの run がデータセットを入力として受け取り、モデルを生成する様子を示しています。

Artifact と Run は共に有向グラフ(Artifact と Run をノードとし、Run とそれが消費または生成する Artifact を矢印で結ぶ、二部 DAG)を形成します。
Artifacts を使用したモデルとデータセットの追跡
インストールとインポート
Artifacts は、バージョン0.9.2 以降の Python ライブラリに含まれています。
他の多くの ML Python スタックと同様に、pip 経由で利用可能です。
Dataset のログ記録
まず、いくつかの Artifacts を定義しましょう。 この例は PyTorch の “Basic MNIST Example” に基づいていますが、TensorFlow や他のフレームワーク、または純粋な Python でも同様に行うことができます。 以下のDataset から始めます:
- パラメータ選択のための
trainセット - ハイパーパラメーター選択のための
validationセット - 最終モデル評価のための
testセット
load するコードと、データを load_and_log するコードが分離されています。
これは良いプラクティスです。
これらのデータセットを Artifacts としてログに記録するには、以下の手順が必要です。
wandb.init()でRunを作成する (L4)- データセット用の
Artifactを作成する (L10) - 関連する
fileを保存し、ログに記録する (L20, L23)
wandb.init()
Artifact を生成する Run を作成する際は、それがどの project に属するかを指定する必要があります。
ワークフローに応じて、プロジェクトは car-that-drives-itself のような大きなものから、iterative-architecture-experiment-117 のような小さなものまで様々です。
ベストプラクティス: 可能であれば、実行する可能性のある様々な種類のジョブを追跡しやすくするために、Artifactを共有するすべてのRunを1つのプロジェクト内に収めてください。これにより管理がシンプルになりますが、心配はいりません。Artifactはプロジェクト間で持ち運び可能です。
Run を作成する際に job_type を指定すると便利です。これにより、Artifacts のグラフが整理された状態に保たれます。
ベストプラクティス:job_typeは記述的で、パイプラインの単一のステップに対応させるべきです。ここでは、データのloadとデータのpreprocessを分けています。
wandb.Artifact
何かを Artifact としてログに記録するには、まず Artifact オブジェクトを作成する必要があります。
すべての Artifact には name があります。これは最初の引数で設定します。
ベストプラクティス: name は記述的でありながら、覚えやすく入力しやすいものにすべきです。ハイフンで区切られ、コード内の変数名に対応する名前を使うのが好ましいです。
また、type も持っています。Run の job_type と同様に、これは Run と Artifact のグラフを整理するために使用されます。
ベストプラクティス:また、typeはシンプルにすべきです。mnist-data-YYYYMMDDよりも、datasetやmodelのようなものを使用してください。
description(説明)や、辞書形式の metadata を添付することもできます。metadata は JSON にシリアル化可能である必要があります。
ベストプラクティス: metadata はできるだけ詳細に記述すべきです。
artifact.new_file と run.log_artifact
Artifact オブジェクトを作成したら、そこにファイルを追加する必要があります。
その通り、複数形の files です。Artifact は、ファイルとサブディレクトリを持つディレクトリのような構造をしています。
ベストプラクティス: 意味がある場合は常に、Artifact の内容を複数のファイルに分割してください。これは、将来スケールアップする際に役立ちます。
new_file メソッドを使用すると、ファイルの書き込みと Artifact への添付を同時に行うことができます。後ほど、これら2つのステップを分ける add_file メソッドも使用します。
すべてのファイルを追加したら、wandb.ai に対して log_artifact を行う必要があります。
出力に Run ページへの URL を含むいくつかの URL が表示されたことに気づくでしょう。そこから、ログに記録された Artifact を含む Run の結果を確認できます。
Run ページの他のコンポーネントをより活用する例を以下で見ていきます。
ログに記録された Dataset アーティファクトの使用
W&B のArtifact は、博物館の展示物とは異なり、ただ保管されるだけでなく 使用 されるように設計されています。
それがどのようになるか見てみましょう。
以下のセルでは、生のデータセットを受け取り、それを使用して preprocess(前処理)されたデータセット(正しく normalize され、形状が整えられたもの)を生成するパイプラインステップを定義しています。
ここでも、コードの核となる preprocess と、wandb とインターフェースするコードを分けていることに注目してください。
preprocess ステップを wandb.Artifact のログ記録で計測するコードです。
以下の例では、新しい要素である Artifact の use(使用)と、前のステップと同じ log(ログ記録)の両方を行っていることに注意してください。Artifact は Run の入力でも出力でもあります。
新しい job_type である preprocess-data を使用して、これが前のジョブとは異なる種類のジョブであることを明確にします。
steps が metadata として preprocessed_data と共に保存されていることです。
実験の再現性を高めようとするなら、多くのメタデータをキャプチャしておくのは良いアイデアです。
また、データセットが「large artifact」であっても、download ステップは1秒足らずで完了します。
詳細については、以下のマークダウンセルを展開してください。
run.use_artifact()
これらのステップはより単純です。消費側は Artifact の name と、もう少しの情報を知っているだけで済みます。
その「もう少しの情報」とは、使用したい特定のバージョンの Artifact の alias(エイリアス)です。
デフォルトでは、最後にアップロードされたバージョンに latest タグが付けられます。それ以外の場合は、v0/v1 などで古いバージョンを選択したり、best や jit-script のような独自のエイリアスを指定したりできます。Docker Hub のタグと同様に、エイリアスは名前と : で区切られるため、必要な Artifact は mnist-raw:latest となります。
ベストプラクティス: エイリアスは短く簡潔に保ちましょう。特定のプロパティを満たすArtifactが必要な場合は、latestやbestのようなカスタムaliasを使用してください。
artifact.download
さて、download の呼び出しについて心配されるかもしれません。別のコピーをダウンロードすると、メモリへの負担が倍増するのではないでしょうか?
ご安心ください。実際に何かをダウンロードする前に、適切なバージョンがローカルに存在するかどうかを確認します。これには、トレント や git によるバージョン管理 の根底にある技術であるハッシュ化が使用されています。
Artifact が作成されログに記録されると、作業ディレクトリ内の artifacts というフォルダに、Artifact ごとのサブディレクトリが作成され始めます。!tree artifacts でその内容を確認してみましょう。
Artifacts ページ
Artifact をログに記録して使用したので、Run ページの Artifacts タブを確認してみましょう。
wandb の出力から Run ページの URL に移動し、左サイドバーから “Artifacts” タブを選択します(データベースのアイコンで、ホッケーのパックが3つ重なっているような形をしています)。
Input Artifacts テーブルまたは Output Artifacts テーブルのいずれかの行をクリックし、各タブ(Overview, Metadata)をチェックして、その Artifact についてログに記録されたすべての情報を確認します。
私たちは特に Graph View(グラフ表示)を推奨しています。デフォルトでは、Artifact の type と Run の job_type を2種類のノードとし、消費と生成を矢印で表したグラフが表示されます。
Model のログ記録
これで Artifacts API の仕組みは十分に理解できたと思いますが、Artifacts がどのように ML ワークフローを改善できるかを確認するために、この例をパイプラインの最後まで進めてみましょう。 最初のセルでは、PyTorch で DNNmodel(非常にシンプルな ConvNet)を構築します。
まずはモデルの初期化のみを行い、トレーニングは行いません。そうすることで、他のすべてを一定に保ちながらトレーニングを繰り返すことができます。
run.config オブジェクトを使用してすべてのハイパーパラメーターを保存します。
その config オブジェクトの dict 形式は非常に有用な metadata になるため、必ず含めるようにしてください。
artifact.add_file()
データセットのログ記録の例のように new_file で書き込みと Artifact への追加を同時に行う代わりに、あるステップでファイルを書き込み(ここでは torch.save)、別のステップでそれらを Artifact に add(追加)することもできます。
ベストプラクティス: 重複を防ぐため、可能な限り new_file を使用してください。
ログに記録された Model アーティファクトの使用
dataset に対して use_artifact を呼び出したのと同様に、initialized_model に対しても呼び出して別の Run で使用することができます。
今回は model を train(トレーニング)しましょう。
詳細については、PyTorch での W&B 計測 に関する Colab をご覧ください。
Artifact を生成する Run を2つ別々に実行します。
最初の run が model の train を完了すると、2番目の run が trained-model アーティファクトを消費し、test_dataset でそのパフォーマンスを evaluate(評価)します。
また、ネットワークが最も混乱している(categorical_crossentropy が最も高い)32個のサンプルを抽出します。
これは、データセットやモデルの問題を診断するのに最適な方法です。
Artifact 機能を追加するものではないため、詳細は省略します。単に Artifact を use し、download し、log しているだけです。