記事に投票

5

Steve H

steve-nvidia

フォロー

nvidia

Oliver Holworthy

nvidia-oliver-holworthy

フォロー

nvidia

If you are building a RAG (Retrieval-Augmented Generation) system, you have likely hit this wall: Everything works… until it doesn’t. General-purpose embedding models are trained to understand the internet; not your contracts, manufacturing logs, proprietary chemical formulations or internal taxonomy. They capture broad semantic similarity, but they do not understand the fine-grained distinctions that matter in your domain. Fine-tuning an embedding model can improve the performance of your retrieval pipeline when off-the-shelf models fail to effectively capture domain-specific nuances. Despite how critical embeddings are to RAG performance, the process remains surprisingly fragmented, the skills required are specialized, and the time investment is daunting.

この投稿の終わりまでに、次の問いに答えられるようになります:
ラベルなしデータからドメイン文書のトレーニングデータを生成する
効果的な対照学習のためにハードネガティブマイニングを使用する
複数のホップクエリで埋め込み品質を向上させる
⚙️ バイエンコーダ埋め込みモデルをファインチューニングする
ファインチューニングが検索性能を改善するか評価する
ファインチューミング済みモデルをパイプラインにデプロイする

⚙️Setup

このチュートリアルでは、ベースモデル Llama-Nemotron-Embed-1B-v2 をファインチューニングします。これは品質と推論コストのバランスを取る10億パラメータの埋め込みモデルです。開始するには、この セットアップガイド に従ってください。

Step 1: Generate Training Data from Documents

埋め込みモデルをファインチューニングするには、数千組の（クエリと関連文書）ペアが必要です。ほとんどのユースケースではこのデータはすぐには利用できません。手動でデータにラベルを付けるのは高価で遅く、しばしばアノテータの個人的な“関連性”の解釈によって偏りが生じます。
代わりに、手作業でデータにラベルを付ける代わりに、LLM（nvidia/nemotron-3-nano-30b-a3b）を使って文書を読み取り、高品質な合成の質問–回答ペアを自動生成することができます。

nemotron embed sdg -c default corpus_dir=./data/my_domain_docs

How does it work?

Behind the scenes, this runs a four-stage synthetic data generation (SDG) pipeline powered by NeMo Data Designer:

What does the output look like?

Source document chunk:

H100 GPU の熱設計電力（TDP）は SXM 形状で 700W です。冷却ソリューションは、連続的なワークロードの下で接合温度を 83°C 未満に維持する必要があります。ノードあたり4台を超える密集展開では、空冷はこの熱負荷を標準の2Uシャーシ構成で処理できないため、液冷が推奨されます。

生成された QA ペア:

{
  "question": "ノードあたり4台を超えるH100 GPUを展開する場合、推奨される冷却アプローチは何ですか？",
  "answer": "密集配置では4台を超えるGPUノードには液冷が推奨されます。空冷では標準の2Uシャーシ構成で十分な熱を散逸できません。",
  "query_type": "contextual",
  "reasoning_type": "factual",
  "question_complexity": 3,
  "segment_ids": [1],
  "quality_score": 8.5
}

{
  "question": "H100 SXM の 700W TDP は、複数GPU構成における空冷と液冷の選択をどのように制約しますか？",
  "answer": "700W の TDP は、接合温度を 83°C 未満に保つために放熱が必要な大量の熱を発生します。ノードあたり 4 台を超える密集配置では、空冷ではこの熱負荷に対処できず、液冷が必要になります。",
  "query_type": "複数ホップ",
  "reasoning_type": "因果",
  "question_complexity": 4,
  "segment_ids": [1, 2],
  "

"hop_count": 2, "quality_score": 9.0 }

違いにご注目ください: 最初の質問は単純な事実検索です。2 番目はマルチホップの因果推論を要します。パイプラインは、設定可能な複雑さのレベル（2–5）とホップ数（1–3）を備え、両方のタイプを生成します。各 QA ペアはその後、関連性、正確さ、文脈のサポート、明確さのサブスコアとともに総合スコアを受け取り、品質評価を受けます。閾値を満たすペアのみがトレーニングに含まれます。

⛏️ ステップ 2: 難易度の高いネガティブをマイニングする（なぜそれらが重要なのか）

