![\"sdg_pipeline\"](\"https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/84IMYChKX4twWnC4U6iCQ.png\")
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.
\nWith a single GPU and less than a day of training time, you can transform a general-purpose embedding model into one that truly understands your domain, no manual labeling required. To help you hit the ground running, we are also releasing a ready-to-use synthetic training dataset generated from NVIDIA's public documentation using this exact pipeline. Using this data and the recipe, we saw over 10% improvement in both Recall@10 and NDCG@10. Atlassian applied this recipe to fine-tune on their JIRA dataset, increasing Recall@60 from 0.751 to 0.951, a 26% improvement - on a single GPU.
\nBy the end of this post, you’ll know how to:
\n📄 Generate training data from domain documents without labeled data
\n🎯 Use hard negative mining for effective contrastive training
\n🔗 Improve embedding quality with multi-hop queries
\n⚙️ Fine-tune a bi-encoder embedding model
\n📊 Evaluate whether fine-tuning improves retrieval
\n🚀 Deploy the fine-tuned model in your pipeline
In this tutorial, we will finetune the base model Llama-Nemotron-Embed-1B-v2 - a 1-billion-parameter embedding model that balances quality and inference cost. To get started, follow this setup guide.
\nFine-tuning an embedding model requires thousands of (query, relevant document) pairs. Most use cases don’t have this data readily available. Creating it manually is expensive, slow, and often biased by the annotator’s personal interpretation of what’s “relevant.”
\nInstead of labeling data by hand, you can use an LLM (nvidia/nemotron-3-nano-30b-a3b) to read your documents and automatically generate high-quality synthetic question–answer pairs.
\nBehind the scenes, this runs a four-stage synthetic data generation (SDG) pipeline powered by NeMo Data Designer:
\n
Source document chunk:
\nThe thermal design power (TDP) of the H100 GPU is 700W in SXM form factor. The cooling solution must maintain junction temperature below 83°C under sustained workloads. Liquid cooling is recommended for dense deployments exceeding 4 GPUs per node, as air cooling cannot dissipate sufficient heat in standard 2U chassis configurations.
\nGenerated QA pairs:
\n\n\nNotice the difference: the first question is a simple factual lookup. The second requires multi-hop, causal reasoning. The pipeline generates both types, with configurable complexity levels (2–5) and hop counts (1–3). Each QA pair then undergoes quality evaluation, receiving sub-scores for relevance, accuracy, context support, and clarity, along with an overall score. Only pairs that meet the threshold are included in training.
\nIf you train an embedding model with only positive pairs (query + correct document), it learns to distinguish obviously different documents but fails on the hard cases — passages that look relevant but are not the right answer. In a real retrieval system, these near-misses are exactly the documents that cause bad answers. Hard negative mining finds these confusing passages so the model can learn to tell them apart.
\n\nThe above command runs three sub-steps automatically:
\nThe generated QA pairs are split into training (80%) and test (20%) sets. The test set is formatted as a BEIR-compatible benchmark for standardized evaluation in Step 5.
\nUsing the base embedding model, the pipeline:
\nThe result: hard negatives are the most similar non-positive passages that still fall safely below the positive-score ceiling. They are passages the current model considers highly relevant but that are not the labeled answer.
\nWhy this works: Training on easy negatives (completely unrelated passages) teaches the model nothing new. Training on hard negatives forces it to learn the subtle distinctions that matter in your domain. For example, in a medical corpus, a question about "metformin dosage for Type 2 diabetes" might have hard negatives about "metformin side effects" or "insulin dosage for Type 1 diabetes" — close but critically different. The 95% margin ceiling prevents the miner from selecting passages that are too close to the positive, which could actually be correct answers that simply weren't labeled during SDG.
\nMulti-hop questions reference multiple positive documents. For example, a question like "How does the thermal management system in Section 3.2 relate to the power constraints described in Section 5.1?" has two positive passages.
\nUnrolling creates one training example per (query, positive document) pair, so the contrastive loss sees each positive independently. A question with 2 positive documents becomes 2 training examples, each with the same hard negatives but a different positive.
\nThe final output is a training-ready JSON file:
\n, \n\nStandard embedding fine-tuning generates one question per passage and trains the model to match them. This works for simple factual lookups, but real users ask complex questions that span multiple documents or sections. If the model has only seen single-hop training data, it will struggle to retrieve all the relevant passages for these complex queries.
\nThe SDG pipeline generates questions at 1 to 3 hops by default:
\nEach hop is tracked with its own context summary and segment IDs, so the training data preserves the full reasoning chain. After unrolling (Step 2c), each (question, relevant passage) pair becomes an independent training signal, teaching the model that all of these passages are relevant to the multi-hop query.
\nThe fine-tuned model learns to retrieve contextually related documents, not just lexically similar ones.
\n\nThe training uses a biencoder architecture with contrastive loss.
\n![\"contrastive_learning\"](\"https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/ntYmgzatUK_Sfn35GCdve.png\")
The temperature of 0.02 is deliberately aggressive, it produces a very sharp probability distribution. This works well because the hard negatives from Step 2 are high-quality: they are genuinely confusing passages that the model needs strong gradients to learn to distinguish.
\n| Parameter | \nDefault | \nNotes | \n
|---|---|---|
| Epochs | \n3 | \nDefault is tuned for the small example dataset; for real-world data, 1–2 epochs is usually sufficient to avoid overfitting. | \n
| Learning rate | \n1e-5 | \nTuning: try double and half of the default value | \n
| Learning rate warmup steps | \n5 | \nSet to 5-10% of total steps of finetune to have better early training stability | \n
| Global batch size | \n128 | \n\n |
| Passages per query | \n5 | \n1 positive + 4 hard negatives | \n
If ckpt_every_steps is omitted from the config, checkpoint frequency is set automatically:
This means you can start with a small corpus (50–100 documents) for a quick proof-of-concept and scale up later without manually tuning checkpoint settings.
\nDid fine-tuning actually help? Let’s find out by running a standardized evaluation comparing the base model against the fine-tuned checkpoint on the held-out test set:
\n\nThe evaluation uses the BEIR framework and computes four standard information retrieval metrics at k = 1, 5, 10, and 100:
\nA successful fine-tune typically results in a 10% improvement in nDCG@10 and Recall@10 within <1 day.
\nResults using Retrieval Synthetic NVDocs:
\n📊 Comparison (Base -> Fine-tuned)\n============================================================\n NDCG:\n NDCG@1: 0.55178 → 0.60796 (+0.05618, +10.2%)\n NDCG@5: 0.51894 → 0.57689 (+0.05795, +11.2%)\n NDCG@10: 0.55506 → 0.61559 (+0.06053, +10.9%)\n NDCG@100: 0.60617 → 0.66567 (+0.05950, +9.8%)\n Recall:\n Recall@1: 0.28478 → 0.31547 (+0.03069, +10.8%)\n Recall@5: 0.54486 → 0.60288 (+0.05802, +10.6%)\n Recall@10: 0.62979 → 0.69296 (+0.06317, +10.0%)\n Recall@100: 0.81421 → 0.87020 (+0.05599, +6.9%)\nThe pipeline makes it easy to iterate:
\nThis recipe has been validated on real enterprise data by Atlassian. They applied this pipeline to fine-tune Llama-Nemotron-Embed-1B-v2 on a public Jira dataset using a single NVIDIA A100 80GB GPU, following the same stages described above
\nRecall@60 jumped from 0.751 to 0.951 — a 26.7% gain.
\nThe fine-tuned model retrieves the correct document within the top 60 results for 95.1% of queries, up from 75.1% with the base model. For a retrieval system underpinning Jira search, this directly translates into more relevant results for millions of users. Find more details in their blog post Advancing semantic search for millions of Rovo users.
![\"ATL](\"https://cdn-uploads.huggingface.co/production/uploads/662a9c2154a9f1037104a075/hsFtTLz1WfSgaWBdHof82.png\")
A PyTorch checkpoint is great for evaluation but too slow for production. The final two stages convert the model and serve it behind an API.
\n\nThis exports the fine-tuned checkpoint to ONNX (opset 17). Optionally, it compiles a TensorRT engine for maximum inference throughput, with configurable optimization profiles for batch size (1–64) and sequence length (3–256):
\n# ONNX only (runs anywhere)\n\n\n# FP8 quantization for further speedup\n\nThe exported model is deployed inside an NVIDIA NIM container — a production-ready inference microservice exposing an OpenAI-compatible /v1/embeddings endpoint:
\n\nOnce running, any client can call it:
\n\nBecause NIM serves an OpenAI-compatible API, you can drop it into any existing RAG pipeline that uses the embeddings API format — no code changes needed.
\nThe pipeline includes a NIM accuracy verification step that runs the same BEIR evaluation against the deployed endpoint:
\n\nThis 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.
\nThe full embedding fine-tuning pipeline can be run in six commands, from raw documents to a deployed model.
\n# 1. Generate synthetic training data from your documents\n\n\n# 2. Prepare the training data (split data, mine hard negatives, unroll)\n\n\n# 3. Fine-tune the embedding model\n\n\n# 4. Evaluate the base vs. fine-tuned model\n\n\n# 5. Export the optimized model\n\n\n# 6. Deploy the model\n\n| Stage | \nGPU Required? | \nEstimated Time | \nNotes | \n
|---|---|---|---|
| SDG | \nNo (uses API) | \n~1 hour | \nVaries by corpus size and API rate limit | \n
| Data Prep | \nYes (40 GB VRAM) | \n~5 min | \nHard negative mining on GPU | \n
| Fine-Tune | \nYes (80 GB VRAM) | \n~1 hours | \nVaries by dataset size and epochs | \n
| Eval | \nYes (40 GB VRAM) | \n~5 min | \n\n |
| Export | \nYes (40 GB VRAM) | \n~5 min | \nTensorRT requires NGC container | \n
| Deploy | \nYes (40 GB VRAM) | \n~5 min | \nNIM container startup | \n
Total: under a day, with most time being hands-off training. For a small corpus (~500 documents), the entire pipeline completes in about 2–3 hours.
\nThe pipeline can run end-to-end, but each stage can also be executed independently depending on your starting point. For example, if you have raw documents, you can begin with synthetic data generation (SDG), while datasets that already include hard negatives can skip earlier steps and go directly to fine-tuning. Since every stage uses standard formats such as JSON, BEIR, and ONNX, it’s easy to integrate custom components or reuse intermediate outputs in other workflows. The recipe is also flexible in how it runs, supporting execution on a local machine, inside Docker containers, or on Slurm-based clusters.
\nIf you have domain documents and some time in your hand, you can generate your first batch of synthetic training data today! The full pipeline - from documents to a deployed, domain-adapted embedding model - runs in under a day on a single GPU. You can start with our ready-made nvidia/Retrieval-Synthetic-NVDocs-v1 dataset to try the pipeline right away. Let us know what you build.
\nStar the repos for Nemotron, NeMo Data Designer and NeMo Automodel if you find them useful.