Lesson 6 — Recap and frequent questions
The five lessons in five sentences
- Scale in parameters, data and compute produced capabilities nobody trained for — instruction following, in-context learning, reasoning, code — while reliable arithmetic, knowing what it does not know, currency and long-horizon consistency barely moved, and those gaps define what you must build around the model.
- Pretraining supplies nearly all capability, instruction tuning makes the model answer rather than continue and incidentally teaches its confident tone, and preference alignment shapes manner and refusals without removing any underlying capability.
- Retrieval puts a search step in front of the model so it reads rather than recalls, and when it disappoints the cause is almost always retrieval quality rather than generation.
- Tool use removes structural weaknesses by delegating to components that are exactly right, and agent reliability compounds badly enough that narrow agents with few steps, verification and human approval are the only designs that survive production.
- Choose a model from constraints rather than benchmarks, expect token costs to grow in non-obvious ways, evaluate on your own cases on every change, and treat prompt injection as an architectural problem because it cannot be filtered away.
The decision that matters most
Most disappointing LLM projects took the wrong branch here, usually by fine-tuning when they needed retrieval or reaching for a bigger model when they needed a tool.
An architecture guide
| Your situation | Build this |
|---|---|
| Questions about documents that fit in the context | Paste them in. No pipeline |
| Questions across many or changing documents | Retrieval with hybrid search and reranking |
| Needs a consistent house style or output format | Prompt with examples first, fine-tune if that fails |
| Needs current facts | Web search as a tool |
| Needs calculation | Code execution or a calculator tool |
| Needs multi-step work | A narrow agent: few tools, few steps, verification |
| Extraction into a schema | Small model, low temperature, validate the output |
| High volume, simple task | Smallest model that passes your evaluation, plus caching |
| Confidential data | Open model, self-hosted |
| Anything irreversible | Human approval gate |
Twelve frequent questions
1. Which model should I use?
Prove the task is solvable with the strongest model you can access, then work downwards until quality drops below your threshold. Deciding from benchmarks wastes time, because the differences that matter are on your task and your data.
2. RAG or fine-tuning?
Retrieval for facts, fine-tuning for form. If you want the model to know your documentation, retrieve. If you want it to write in your house voice or emit your exact format, fine-tune. Fine-tuning on documents to make the model answer questions about them is the classic expensive mistake.
3. Why does my RAG system give wrong answers?
Log the retrieved chunks for twenty bad answers and read them. In most cases the right passage was never retrieved, which points at chunking, at vector search missing exact terms, or at a mismatch between how users ask and how documents are written. Fix retrieval before touching prompts.
4. How do I stop it inventing things?
Ground it in supplied passages, require citations and verify they exist, prefer extraction over free generation, and make declining an acceptable outcome. You cannot eliminate fabrication because it is the same process that produces correct output.
5. Are agents ready for production?
Narrow ones, yes. A few tools, three to five steps, programmatic verification, hard limits and a human gate before anything irreversible works today. Open-ended autonomous agents are demo material, because reliability compounds down rather than up.
6. How much will this cost?
Estimate tokens per request, multiply by expected volume, then double it for the things you have not thought of. The costs that surprise people are conversation history being resent every turn, retrieved passages billed on every query, and reasoning models charging for internal working.
7. Can I trust the model's confidence?
No. Confidence correlates poorly with correctness, and the confident tone was substantially taught during instruction tuning by examples that were themselves confident. Treat stated certainty as a stylistic property rather than information.
8. How do I evaluate whether a change improved things?
Fifty to two hundred of your own examples with known good outputs, automated checks where possible, and a strong model as a judge against a rubric for the rest. Run it on every prompt edit and model upgrade, because prompts regress silently.
9. Is prompt injection actually a serious risk for me?
It depends entirely on what your model can do. A model that only writes text for a human to read is low risk. A model that reads untrusted content and can send email, query a database or call an API is a genuine attack surface, and the defence is reducing its privileges rather than filtering its inputs.
10. Should I use a framework or call the API directly?
Direct API calls for anything simple — the abstraction rarely pays for itself and it obscures what is being sent. Frameworks earn their place for complex retrieval pipelines and agent orchestration, where you would otherwise rebuild the same plumbing. Start direct and adopt a framework when you feel the absence.
11. What about open models?
Strong enough for a large share of real tasks, behind the frontier on the hardest reasoning, and decisive when data cannot leave your infrastructure or volume makes hosted pricing painful. Running one locally also removes any dependency on a vendor's roadmap and deprecation schedule.
12. Where should I start if I want to build?
Pick one task you do repeatedly where you can check the answer. Build the smallest thing that does it, including the evaluation set and the verification step, and take it to production for real users. That teaches you more about cost, latency, prompt brittleness and error handling than months of experimenting in a chat window. The premium catalogue covers RAG, fine-tuning, LangChain and agents hands-on.
Vocabulary you can now use precisely
| Term | Meaning in one line |
|---|---|
| Parameter | One trainable number inside the network |
| Base model | Pretrained only; continues text rather than answering |
| Instruction tuning | Training on request-and-response pairs so the model answers |
| RLHF / DPO | Shaping behaviour from human preferences between responses |
| System prompt | Prioritised text at the front of the context; not a security boundary |
| Context window | The fixed token budget holding everything the model sees |
| In-context learning | Performing a task from examples in the prompt, with no training |
| RAG | Retrieving relevant passages and answering from them |
| Chunking | Splitting documents into retrievable passages |
| Hybrid search | Combining vector similarity with keyword search |
| Reranking | Re-scoring retrieved candidates with a more accurate model |
| Function calling | The model emitting a structured tool request your code executes |
| Agent | A model in a loop deciding actions, observing results, deciding again |
| Prompt injection | Content the model reads acting as instructions to it |
| LLM as a judge | Using a strong model to score outputs against a rubric |
And now?
You can tell what an LLM is from what it is not, diagnose which layer a failure belongs to, and choose between prompting, retrieval, tools and fine-tuning on evidence rather than fashion. That is most of what separates working systems from expensive experiments.
Validate it: take the 5-question quiz →
Continue free: MLOps covers running and monitoring this in production.
Go deeper: the premium catalogue covers RAG, fine-tuning, LangChain, agents and local deployment hands-on, with a verifiable certificate after a 40-question examination.