Prompting, RAG, or fine-tuning? Choose by failure mode

Prompting, RAG, and fine-tuning address different causes of failure. Clarify instructions and examples when the task is underspecified. Supply permitted, current information at request time when the model lacks facts. Consider training only when the right facts are already present yet a stable behavior repeatedly fails. The approaches can be combined, but one should not masquerade as another.

This lesson helps you choose the next intervention to test. Deciding whether RAG is worth building has a separate investment gate for a proven source-selection bottleneck, including indexing, access, and upkeep. First ask where the present result went wrong.

Fix the job, acceptance rule, and failures first

Select one real workflow. Save the user input, the instructions and material actually sent to the model, its output, the expected result, and the first point a reviewer can identify as wrong. Define intolerable failures: citing an expired warranty clause, placing an urgent ticket in an ordinary queue, or breaking a machine-readable interface. If reviewers cannot agree on a passing answer, repair the acceptance contract before changing methods.

Run the current model and workflow as a baseline. Tag cases by slice: ordinary, missing source, conflicting version, ambiguous category, refusal, or human handoff. Set aside representative holdout cases for the final comparison; do not copy them all into prompt examples or training data. OpenAI’s optimization and supervised fine-tuning guides put evaluation before tuning. Anthropic likewise asks for measurable success criteria before prompt engineering.

Route from the first point of failure

What failed	Smaller next test	When to consider a different method
Goal, output shape, or exception rule is unclear	Clarify instructions, add a few positive and negative examples, validate structured output	If clear rules still fail repeatedly on holdout cases, investigate capability or tuning
An answer lacks facts specific to this request	Attach the current file selected by the user or query an authoritative structured field	Trial retrieval when many different sources must be selected per request
Correct material is present but stable behavior remains wrong	Compare examples, validators, and model candidates	Test fine-tuning only if usable labeled data and an available training service exist
Exact price, stock, or eligibility lives in a business system	Return the value through deterministic code or a controlled tool	Let the model explain a verified result rather than train it to guess a changing value

The prompting route includes clear instructions, a few examples, and a small approved reference placed directly in context. RAG selects external evidence at request time; it does not validate the source or enforce access by itself. Fine-tuning changes the model’s tendency on similar inputs. It is not a dependable mechanism for synchronizing current facts.

Give each route an entry gate

Start with prompting and direct context. For the same failed inputs, change one thing at a time: a rule, example, output contract, or attached current reference. Record whether the target slice improves and whether another slice regresses. A two-page stable guide does not need an index merely to qualify as “RAG.”

Prove source selection before retrieval. For each question, record the passage that should be found, retired or unauthorized near matches that must be excluded, and the correct no-evidence result. If attaching the chosen document or querying an authoritative database meets acceptance, defer a retrieval layer. If RAG is still warranted, use a separate retrieval trial to test passage coverage, ranking, versions, and access before scoring generated prose.

Check whether tuning is actually possible. You need examples whose training use is permitted and whose labels have been reviewed, a reasonably stable task, reproducible behavior failures after a prompting baseline, and support for the chosen provider, product interface, model, account, and region. These are distinct gates. As checked on October 1, 2026, OpenAI’s documentation says its fine-tuning platform is winding down and unavailable to new users. Google’s Gemini API and AI Studio currently have no tunable model, while its Gemini Enterprise Agent Platform has a separate tuning route. Recheck the exact deployment environment before acting; these notices are time-sensitive.

There is no universal training-example minimum across providers and tasks. Hold out cases that were not used for training or prompt-example selection. Check label agreement, rights, and privacy before following the current platform’s requirements for a limited trial. A model tuned for format or classification may still need retrieval for live facts.

Compare matched trials with a stopping rule

For every candidate, record the model version, prompt, source snapshot, retrieval settings, training-data version, and run date. On the same holdout cases, compare accepted completion rate, important slices, severe failures, human correction, end-to-end latency, and cost per accepted task. For RAG, measure whether the right evidence reached the model separately from answer quality. For tuning, measure unseen behavior and regression on existing capabilities.

Declare hard gates before running: unauthorized material in context, an expired source that changes a decision, an unsafe action, or a missing required output field pauses that candidate. An average score cannot cancel a blocking failure. If a small gain does not justify added operations, keeping the baseline is a valid decision. Retest when business rules, source cadence, model version, or training-service availability changes.

Example one: weekly warranty bulletins

An equipment service provider answers whether a model qualifies for an extended warranty after its purchase date. Regional service teams replace bulletins weekly. An answer must identify the effective bulletin; dealers may see only their authorized region. The failed baseline cited an old bulletin. Stronger wording would not fix that source error.

First try a deterministic query by model and purchase date, attaching the matching bulletin to the request. If it reliably selects one effective clause, the prompt can focus on citation and uncertainty. If the questions need cross-section conditions from a large unstructured collection, apply the RAG investment gate and test retired bulletins, similarly named models, and access-empty results. Training bulletin contents into a model cannot promise that next week’s effective notice will immediately replace an old rule.

Example two: seven-way support routing

Another team classifies complete support tickets into seven stable categories and emits fixed JSON. Ambiguous or high-risk tickets go to a person. The ticket and approved category definitions contain all required facts; no changing document collection needs to be searched. The first trial should clarify category boundaries, show a few confusing cases, and validate the JSON, rather than build a vector store.

If the same category boundary still fails on unseen tickets, the team can inspect annotator agreement, permission to train on examples, and current training-service access before trying a tuned model. It must clear the preset gate on mixed-intent and high-risk holdout tickets, with training, deployment, retraining, and review counted in cost. If it merely saves retries while increasing severe misroutes, keep the simpler baseline.

Leave a decision someone else can replay

Use the workbench below to record the job, first failing layer, direct-context or deterministic alternatives, fact volatility and citation needs, usable labeled data and rights, provider availability, and matched results for each candidate. Finish with the next experiment, blocking conditions, owner, and review date. “Choose RAG” or “fine-tuning is more advanced” is not enough; a colleague should be able to rerun the reasoning on the same cases.

Common questions

Can a fine-tuned model store product knowledge? Stable behavior or formatting can be tested with tuning. Changing facts, permissions, and effective dates still need an authoritative source at request time and answer-level verification.

Does a large document collection always require RAG? No. If a user chooses one file, or a business system can return the exact field, test that route first. Retrieval earns its place through a demonstrated selection problem and an owner for maintenance.

Must prompting, RAG, and fine-tuning be mutually exclusive? No. Instructions can set task rules, retrieval can supply current evidence, and a tuned model can be tested for stable output behavior. Each added layer needs evidence of benefit and an operating owner.

Boundary

This record cannot replace verification of a provider’s current capabilities, data terms, or prices, and it cannot solve disputed business rules. A small trial identifies the next experiment, not long-term reliability. Before production, every candidate still needs task-specific evaluation, source and access checks, and a human path for failures.