The model keeps getting our work wrong — what do we actually fix?
Diagnose the failure before choosing the remedy: a knowledge gap wants retrieval, a behaviour problem wants a better prompt and schema, and only a specific, well-evidenced shortcoming justifies fine-tuning. Most firm complaints are the first two.
Three failures that get one diagnosis
When a fee-earner says the tool keeps getting our work wrong, that sentence covers at least three different problems, and the remedy is different for each. The first is a knowledge gap. The model does not know your precedent, your client, the terms of this particular agreement or the fact that the firm's house position on exclusion clauses changed last year. The remedy is retrieval, or an instruction that supplies the facts. The second is a behaviour problem. The model has the material and still does the wrong thing: it paraphrases when you asked for a quotation, it abandons your schema halfway through a long schedule, it refuses to say the documents are silent, it writes in American legal register for an English-law letter. The remedy is a better instruction, a stricter output structure, and worked examples of the behaviour you want. The third is a capability ceiling. The task genuinely needs reasoning the model cannot do — reconciling four interlocking definitions across a badly scanned agreement, or holding a long chain of dates together. The remedy is a different model, and no amount of tuning will substitute for it. In our experience the third is invoked far more often than it is the actual cause, usually by somebody who would rather change the model than the prompt.
What retrieval really does
Retrieval, sometimes called retrieval-augmented generation, works at the moment of asking. When the question arrives, a search layer fetches passages from your own corpus — precedents, know-how, clause banks, the documents in this matter — and those passages are placed in the prompt alongside the question. The model's weights are untouched. Three consequences follow, and they are the reasons retrieval is usually the right first answer. It is current: a new precedent is available as soon as it is indexed, with no training run and no technical project. It can inherit your permissions, so a fee-earner retrieving from the know-how system sees what their existing access allows and no more, which is the confidentiality answer your DPIA needs. And it can cite: because the prompt contained specific passages, the model can point at them, and a reviewer can check the quotation against the source in seconds. Retrieval quality becomes the ceiling on answer quality, so a badly chunked index produces confidently wrong answers that no prompt can fix. It adds latency and infrastructure, and it needs maintenance, because an index of superseded precedents is a liability with a search box. Retrieval cannot teach a model to hold a schema or to write in your house register; those are behaviour, and behaviour is what instructions and examples change.
What fine-tuning really does
Fine-tuning is further training on examples. You supply pairs — a prompt and the response you wanted — and the training process adjusts the model's weights so that it is more likely to produce responses of that kind. Done well, it changes form: tone, structure, the shape of an output, the way a model handles a specialised format. What it does not do reliably is install facts. A model trained on your precedent bank will not remember clause 4.2 of a particular agreement in a way you can rely on or cite. Facts learned this way are approximate, cannot be traced to a source and will not update when the precedent does. If you want the model to know something, retrieve it. A second trap: fine-tuning to stop hallucination, using examples that contain only right answers, tends to make it more confident in the same wrong shape rather than more careful, because you have taught it that the expected output is always a fluent answer. If abstention is the behaviour you want, the training data must contain refusals — hard negatives where the correct response is that the material does not answer the question. And fine-tuning is not a one-off. It is tied to a base model version. When the base model moves, for whatever reason, you retrain, re-evaluate and re-document, and the model you trained is not one you own outright — check what the licence says about derivatives before you invest in the exercise.
Where prompting sits, and why it is first
Prompting is unfashionable and it is the cheapest, fastest lever available. A clear instruction, an explicit refusal rule, a fixed output schema and two or three worked examples of your house style will fix a surprising share of what firms describe as the model being wrong. The reason is mechanical rather than magical. Most failures described as the model not understanding are the model doing precisely what it was asked, in a way nobody wrote down. Ask for a summary and you get a summary, not a table with citations. Say nothing about jurisdiction and the model applies whatever register its training data supplies. Specify nothing about length and it produces what its tuning called a good length. Writing the instruction properly converts an unstated expectation into a checkable requirement, and a checkable requirement is what makes supervision possible. The limitation is scale. A partner who writes an excellent prompt has built a private asset that walks out of the building at retirement and is not applied by the next person doing the task. So the target is not good prompting by individuals; it is a small library of firm templates and named configurations that anyone can use, each tied to a task, tested once, and reviewed when the model version changes.
The order that usually works
Work in sequence and make each step earn its place. Start with the prompt: state the task, the jurisdiction, the output structure, the refusal rule and what to do when the material is insufficient. Run your evaluation tasks and see what is left. Then add retrieval, because if the failures that remain are about missing knowledge, retrieval addresses them directly, with citations and permission inheritance as by-products. Re-run the same tasks and record the change. Fine-tune only if a behaviour survives both and the case is strong: high volume, a house register that instructions cannot capture, a task where prompt length is itself a measurable cost, or a need to run a smaller model for privacy reasons. And write down what the fine-tune was for, because the evidence for the decision is the failure it was bought to fix. Whatever you choose, the fine-tuned model needs the same treatment as any other: its own evaluation record, its own version, its own register entry. A firm that evaluates a base model and deploys a tuned derivative has tested something it is not using.
What to watch
- Reaching for fine-tuning to fix a knowledge gap that a properly indexed precedent bank would close
- Fine-tuning to reduce invention with training examples that contain no refusals, teaching confidence instead of caution
- Deploying a fine-tuned derivative that was never itself evaluated, on the strength of tests run on the base model
- A retrieval index built once at pilot and never refreshed when precedents are superseded
- A retrieval layer that sits outside the document management system's permissions, so a fee-earner can retrieve another matter's clause
- Commissioning training work before anyone has written down what the prompt should say
For each recurring failure, write down which of the three causes it is before spending anything. If the model lacks your facts, fix retrieval: index the relevant precedent and know-how, test that the right passages come back for a sample of real questions, and check the index inherits your document permissions. If the behaviour is wrong, rewrite the instruction with an explicit output schema and a refusal rule, and keep it as a firm template rather than in one person's notes. Only if a behaviour survives both, and you can point to the volume and cost that justify it, consider fine-tuning — and budget for the evaluation and retraining that follows.