AI / FIELD NOTES

RAG or fine-tuning? Start with the problem.

Use RAG when an answer needs relevant information from your documents. Consider fine-tuning when a model needs to perform a specific task or follow a particular behavior more consistently. Some systems need both.

Need current knowledge?

Retrieve approved sources with RAG.

Need consistent behavior?

Evaluate prompting, then consider fine-tuning.

Need both?

Combine approaches and evaluate the full system.

Two different ways to adapt AI

Retrieval-augmented generation (RAG) finds relevant material and includes it in the context supplied to a model. Fine-tuning changes a pretrained model through additional training on examples. One supplies knowledge at the time of a request; the other adjusts model behavior through training.

Reference: Google Cloud: fine-tuning and RAG ↗

Start with the answer you need

Imagine an internal assistant answering questions about a product manual. Your first concern might be whether it can find the right version of the right document. Our starting point would be a retrieval prototype, a set of representative questions and a review of document permissions.

Now imagine a repetitive classification task with a defined set of labels. We would first test a prompted baseline, inspect its errors and ask whether you have enough appropriate examples to evaluate a tailored model. Fine-tuning is a candidate to test, not a prerequisite for calling the product “custom AI.”

Ask these questions before choosing

A short decision brief can keep the project focused:

  • What exact task should the system complete, and what would a good answer look like?
  • Does the answer depend on information that changes, or on a repeatable style or classification rule?
  • Which documents or examples are you permitted to use, and who may see them?
  • How will you test wrong answers, missing information and requests outside the intended scope?
  • Who owns updates, evaluations and operating costs after launch?

Evaluate the whole workflow

For a retrieval pilot, we would separate two questions: did the system find suitable evidence, and did its answer use that evidence appropriately? That makes it easier to distinguish a source problem from an answer-generation problem.

For a fine-tuning pilot, we would agree on test cases that are kept separate from the training examples. Compare the candidate with the original baseline on quality, latency and cost. Define an acceptance threshold before deciding to adopt it.

A practical first engagement

Bring a small collection of representative documents or examples, the task you want to support, and the people who can judge the output. We can use discovery to map the information flow, define a bounded prototype and identify the evidence needed for the next decision.

The best initial deliverable may be a clear evaluation and a decision to simplify. The goal is a useful system your team can operate.