GaiaExGaiaEx
モデル監視のための TensorFlow、Keras、TensorBoard
開発者AI & ML12 min read

モデル監視のための TensorFlow、Keras、TensorBoard

Google の ML フレームワークと、その強力な可視化ダッシュボード

投稿を共有

TensorFlow エコシステム — 単なるフレームワークではない

TensorFlow は Google Brain が開発し、2015 年にリリースされた深層学習ライブラリです。ただし、単なるライブラリではなく、どのような規模でも機械学習モデルを構築・学習・デプロイ・監視できる一つのエコシステムです。研究分野では PyTorch が優勢ですが、TensorFlow は今も本番運用の主力であり、Google、Airbnb、Twitter など数千社のシステムで日々数十億件の予測処理を支えています。

このエコシステムは ML のライフサイクル全体をカバーしています。

  • Keras — モデルの構築・学習を行う高レベル API。現在は tf.keras として TensorFlow に完全統合されている
  • TensorBoard — 学習の監視、実験の比較、モデルのデバッグを行う可視化ツールキット
  • tf.data — 大規模データセットをモデルに供給する高性能データパイプライン
  • TensorFlow Serving — バージョン管理・バッチ処理・ハードウェアアクセラレーションに対応した本番運用向けモデルサービング
  • TensorFlow Lite — モバイル・エッジデバイス向けに最適化されたランタイム
  • TensorFlow.js — ブラウザ上で直接モデルを実行

この幅広さこそが TensorFlow 最大の強みです。Jupyter notebook で Keras を使ってモデルを試作し、GPU クラスタで学習し、TensorBoard で学習状況を監視し、TF Serving で API の背後にサービングし、さらに圧縮版を Raspberry Pi にデプロイする——これらすべてを同じフレームワーク内で行えます。金融アプリケーションでは、クラウド上のトレーディングエンジン(GaiaEx の API に接続)と、リサーチ用のローカルワークステーションの両方でモデルを動かす必要がある場合があり、この汎用性が重要になります。

TensorFlow ML lifecycle (simplified) Data Keras Train TB logs Serve / edge Same graph can feed research notebooks and production if you standardize artifacts (SavedModel). tf.data pipelines keep GPUs fed; TF Serving versions models without downtime
試作、学習、観察、デプロイ——一つのスタックで、多様なランタイムに対応する。

Keras — モデル構築のための Sequential API と Functional API

Keras は「ニューラルネットワーク構築の認知的な負荷を減らす」という一つの指針のもとに設計されています。これを実現するのが、複雑さのレベルに応じて使い分ける 2 種類のモデル構築 API です。

Sequential API は最もシンプルで、レイヤーを一列に積み重ねます。

import tensorflow as tf
from tensorflow import keras

model = keras.Sequential([
    keras.layers.Dense(128, activation="relu", input_shape=(20,)),
    keras.layers.Dropout(0.3),
    keras.layers.Dense(64, activation="relu"),
    keras.layers.Dropout(0.2),
    keras.layers.Dense(1, activation="sigmoid"),
])

複数の入力・複数の出力、レイヤーの共有、スキップ接続を持つモデルには、グラフレベルで完全に制御できる Functional API を使います。

price_input = keras.Input(shape=(60, 5), name="price_sequence")
meta_input = keras.Input(shape=(10,), name="metadata")

x = keras.layers.LSTM(64, return_sequences=True)(price_input)
x = keras.layers.LSTM(32)(x)

combined = keras.layers.concatenate([x, meta_input])
combined = keras.layers.Dense(64, activation="relu")(combined)
output = keras.layers.Dense(1, activation="sigmoid")(combined)

model = keras.Model(inputs=[price_input, meta_input],
                    outputs=output)

このモデルは 2 つの入力を受け取ります。積み重ねた LSTM で処理する 60 ステップの価格系列と、静的な特徴量からなるメタデータベクトルです。これらを結合し、方向性の予測を出力します。この構成は金融 ML でよく使われるパターンで、時間的なパターン(直近の価格の動き)とコンテキスト情報(ボラティリティのレジーム、ファンディングレート、曜日など)を組み合わせたい場合に用いられます。

金融アプリケーションで使う主なレイヤータイプは、表形式の特徴量には Dense、時系列には LSTMGRU、局所的な時間パターンの学習には Conv1D、Transformer 型の系列モデリングには MultiHeadAttention です。

モデルのコンパイルと、より賢い学習のためのコールバック

構築が終わった Keras モデルは、オプティマイザ、損失関数、評価指標の 3 要素を指定して コンパイル する必要があります。

