The question raised in part 1
This series began with a single question. When you run into a problem, what tells you whether it can be solved with a prompt, whether it needs RAG, or whether you have to go all the way to fine-tuning.
The question is hard because the three sit at different layers. A prompt changes the input, RAG fetches the material that goes into the input, and fine-tuning changes the model itself.
The previous five parts covered that structure. Now the criteria can be built from where each one acts.
The default is the prompt
To start with the conclusion, most problems you meet in practice are solved with prompts and instructions. That is the default, and the other two are things you add when specific conditions appear.
Part 5 showed why. A prompt changes the shape of the candidate list. Putting 'a Japanese restaurant just opened near my place' in front of 'for lunch today we are having' rewrote the top of the candidate list wholesale. The output changes a great deal without touching anything inside the model.
A prompt can also be fixed immediately. No deployment, no retraining; if it is wrong you change the sentence and run it again. That turnaround speed is not comparable to the other two.
To add, the agent and skill design people talk about today belongs here in principle. Typing a sentence and designing a flow with tools differ in difficulty, but they sit at the same layer in that both define behavior through the input without changing the model internals.
The conditions for adding RAG
RAG stands for Retrieval Augmented Generation. It is a way of fetching the material you need, putting it into the prompt, and having the answer produced in that state.
How it works connects to the embeddings from part 4. Documents are cut into pieces, and each piece is converted into a bundle of numbers that carries its meaning and stored. When a question comes in, the question is converted the same way, and the pieces closest in meaning among the stored ones are found. Those pieces are inserted into the prompt.
The important point here is that RAG ultimately puts material into the prompt. The model does not change. It is closer to an automation of the 'context narrows the candidates' idea from part 5.
There are two conditions for adding it. First, the material that grounds the answer is larger than the context limit. You cannot insert the entire internal rulebook every time. Second, the material changes often. Retraining the model every time a document is updated does not add up in cost terms.
To add, even when you can insert everything, inserting everything is not always better. As part 4 showed, attention measures the relationship between every pair of tokens, so the longer the input, the larger the computation and the blurrier the focus. Selecting only what is needed is often the better option.
The conditions for going down to fine-tuning
Fine-tuning, as part 3 showed, is adjusting the parameters of the model. It is the only one of the three that changes the model itself.
That makes it the heaviest, and its conditions are correspondingly narrow. In short, it is when three things overlap. Repetition of the same behavior in a fixed format, one specialized task, and scale.
The third is the key. And the reason is visible in precise terms only to someone who has read this series.
Suppose you have a job that should emit results only in a fixed format. To do it with a prompt, the instructions describing the format get attached to the input every time. That means a few hundred tokens tag along with every call. If there are a few calls a day, this is no problem at all. But at hundreds of thousands or millions of calls a month, those instruction tokens alone add up to a large amount of money.
Fine-tuning lets you remove those instructions entirely, because the model has been changed to answer that way in the first place. The input length drops to a fraction, and that difference is multiplied by the number of calls. In other words, the practical value of fine-tuning often lies in the cost structure rather than in performance.
Flip that around and fine-tuning is a loss at small scale. The training cost and the maintenance burden exceed the savings.
Why the place for fine-tuning has narrowed
Fine-tuning used to be chosen more often. The baseline performance of base models was not what it is now, and the methodology for handling prompts was less well organized.
As those two improved, a large share of the work that only fine-tuning could do moved over to prompting. So the place for fine-tuning is now more specialized than it used to be.
This misunderstanding shows up often in practice. The request to 'train it on our data' usually is one. As part 2 showed, training is changing the values inside the model, which is a different matter from wanting internal documents reflected in the answers. That request is almost always the domain of RAG.
That said, knowing about it and using it are different things. Practice environments have become cheap enough that trying it yourself is not hard, so it is enough to hold it as a basis for judgment.
In short, it is an order
It is more accurate to see it as moving down in order rather than choosing among the three.
You try the prompt first. Most cases end there. If the material that grounds the answer is large and changes often, you add RAG. The most common combination in practice is prompt plus RAG. If even after that the cost becomes a problem because of large-volume repetition in the same format, that is when you consider fine-tuning.
Walking this order backwards is a common failure. Starting from fine-tuning means spending time and money only to confirm that a prompt would have done it.
| Approach | What it changes | When to use it | Weakness |
|---|---|---|---|
| Prompt and instructions | The input | Most cases. The default | Attached to the input every time, becoming length and cost |
| RAG | The material put into the input | When the grounding material is large or changes often | If the retrieved piece is wrong, the answer is wrong too |
| Fine-tuning | The model parameters | When the same format repeats at volume and cost is the problem | Training and maintenance cost. A loss at small scale |
What do you choose a model on
Once the approach is settled you choose a model, and this is where the order often goes wrong. People open the performance comparison table first.
What comes first in practice is the constraints. Does it have to run only on the internal network, or can it go up to the cloud. That decides whether you use an API or run a model yourself. And often the governance and compliance of the client or the company already impose constraints. Places where only a specific provider can be used are common.
Optimizing cost among the options that remain within those constraints is the actual order. And here part 1 comes back into play. Cost is not determined by the unit price alone. Depending on how finely the tokenizer splits Korean, the same text yields a different token count. You have to look at the unit price and the token count together.
Finally, a model is not something you fix in place. When something better comes out you swap it in, and you may split work across several models by task type. So it is better to design things so the model can be swapped.
Closing the six parts
We started from tokens, passed through training and inference, and arrived at practical judgment. In summary, text becomes tokens, parameters are refined by next-token prediction, post-training teaches the format, inference measures relationships with attention, and at the end one token is drawn by probability.
Holding this picture changes something. When you hear a claim about LLMs you can tell which stage it belongs to, and whether it holds up gets filtered. That 'let us train it' and 'let us have it consult the documents' are different statements becomes immediately visible.
What is actually hard in AX is not the technology but defining the problem precisely. Still, defining the problem requires knowing what is possible and what is expensive, and these six parts lay the floor for that judgment.