OpenAI just opened fine-tuning on GPT-3.5, and my inbox filled up within a day. Most of the questions carry the same hopeful assumption: if I fine-tune the model on our product catalog, our documents, our internal wiki, it will finally "know" our business. That assumption is where most gpt-3.5 fine-tuning business projects quietly fail.
Here is the honest version. Fine-tuning shapes how the model behaves. It does not reliably teach the model new facts. Those are two different problems, and confusing them costs money and weeks of nobody's time.
I want to give you the decision rule I use before I let a client spend a rupiah on training data. It is not complicated, but it saves you from the most expensive mistake in this space.
What fine-tuning actually changes
Think of the base model as a very well-read employee who has never worked at your company. Fine-tuning is like giving that employee a stack of examples showing how you want things done: this tone, this format, this length, these categories. After enough examples, they internalize the pattern and stop needing you to explain the rules every time.
That is what gpt-3.5 fine-tuning is good at:
- Consistent tone and voice across thousands of replies, so every customer message sounds like your brand and not like a generic assistant.
- Reliable output format, like always returning clean JSON with the same fields, or always structuring a summary the same way.
- Classification into your own categories, for example routing incoming messages into your specific ten intents instead of generic ones.
- Shorter prompts. Once behavior is baked in, you stop paying for long instructions on every call, which lowers cost per request.
Notice what all of these have in common. They are about behavior and style, not about knowledge. You are teaching the model how to act, not what is true about your inventory today.
What fine-tuning does not do
Here is the part people resist hearing. If you fine-tune GPT-3.5 on your 4,000-SKU product catalog, it will not become a reliable place to ask "do we have this item in blue, and what is the price?"
Two reasons:
- Fine-tuning blends facts into weights, it does not store them. The model may produce something that sounds like your catalog and is wrong. That is called confabulation, and in a sales or support context it is worse than saying "I don't know."
- Your facts change. Prices move, stock runs out, policies get updated. You cannot retrain the model every time a price changes. That is a database's job, not a language model's.
I have watched a distributor spend three weeks preparing catalog data for fine-tuning, only to end up with a model that confidently quoted last quarter's prices. The fix was not more training. The fix was a different architecture entirely.
Knowledge lives in retrieval, not in weights
When you need the model to answer using your specific, current facts, the right pattern is retrieval: keep your facts in a database or document store, fetch the relevant pieces at question time, and hand them to the model as context so it answers from what you gave it rather than from memory.
This is why the two approaches are not competitors. They solve different halves of the same product:
| Need | Use | Why |
|---|---|---|
| Consistent tone, format, category | Fine-tuning | Behavior is stable and worth baking in |
| Current prices, stock, policy, docs | Retrieval | Facts change and must be exact |
| Both (common) | Retrieval + light fine-tuning | Facts from retrieval, style from tuning |
Most real business systems I build end up in that third row. Retrieval supplies the truth. A light touch of fine-tuning makes the answer sound right and come back in the format your app expects. If you want the deeper trade-off analysis for smaller teams, I wrote it up in Fine-Tuning vs Prompting: What SMEs Actually Need.
The decision rule I actually use
Before recommending fine-tuning, I ask one question about the thing you want the model to do:
Does the correct answer depend on a fact that can change, or on a way of behaving that stays constant?
- If it depends on a changing fact (price, stock, account balance, this week's promo), you need retrieval. Fine-tuning will lie to you eventually.
- If it depends on a constant behavior (always polite, always this format, always these categories), fine-tuning earns its cost.
- If it depends on both, build retrieval first, then add fine-tuning only if prompting alone cannot hold the format or tone.
That last point matters for budget. For many teams, a well-written prompt gets you 80 percent of the behavior benefit at zero training cost. Fine-tune only when you have proven that prompting cannot hold the line at your volume, and you have a real dataset of good examples to train on. Fifty hand-picked examples usually beats five thousand messy ones.
A realistic first project
If you want to try gpt-3.5 fine-tuning without burning goodwill, pick something small and behavioral:
- Take one repetitive writing task your team does, like drafting order-confirmation replies.
- Collect 60 to 100 of the best real examples, cleaned up.
- Fine-tune on those, and compare against a strong prompt with no fine-tuning.
- Measure on the boring metrics: format compliance, tone consistency, and how often a human had to fix the output.
If the fine-tuned version measurably reduces human editing, you have a keeper. If it only ties the prompt, keep the prompt and keep your money.
Practical takeaway
Fine-tuning GPT-3.5 is a real capability, and it is genuinely useful for style, format, and classification at scale. It is not a shortcut to a model that knows your business. Knowledge belongs in retrieval, where it can stay current and exact; behavior belongs in fine-tuning, where consistency is the whole point. Sort your problem into the right bucket first, and the rest of the project gets much cheaper.
If you are weighing a custom AI build and want a straight answer on whether tuning, retrieval, or a plain prompt fits your case, that is exactly the kind of scoping I help partners with. You can start that conversation on the partner page.