RAG vs Fine-Tuning vs Prompting: Which Does Your LLM App Need?

Retrieval gives a model knowledge, fine-tuning shapes its behavior, and prompting is where you should almost always start. Here is how to choose.

Close-up of a printed circuit board with processors

Start with prompting, add retrieval-augmented generation (RAG) when the model needs private or frequently changing knowledge, and consider fine-tuning only when you need consistent behavior, format, or efficiency that prompting and RAG cannot deliver. RAG gives a model the right facts at answer time; fine-tuning changes how the model responds. They solve different problems, and many production LLM apps use both on top of a well-designed prompt.

What each approach actually changes

  • Prompting changes the instructions and examples the model sees on each request. It is fast to iterate, needs no training, and works with any model.
  • RAG changes the context: before the model answers, your system retrieves relevant documents or records and includes them in the prompt.
  • Fine-tuning changes the model weights by training on example inputs and outputs, so the desired behavior is built in rather than described.

A helpful way to think about it: prompting is the job description, RAG is the reference library on the desk, and fine-tuning is training and practice. You would not train someone for weeks to memorize a policy manual that changes monthly; you would give them the manual.

When is prompting enough?

More often than teams expect. Modern models follow detailed instructions well, and a carefully structured prompt with a clear role, explicit rules, output format, and a few representative examples handles a wide range of tasks. Prompting is enough when the knowledge required is general or fits comfortably in the prompt, and when the quality you measure on a representative evaluation set is acceptable.

Signs you have outgrown prompting alone: the model lacks information it cannot know, such as your product catalog or internal policies; prompts are ballooning with pasted reference material; or behavior stays inconsistent no matter how you rephrase instructions.

When should you use RAG?

Use RAG when answers depend on information that is private, large, or changes over time: documentation, knowledge bases, contracts, tickets, product data, or user-specific records. RAG also makes it possible to cite sources, which matters for trust and for debugging.

How a RAG pipeline works

  1. Ingest: collect source documents and split them into chunks that preserve meaning, such as sections with their headings.
  2. Index: create embeddings for each chunk and store them in a vector database or a vector extension such as pgvector for PostgreSQL, often alongside a keyword index.
  3. Retrieve: for each query, find candidate chunks with semantic search, keyword search, or both (hybrid search), filtered by permissions and metadata.
  4. Rerank: optionally reorder candidates with a reranking model so the most relevant few reach the prompt.
  5. Generate: pass the selected chunks to the model with instructions to answer from them and cite them.

Where RAG systems go wrong

Most RAG quality problems are retrieval problems. If the right passage never reaches the model, no prompt will save the answer. Common causes include chunks that split tables or lose their headings, pure semantic search missing exact terms like product codes, stale indexes, and missing metadata filters. Measure retrieval separately from generation: for a set of test questions, check whether the correct source appears in the top results before you judge the final answer.

When does fine-tuning make sense?

Fine-tuning is the right tool when you need the model to behave in a specific, consistent way that is hard to describe in instructions, or when you want a smaller, cheaper, faster model to perform a narrow task as well as a larger one. Good candidates include:

  • Strict output formats or domain-specific structures the base model often gets slightly wrong.
  • A distinctive tone or style that must be consistent across many outputs.
  • High-volume classification, extraction, or routing tasks where latency and cost per request matter.
  • Reducing prompt length by baking in instructions that would otherwise be repeated on every call.

Fine-tuning is a poor way to add factual knowledge. Facts learned in training are hard to update, impossible to cite, and can be blended or misremembered. If the information changes, belongs to specific users, or needs a source, retrieve it.

What fine-tuning requires

You need a dataset of high-quality input and output pairs that reflect exactly the behavior you want, a held-out evaluation set, and a plan to retrain when requirements or base models change. Parameter-efficient methods such as LoRA reduce compute needs for open-weight models, and several hosted providers offer managed fine-tuning. Either way, the dataset is the real investment, and inconsistent examples produce an inconsistent model.

Comparing cost, speed, and maintenance

  • Prompting: lowest upfront effort; cost grows with prompt length and request volume.
  • RAG: moderate engineering for ingestion, indexing, and retrieval; ongoing work to keep sources fresh; adds some latency per request.
  • Fine-tuning: upfront effort to build data and train; can reduce per-request cost and latency; requires retraining as needs evolve.

Combining the approaches

In practice these are layers, not rivals. A typical mature setup uses a clear system prompt, RAG for grounding in current knowledge, and, where volume justifies it, a fine-tuned model that reliably follows the output format and tone. Each layer should earn its place through measured improvement on your evaluation set.

A simple decision path

  1. Build an evaluation set of real questions with expected answers or criteria.
  2. Get the best result you can with prompting alone and measure it.
  3. If failures come from missing or outdated knowledge, add retrieval and measure retrieval quality separately.
  4. If failures come from inconsistent behavior or format, or cost and latency are too high at scale, consider fine-tuning.
  5. Re-run the evaluation after every change and keep what helps.

In discovery, we usually spend more time on the evaluation set and the retrieval layer than on model selection. That is where most of the quality comes from, and it keeps your options open as models improve.

Planning something similar? We are happy to talk it through.

Prepare your project brief
RELATED SERVICES

Where we can help.

All services
THE NEXT CHAPTER STARTS HERE

Big idea?
Let’s make it real.