1日以内にドメイン固有の埋め込みモデルを構築する

Back to Articles Build a Domain-Specific Embedding Model in Under a Day Upvote 2 ![](/avatars/9e3e29394381d2ce973910e3cba1fe44.svg) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/67329fe54c2f18a60e5c7705/hhaORAzSD3WMCmOKVDokx.jpeg) RAG（Retrieval-Augmented Generation、検索拡張生成）システムを構築しているなら、この壁にぶつかったことがあるでしょう：すべてがうまくいく…はずが、そうならない瞬間が来ます。汎用埋め込みモデルはインターネットを理解するように訓練されていますが、あなたの契約書、製造ログ、独自の化学処方、社内分類体系を理解しているわけではありません。それらは広範な意味的類似性を捉えますが、あなたのドメインで重要な細かい区別を理解しません。既製モデルがドメイン固有のニュアンスを効果的に捉えられない場合、埋め込みモデルのファインチューニング（微調整）を行うことで、検索パイプラインの性能を向上させることができます。埋め込みがRAGの性能にとってどれほど重要であるにもかかわらず、そのプロセスは驚くほど断片的で、必要なスキルは専門的であり、時間投資は気が遠くなるものです。 単一のGPUと1日未満の訓練時間で、汎用埋め込みモデルを、あなたのドメインを真に理解するモデルに変えることができます。手動ラベリングは必要ありません。すぐに始められるように、この正確なパイプラインを使用してNVIDIAの公開ドキュメントから生成された、すぐに使用できる合成訓練データセットも公開します。このデータとレシピを使用して、Recall@10とNDCG@10の両方で10%以上の改善が見られました。Atlassianはこのレシピを彼らのJIRAデータセットに適用してファインチューニングを行い、Recall@60を0.751から0.951に、26%改善しました - 単一のGPUでです。 🔗データセットとコードへのクイックリンク： Embedding Model Synthetic dataset on NVIDIA’s public documents 🧑💻オープンソースプロジェクト レシピ統合： 合成データ生成のためのNeMo Data Designer 埋め込みモデル訓練のためのNeMo Automodel 情報検索評価のためのBEIR ONNX/TensorRT変換のためのNeMo Export-Deploy 本番推論サービングのためのNVIDIA NIM 📋前提条件： ドメイン文書のディレクトリ（テキストファイル - .txt、.md、または類似形式） 有効なNVIDIA APIキー（build.nvidia.comで無料） 少なくとも80GBメモリを搭載したNVIDIA Ampere GPU以降（Compute Capability >= 8.0） このチュートリアルは1xA100（80GB）および1xH100（80GB）でテストされています この投稿の終わりまでに、以下の方法を知ることができます： 📄 ラベル付きデータなしでドメイン文書から訓練データを生成する 🎯 効果的な対照学習のためのハードネガティブマイニングを使用する 🔗 マルチホップクエリで埋め込み品質を改善する ⚙️ バイエンコーダ埋め込みモデルをファインチューニングする 📊 ファインチューニングが検索を改善するか評価する 🚀 ファインチューニングされたモデルをパイプラインにデプロイする このチュートリアルでは、ベースモデルLlama-Nemotron-Embed-1B-v2 - 品質と推論コストのバランスをとる10億パラメータの埋め込みモデル - をファインチューニングします。始めるには、このセットアップガイドに従ってください。 📚 ステップ1：文書から訓練データを生成する 埋め込みモデルのファインチューニングには、数千の（クエリ、関連文書）ペアが必要です。ほとんどのユースケースでは、このデータはすぐには利用できません。手動で作成するのは高価で遅く、しばしばアノテーターの「関連性」に対する個人的解釈によって偏りが生じます。手作業でデータにラベルを付ける代わりに、LLM（nvidia/nemotron-3-nano-30b-a3b）を使用して文書を読み取り、高品質の合成質問-回答ペアを自動生成できます。 nemotron embed sdg -c default corpus_dir=./data/my_domain_docs どのように機能するか？ 舞台裏では、NeMo Data Designerによって駆動される4段階の合成データ生成（SDG）パイプラインが実行されます： ![](https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/84IMYChKX4twWnC4U6iCQ.png) 出力はどのようなものか？ ソース文書チャンク： H100 GPUの熱設計電力（TDP）は、SXMフォームファクタで700Wです。冷却ソリューションは、持続ワークロード下で接合部温度を83°C未満に維持する必要があります。液体冷却は、ノードあたり4GPUを超える高密度デプロイメントに推奨されます。なぜなら、空冷では標準2Uシャーシ構成で十分な熱を放散できないからです。 生成されたQAペア： { "question": "サーバーノードあたり4台を超えるH100 GPUをデプロイする場合、どの冷却アプローチが推奨されますか？", "answer": "ノードあたり4GPUを超える高密度デプロイメントには液体冷却が推奨されます。なぜなら、空冷では標準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未満に保つために放散しなければならない大量の熱を発生させます。ノードあたり4GPUを超える高密度構成では、標準2Uシャーシでの空冷はこの熱負荷を処理できず、液体冷却が必要になります。", "query_type": "multi_hop", "reasoning_type": "causal", "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. 訓練/検証/テスト分割 生成されたQAペアは、訓練セット（80%）とテストセット（20%）に分割されます。テストセットは、ステップ5での標準化評価のためのBEIR互換ベンチマークとしてフォーマットされます。 2b. ハードネガティブマイニング ベース埋め込みモデルを使用して、パイプラインは： コーパス内のすべてのクエリとすべての文章を埋め込みます。 各クエリとすべての文章の間の類似性を計算します。 各クエリのラベル付きポジティブ文書をマスクアウトします。 マージンフィルターを適用：最小ポジティブスコアの95%を超えるスコアを持つ非ポジティブ文書は除外されます。この除外ゾーンは、偽ネガティブ - ポジティブに非常に近く、実際に関連している可能性のあるラベルなし文章 - を防ぎます。 残った候補から、トップkの最高スコア文書をハードネガティブとして選択します（デフォルトでクエリあたり5つ）。 結果：ハードネガティブは、ポジティブスコア上限を安全に下回る、最も類似した非ポジティブ文章です。それらは現在のモデルが非常に関連性が高いと考えるが、ラベル付けされた答えではない文章です。 なぜこれが機能するか：簡単なネガティブ（完全に関連のない文章）で訓練しても、モデルは何も新しいことを学びません。ハードネガティブで訓練することで、あなたのドメインで重要な微妙な区別を学ぶことを強制します。例えば、医療コーパスでは、「2型糖尿病のメトホルミン投与量」に関する質問は、「メトホルミンの副作用」や「1型糖尿病のインスリン投与量」に関するハードネガティブを持つかもしれません - 近いが決定的に異なります。95%マージン上限は、マイナーがポジティブに近すぎる文章を選択するのを防ぎます。それらは実際には正解であり、単にSDG中にラベル付けされなかった可能性があります。 2c. マルチホップアンローリング マルチホップ質問は複数のポジティブ文書を参照します。例えば、「セクション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、冷却制約、ラック密度制限を考慮して、標準データセンター列にデプロイ可能なH100 GPUの最大数は何ですか？」 - 3つの文章を統合します。 各ホップは独自の文脈要約とセグメントIDで追跡されるため、訓練データは完全な推論チェーンを保持します。アンローリング（ステップ2c）後、各（質問、関連文章）ペアは独立した訓練信号となり、モデルにこれらの文章すべてがマルチホップクエリに関連していることを教えます。 ファインチューニングされたモデルは、語彙的に類似したものだけでなく、文脈的に関連する文書を検索することを学びます。 🧠 ステップ4：埋め込みモデルをファインチューニングする nemotron embed finetune -c default 対照学習の仕組み トレーニングは、コントラスティブ損失（contrastive loss）を用いたバイエンコーダー（biencoder）アーキテクチャを使用します。 ![](https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/ntYmgzatUK_Sfn35GCdve.png) 温度（temperature）0.02は意図的に攻撃的に設定されており、非常に鋭い確率分布を生成します。これは、ステップ2からのハードネガティブ（hard negatives）が高品質であるため、うまく機能します。それらは真に紛らわしい文章であり、モデルが区別を学ぶために強い勾配を必要とします。 主要なハイパーパラメータ 大規模データセットの場合、2または1に下げてもよい チューニング: デフォルト値の2倍と半分を試す 学習率ウォームアップステップ数 微調整の総ステップ数の5〜10%に設定して、初期トレーニングの安定性を向上させる グローバルバッチサイズ 小規模データセットでは自動的に縮小される クエリあたりの文章数 1ポジティブ（positive）+ 4ハードネガティブ（hard negatives） 小規模データセットの自動スケーリング データセットのトレーニング例が2,000未満の場合、パイプラインは自動的に以下を行います: バッチサイズを縮小（16〜64）して勾配が意味を持つようにする。 チェックポイント頻度を調整して、実行ごとに少なくとも3つのチェックポイントを確実に生成する。 検証頻度を比例的にスケーリングする。 これは、迅速な概念実証のために小さなコーパス（50〜100ドキュメント）から始め、後で拡張できることを意味します。 📈 ステップ5: 改善を測定する 微調整は実際に役立ったでしょうか？ベースモデルと微調整済みチェックポイントをホールドアウトテストセットで比較する標準化された評価を実行して確認しましょう: nemotron embed eval -c default 評価はBEIR（BEIR）フレームワークを使用し、k = 1、5、10、100で4つの標準情報検索（information retrieval）メトリクスを計算します: nDCG@k: ランキング品質 — 最良のドキュメントが最高位にランクされているか？ Recall@k: カバレッジ — 関連ドキュメントのうち、上位k件に現れる割合は？ Precision@k: 精度 — 上位k件の結果のうち、実際に関連している割合は？ MAP@k: 全クエリにわたる平均適合率（average precision） 成功した微調整では、通常、1日以内にnDCG@10とRecall@10が15%改善します。 Retrieval Synthetic NVDocsを使用した結果: 📊 比較（ベース -> 微調整後） ============================================================ 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の品質スコアが低い？ドキュメント品質を確認してください — クリーンで適切にフォーマットされたテキストは、より優れた合成データ（synthetic data）を生成します。より大規模で強力なLLM（Large Language Model）を試してください。 トレーニングデータが不足している？コーパスにドキュメントを追加して、ステージ0を再実行してください。 過学習（overfitting）？エポック数を減らすか、品質閾値を上げて最良のトレーニング例のみを保持してください。 学習率が不適切？大規模データセットには5e-6、非常に小規模なデータセットには2e-5を試してください。 🏆 実世界の結果: Atlassian このレシピは、Atlassianによって実際の企業データで検証されています。彼らはこのパイプラインを適用し、上記と同じステージに従って、単一のNVIDIA A100 80GB GPUを使用して公開JiraデータセットでLlama-Nemotron-Embed-1B-v2を微調整しました。 Recall@60は0.751から0.951に跳ね上がり、26.7%の向上を示しました。微調整済みモデルは、クエリの95.1%に対して上位60件の結果内で正しいドキュメントを検索します。これは、ベースモデルの75.1%から向上しています。Jira検索を支える検索システムにとって、これは数百万のユーザーにより関連性の高い結果をもたらすことになります。詳細は彼らのブログ記事「Advancing semantic search for millions of Rovo users」をご覧ください。 ![](https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/hsFtTLz1WfSgaWBdHof82.png) 🚀 ステップ6: エクスポートとデプロイ PyTorchチェックポイントは評価には優れていますが、本番環境では遅すぎます。最後の2つのステージでは、モデルを変換してAPIの背後で提供します。 ONNX / TensorRTへのエクスポート nemotron embed export -c default これにより、微調整済みチェックポイントがONNX（opset 17）にエクスポートされます。オプションで、最大推論スループットのためにTensorRTエンジンをコンパイルし、バッチサイズ（1〜64）とシーケンス長（3〜256）に対して設定可能な最適化プロファイルを提供します: # ONNXのみ（どこでも実行可能） nemotron embed export -c default export_to_trt=false # FP8量子化（quantization）によるさらなる高速化 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（Retrieval-Augmented Generation）パイプラインにコード変更なしで組み込むことができます。 デプロイ精度の検証 パイプラインには、デプロイされたエンドポイントに対して同じBEIR評価を実行するNIM精度検証ステップが含まれています: nemotron embed eval -c default eval_nim=true eval_base=false これにより、ONNX/TensorRT変換による精度損失を捕捉します。許容範囲内（@1では0.03、@5以上では0.01）で一致するメトリクスはチェックマークで示され、変換ノイズを超える偏差はフラグが立てられます。 全体をまとめる 完全な埋め込み微調整パイプラインは、生ドキュメントからデプロイ済みモデルまで、6つのコマンドで実行できます。 # 1. ドキュメントから合成トレーニングデータを生成 nemotron embed sdg -c default corpus_dir=./data/my_docs # 2. トレーニングデータを準備（データ分割、ハードネガティブマイニング、アンロール） nemotron embed prep -c default # 3. 埋め込みモデルを微調整 nemotron embed finetune -c default # 4. ベースモデルと微調整済みモデルを評価 nemotron embed eval -c default # 5. 最適化モデルをエクスポート nemotron embed export -c default # 6. モデルをデプロイ nemotron embed deploy -c default 予想時間とリソース コーパスサイズとAPIレート制限によって異なる 必要（40 GB VRAM） GPUでのハードネガティブマイニング 必要（80 GB VRAM） データセットサイズとエポック数によって異なる 必要（40 GB VRAM） 必要（40 GB VRAM） TensorRTにはNGCコンテナが必要 必要（40 GB VRAM） NIMコンテナ起動 合計: 1日以内、ほとんどの時間は人手を介さないトレーニングです。小さなコーパス（約500ドキュメント）の場合、パイプライン全体は約2〜3時間で完了します。 パイプラインはエンドツーエンドで実行できますが、各ステージは開始点に応じて独立して実行することもできます。例えば、生ドキュメントがある場合は合成データ生成（SDG）から始めることができ、ハードネガティブが既に含まれているデータセットは初期ステップをスキップして直接微調整に進むことができます。各ステージはJSON、BEIR、ONNXなどの標準フォーマットを使用するため、カスタムコンポーネントを統合したり、中間出力を他のワークフローで再利用したりするのが容易です。このレシピは、ローカルマシン、Dockerコンテナ内、またはSlurmベースのクラスタでの実行など、実行方法にも柔軟性があります。 自分で試す ドメインのドキュメントと少しの時間があれば、今日中に最初のバッチの合成トレーニングデータを生成できます！ドキュメントからドメイン適応済みの埋め込みモデルがデプロイされるまでの完全なパイプラインは、単一GPUで1日以内に実行できます。すぐにパイプラインを試すには、既製のnvidia/Retrieval-Synthetic-NVDocs-v1データセットから始めることができます。何を構築したか教えてください。Nemotron、NeMo Data Designer、NeMo Automodelのリポジトリが役立つと思ったら、スターを付けてください。 ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1613114437487-60262a8e0703121c822a80b6.png) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1613114437487-60262a8e0703121c822a80b6.png) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1613114437487-60262a8e0703121c822a80b6.png) ![](https://cdn-avatars.huggingface.co/v1/production/uploads/1613114437487-60262a8e0703121c822a80b6.png)

1日以内にドメイン固有の埋め込みモデルを構築する

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト