Choose supervised fine-tuning (SFT) when you can demonstrate desired responses, direct preference optimization (DPO) when you can compare preferred and rejected responses to the same input, and reinforcement fine-tuning (RFT) when you can reliably grade generated responses. The usable training signal should determine the method; the method's name does not establish that a particular model supports it.
Before committing to training in Microsoft Foundry, verify the exact model and version, supported method and modality, training approach and geography, and eligible serving path. Compare a candidate against a stable baseline on independent held-out tasks. A successful training job, lower training loss, or higher training reward does not by itself demonstrate a better application.
Establish a Behavioral Problem Worth Training
Fine-tuning updates a pretrained model's weights using additional task-specific training. Prompt examples instead condition individual requests, while retrieval-augmented generation (RAG) supplies external evidence at request time. These mechanisms can work together, but their failure modes differ.
Suppose a maintenance assistant consistently extracts the right evidence but produces inconsistent handover summaries. Start by testing a clearer output contract and representative prompt examples. Training becomes a candidate if a measured behavioral gap remains and the team can provide suitable learning signals. If the assistant lacks the latest equipment policy, first investigate document freshness and retrieval. Memorizing a changing policy is a poor maintenance strategy.
Write the desired change as an observable requirement: correctly structured handovers without losing relevant warnings, for example. Include safety and operational constraints alongside the target benefit. Neither fewer prompt examples nor a smaller adapted model guarantees a lower total cost; training, grading, evaluation and serving all contribute to the decision.
Match the Method to Evidence You Can Defend
The following comparison concerns the predefined methods in managed fine-tuning. Availability is specific to the selected model.
| Method | Evidence supplied | Example selection decision | Main evidence risk |
|---|---|---|---|
| SFT | Inputs paired with desired outputs | Choose it when reviewers can write representative handovers demonstrating required structure and content. | Inconsistent demonstrations teach inconsistent behavior; polished examples can omit difficult cases. |
| DPO | A preferred and a rejected response for the same input | Consider it when reviewers can reliably prefer a complete, restrained handover over a verbose or incomplete alternative. | Preference labels can reward style while overlooking factual errors or missing warnings. |
| RFT | Inputs plus a grader that scores generated outputs | Consider it when several solutions are acceptable and a dependable scoring process can distinguish their quality. | A model can exploit weaknesses in a grader while earning a higher reward. |
The example choices are engineering reasoning, not claims that a particular training run has succeeded. For SFT, audit whether demonstrations cover both routine and exceptional handovers. For DPO, ask reviewers to explain why one response is preferred and resolve inconsistent criteria. For RFT, challenge the grader with correct, incorrect and adversarial responses before treating its scores as a usable learning signal.
An application evaluator and an RFT training grader also have different jobs. An evaluator may help decide whether a release is acceptable; a training grader supplies feedback during optimization. Reusing a rubric requires deliberate validation. A grader that approves the exact training reward pattern is not an independent test of general task performance.
Check Service Compatibility Before Preparing a Run
Create a short compatibility record for the proposed experiment. Record the evidence date because support can change, and resolve every dimension for the exact candidate rather than a similarly named model family.
- Identify the base model and version, required input/output modality and intended method. Check the supported-model table and its footnotes; support for SFT does not establish DPO or RFT support.
- Choose the training approach. Managed fine-tuning supplies predefined workflows. Interactive training exposes lower-level operations, is preview, and requires explicit access approval; a cookbook recipe alone does not prove service availability.
- Verify the training type and permitted location for the selected model. Check applicable processing and data-handling constraints rather than assuming that all training stays in the resource's region.
- Verify the intended deployment option, deployment type and regional eligibility for the resulting artifact. Training geography and serving geography are separate checks. A model that can be trained is not automatically eligible for the desired production runtime.
- Establish experiment, grading, evaluation and hosting budgets and any capacity or access prerequisites before submitting work. Stop when required support or organizational eligibility is unresolved.
This record prevents a costly dead end: choosing a method and preparing data only to discover that the required model/method combination cannot serve through the approved path. Preview eligibility deserves its own decision; experimental availability does not establish production suitability.
Use a Comparison That Can Reject Fine-Tuning
Keep a baseline representing the application as it currently works, including its prompt and retrieval configuration. Preserve an independent final test set before selecting examples or optimizing graders. Keep related or duplicated cases from leaking across the training and test boundary, and document any necessary grouping, such as multiple records from one underlying incident.
For the maintenance assistant, compare the baseline and candidate on the same unseen incident cases and relevant operational slices. Assess required fields, warning preservation, unsupported assertions and safety behavior. Measure latency and resource use under comparable conditions. The team should define acceptable tradeoffs before examining candidate results, rather than selecting only the dimensions that improved.
A candidate that improves summary consistency but omits rare warnings should not be accepted solely because its average rubric score increased. Investigate whether the issue lies in demonstrations, preference criteria, grader behavior or the application contract. Repeat only a justified experiment with a recorded change. Preserve the baseline as a valid outcome when the candidate does not meet the intended benefit and constraints.
This is an experiment design, not a claimed benchmark. It establishes what evidence would support a method choice without inventing training outputs, success rates or a universal minimum dataset size.
Common Selection Mistakes
- Choosing RFT because it sounds more advanced even though nobody can validate the grader.
- Treating preference pairs as desired-output demonstrations without checking their meaning or consistency.
- Selecting a supported model family while overlooking version, modality, method or region restrictions.
- Using training reward or training loss as the sole release criterion, or repeatedly inspecting the final test set during optimization.
- Expecting weight adaptation to replace current retrieval evidence, application safety controls or final-runtime evaluation.
Carry the Decision into Data Qualification
The useful output of method selection is a supported candidate, an explicit training signal, a documented baseline and a comparison capable of rejecting the candidate. Data qualification can then examine provenance, sensitive content, coverage and leakage against that decision. Production release needs its own artifact lineage and serving checks after training. Keeping these outcomes explicit makes the selection reviewable and gives later experiments a clear reason to proceed or stop.