RAG Versus Fine-Tuning

Both halves of educational objective 1.2 come together here. A base language model knows what was in its training data and nothing else. It does not know your project's glossary, your client's regulatory obligations, or the decisions your team took in last week's workshop. There are two established ways to change that, and the syllabus asks you to be able to compare them.

Both operate at the context assembly stage of the pipeline you saw in the previous lesson — or, in fine-tuning's case, upstream of it.

Fine-tuning

Fine-tuning incorporates the additional knowledge directly into the model, by continuing its training on additional, relevant data. Once done, that knowledge is available for all future interactions without anything extra being supplied at prompt time.

Its drawbacks follow from that same property. The model must be re-trained every time you add new information, which is resource-demanding. And the source of any given piece of knowledge becomes hard to pin down: after fine-tuning, it is part of the model. You cannot ask which document a statement came from, because there is no longer a document — there are adjusted weights.

Fine-tuning also requires effort, domain expertise and quality-controlled data to be effective. Feeding a model a pile of inconsistent internal documents does not produce a domain expert; it produces a model that has learned your inconsistencies.

Retrieval-Augmented Generation

RAG takes the other route. It keeps a separate knowledge store that a search engine can query, triggered by the model. Relevant documents are found — typically using embeddings, so that semantically related passages are retrieved even when the wording differs — and passed into the model along with the prompt.

Newly added information is available instantly, with no retraining. And because the content came from an identifiable document, the source can be traced back to the knowledge store. In Requirements Engineering, that traceability is not a nice-to-have. It is what lets you show a stakeholder or an auditor where a statement came from.

RAG's costs are equally concrete. It introduces extra search latency: something must be retrieved before anything can be generated. And it depends entirely on the quality of the retrieval index — retrieved information is only valuable if it is good information. A RAG system pointed at an out-of-date wiki will confidently ground its answers in out-of-date facts, and it will cite them, which makes the wrong answer more convincing rather than less.

Choosing between them

The syllabus's summary is worth learning as written, because it is exactly what an exam question tests. Fine-tuning excels when you can afford the recurring training effort and need low-latency answers without a separate knowledge store, but it risks becoming outdated and offers no built-in source citations. RAG keeps content fresh and traceable, at the cost of search latency and a dependency on index quality.

Translated into RE decisions:

Choose fine-tuning when the thing you are teaching the model is a style or a form rather than a fact. Getting a model to reliably produce requirements in your organisation's phrase template, in your house tone, at your usual level of detail, is a good fit: the target does not change weekly, and there is no source document a reader would want cited.

Choose RAG when the thing you are supplying is facts that change and facts that must be attributable. Project glossaries, current regulatory text, the live requirements baseline, decisions from recent workshops. If a stakeholder could reasonably ask "where does that come from?", the answer needs to be a document, not a set of weights.