企業がエージェント型 AI の導入を加速させている昨今、チームは推論コストを管理しながらインテリジェント アプリケーションを拡張するという課題に直面し、その課題は大きくなるばかりです。大規模言語モデル (LLM) はパフォーマンスに優れているものの、かなりの計算負荷がかかるため、レイテンシとコストが高くなることがよくあります。
同時に、開発には、評価、データ キュレーション、ファインチューニングといった多くのワークフローがありますが、その大部分は依然として手作業で行われています。これらのプロセスは時間がかかり、自動化が難しく、効果的な拡張ができていません。
AI エージェントは、その複雑さに加えて、リーズニング、ツール ルーティング、要約といったタスクにおいて、専門性の高い多くのモデルへの依存を高めています。これらのコンポーネントが持つパフォーマンス特性や最適化要件はそれぞれ異なるため、個別の評価やチューニングを大規模に行うことは困難です。
この問題を解決するために、NVIDIA はこのたび、データ フライホイール構築のための NVIDIA AI Blueprint を発表しました。これは、NVIDIA NeMo マイクロサービスを基盤とするリファレンス アーキテクチャであり、AI エージェントのインタラクションが提供する実際の本番環境のトラフィックを使用して、LLM を継続的に蒸留し、精度を損なうことなくより小規模かつ安価で、さらに高速なモデルにすることが可能です。この blueprint は利用可能なモデルの空間を探索する構造化された実験の実行が自動化し、有望な効率的モデル候補をプロダクションへの昇格や詳細な手動評価のために浮かび上がらせます。
このブログでは、Data Flywheel Blueprint について、その仕組み、エージェントのツール呼び出しを中心とした実際のユース ケースへの適用方法、そして自社のエージェント型 AI ワークフロー用のデータ フライホイールを簡単に構築するための設定方法について、詳しく解説します。こちらのデモ ノートブックでは、事前にキュレーションされたカスタマー サービス エージェント データセットでフライホイールを実際に動作させています。
仕組み
この blueprint は、チームが (例えば 700 億パラメーターなどの) 大規模な基盤モデルの機能を、より小規模で効率的な代替モデルで再現できるように設計されています。既存モデルや新規リリースのモデルを本番環境のタスクに対して継続的にベンチマークし、有望な候補をファインチューニングし、最もパフォーマンスの高い小規模モデルを提示することで、チームはモデルの精度を損なうことなく、レイテンシを低減させ推論コストを削減できます。
Data Flywheel Blueprint の中核を成すのが Flywheel Orchestrator Service です。これは、NeMo マイクロサービスと直接やり取りする際の複雑さを緩和する統合型コントロール プレーンです。フライホイール システムの頭脳として機能する Orchestrator API は、モジュール式の NeMo マイクロサービス スイートを活用して、データ フライホイールのジョブを調整します。
- NVIDIA NeMo Customizer: LoRA ベースの軽量なファインチューニングを行います。
- NVIDIA NeMo Evaluator: LLM-as-a-judge スコアリングを使用して評価を自動化します。
- NeMo Datastore: 構造化されたデータセットとアーティファクトを管理します。
- NeMo Deployment Manager: 推論用の候補モデル (NIM) を動的に起動して提供します。
ここからはフライホイールの仕組みを、順を追って説明します。
ステップ 1: ログの取り込み
教師モデルであるベース NIM (例: 70B の大規模モデル) から本番環境のプロンプト/応答ログが Elasticsearch のインデックスに取り込まれます。これらのログは OpenAI 準拠の形式に則っています。
ステップ 2: パーティショニングのためのタグ付け
各ログには workload_id などのメタデータがタグ付けされているため、システムがエージェント ノードごとにタスク単位でデータを分離および処理できるようになります。
ステップ 3: データセットの作成
オーケストレーターはログの重複を排除し、トレーニングと評価のために、タスクに合わせたデータセットへと変換します。注目すべきは、これらのデータセットは外部の正解ラベルに依存せず、元のモデルの応答のみに基づいているため、手動でラベル付けする必要がなくなることです。これらのデータセットは NeMo Datastore に保存されます。
ステップ 4: ファインチューニング ジョブの実行
NeMo Customizer を使用して、LoRA アダプターを用いた教師ありファインチューニング ジョブが実行されます。各ジョブは、NeMo Datastore に保存されている大規模な教師モデルの知識を蒸留し、小型でタスク特化型の候補モデルへと蒸留します。手作業によるデータセット作成は不要です。
ステップ 5: 評価の実行
NeMo Evaluator は、3 つの評価方法を用いて、複数の候補 NIM モデルをベンチマークします。
base-eval: 生ログに対する Zero-shot のベースラインicl-eval: コンテキストを活用した Few-shot の評価customized-eval: ファインチューニング後のパイプラインの評価
ステップ 6: スコアリングと集計
モデル出力は、LLM-as-a-judge を含む NeMo Evaluator を使用してスコアリングされ、結果は Orchestrator API を通じて報告されます。
ステップ 7: レビューとプロダクション昇格
開発者と管理者は、プログラムからメトリクスにアクセスし、アーティファクトをダウンロードし、フォローアップ実験を開始できます。あるいは最も高性能な候補モデルをプロダクションへ昇格させ、より大きな NIM を置き換えるといった操作が可能です。
このループ全体は、スケジュールに従って自動的に、またはオンデマンドで実行可能です。これにより、精度を維持しながら、より小型、高速、低コストなモデルを継続的かつ段階的に発見および導入できる、スケーラブルな自動化システムが実現します。
エージェントのツール呼び出しに Data Flywheel Blueprint を採用する
私たちは Data Flywheel Blueprint を、その価値と用途を実証するために、影響の大きなユース ケースである「エージェントのツール呼び出し」に適用しました。これは、構造化された API 呼び出しを介して外部システムと確実にインターフェイスする必要がある本番環境の AI エージェントには特に適しています。
私たちは、AI 仮想アシスタント用の NVIDIA AI Blueprint をベースに、製品に関する Q&A、注文の追跡、返品、日常会話などを行うカスタマー サポート タスク向けに設計されたマルチツール エージェントを構築しました。当初、このエージェントは Llama-3.3-70B-instruct の大規模モデルによって駆動されており、高い精度でツールコールを実行していました。私たちは、小規模なモデルをチューニングして大規模なモデルの精度に一致させ、同時にコストも削減したいと考えました。本番環境においては、顧客とのインタラクションを通じて継続的にツールコール性能を向上させることを目指しています。
本番環境のトラフィックをシミュレートするために、自然言語クエリを合成し、エージェントのツール呼び出し動作を OpenAI 互換のリクエスト – 応答ログに記録しました。これらのログは、トレーニング データセットでも評価データセットでも基礎となりました。
この設定を用いて、Data Flywheel Blueprint を用いた 3 つの最適化実験を実行し、小型の候補モデルのツールコール性能を評価しました。。
- Zero-shot プロンプティング (
`base-eval`): 事前サンプルやカスタマイズなしで、本番環境と同様のプロンプトでモデル (大きなベース NIM を含む) を評価しました。この評価がゴールド スタンダードとなって、大規模モデルの本来の動作をキャプチャし、より小規模なモデルのベンチマークの基準点となります。 - In-context learning (
`icl-eval`): 各プロンプトの先頭に、Few-shotのサンプルを付加しました。これらのサンプルは実際の本番環境のトラフィックから自動的にサンプリングおよび整形され、取得され、blueprint に付属のconfig.yaml に基づいてフライホイールが処理します。このアプローチは、コンテキスト プロンプトのみでモデルがどの程度改善されるかをテストします。 - LoRA による教師ありファインチューニング (
`customized-eval`):`training_config`および`lora_config`セクションを使用して、LoRA アダプターでモデルをファインチューニングしました。本番環境のログから得られた、タスク固有のキュレーション済みデータセットでトレーニングしました。その後、これらのモデルを評価し、base-evalおよびicl-evalに対するゲインを測定しました。
NeMo Evaluator は、LLM-as-judge 機能を使用して、人間によるラベル付けを必要とせずに、すべてのモデル出力を自動的にスコアリングします。各実行では、`function_name_and_args_accuracy` や `tool_calling_correctness` などの構造化されたメトリクスが提供されました。メトリクスはログに記録され、Orchestrator API を通じて提示されて、レビューや比較に使われます。この一連のプロセスはすべて完全に自動化されており、開発者は評価レポートへプログラム的にアクセスし、最も性能の高い候補モデルを本番環境に昇格させ、元のNIMモデルを置き換えることが可能です。
結果: SFT-LoRA を用いてファインチューニングされた Llama-3.2-1B モデルは、元の 70B モデルのツールコール精度の 98% を達成しました。この精度は、blueprint を通過するトラフィック データが増えるにつれて、ファインチューニングと評価のサイクルが自動化されて繰り返されることで実現しました。
結果的に、精度を維持しながらレイテンシとコストが大幅に改善され、劇的に軽量化されたモデルが実現しました。特筆すべきは、元の Llama-3.3-70B モデルでは 2 基の GPU が必要だったのに対し、最適化された Llama-3.2-1B は、GPU を 1 基しか必要としないことです。
この blueprint を起動してこれらの実験を実行したときの様子については、こちらのデモ動画をご覧ください。
blueprint の設定と実行
Data Flywheel Blueprint を起動して実行するには、まず環境をセットアップし、必要なサービスをデプロイする必要があります。詳細な手順はこちらの GitHub リポジトリの Readme に記載されていますが、手順はおおよそ以下のとおりです。
- 個人用の API キーを生成し、NeMo マイクロサービスをデプロイして NIM としてホストされているモデルにアクセスし、オンプレミスでモデルをダウンロードする
- NeMo マイクロサービス プラットフォームをデプロイする
- Data Flywheel Orchestrator をインストールして設定する
環境の準備が整ったら、config.yaml ファイルを使用してモデルとワークフローを設定します。このファイルには、デプロイする NIM モデルから、ファインチューニング (LoRA など) や評価 (ICL、LLM-as-a-Judge など) のための設定まで、あらゆる情報が定義されています。
注記: このファイルはシステムの起動時に読み込まれます。フライホイールの実行中、設定は静的のままです。更新する場合には、サービスを停止し、YAML を変更して再デプロイする必要があります。
以下は、フライホイールのジョブを起動するためにレビューまたは変更する必要がある、重要な手順と設定ブロックです。
モデル設定
デプロイおよび評価する NIM を指定します。モデル名、コンテキストの長さ、GPU 数、カスタマイズなどのその他のオプションを設定できます。NeMo Customizer でファインチューニング可能なサポート済みモデルを参照してください。
nims:
- model_name: "meta/llama-3.2-1b-instruct"
context_length: 32768
gpus: 1
pvc_size: 25Gi
tag: "1.8.3"
customization_enabled: true
ファインチューニング
ファインチューニング パラメーターを指定します。これには、トレーニング タイプ、ファインチューニングのタイプ、バッチ サイズ、トレーニング エポック数が含まれます。
training_config:
training_type: "sft"
finetuning_type: "lora"
epochs: 2
batch_size: 16
learning_rate: 0.0001
lora_config:
adapter_dim: 32
adapter_dropout: 0.1
In-context learning (ICL) 設定
ICL モードでモデルを評価する際に使用するフューショットのサンプル数とコンテキスト ウィンドウを設定します。
icl_config:
max_context_length: 32768
reserved_tokens: 4096
max_examples: 3
min_examples: 1
評価設定
各評価ジョブで、データを検証セットと評価セットに分割する方法を制御します。
data_split_config:
eval_size: 20
val_ratio: 0.1
min_total_records: 50
random_seed: null
limit: null
eval_size: 評価対象サンプルの数
val_ratio: 検証に使用されるデータの比率
フライホイール ジョブの起動
設定が完了したら、マイクロサービスへのシンプルな API 呼び出しを介してジョブを起動します。
# client_id: Identifier of the application or deployment that generated traffic
# workload_id: Stable identifier for the logical task / route / agent node
curl -X POST http://localhost:8000/api/jobs \
-H "Content-Type: application/json" \
-d '{"workload_id": "tool_router", "client_id": "support-app"}'
送信が成功すると、ツール呼び出し精度メトリクスが返されます。これは、さまざまなモデル間でパフォーマンスを比較するために使用できます。
"scores": {
"function_name_and_args_accuracy": 0.95,
"tool_calling_correctness": 1
}
blueprint をカスタム ワークフローに拡張する
この blueprint は、あらゆる下流タスク向けにデータ フライホイールを構築するためのリファレンス ワークフローとして設計されており、簡単にカスタマイズ可能です。NVIDIA はすでに、パートナー エコシステムで早期導入されている事例を確認しています。
- Weights & Biases は、NVIDIA API カタログでこの Data Flywheel Blueprint のカスタム バージョンを提供しており、エージェントのトレース性および可観測性、モデル実験のトラッキング、評価、レポート機能が強化されています。
- 機械学習企業の Iguazio (McKinsey の AI 部門である QuantumBlack が買収) は、この blueprint を適用し、AI オーケストレーションとモニタリング コンポーネントを備えた独自のカスタム データ フライホイールを構築して AI プラットフォームを強化しました。このプラットフォームは、NVIDIA API カタログのパートナー サンプルでも提供されています。
- Amdocs はこの blueprint を amAIz プラットフォームに統合し、LLM のファインチューニングと評価を CI/CD パイプラインに直接統合しました。自動化と機能強化が追加されたことで、Amdocs は新しいベース モデルの登場に合わせてエージェントの精度とパフォーマンスを継続的に向上させ、開発サイクルの早い段階で潜在的な問題を検出できるようになりました。
- EY はリアルタイムのモデル最適化によって、EY.ai Agentic Platform を強化できる blueprint を統合しています。これにより、税務、リスク、財務の各分野にわたって自己改善型のコスト効率の高いエージェントが実現します。
- VAST は、VAST AI Operating System と NVIDIA の Data Flywheel Blueprint を統合することで、カスタム ユース ケース向けに独自のデータ フライホイールを設計しています。これにより、マルチモーダル ソース全体にわたるリアルタイムのデータ収集、エンリッチメント、フィードバックが可能になり、金融、ヘルスケア、科学研究などの業界向けのインテリジェント AI パイプラインの提供が加速されます。
ユース ケースに合わせたデータ フライホイールを構築
データ フライホイールのための NVIDIA AI Blueprint についてさらに理解を深めましょう。NVIDIA API カタログで公開されています。セットアップ ガイド、実装の詳細、チュートリアルをご一読ください。ブログで紹介されている、エージェントのツール呼び出しのユース ケースに向けたフライホイールの構築に関するハンズオンのガイドについては、チュートリアル動画をご覧ください。
新しい NVIDIA NeMo Agent ツールキットを使用してエージェント ワークフローを構築する開発者は、この blueprint を使用すれば、エージェントの周囲にデータ フライホイールをシームレスに構築してツールキットの評価機能とプロファイリング機能を統合できます。
6 月 18 日に開催したウェビナーのリプレイをご視聴ください。NVIDIA NIM と NeMo マイクロサービスがデータ フライホイールをどのように強化するかを専門家が解説します。
関連情報
- GTC セッション: Building Scalable Data Flywheels for Continuously Improving AI Agents (AI エージェントを継続的に改善するためのスケーラブルなデータ フライホイールの構築)
- GTC セッション: Building Future-Ready AI With Agents and Data Flywheels: Insights From NVIDIA’s Enterprise Deployments (エージェントとデータ フライホイールを活用した未来志向の AI の構築: NVIDIA のエンタープライズ導入事例からのインサイト)
- GTC セッション: Create your own End-to-End Data Flywheel on NVIDIA DGX Cloud (NVIDIA DGX Cloud でエンドツーエンドの自社用データ フライホイールを構築する)
- SDK: NeMo Customizer
- SDK: NeMo Curator
- SDK: NeMo Framework
翻訳に関する免責事項
この記事は、「Build Efficient AI Agents Through Model Distillation With the NVIDIA Data Flywheel Blueprint」の抄訳で、お客様の利便性のために機械翻訳によって翻訳されたものです。NVIDIA では、翻訳の正確さを期すために注意を払っておりますが、翻訳の正確性については保証いたしません。翻訳された記事の内容の正確性に関して疑問が生じた場合は、原典である英語の記事を参照してください。
