Fine-Tune an Embedding Model for RAG Without False Negatives

Fine-tuning has a fixed cost that a hit-rate chart does not show: a new embedding model means re-embedding every chunk you have. So the first job is to find out whether you need one.

Build a held-out set of real user queries, not synthetic ones, and have a domain reviewer label which chunks answer each. Use exactly the chunking you run in production, because a fine-tune evaluated on different chunk boundaries is evaluated on a different retrieval problem. A few dozen to a hundred labelled queries is enough to see whether the base model is in the right neighbourhood. This set never enters training, mining or dev evaluation.

Score two arms on it: the base model alone, and the base model plus the reranker you already run or would run. If the second arm clears your target, stop. A reranker improves results without touching the index, and our guide to when reranking is worth adding to RAG covers that trade. Fine-tune only when the reranker cannot recover passages the bi-encoder never retrieves, which shows up as low recall@k at the depth you feed the reranker.

The target is yours to set, before you look at results. For labelling discipline and metric definitions, use the method in how to test RAG retrieval accuracy; the gate later in this post reuses the same set.

One scoping note: this is retriever fine-tuning only. A 2025 comparison of independent, joint and two-phase fine-tuning of the embedding model and the generator found they reached about equal EM and F1 improvement at very different compute cost (arXiv 2510.01600), which supports fine-tuning the retriever on its own.

Regulated teams cannot ship the corpus to a hosted fine-tuning API, and they do not need to. The published basis for training on an unlabelled private corpus is GPL (arXiv 2112.07577): a query generator writes queries for each passage and a cross-encoder pseudo-labels them. It outperformed an out-of-the-box dense retriever by up to 9.3 nDCG@10 points across six domain-specialized datasets. That is the paper's result on its datasets, not an expected gain on yours.

The on-prem version of that pipeline is a local instruction model on your own serving stack writing one or more queries per chunk. Deduplicate the generated queries, drop the ones that copy a sentence verbatim from the chunk (they teach lexical matching, not retrieval), and split off a synthetic dev set for training-time evaluation. The real held-out queries stay out of all of it.

Pick the base checkpoint on the baseline numbers before you train anything; which embedding model to use for RAG covers that choice.

Hard negatives are, by construction, the passages most similar to the query that are not the labelled positive. On web-scale data most of those are genuinely wrong. On a corpus built from versioned procedures, templated contracts and repeated label text, the nearest non-positive passage is frequently a near-copy of the positive.

sentence-transformers does not protect you from this by default. At 6.2.0, mine_hard_negatives builds its candidate pool by merging the corpus with the positives and deduplicating on exact text, then masks the positive's own index. A superseded SOP that differs from the current one by a revision date and two words is not the same string, so it is a normal candidate negative unless a score filter removes it.

Five of the mining methods NV-Retriever compared, each used to fine-tune e5-large-unsupervised with the top 4 mined negatives. NDCG@10, from the paper's Table 3:

The two positive-aware methods at the bottom set the threshold relative to each query's positive score: MarginPos subtracts an absolute margin, PercPos takes a percentage. In the paper's false-negative check, they mined 57% fewer false negatives than naive top-k on NQ and 50% fewer on StackExchange. Accuracy dropped when the PercPos threshold went above 95%.

Rank-skipping (the second row) helps, and it is still the weakest fix. The paper's own assessment is that shifting by N "might even throw away valuable hard-negatives or keep false negatives": a fixed rank cannot know whether rank 11 is a near-copy of the positive or an unrelated passage. A fixed absolute score threshold (TopK-Abs) ignores how relevant the positive itself is. Earlier work on MS MARCO, as summarised in the NV-Retriever paper, estimated that about 70% of the passages most similar to queries there should have been labelled positive. The problem is not new; the near-duplicate density of regulated corpora makes it sharper.

One more finding is worth carrying into your pipeline: in NV-Retriever's comparison, the top-4 negatives mined by four different teacher models overlapped poorly, with Jaccard similarity below 30%. The model you mine with decides which negatives you get, so record it alongside the dataset.

Every filter below is a parameter of mine_hard_negatives at 6.2.0. They run in a fixed order: positives masked, then absolute or relative margin, then max_score, then min_score, then the top range_max candidates kept, then the first range_min of those dropped, then sampling.

Two behaviours in the source are easy to get wrong.

from datasets import Dataset
from sentence_transformers import SentenceTransformer
from sentence_transformers.util import mine_hard_negatives

base = SentenceTransformer("/models/base-embedder")  # local path, no Hub call

# queries[i] is a synthetic query written for chunk positives[i].
# A superseded version of the same clause goes in as an extra (query, positive) row,
# not as a candidate negative.
pairs = Dataset.from_dict({"query": queries, "positive": positives})

mined = mine_hard_negatives(
    dataset=pairs,
    model=base,
    corpus=all_chunks,         # mine from every chunk, not only the positive column
    relative_margin=0.05,      # drop candidates scoring above 95% of the positive
    num_negatives=4,
    sampling_strategy="top",
    output_format="n-tuple",   # query, positive, negative_1..negative_4
    batch_size=128,
    use_faiss=True,
)

Mining filters only clean the negatives you add explicitly. MultipleNegativesRankingLoss also treats every other row's positive in the batch as a negative for the current query. If two chunks of the same boilerplate clause land in one batch, each is a false negative for the other's query.

BatchSamplers.NO_DUPLICATES is recommended for this loss family, and it removes exact duplicate texts from a batch. It does nothing about near-duplicates. The in-batch counterpart of a mining margin is GISTEmbedLoss (arXiv 2402.16829): a guide model scores the in-batch candidates and any negative scoring above the positive (minus an absolute or relative margin, set with margin_strategy and margin) is dropped.