model.compile(
    optimizer=keras.optimizers.Adam(learning_rate=1e-3),
    loss="binary_crossentropy",
    metrics=["accuracy", keras.metrics.AUC(name="auc")],
)

history = model.fit(
    X_train, y_train,
    epochs=100,
    batch_size=64,
    validation_data=(X_val, y_val),
    callbacks=[...],
)

コールバック は、学習中の特定のタイミング——各エポック後、各バッチ後、あるいは特定の条件を満たしたとき——に実行されるフックです。手動で監視する必要がある学習管理を自動化してくれます。

  • EarlyStopping — 検証損失が patience エポックの間改善しなくなったら学習を停止します。過学習と計算資源の浪費を防ぎます。restore_best_weights=True を設定すると、自動的に最良のチェックポイントに戻ります。
  • ModelCheckpoint — 検証性能が改善するたびにモデルを保存します。学習のクラッシュや後のエポックでの過学習によって、最良のモデルを失うことがなくなります。
  • ReduceLROnPlateau — 検証損失が停滞したときに学習率を下げます。固定の学習率では見逃してしまう追加の性能改善を引き出せることが多く、モデルは最初に大きなステップで学習し、その後小さなステップで微調整します。
callbacks = [
    keras.callbacks.EarlyStopping(
        monitor="val_loss", patience=15,
        restore_best_weights=True),
    keras.callbacks.ModelCheckpoint(
        "best_model.keras", monitor="val_auc",
        mode="max", save_best_only=True),
    keras.callbacks.ReduceLROnPlateau(
        monitor="val_loss", factor=0.5,
        patience=5, min_lr=1e-6),
    keras.callbacks.TensorBoard(log_dir="./logs"),
]

EarlyStopping と ModelCheckpoint は必ず併用しましょう。金融モデルを必要以上に多くのエポックで学習させると、ほぼ確実に過学習が起こります——モデルが学習データ中のノイズを記憶し始めるのです。この 2 つのコールバックを使えば、適切なタイミングで学習を止め、正しい重みを保持できます。

TensorBoard — 学習の可視化とモデルのデバッグ

TensorBoard は TensorFlow の可視化ツールキットであり、TensorFlow、PyTorch、JAX のどれを使っていても、ML 実務者のワークフローの中で最も価値のあるツールの一つです。生の学習ログを、モデルの内部で何が起きているかを明らかにするインタラクティブなダッシュボードに変換します。

TensorBoard は、ログディレクトリを指定して起動します。

# Terminal
tensorboard --logdir=./logs --port=6006

# Or in a Jupyter notebook
%load_ext tensorboard
%tensorboard --logdir ./logs

金融モデル開発で重要な可視化は以下のとおりです。

Scalars(スカラー) — 学習損失と検証損失の推移を時系列でプロットしたものです。両者の差が過学習を示します。学習損失が下がり続ける一方で検証損失が上昇している場合、モデルはノイズを記憶していることになります。健全な学習では両方の曲線が一緒に下がっていき、検証曲線は学習曲線よりわずかに上に位置します。

Histograms(ヒストグラム) — 各レイヤー・各エポックにおける重み、バイアス、活性化の分布です。重みの分布がゼロに収束する(勾配消失)、大きな値に発散する(学習の不安定化)、活性化が 0 や 1 に飽和する(死んだニューロン)といった問題がないか確認します。これらの問題は損失曲線には現れませんが、ヒストグラムには明確に表れます。

Embeddings(埋め込み) — 高次元の表現を t-SNE や PCA で 2 次元・3 次元空間に投影します。モデルが内部表現の中で、異なる市場レジーム、アセットクラス、ボラティリティ状態を分離して学習できているかを可視化できます。

HParams — 実験間でハイパーパラメータの組み合わせを比較します。同じモデルを異なる学習率、アーキテクチャ、ドロップアウト値で実行し、どの組み合わせが最良の検証指標を生み出すかを特定します。この体系的な比較によって、当てずっぽうの試行を、根拠に基づくモデル選択に置き換えられます。

TensorBoard は torch.utils.tensorboard.SummaryWriter クラスを通じて PyTorch でも利用できます。この可視化ツールはフレームワークに依存しない設計になっており、これが TensorBoard が ML エコシステム全体で事実上の標準になっている理由の一つです。

TensorBoard panels (conceptual) Scalars train vs val loss Histograms weights / activations HParams compare runs Overfitting shows up as diverging curves before it shows up in your P&L backtest.
Scalars はフィットの良さを、Histograms は壊れたレイヤーを検知し、HParams は実験同士を比較する。

