Fine-Tuning vs RAG vs Prompt Engineering: The LLM Customization Decision Framework
Three tools, one recurring argument
Every team that ships an LLM feature ends up in the same meeting. The answers are not good enough, and someone proposes fine-tuning. Someone else has read about retrieval and wants a vector database. A third person quietly points out that nobody has looked at the prompt in three weeks. The fine-tuning vs RAG vs prompt engineering debate stalls because the three approaches get treated as competing options for the same job, when in practice they fix different failures.
Prompt engineering changes how the model is instructed. RAG changes what information the model sees at request time. Fine-tuning changes the model's weights, and with them its default behavior. Once you frame it that way, most of the decisions make themselves. The rest of this post works through each approach, where it fits, what it costs, and whether you should run it yourself or pay someone else to.
Start with the prompt, every time
The prompt is the cheapest lever and the one most teams underuse. You can change it today, ship it in the next deploy, and read the result with your own eyes. You do not need a training run, a dataset, or any new infrastructure. If an output is wrong, you can see exactly what the model was told and reason about why it went wrong.
A surprising number of "we need to fine-tune" requests turn out to be prompt problems. Common cases include instructions buried in the middle of a long system message, no examples of the expected output, contradictory rules added by different people over time, and a single mega prompt trying to handle six distinct tasks. Splitting that prompt into one per task, adding two or three worked examples, and moving the most important constraint to the end of the instructions fixes more quality issues than any other single change we have seen on client projects.
Prompt work has limits. It cannot give the model facts it never saw. It gets expensive at scale if you are stuffing thousands of tokens of context into every request. And it will not reliably force a specific output format across millions of calls without help from a schema or validation layer. When you hit those walls, you have found the boundary of what prompting can do, and only then does it make sense to look further.
If you have not exhausted the prompt, do not skip ahead. The fine-tuned model you build will inherit every unclear instruction you failed to fix.
RAG is for knowledge that changes or does not fit
Retrieval-augmented generation solves a specific problem: the model needs information it does not have. That covers product documentation, internal knowledge bases, customer records, support ticket history, contracts, anything that is either too large to put in the context window or changes often enough that a static snapshot would be stale within weeks.
The misconception that causes the most wasted budget is the belief that fine-tuning teaches a model facts. It does not, at least not reliably. Fine-tuning shifts how a model responds, but a model trained on your documentation last month still does not know what changed yesterday, and it will happily invent plausible-sounding details when asked about things it half remembers. RAG sidesteps this by fetching the relevant passages at request time and putting them in front of the model, so the answer is grounded in the current version of the source.
RAG has its own failure modes, and they are almost all retrieval failures rather than generation failures. Bad chunking, weak embeddings for your domain vocabulary, no reranking step, and a missing evaluation harness account for most of the "the AI gives confident wrong answers" complaints we get called in to investigate. We covered the mechanics in Building Production-Ready RAG: A Symfony + pgvector Architecture Blueprint and the measurement side in RAG Evaluation Metrics: Measuring Retrieval Quality Before You Blame the Model.
The signal that you need RAG is simple. If the correct answer to a user's question lives in a document somewhere, and the model cannot be expected to know that document, you need retrieval. No amount of prompting or fine-tuning substitutes for showing the model the source.
Fine-tuning is for behavior, not knowledge
Fine-tuning is the right tool when the problem is how the model responds rather than what it knows. Typical cases include getting a model to write in a specific house tone without a 2,000 token style guide in every prompt, forcing a consistent JSON schema for high volume structured extraction, teaching a domain specific reasoning pattern (for example, how a claims adjuster works through a case), and shrinking a prompt that has become so long it dominates your per-request cost.
The economics are what make fine-tuning attractive at volume. If you are sending the same 1,500 tokens of instructions and examples on every one of ten million monthly calls, those tokens cost real money. A fine-tuned model that has internalized the instructions can run on a fraction of the prompt, and often on a smaller base model, which cuts both latency and spend. This is also why fine-tuning shows up late in a product's life rather than early: you need the volume for the savings to matter, and you need a stable task definition so the training data does not go stale.
The prerequisites are where teams get stuck. You need a few hundred to a few thousand high quality examples of the exact behavior you want. Those examples have to be consistent, because the model will learn your inconsistencies just as eagerly as your intent. You need an evaluation set held back from training so you can tell whether the new model is better or just different. And you need to accept that every time the task changes, the training set and the model need refreshing.
One more thing fine-tuning does not do: it does not fix retrieval. The typical failure looks like this. A team fine-tunes a model on its support articles, expecting it to answer product questions. The tone comes out right, but the facts drift as soon as the articles are updated, because the model only knows the version it was trained on. What that team needs is RAG, with the fine-tuned model sitting behind it for tone. That combination works well, but only if you understand which layer is doing which job.
The decision framework
Here is the sequence we walk clients through.
First, is the output wrong because the model was instructed poorly? Rewrite the prompt, add examples, split tasks. Measure. This step is free and should never be skipped.
Second, is the output wrong because the model lacks information? If the correct answer exists in a document, database, or API, add retrieval. Start with a simple pipeline, measure retrieval quality separately from answer quality, and only then tune chunking and reranking.
Third, is the output correct in substance but wrong in form, tone, or structure, and is that costing you at scale? Now fine-tuning is worth the investment. Collect examples from your best prompted outputs, train, evaluate against a held out set, and compare cost per request against the prompted baseline.
The three are not exclusive. A mature system often uses all of them: a tight prompt, retrieval for facts, and a fine-tuned model for consistent format. The mistake is starting at step three.
| Problem you are seeing | Likely fix | Why the others do not help |
|---|---|---|
| Ignores instructions, inconsistent quality | Prompt engineering | Fine-tuning bakes in the unclear instructions; RAG adds no guidance |
| Facts wrong, outdated, or invented | RAG | Fine-tuning does not reliably store facts; prompts cannot hold your whole knowledge base |
| Right content, wrong tone or format at high volume | Fine-tuning | Prompting works but costs tokens on every call; RAG is irrelevant to style |
| Prompt so long it dominates cost | Fine-tuning | RAG adds tokens; prompt compression has a floor |
| Answers need to cite current sources | RAG | Neither of the others can point to a document |
What each approach costs at different scales
Numbers vary by provider and model, so treat these as orders of magnitude rather than quotes.
At a few thousand requests a month, prompt engineering costs engineering time and almost nothing else. RAG costs a vector store (pgvector in your existing Postgres is often enough) plus embedding calls, typically tens of dollars a month. Fine-tuning at this scale is hard to justify: the training run and evaluation work cost more than a year of the token savings.
At a few hundred thousand requests a month, prompt length starts to show up on the invoice. A 1,500 token system prompt on 300,000 calls is 450 million input tokens, and with current pricing that is a line item someone will ask about. RAG infrastructure grows modestly, but retrieval latency becomes a product concern. Fine-tuning begins to pay for itself if the task is stable, because trimming the prompt by 1,000 tokens per call saves more than the training cost within a quarter.
At millions of requests a month, all three matter and the trade-offs get sharper. Prompt caching, which we covered in Prompt Caching in Production, can reclaim a large share of the repeated prefix cost without fine-tuning. RAG needs a real retrieval architecture with reranking and monitoring. Fine-tuning a smaller model to replace a larger one on a narrow task can cut cost by an order of magnitude, and at this volume that justifies a dedicated ML engineer or a consulting engagement.
Build it yourself or use a managed service
Each approach has a build vs buy question, and the answer differs.
For prompt engineering, there is nothing to buy. Keep prompts in version control, test them like code, and log inputs and outputs so you can see regressions. Prompt management SaaS tools exist, but a Git repository and a small evaluation script cover most teams.
For RAG, the managed options (hosted vector databases, retrieval APIs bundled with model providers) are fast to start and fine for prototypes. The case for building on your own stack gets stronger when your data is sensitive, when you already run Postgres and can add pgvector, or when you need retrieval logic tied to your existing permissions model. Multi-tenant SaaS in particular tends to end up self hosted, because tenant isolation in a third party vector store is either awkward or expensive.
For fine-tuning, managed fine-tuning from the major model providers is the default choice for most SaaS teams. You upload examples, they train, you get a model endpoint. Running your own training on open weights models makes sense when you need to own the model, when data cannot leave your infrastructure, or when the per-token pricing of the managed model is too high at your volume. That is a real engineering commitment, and it is worth an honest assessment of whether your team has the capacity before starting.
FAQ
Can RAG and fine-tuning be used together?
Yes, and for mature products this is the usual end state. RAG supplies the facts, the fine-tuned model supplies consistent tone and structure. Build the RAG layer first, since it fixes the more common failure.
How many examples do I need to fine-tune?
For style and format adaptation, a few hundred consistent examples often produce a measurable improvement. For more complex reasoning patterns, expect to need thousands. Quality and consistency matter more than raw count.
Does fine-tuning make the model remember my documentation?
Not reliably. It will pick up vocabulary and phrasing, but it will not become a trustworthy source of facts, and anything that changes after training is invisible to it. Use retrieval for facts.
When is prompt engineering not enough?
When the model lacks the information it needs (use RAG), or when the prompt required to get the right behavior is so long that it dominates cost or latency at your request volume (consider fine-tuning).
Where to start
If your LLM feature is producing disappointing output, spend a day on the prompt before spending a month on anything else. If the failures are factual, add retrieval and measure it separately. If the failures are stylistic and you are at meaningful volume, fine-tune. Working through that order avoids the two most expensive mistakes we see: fine-tuning to fix a prompt problem, and fine-tuning to fix a knowledge problem.
Wolf-Tech helps SaaS teams design and review LLM integrations, including the architecture decisions around retrieval and model customization. If you want a second opinion on where your system should go next, write to hello@wolf-tech.io or read more about our custom software development and code quality consulting work at wolf-tech.io.