CachedMultipleNegativesRankingLoss implements gradient caching, so, in its docstring's words, memory that works with a batch size of 32 can process much larger batches. The block below uses the v6 import paths from the official training overview. learning_rate=2e-5 and warmup_steps=0.1 are that documentation example's starting values, not tuned recommendations: tune epochs and learning rate against your synthetic dev evaluator, never against the held-out set.

from sentence_transformers import (
    SentenceTransformer,
    SentenceTransformerTrainer,
    SentenceTransformerTrainingArguments,
)
from sentence_transformers.sentence_transformer.losses import CachedMultipleNegativesRankingLoss
from sentence_transformers.sentence_transformer.training_args import BatchSamplers

model = SentenceTransformer("/models/base-embedder")
loss = CachedMultipleNegativesRankingLoss(model, mini_batch_size=32)

args = SentenceTransformerTrainingArguments(
    output_dir="/models/embedder-ft",
    num_train_epochs=1,
    per_device_train_batch_size=256,  # effective batch; memory is bounded by mini_batch_size
    learning_rate=2e-5,
    warmup_steps=0.1,
    bf16=True,
    batch_sampler=BatchSamplers.NO_DUPLICATES,
    eval_strategy="steps",
    eval_steps=0.1,
)

trainer = SentenceTransformerTrainer(
    model=model,
    args=args,
    train_dataset=mined,
    loss=loss,
    evaluator=dev_evaluator,  # synthetic dev split, never the held-out real queries
)
trainer.train()
model.save_pretrained("/models/embedder-ft/final")

If you are coming from v5, the old paths (sentence_transformers.losses, sentence_transformers.evaluation, sentence_transformers.training_args) still resolve through a deprecation shim in 6.2.0; move to the new ones. The library also ships PEFT LoRA and Unsloth training examples if you want adapter training instead of full fine-tuning. Late-interaction (ColBERT-style) training uses the separate MultiVectorEncoder trainer added in v6.0.0 and is out of scope here.

The gate runs once, on the held-out real queries from the baseline step, with production chunking unchanged. It has four arms:

InformationRetrievalEvaluator covers the first two. Its defaults report MRR@10, NDCG@10, accuracy and precision and recall at 1, 3, 5 and 10, and MAP@100. Calling it on a model returns a dict whose keys follow name, score function and metric, so a cosine model with name "heldout" yields heldout_cosine_ndcg@10. Queries with no labelled relevant chunk are skipped, so check your qrels coverage before trusting the averages.

from sentence_transformers import SentenceTransformer
from sentence_transformers.sentence_transformer.evaluation import InformationRetrievalEvaluator

gate = InformationRetrievalEvaluator(
    queries=heldout_queries,   # {qid: text}: real user queries, never used in training
    corpus=chunks_by_id,       # {cid: text}: production chunking, unchanged
    relevant_docs=qrels,       # {qid: {cid, ...}}: labelled by a domain reviewer
    mrr_at_k=[10],
    ndcg_at_k=[10],
    precision_recall_at_k=[5, 10, 20],
    name="heldout",
)

for path in ("/models/base-embedder", "/models/embedder-ft/final"):
    scores = gate(SentenceTransformer(path))
    print(path, scores["heldout_cosine_ndcg@10"], scores["heldout_cosine_recall@10"])

For arms 3 and 4, use CrossEncoderRerankingEvaluator with samples that carry a "documents" list: each bi-encoder's own ranked results for the query. With "documents", it reports performance both before and after reranking. Set always_rerank_positives=False. The default (True) inserts every labelled positive into the list, which measures the reranker on passages your retriever may never have returned. False is the realistic setting, and it is the one that shows whether the fine-tune improved what reaches the reranker.

Then add a general-query slice to catch regressions on questions outside your training distribution. NanoBEIREvaluator reports the same metrics on downsized BEIR datasets, loaded from the Hugging Face Hub by default, so on an air-gapped network mirror the dataset internally first.

The merge option is new in 6.2.0: SentenceTransformer.merge interpolates checkpoints (linear, slerp, ties and DARE variants) with the [merge] extra installed. The library's own documentation warns that merging "can improve some tasks while making others worse", so the merged model is a fifth arm through the same gate, not a fix you assume.

A fine-tuned model writes vectors into a different space from its base, so every chunk gets re-embedded and the two sets of vectors never share an index. Build the new index beside the old one, point the gate at it, and cut over in one change-controlled step with the old index kept for rollback. The wider cost of switching embedding models, and the lock-in it creates, is covered in self-hosted vs API embeddings.

Everything in this pipeline runs inside the perimeter. Model loads come from local paths, query generation runs on your own serving stack, mining and training fit on one in-house GPU with the cached loss, and the gate runs on reviewer-labelled queries that never leave the building. For serving the result, see Text Embeddings Inference vs vLLM vs Infinity.

What changes in a regulated setting is that the fine-tuned model is a new artifact somebody has to validate. Version these together, as one bundle:

That bundle is what a model-risk or validation function reviews, and it is what lets you reproduce the model when a regulator or auditor asks how retrieval behaved on a given date. Whether fine-tuning changes your role under the EU AI Act is a separate question, covered in does fine-tuning make you a provider under the EU AI Act. More on building retrieval in-house is in our RAG systems guide.

Pull a few dozen to a hundred real queries from your logs, have someone who knows the documents label the chunks that answer each, and run the base model and the base model plus your reranker through InformationRetrievalEvaluator with name="heldout". If the reranker arm clears your target, you are done and your index stays as it is. If recall@k at the reranker's input depth is the bottleneck, you have your reason to fine-tune, and the held-out set you just built is the gate it will have to pass.