埋め込みモデルを正のペアのみ（クエリと正しい文書）で訓練すると、明らかに異なる文書を識別することは学習しますが、難しいケースには対応できません。これらは見かけ上は関連性がありそうですが正解ではないパッセージです。実際の検索システムでは、これらのニアミスは正解に近いがラベル付けされていない文書で、悪い回答を引き起こす原因になります。難しいネガティブマイニングは、モデルがそれらを区別できるよう、混乱させるパッセージを見つけ出します。

nemotron embed prep -c default

上記のコマンドは自動的に3つのサブステップを実行します：

2a. Train / Validation / Test Split

生成されたQAペアは、トレーニング（80%）とテスト（20%）のセットに分割されます。テストセットは、Step 5 での標準化評価のために BEIR-互換のベンチマークとしてフォーマットされます。

2b. Hard Negative Mining

基底の埋め込みモデルを使用して、パイプラインは以下を実行します：

1. コーパス内のすべてのクエリとすべてのパッセージを埋め込み表現に変換します。
2. 各クエリとすべてのパッセージとの類似度を計算します。
3. 各クエリのラベル付き正例ドキュメントをマスクします。
4. マージンフィルターを適用します：正のスコアの最小値の95%を上回るスコアを持つ、非正の文書はすべて除外されます。この除外ゾーンは偽陰性を防ぎます—正例に近いがラベル付けされていないパッセージ。
5. 生存した候補の中から、上位k件の高スコア文書をハードネガティブとして選択します（デフォルトは各クエリあたり5件）。

結果: ハードネガティブは、正スコアの天井を安全に下回る、最も類似した非正のパッセージです。これらは現在のモデルが非常に関連性が高いと見なすパッセージですが、ラベル付けされた回答ではありません。

なぜこれが機能するのか: 簡単なネガティブ（完全に無関係なパッセージ）での学習は、モデルに新しい知識を教えません。難しいネガティブでの学習は、あなたのドメインで重要な微妙な差異を学習させる力を与えます。例えば医療コーパスでは、「Type 2 diabetes のメトホルミンの用量」という質問には「メトホルミンの副作用」や「Type 1 diabetes のインスリン用量」といった難しいネガティブがあり得ます—近いが決定的に異なる例です。95％のマージン上限は、正のケースに近すぎて実際には正解となり得るがSDG中にはラベル付けされていなかった可能性のあるパッセージをマイニング処理から除外します。

2c. Multi-Hop Unrolling

マルチホップの質問は、複数の正例文書を参照します。例えば、"セクション 3.2 の熱管理システムは、セクション 5.1 で説明される電力制約とどのように関連しますか？" には2つの正例パッセージがあります。

アンローリングは、(クエリ、正の文書)ペアごとに1つのトレーニング例を作成します。したがって、コントラスト損失は各正例を独立して見ることになります。正例が2つの正例文書を含む質問は、同じハードネガティブを用いつつ、異なる正例を持つ2つのトレーニング例になります。

最終出力は、トレーニング準備が整った JSON ファイルです：

{
  "question_id": "q42_0",
  "question": "H100 SXMの700W TDPは、マルチGPUノードにおける冷却の選択肢をどのように制約しますか？",
  "pos_doc": [{"id": "d_a1b2c3"}],
  "neg_doc": [{"id": "d_x7y8z9"}, {"id": "d_m4n5o6"}, {"id": "d_p1q2r3"}, {"id": "d_s4t5u6"}, {"id": "d_v7w8x9"}]
}

ステップ 3: マルチホップ質問を理解することと、それが検索取得を改善する理由

標準的な埋め込みのファインチューニングは、パッセージごとに1つの質問を生成し、それらをマッチさせるようにモデルを訓練します。これは単純な事実検索には有効ですが、実際のユーザーは複数の文書やセクションにまたがる複雑な質問をします。モデルが単一ホップの訓練データしか見たことがない場合、これらの複雑なクエリに対して関連するすべてのパッセージを取得するのに苦労します。

SDGパイプラインはデフォルトで1～3ホップの質問を生成します：

• 1ホップ: 「H100 SXMのTDPはどれくらいですか？」 — 単一のパッセージで回答されます。
• 2ホップ: 「H100のTDPは、密集展開の冷却要件とどのように関連しますか？」 — 2つのパッセージの情報を結び付ける必要があります。
• 3ホップ: 「TDP、冷却制約、ラック密度の制限を考慮して、標準データセンターの1列に配置できるH100 GPUの最大数はいくつですか？」 — 3つのパッセージを統合します。

