SFT vs. RL: Which Fine-Tuning Method Should Enterprises Use?

Ask a model what happens when someone touches fire, enters deep water without knowing how to swim, or provokes a violent bully. If you show it the desired answers, you are teaching by example. If you let it answer, score the result, and reward safer or more accurate predictions, you are teaching by consequence. That is the simplest useful explanation of supervised fine-tuning versus reinforcement learning.

The confusion starts because both methods are called fine-tuning, both can improve the same base model, and both eventually update weights with gradient-based optimization. The difference is not whether the model learns. The difference is the signal that tells it what to learn.

For an enterprise buyer, this is not an academic distinction. The wrong method can turn a fixable workflow problem into a costly training program. The right decision often saves more money than the training itself.

SFT Gives the Model an Answer Key

Supervised fine-tuning, or SFT, trains on demonstrations. Each training example contains an input and the output you want the model to produce.

Consider a basic cause-and-effect dataset:

After training, the model receives a new input: "What might happen if you touch a hot stove?" It has never seen that exact sentence, but it can generalize the demonstrated pattern and answer, "You could burn your hand."

The child-level version is accurate: SFT shows the student questions together with the answer key. Technically, training minimizes the difference between the tokens in the model's response and the tokens in the demonstrated response, usually with cross-entropy loss. The optimizer then changes the trainable weights so the demonstrated responses become more probable.

This is similar to few-shot prompting, with one important difference:

• Few-shot prompting puts examples on the model's desk for the current test.
• SFT uses examples as homework and changes what the model has learned internally.

SFT is a good fit when experts can show what good looks like. Common enterprise applications include:

• Style and tone: Rewrite support answers in the company's approved voice.
• Formatting: Produce valid JSON or follow a fixed report template.
• Classification: Route a ticket, detect intent, or label a document.
• Extraction: Pull names, dates, amounts, clauses, or product codes from text.
• Domain behavior: Use company terminology or follow a legal-review checklist.
• Tool-call patterns: Produce the right CRM or API call for a known request.
• Standard workflows: Turn a complaint into an approved response and next action.

For example, a support team can train on pairs like:

Input: Customer says, "I was charged twice."
Desired output: {"category":"billing","issue":"duplicate_charge"}

The training set gives the model the target behavior directly. Fireworks' current fine-tuning guidance recommends SFT when a team has a sizable set of high-quality labels that covers the main input patterns. That is the right operational test: if your staff can write the answer key consistently, SFT has a strong training signal.

RL Gives the Model a Score

Reinforcement learning, or RL, starts from a different asset. You may not know the one ideal response, but you can evaluate whether an attempt worked.

Imagine an agent trying to cross a room:

• Walk into a wall: reward -1
• Move closer to the door: reward +0.1
• Reach the door: reward +10

The agent tries actions, observes the scores, and updates its policy so action sequences with higher expected reward become more likely. For language models, the actions are generated tokens, tool calls, or steps in a larger workflow. The score can come from unit tests, an exact-answer checker, a business simulator, a human preference, or another model acting as a grader.

The simplest distinction is: SFT learns from demonstrated answers; RL learns from evaluated attempts.

Calling RL "hill climbing" is conceptually reasonable. Generate behavior, measure reward, adjust toward behavior with higher expected reward, and repeat. The actual training is normally gradient-based. Policy-gradient methods estimate which generated actions contributed to the reward, then increase or decrease their probability. They do not randomly change every weight and keep whichever mutation wins.

RL is strongest where many paths could be valid and the result is easier to score than to demonstrate:

• Coding: Reward code that compiles and passes tests; penalize crashes or excessive runtime.
• Math and reasoning: Reward correct final answers and, where appropriate, valid intermediate work.
• Agents and tool use: Reward completed tasks; penalize forbidden actions, failed calls, excess cost, or latency.
• Search and research: Reward finding the required evidence; penalize unsupported claims or missed sources.
• Games and simulations: Reward the final state while allowing the model to discover useful action sequences.

This is why reinforcement fine-tuning works well for verifiable tasks. Fireworks describes an RFT loop as three parts: the agent produces a rollout, an evaluator scores it from 0 to 1, and the trainer updates the model. Its RFT documentation also makes the data difference clear: SFT and preference training consume labeled examples, while RFT depends on graders and generated rollouts.

There is a catch. A reward function is not the business objective. It is an executable approximation of the business objective. An agent can earn a high score by exploiting a blind spot in the grader, a failure called reward hacking or specification gaming. Google DeepMind's collection of specification-gaming examples shows how readily agents find shortcuts that satisfy the literal metric without doing what the designer intended.

An RL project is therefore a grader project before it is a training project.

SFT vs. RL: Use the Asset You Actually Have

Teams often ask which method is more powerful. That is the wrong first question. Ask which trustworthy training signal the company can produce.

A reliable selection process uses five questions.

1. Can an expert write the desired output? If yes, start with SFT. Do not build an RL environment to teach a model a JSON schema.