本番運用のための tf.data パイプラインと TensorFlow Serving

データセットがメモリに収まらないほど大きい場合——GaiaEx のような取引所のティックレベルデータを扱う際によくある状況です——tf.data は、すべてを一度にロードすることなく GPU にデータを供給し続ける、効率的で並列化されたデータパイプラインを提供します。

dataset = tf.data.Dataset.from_tensor_slices((features, labels))
dataset = (dataset
    .window(60, shift=1, drop_remainder=True)
    .flat_map(lambda w: w.batch(60))
    .batch(64)
    .prefetch(tf.data.AUTOTUNE)
)

prefetch(AUTOTUNE) の呼び出しは非常に重要です。これによりデータの読み込みとモデルの計算を重ねて実行できるため、GPU が次のバッチを待ってアイドル状態になることがありません。複雑な特徴量エンジニアリングを行う金融データセットでは、.map() による変換を連鎖させて並列実行し、指標や正規化を事前計算・保存するのではなく、その場で計算することができます。

TensorFlow Serving は、高性能な gRPC や REST の API の背後にモデルをデプロイするための本番運用向けシステムです。モデルのバージョン管理(新しいモデルをサービングしつつ古いモデルをフォールバックとして保持する)、リクエストのバッチ処理(複数の推論リクエストをまとめて GPU の効率を上げる)、ハードウェアアクセラレーションに対応しており、レイテンシと信頼性の両方が重要なトレーディングシステムでは欠かせない機能です。

# Export a SavedModel
model.save("models/price_predictor/1")

# Serve with Docker
# docker run -p 8501:8501 \
#   --mount type=bind,source=$(pwd)/models,target=/models \
#   -e MODEL_NAME=price_predictor \
#   tensorflow/serving

典型的な本番アーキテクチャはこうです。トレーディングボットが GaiaEx の WebSocket フィードに接続し、リアルタイムで特徴量を計算し、TF Serving に推論リクエストを送り、1 桁台のミリ秒で予測結果を受け取ります。新しいデータで再学習した場合は、更新されたモデルをバージョン 2 としてデプロイすれば、TF Serving はダウンタイムなしで切り替えてくれます。

TensorFlow Lite、エッジデプロイ、そして TF と PyTorch の比較

TensorFlow Lite は、モバイルデバイス、組み込みシステム、エッジハードウェアへのデプロイのためにモデルを圧縮します。量子化(32 ビット浮動小数点の重みを 8 ビット整数に変換する)、プルーニング(ほぼゼロの重みを取り除く)、アーキテクチャの最適化といった手法により、TF Lite は精度の大部分を保ったままモデルを 4 倍以上に縮小できます。これにより、計算リソースが限られたデバイス上でも直接推論を実行できるようになり、クラウド基盤に依存せず単独で動作する必要があるエッジのトレーディングノードや監視ダッシュボードで役立ちます。

# Convert a Keras model to TF Lite
converter = tf.lite.TFLiteConverter.from_saved_model("models/v1")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
tflite_model = converter.convert()

with open("model.tflite", "wb") as f:
    f.write(tflite_model)

TensorFlow と PyTorch——金融アプリケーションではどちらを選ぶべきか。

  • リサーチ・試作向け: PyTorch です。動的グラフ、Python らしい API、そして学術研究における圧倒的な地位により、PyTorch を使う論文やチュートリアルが多く、デバッグも直感的に行えます。
  • 大規模な本番デプロイ向け: TensorFlow には今も優位性があります。TF Serving、TF Lite、TensorFlow.js は実戦で鍛えられたデプロイ手段を提供しており、PyTorch の TorchServe や ONNX Runtime はまだそこに追いつく途上にあります。
  • 金融 ML に特化して考えるなら: モデル開発と実験は PyTorch から始めましょう。本番の要件として TF Serving の成熟度や TF Lite のエッジデプロイが必要になった場合は、最良のモデルを変換すればよいのです。多くのチームはリサーチに PyTorch、デプロイに TensorFlow を使い、ONNX(Open Neural Network Exchange)形式でその両者を橋渡ししています。

正直なところ、両フレームワークは収束に向かっています。TensorFlow は eager execution を採用し、PyTorch はグラフレベルの最適化を行う torch.compile を追加しました。Keras 自体も、いまや PyTorch、JAX、TensorFlow をバックエンドとしてサポートしています。最良のフレームワークとは、自分のチームがよく知っていて、本番コードを出荷できるものです。一つを選び、使い込み、道具論争ではなく本当に解くべき問題——市場を予測すること——に集中しましょう。