各ホップはそれぞれのコンテキスト要約とセグメントIDで追跡されるため、訓練データは完全な推論チェーンを保存します。アンローリングの後、各（質問、関連パッセージ）ペアは独立した訓練信号となり、これらすべてのパッセージがマルチホップクエリに関連していることをモデルに教えます。

ファインチューニングされたモデルは、語彙的に似ているだけでなく、文脈的に関連する文書を取得する能力を学習します。

ステップ 4: 埋め込みモデルのファインチューニング

nemotron embed finetune -c default

対比学習の仕組み

このトレーニングは、バイエンコーダーアーキテクチャと、対比損失を用います。

0.02の温度は意図的に鋭く、確率分布を非常に鋭くします。これはステップ2のハードネガティブが高品質だからこそ効果があります。

主要ハイパーパラメータ

パラメータ	デフォルト	ノート

"} エポック数 3 大規模なデータセットの場合、これを2または1に下げることができます 学習率 1e-5 チューニング: デフォルト値の2倍と半分を試してみてください 学習率ウォームアップステップ 5 ファインチューニングの総ステップ数の5-10%に設定すると、初期のトレーニングの安定性が向上します グローバルバッチサイズ 128 小規模データセット向けに自動的にスケールダウンされます クエリあたりのパッセージ 5 1つの正例 + 4つのハードネガティブ

小規模データセット向けの自動スケーリング

データセットに訓練例が2,000件未満しか含まれていない場合、パイプラインは自動的に以下を実行します：

• 勾配が有意になるように、バッチサイズを縮小します（16–64へ）。
• 1回の実行あたり少なくとも3つのチェックポイントが作成されるように、チェックポイント頻度を調整します。
• 検証頻度を比例してスケールします。

これにより、迅速な概念実証のために小規模なコーパス（50–100 文書）から始め、後で規模を拡大できます。

ステップ5: 改善を測定する

ファインチューニングは実際に役立ちましたか？ 保持済みのテストセットでベースモデルとファインチューニング済みのチェックポイントを比較する標準化された評価を実行して確認してみましょう：

nemotron embed eval -c default

この評価には BEIRフレームワーク が使用され、k = 1, 5, 10, 100 で4つの標準的な情報検索指標を計算します：

1. nDCG@k: ランキング品質 — 最高の文書が最上位にランクされていますか？
2. Recall@k: カバレッジ — 上位kに表示される関連文書の割合はどれくらいですか？
3. Precision@k: 正確性 — 上位k件の結果のうち、実際に関連するものはどれくらいですか？
4. MAP@k: すべてのクエリに対する平均適合率

通常、ファインチューニングは1日未満でnDCG@10とRecall@10を約15%改善します。

Retrieval Synthetic NVDocs の結果:

 Comparison (Base -> Fine-tuned)
============================================================
  NDCG:
    NDCG@1: 0.55178 → 0.60796 (+0.05618, +10.2%)
    NDCG@5: 0.51894 → 0.57689 (+0.05795, +11.2%)
    NDCG@10: 0.55506 → 0.61559 (+0.06053, +10.9%)
    NDCG@100: 0.60617 → 0.66567 (+0.05950, +9.8%)
  Recall:
    Recall@1: 0.28478 → 0.31547 (+0.03069, +10.8%)
    Recall@5: 0.54486 → 0.60288 (+0.05802, +10.6%)
    Recall@10: 0.62979 → 0.69296 (+0.06317, +10.0%)
    Recall@100: 0.81421 → 0.87020 (+0.05599, +6.9%)

数値が改善しない場合は？

パイプラインは繰り返しを容易にします：

• SDGの低品質スコア? 文書の品質を確認してください — 清潔で整形されたテキストはより良い合成データを生み出します。より大きくて強力なLLMを試してください。
• 訓練データが不足していますか? コーパスに文書を追加して Stage 0 を再実行してください。
• 過学習? エポック数を減らすか、品質閾値を高めて最高の訓練例だけを残してください。
• 学習率が間違っていますか? 大規模データセットには5e-6、非常に小さなデータには2e-5を試してください。

実世界での成果: Atlassian

このレシピは Atlassian によって実企業データで検証されています。彼らはこのパイプラインを用いて Llama-Nemotron-Embed-1B-v2 をファインチューニングしました。1台の NVIDIA A100 80GB GPU を使用し、上記と同じ段階を踏んで公開 Jira データセットを用いました。

