メインコンテンツへスキップ
W&B Tables を使用して、表形式データを可視化し、ログできます。W&B Table は 2 次元のデータグリッドで、各列には 1 つのタイプのデータのみが入ります。各行は、W&B の run にログされた 1 つ以上のデータポイントを表します。W&B Tables は、プリミティブ型や数値型に加えて、ネストされたリスト、辞書、リッチメディア型もサポートします。 W&B Table は、W&B における特殊な データ型 であり、artifact オブジェクトとしてログされます。 W&B Python SDK を使用して、表オブジェクトを作成してログできます。表オブジェクトを作成する際には、表の列とデータ、および モード を指定します。このモードによって、ML Experiments の実行中に表がどのようにログされ、更新されるかが決まります。
INCREMENTAL モードは、W&B Server v0.70.0 以降でサポートされます。

表を作成してログする

  1. wandb.init() で新しい run を初期化します。
  2. wandb.Table クラスを使用して 表 オブジェクトを作成します。columns パラメーターと data パラメーターに、それぞれ表の列とデータを指定します。オプションの log_mode パラメーターは、IMMUTABLE (デフォルト) 、MUTABLEINCREMENTAL の 3 つのモードのいずれかに設定することを推奨します。詳細については、次のセクションの Table Logging Modes を参照してください。
  3. run.log() を使用して表を W&B にログします。
次の例は、2 つの列 ab、および 2 行のデータ ["a1", "b1"]["a2", "b2"] を持つ表を作成してログする方法を示しています。

ログモード

wandb.Tablelog_mode パラメーターは、ML 実験中に表がどのようにログされ、更新されるかを決定します。log_mode パラメーターには、IMMUTABLEMUTABLEINCREMENTAL の 3 つの引数のいずれかを指定できます。各モードによって、表のログ方法、変更可能な範囲、W&B App での表示方法が異なります。 以下では、3 つのログモード、それぞれの主な違い、および各モードの一般的なユースケースについて説明します。 次のセクションでは、各モードのコードスニペット例と、各モードをいつ使用するべきかに関する考慮事項を示します。

MUTABLE モード

MUTABLE モードでは、既存の表を新しい表で置き換えることで更新します。MUTABLE モードは、反復処理ではないプロセスで既存の表に新しい列や行を追加したい場合に便利です。UI では、初回のログ後に追加された新しい行と列も含め、すべての行と列が表示されます。
MUTABLE モードでは、表をログするたびにテーブルオブジェクトが置き換えられます。新しい表で表を上書きする処理は計算コストが高く、大きな表では時間がかかる場合があります。
次の例では、MUTABLE モードで表を作成してログし、その後に新しい列を追加する方法を示します。テーブルオブジェクトは 3 回ログされます。1 回目は初期データ、2 回目は信頼度スコア、3 回目は最終的な予測です。
次の例では、データを読み込むためのプレースホルダー関数 load_eval_data() と、予測を行うためのプレースホルダー関数 model.predict() を使用しています。これらはご自身のデータ読み込み関数および予測関数に置き換える必要があります。
新しい行のバッチだけを (列は追加せずに) トレーニングループのように段階的に追加したい場合は、代わりに INCREMENTAL モード の使用を検討してください。

INCREMENTAL モード

INCREMENTAL モードでは、機械学習の実験中に行のバッチを表にログします。これは、長時間実行されるジョブを監視する場合や、更新のたびに run 中にログすると非効率になる大きな表を扱う場合に適しています。UI では、ログされるたびに新しい行で表が更新されるため、run 全体の完了を待たずに最新のデータを表示できます。また、増分ごとに順にたどって、異なる時点での表を表示することもできます。
W&B App の run Workspace では、増分は 100 件までという上限があります。100 件を超える増分をログした場合、run Workspace に表示されるのは直近の 100 件のみです。
次の例では、INCREMENTAL モードで表を作成してログし、その後に新しい行を追加します。表はトレーニングの各 step (step) ごとに 1 回ログされる点に注意してください。
次の例では、データを読み込むためのプレースホルダー関数 get_training_batch()、モデルをトレーニングするためのプレースホルダー関数 train_model_on_batch()、予測を行うためのプレースホルダー関数 predict_on_batch() を使用しています。これらは、ご自身のデータ読み込み、トレーニング、予測用の関数に置き換える必要があります。
段階的な logging は、毎回新しい表をログする場合 (log_mode=MUTABLE) より、一般に計算効率に優れています。ただし、多数の増分をログすると、W&B App ですべての行が表示されないことがあります。run の進行中に表データを更新して確認しつつ、分析用にすべてのデータも利用できるようにしたい場合は、2 つの表を使うことを検討してください。1 つは INCREMENTAL ログモード、もう 1 つは IMMUTABLE ログモードです。 次の例では、これを実現するために INCREMENTALIMMUTABLE のログモードを組み合わせる方法を示します。
この例では、incr_table はトレーニング中に段階的にログされます (log_mode="INCREMENTAL") 。これにより、新しいデータが処理されるたびに、表の更新をログして表示できます。トレーニングの最後に、段階的にログした表のすべてのデータを含む不変の表 (final_table) が作成されます。不変の表は、後続の分析に備えて完全なデータセットを保持するためにログされ、W&B App ですべての行を表示できるようになります。

MUTABLE で評価結果を充実させる

INCREMENTAL 表で run を再開する

run を再開するときに、INCREMENTAL 表へのログを継続できます。
wandb.Run.define_metric("<table_key>", summary="none") または wandb.Run.define_metric("*", summary="none") を使用して、段階的な表で使用するキーの summary を無効にすると、増分は新しい表にログされます。

段階的バッチトレーニングでトレーニングする