Base models are getting much better. But a strong general-purpose model is often not automatically ready for a production application. If your product has to meet a high bar for accuracy, consistency, cost, or user experience, you will usually need to adapt that base model for your specific tasks and domains.

That does not always mean re-training the model. A more useful question is: what is the model missing for this job?

Does the model need clearer instructions? Access to current documents? A behavior that holds across thousands of inputs? Deeper fluency in a specialized domain? A better sense of which response people prefer? Or a way to learn from whether a task actually succeeds?

Each requires a different strategy to adapt the base model. Some change the information available to the model at runtime. Others change what the model learns during training.

Here are the five techniques that we’ll go through in this post:

1. Prompt engineering, including few-shot examples and context engineering

2. Retrieval-augmented generation (RAG)

3. Supervised fine-tuning, including full and LoRA fine-tuning

4. Preference optimization, including DPO

5. Reinforcement learning (RL)

1. Prompt engineering: give the model a clearer brief

Prompt engineering changes what the model sees on each request. A good prompt spells out the job, the constraints, the output format, and any edge cases that matter. Few-shot examples show it a few representative input-output pairs.

Context engineering is another prompt-level technique. It organizes information already available for the current interaction, such as a user’s account details, earlier turns in the conversation, or a file they just uploaded.

Use prompting when the model already has the underlying capability and simply needs a clearer brief. A general model may be able to extract an invoice accurately once you name the fields, define what to do with missing values, and show two representative examples. If the relevant material is already known and fits in the context window, include it directly. You do not need a retrieval system just to pass along a three-page contract a user uploaded.

Prompting is the lowest-lift place to start because you can change it immediately, without preparing training data or running a training job. Its trade-off is that the instructions and examples travel with every request, and some task behaviors remain too fragile to hold with prompting alone.

2. RAG: bring the right knowledge to the request

RAG retrieves relevant material at inference time and puts it in the model's context. It does not modify the model’s underlying weights. Instead, it makes relevant documents or records available to the model when it needs them.

That makes RAG a good fit when the answer depends on information outside the model, especially information that changes or needs to be grounded in sources. A support assistant answering from current product documentation is a RAG problem. So is a policy assistant that must cite the policy in force today. The source material stays outside the weights, which means it can be updated, permissioned, and cited without another training run.

In practice, RAG can retrieve from an internal knowledge base of manuals, tickets, PDFs, or knowledge-base articles. An agent can also use search or tools to find external information, such as public webpages or structured records from a database or API. In either case, the system looks up the information instead of trying to bake changing facts into model weights.

RAG can make answers more reliable when it retrieves the right evidence, because it grounds the model in current, relevant facts. But retrieval can also surface irrelevant or incorrect material. And RAG does not, by itself, guarantee a strict JSON schema or a particular style. Evaluate both parts of the system to ensure retrieval surface the right material, and the model use this material correctly.

3. Supervised fine-tuning: teach the model the task

Supervised fine-tuning updates a base model using curated examples of the work you want it to perform. Those examples usually look like input → desired output.

It is useful when a behavior needs to be dependable across a large volume of requests. That might mean extracting a particular schema, applying an internal label taxonomy, following a specialized response style, or handling a repetitive workflow. Fine-tuning can also help a smaller model match the quality of a larger, slower, more expensive model on a narrow task.

Full fine-tuning updates all of the model’s weights. LoRA (Low-Rank Adaptation) fine-tuning updates a much smaller set of additional parameters while keeping the base weights fixed. Both can produce a specialized model for the same task, but LoRA is usually the more practical place to start because it requires less compute and makes it easier to manage task-specific variants.

For a deeper look at the practical work of fine-tuning, including model selection, data curation, training strategies, and evaluation, see our guide to fine-tuning open weight models.

Fine-tuning is a poor fit for information that changes frequently. Use RAG for material that needs to stay current or be cited. Fine-tuning also depends on clear, consistent training examples. Otherwise, it can reinforce ambiguity rather than resolve it.

4. Preference optimization: refine response quality with feedback

Preference optimization learns from comparisons rather than a single target answer. The data says, in effect, “for this prompt, response A is better than response B.”

That is useful when quality is comparative or partly subjective. Reviewers may be able to judge helpfulness, concision, tone, safety, adherence to a writing rubric, or which of two defensible responses is better, even when there is no single perfect answer to write down.

Direct Preference Optimization (DPO) is a common way to learn from those preferred-versus-rejected pairs. It is not reinforcement learning: DPO learns directly from the comparisons instead of adding the explicit reward-model and RL stage used in RLHF.

Preference optimization changes the model's behavior, not its access to facts. It cannot make the model know a new policy, and it cannot replace retrieval for current information.

5. Reinforcement learning: learn from whether the outcome worked

Reinforcement learning trains from feedback on outcomes instead of only showing the model an ideal answer. The model attempts a task, an evaluator assigns a reward, and the training process reinforces the approaches that earn higher rewards over many attempts.

This is most useful when success is easier to verify than to demonstrate. For example, an evaluator might check whether generated code compiles and passes tests, whether a database query returns the expected result, whether a structured output validates, or whether a multi-step workflow reaches the right end state. RL can learn from many valid paths to success, rather than being limited to a single reference solution.

The evaluator is the hard part. RL is only as useful as the reward signal, so it is a poor fit when the score is weak or easy to game. If the evaluator rewards the wrong behavior, the model will learn the wrong behavior very efficiently.

These techniques work together

These techniques are not mutually exclusive, but most applications do not need all six. Start with the pieces that solve the problem in front of you, then add more only when the evaluation shows a real gap.

For example, an internal support assistant might use a prompt to set its role and response format, plus RAG to pull the latest documentation. If, even with the right documentation retrieved through RAG, the assistant still struggles to emit the routing schema reliably across tickets, supervised fine-tuning may be the next step. Preference optimization is useful only if reviewers can consistently judge which customer-facing answer is better. RL is useful when the system can reliably score whether the model’s output or outcome was successful, especially for tasks with multiple valid paths to a solution.

A practical rule of thumb is to start with the smallest change that can meet the bar for your application. Keep knowledge outside the model when it needs to stay current. Train the weights when the behavior, preference, strategy, or domain fluency itself needs to persist.

Ready to adapt an open weight model for your use case?

You can fine-tune GLiNER2.5 and GLiNER2.5-Decide models today with our training API. Sign up on agent.fastino.ai to get started.