What a Small RAG Fine-Tuning Experiment Can Actually Prove

I fine-tuned a pretrained reranker, verified that its weights changed, reloaded the selected checkpoint, and ran a controlled comparison with the original model.

The measured ranking gain on the held-out synthetic slice was zero.

That result was useful. It showed that the training and evaluation path executed while giving me no reason to claim an improvement. The slice contained three questions, only two of them answerable. Both rerankers reached nDCG@5 of 1.0 on those two answerable questions.

This is a local, AI-assisted experiment in progress. Real-domain fine-tuning and a sealed real held-out comparison have not been completed. Human review of generated answers is also pending. The current evidence supports a working experimental pipeline and a tied result on a tiny synthetic fixture.

The domain question is whether adjusting the reranker helps a retrieval-assisted answer system find useful source material and produce better supported answers.

That question contains several mechanisms. Retrieval selects candidates. Reranking orders them. Generation turns the selected context into an answer. An output can fail because of any of these stages, and improving one metric does not guarantee improvement downstream.

I chose to isolate reranking. The component being trained was a pretrained multilingual cross-encoder. The embedding model and answer generator remained fixed.

The concrete model identities were:

These official model weights were downloaded and actually exercised locally. The experiment used a CPU runtime. I have no verified CUDA execution to report.

Saying “I fine-tuned the RAG system” would leave too much unspecified. The adjusted weights belonged to the reranker; the experiment did not fine-tune the answer-generating language model.

I implemented four comparisons to make the source of a difference easier to inspect:

The hybrid retriever returns up to twenty candidates. C and D score the same candidate set, including cases where it contains no relevant material. Injecting the known correct passage into one variant would make the comparison answer a different question.

The generator identity includes the prompt, chat-template version, and decoding settings. Thinking was disabled for this comparison. Keeping those settings fixed matters because a prompt change can alter an answer even if retrieval is unchanged.

A versus B examines the addition of retrieval in this setup. B versus C examines the pretrained reranker. C versus D is the direct comparison for the adjusted weights. The differences remain conditional on this corpus, candidate generation, prompt, and evaluation design.

The synthetic training fixture contained forty pairs. I ran one epoch for each of three seeds: 42, 314, and 2026, with an effective batch size of sixteen.

The verification checked actual weight updates. It also checked that the saved selected weights matched the intended checkpoint and that independently re it preserved the expected predictions.

Those checks address concrete implementation mistakes: a frozen model that never updates, saving the wrong state, the original weights again, or evaluating a component whose identity does not match the recorded run.

They establish that training happened. They do not establish useful learning on the domain task.

On three answerable synthetic validation queries, nDCG@5 remained approximately 0.6667 before and after adjustment. The separately sealed synthetic held-out comparison also showed no ranking gain. I keep those two evaluations distinct rather than treating their denominators or scores as interchangeable.

The held-out fixture had two answerable questions and one unanswerable question. Four variants generated twelve answers in total.

A perfect score on two answerable questions leaves no visible room for an improvement in that metric. It does not establish that the original model is sufficient for deployment, or that fine-tuning would never help.

The useful decision is narrower: this fixture cannot justify retaining the adjusted component on the basis of a measured benefit. A harder, independently reviewed domain evaluation is needed.

Three training seeds also do not turn two answerable questions into six independent examples. Seed variation and variation across evaluation questions are different sources of uncertainty.

The evaluation has three layers because each catches a different failure.

Retrieval relevance asks whether the system recovered and ranked the passages needed to answer a question. Recall@20, MRR@5, and nDCG@5 are computed over answerable questions. Unanswerable questions receive null retrieval metrics and are counted separately. A system cannot retrieve a nonexistent relevant passage.

Citation integrity asks whether an emitted reference identifies a source that actually exists and belongs to the allowed context. This catches invented identifiers and broken provenance. It cannot establish that the cited text supports the claim.

Human factual and utility review asks whether the answer is supported, whether the actual cited sources are correct, whether the response is useful, and whether clarification or handoff was appropriate.

Consider this entirely invented example:

Source: "This material supports engraving. Delivery timing depends
on the order and must be confirmed separately."

Answer: "Engraving is available, and delivery takes two days. [S1]"

The identifier could be valid, and the source could be highly relevant. The delivery claim would still be unsupported. A citation parser passing would not repair the answer.

The lab prepares a blinded review packet with shuffled groups and answer ordering. Missing or unreviewed ratings remain pending. The generator does not approve its own factual correctness. The twelve synthetic answers currently have no completed human quality evaluation to report.

The pipeline binds corpus, splits, configuration, model identities, and actual weight hashes before the held-out evaluation. It verifies those bindings before inference.

A one-use receipt is anchored beside the freeze record. Repeating a completed request with unchanged inputs returns its saved, hash-checked results instead of generating fresh predictions. Interrupted or changed-input runs remain recorded rather than becoming opportunities to quietly try again.

This reduces accidental test reuse and configuration drift. It does not make the local operator unable to tamper with every file and receipt together. Independent storage and clear provenance still matter for an audit.

For the real experiment, checkpoint selection must use validation only. The protocol retains validation results from all three seeds and selects the confirmatory comparison before observing the test. Picking whichever seed wins on the held-out result would change the role of that test.

Work on the real corpus has progressed: the factual sources were reviewed, an index was built, and relevance annotation is underway. That progress is not a completed real-domain experiment.

Annotation needs usable positive passages, appropriate negatives, explicit answerability, and privacy review. A checkbox saying “reviewed” cannot substitute for missing passage labels or resolve a contradiction between “answerable” and “handoff.”

Equivalent questions introduce another constraint. Reusing a reviewed decision can reduce repeated annotation, but the copied decision is not independent evidence. Equivalent questions need to remain in the same split component, with provenance linking the reuse.

The protocol groups related customers, conversations, and near-duplicate questions before split assignment. It also keeps privacy review separate from relevance review. Approval to use a factual source does not automatically approve every conversation connected to it.

Until those requirements are met, producing more training steps would run ahead of the evidence. The pending work is reference quality and dataset preparation, followed by actual training and a separately frozen comparison.

I would include cases that make the components work harder: similar product sizes, material versus engraving questions, conflicting facts, missing price or delivery information, ambiguous requests, and prompt injection attempts.

I would report failure categories alongside aggregate ranking scores: missing retrieval, misranking, unsupported claims, unnecessary abstention, and incorrect handoff. Human review would use the same factual sources for every answer.

time and warmed inference time would remain separate. Any operational benefit would need its own measured evidence rather than being inferred from a short model call or a passing software test.

The current experiment proves that the selected models can run through a controlled local pipeline and that the pretrained reranker can be adjusted, saved, reloaded, and compared. Its synthetic held-out comparison found zero ranking gain. The next decision depends on independently reviewed domain examples and human answer evaluation.

I have published the architecture, comparison table, results, and evidence boundaries in the GitHub case study. It is a public writeup; the original training package, checkpoints, private sources, and individual predictions are not exported in that repository. The accompanying aggregate checker validates the arithmetic of the reported counts. It does not rerun the models, reproduce the training, or independently establish answer quality.

What evidence would make you keep—or remove—a fine-tuned component from your retrieval pipeline?