Recall@60 は0.751から0.951に跳ね上がりました — 26.7%の向上。
ファインチューニング済みモデルは、トップ60件の結果の中で正しい文書を取得する割合を95.1%に達します。ベースモデルの75.1%から向上しました。Jira検索を支える検索システムでは、これにより数百万人のユーザーにとってより関連性の高い結果が直接得られます。詳しくは彼らのブログ記事「Advancing semantic search for millions of Rovo users」をご覧ください。

ステップ 6: エクスポートとデプロイ

PyTorch のチェックポイントは評価には適していますが、本番運用には遅すぎます。最終の 2 つのステージはモデルを変換し、API の背後で提供します。

ONNX / TensorRT へのエクスポート

nemotron embed export -c default

これは微調整済みのチェックポイントを ONNX（opset 17）へエクスポートします。任意で、推論処理のスループットを最大化するために TensorRT エンジンをコンパイルし、バッチサイズ（1–64）とシーケンス長（3–256）の最適化プロファイルを設定できます:

# ONNX only (runs anywhere)
nemotron embed export -c default export_to_trt=false

# FP8 quantization for further speedup
nemotron embed export -c default quant_cfg=fp8

NVIDIA NIM でのデプロイ

エクスポートされたモデルは NVIDIA NIM コンテナ内にデプロイされます — OpenAI互換の /v1/embeddings エンドポイントを公開する、本番運用向けの推論マイクロサービスです:

nemotron embed deploy -c default

実行されると、任意のクライアントが呼び出すことができます：

curl -X POST http://localhost:8000/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"input": ["What cooling is needed for 8 H100 GPUs in a 2U chassis?"],
       "model": "custom",
       "input_type": "query"}'

NIM は OpenAI 互換の API を提供するため、埋め込み API 形式を使用する既存の RAG パイプラインに組み込むことができます — コードの変更は不要です。

デプロイの正確性を検証

The pipeline includes a NIM accuracy verification step that runs the same BEIR evaluation against the deployed endpoint:

nemotron embed eval -c default eval_nim=true eval_base=false

This catches any accuracy loss from the ONNX/TensorRT conversion. Metrics that match within tolerance (0.03 for @1, 0.01 for @5+) are marked with a check; deviations beyond conversion noise are flagged.

すべてを統合する

完全な埋め込み微調整パイプラインは、生の文書からデプロイ済みモデルまで、6つのコマンドで実行できます。

# 1. Generate synthetic training data from your documents
nemotron embed sdg -c default corpus_dir=./data/my_docs

# 2. Prepare the training data (split data, mine hard negatives, unroll)
nemotron embed prep -c default

# 3. Fine-tune the embedding model
nemotron embed finetune -c default

# 4. Evaluate the base vs. fine-tuned model
nemotron embed eval -c default

# 5. Export the optimized model
nemotron embed export -c default

# 6. Deploy the model
nemotron embed deploy -c default

想定時間とリソース

総計: 1日未満で、ほとんどの時間は手を動かさないトレーニングです。 小さなコーパス（約500ドキュメント）の場合、全パイプラインは約2–3時間で完了します。

パイプラインはエンドツーエンドで実行できますが、開始点に応じて各ステージを独立して実行することも可能です。例えば、生データ文書がある場合は合成データ生成（SDG）から開始できます。一方、すでにハードネガティブを含むデータセットは前のステップをスキップし、直接ファインチューニングに進むことができます。JSON、BEIR、ONNXなどの標準フォーマットを使用しているため、カスタムコンポーネントの統合や他のワークフローで中間出力を再利用することが容易です。実行方法は柔軟で、ローカルマシン、Dockerコンテナ、またはSlurmベースのクラスタ上での実行をサポートします。

自分で試してみる

ドメイン文書があり、少し時間があるなら、今日から最初の合成トレーニングデータのバッチを生成できます！文書からデプロイ済みでドメイン適応済みの埋め込みモデルまでの全パイプラインは、1つのGPUで1日未満で完了します。すぐにパイプラインを試すには、すでに用意されている nvidia/Retrieval-Synthetic-NVDocs-v1 データセットから開始できます。作成したものを教えてください。
リポジトリをスターしてください：Nemotron、NeMo Data Designer、および NeMo Automodel が役に立つと感じたら。