2. Can success be scored automatically? "The code passes all tests" is strong. "The answer feels strategic" is weak unless human reviewers agree consistently and a grader can reproduce their judgment.

3. Are there many acceptable solution paths? RL earns its added cost when forcing one demonstrated path would limit useful exploration. A research agent may find the same evidence through several query sequences. A code agent may produce many correct patches.

4. Can the grader be gamed? Test it against empty answers, copied reference text, overly long answers, forbidden tools, false citations, and cheap shortcuts. If obvious bad behavior receives a good score, training will amplify the problem.

5. Does the base model already have the capability? Post-training is best at steering and specializing behavior the model can already perform. The original InstructGPT work used SFT demonstrations first, then human comparisons and RL. The authors were explicit that this post-training mostly made existing capabilities easier to elicit; it did not replace pretraining.

The common enterprise path is not SFT or RL. It is a sequence:

1. Establish a held-out evaluation set.
2. Improve the prompt, context, retrieval, tools, and workflow.
3. Use SFT to teach stable behavior and domain conventions.
4. Add preference training if ranking outputs is easier than writing perfect answers.
5. Add RL only for the remaining outcomes that are reliably scorable and require exploration.

That sequence is close to the method used for instruction-following models: demonstrations establish competent behavior, then preferences or rewards sharpen it. Starting directly with RL asks an unstable model to explore against a grader that the team has probably not tested enough.

Where Tinker and Fireworks Fit

Managed training APIs remove much of the GPU work, but they do not remove the need to choose and own the training signal.

Thinking Machines' Tinker is a programmable training API. A developer writes the local training logic and uses a small set of remote operations to sample outputs, compute gradients, update weights, and save checkpoints. Its quickstart maps both SFT and RL loops to those operations. Tinker currently uses LoRA, where a smaller set of adapter parameters is trained instead of updating every base-model weight, and it allows checkpoints to be downloaded.

Fireworks covers a broader path from training to hosted inference. Teams can use managed SFT, preference optimization, or RFT jobs with configuration rather than a custom loop. Research teams can instead use its Tinker-compatible Training API for custom objectives, rollout orchestration, and inference during training. Managed fine-tuning supports both LoRA and full-parameter training, depending on the model and job.

The choice is less about whether either platform "can do RL" and more about the operating model. Tinker is training infrastructure exposed as programmable primitives. Fireworks is a model platform with managed recipes, lower-level training, and production inference.

LoRA also matters for procurement and deployment. The original LoRA paper showed how freezing base weights and training small low-rank matrices can cut the number of trainable parameters sharply. That can make experiments cheaper and make adapters easier to store or move. It does not solve evaluation, data rights, security review, rollback, or serving economics. Those remain enterprise responsibilities.

What Enterprises Should Do Before Training

Most enterprise AI failures are not weight problems. They are missing-context problems, weak tool contracts, poor data, unclear acceptance rules, or broken process design. Fine-tuning a model on top of those defects makes them harder to see.

Before approving SFT or RL, require six artifacts:

1. A workflow baseline. Record current quality, cycle time, cost, escalation rate, and failure severity.
2. A held-out eval set. Keep representative and adversarial cases out of training so improvement can be measured honestly.
3. A data contract. Document provenance, consent, retention, sensitive fields, labeling rules, and who can approve training data.
4. A method hypothesis. State why a weight update should fix the observed failure better than prompting, retrieval, code, or workflow changes.
5. A release gate. Set minimum quality plus limits for regressions, cost, latency, security, and policy compliance.
6. A rollback plan. Version the base model, adapter, dataset, grader, prompt, and tool definitions so the last known-good system can be restored.

Run a small experiment first. For SFT, inspect whether the model generalizes beyond the phrasing and entities in the demonstrations. For RL, compare reward against independent human review and a separate test suite. A rising training reward with flat business quality is evidence that the grader is wrong, not that the model needs more training.

The counter-intuitive result is that the evaluation system is usually the lasting asset. Models and training vendors will change. A company-specific set of accepted examples, failure cases, graders, and release thresholds can be reused across each new model.

How OpenNash Can Help

OpenNash helps enterprises decide whether a problem needs training at all, then builds the smallest system that can prove the answer.

We start with the workflow rather than a preferred model vendor. We map the system of record, inputs, outputs, approvals, failure costs, and current human corrections. Those corrections often reveal the right path: repeatable target outputs point toward SFT; measurable outcomes with several valid paths point toward RL; missing or stale knowledge points toward retrieval; exact policy logic belongs in deterministic code.

If fine-tuning is justified, we help the team turn production evidence into a governed training program. That includes dataset design, grader tests, held-out evals, vendor and model comparisons, cost controls, tracing, release gates, human review, and rollback. We can implement against a managed platform or an open-model stack, with ownership and deployment constraints decided before the first training job.

The deliverable is not a model that scored well once. It is a repeatable process for deciding what to train, proving that it improved the workflow, and catching regressions before users do.

Book a call to map SFT, RL, or a simpler alternative to one enterprise workflow. Bring ten examples of where the current system fails and the business definition of a successful outcome.