There is a standard conversation about AI architecture that goes straight to whether you should use retrieval or fine-tune a model. It is the wrong first question, and answering it early is how projects get expensive.
The right first question is what kind of gap you are closing. There are only three, and each one has an obvious answer.
The three gaps
If the model does not know facts about your business — your customers, your prices, your documents, your policies — that is a knowledge gap. Retrieval fixes it. You give the model the relevant material at the moment it answers.
If the model knows enough but cannot produce output in the form you need, consistently, in your terminology, that is a behaviour gap. Fine-tuning is the tool, though it is rarely the first thing to reach for.
And if the task is deterministic, the gap is neither. It is a rule you have not written yet, and the correct answer is code.
Most business problems are the first kind. A large share of the rest are the third. Genuine behaviour gaps are the smallest category, and they are the ones fine-tuning gets bought for even when the problem is elsewhere.
Why retrieval wins most of the time
Retrieval keeps your knowledge outside the model. That has three consequences that matter more than accuracy in a benchmark.
When a price changes, you update a record and the next answer is right. With a fine-tuned model, your knowledge is baked in, and correcting it means retraining. Businesses change more often than anyone plans for.
It also gives you a citation. The answer arrives attached to the document it came from, which makes it checkable in seconds. A fine-tuned model produces fluent output with no source, and fluent output with no source is the hardest kind of wrong to catch.
And access control still works. If a user should not see a document, it is not retrieved. Once information is inside a fine-tuned model's weights, you cannot restrict who it reaches.
When fine-tuning is genuinely right
Not for teaching facts. For teaching form.
Highly consistent structured output where the format matters more than the reasoning. Classification into your own categories, where you have thousands of correctly labelled examples. A specialised vocabulary the base model keeps getting subtly wrong. Or cost and latency, where a small tuned model does one narrow job cheaply at high volume.
Notice the pattern: all of these need a lot of good examples. If you do not have several thousand labelled cases, fine-tuning is usually not on the table yet, whatever the ambition is.
The example we hit most often
Invoice processing is the case where all three answers show up in one workflow, which is why it is worth walking through.
Extracting fields from a supplier's document is a knowledge problem with an unusual property: the answer is checkable. The line items should sum to the total. So retrieval plus a validation rule handles it, and anything that fails the check goes to a person rather than through.
Matching that invoice to a purchase order, where the reference is exact, is not an AI problem at all. It is a lookup, and it should be code — instant, free, correct every time.
Deciding whether an unmatched invoice is a duplicate, a partial delivery or an error is judgement, and it is where the actual value sits. That is where the model earns its place, and where the output is a recommendation a person approves.
One workflow, three answers. If we had decided the architecture up front, we would have used one approach for all three and been wrong twice.
How to hold a partner to this
Ask which parts of the proposal are AI and why the rest are not. A good answer includes something that is deliberately just code, and something the model prepares for a person to commit.
If everything in the design is AI, that is a technology looking for places to go, and you will pay for the difference.
