Improving Model Output
Improving output means matching a fix to a failure, not finding a perfect model
A foundation model is trained once on a fixed snapshot of data, so a handful of limits ship with it rather than being defects you can patch away: a knowledge cutoff, inherited bias, fluent but false answers (hallucinations), shaky results on rare edge cases, and a blanket dependence on whatever that training snapshot happened to cover. Those five are the set the Overcoming Model Limitations subtopic works through, grouped by whether a limit comes from what the model learned or from how it generates text. Improving its output is therefore not a hunt for one perfect model but the discipline of reading the specific failure in front of you and reaching for the technique built to fix it. The one rule that ties this whole domain together is simple: match the fix to the failure, then start with the lightest lever that could work. The trap the exam sets is answering every quality problem with the biggest hammer, further training the model on your own labeled examples (fine-tuning) or writing an ever-cleverer prompt, when a lighter and better-matched technique was the right call.
The domain unfolds in three moves, from naming the limit to attaching a source of truth
Overcoming Model Limitations comes first: it names those built-in limits and lays out the full mitigation map, from grounding and retrieval-augmented generation (RAG) through prompt engineering and fine-tuning to keeping a human in the loop (HITL), and it adds the continuous monitoring a launched model needs as live traffic drifts away from its training data. Prompt Engineering is the lightest lever: it reshapes the words you send the model, with worked examples, an assigned role, or step-by-step reasoning, to fix the format, tone, or reasoning of an answer without touching the model or the facts it holds, and Google frames it as an iterative, test-driven loop. Grounding and RAG close the domain by attaching a verifiable source of truth, retrieving current or private data at answer time so the answer is factual and can cite where it came from, and this is also where the sampling dials that shape how the model writes, such as temperature and top-p, live.
When two fixes both work, match the technique to the symptom and go no heavier
When two answers both look plausible, the exam rewards the one that fits the technique to the actual symptom and stops there. A wrong format, tone, or reasoning path is a prompt problem, so prompt engineering solves it. A stale, private, or made-up fact is a knowledge problem, so grounding or RAG solves it, because no change of wording can add a fact the model never learned. Fine-tuning and human-in-the-loop review are the heavier tools you layer on only when a concrete need, such as a specialized house style at scale or a high-stakes decision, puts the lighter fix out of reach; reaching for them first buys cost and a model to maintain for no gain. The whole toolkit runs on Vertex AI, the managed platform that hosts tuning, evaluation, and monitoring, with Google's responsible-AI guidance framing where a human belongs.
Match the fix to the failure
| Reach for | When the output is | What it changes | Drill into |
|---|---|---|---|
| The mitigation map | broken in any way and you must pick which fix fits | How you diagnose the failure, plus the post-launch monitoring a live model needs | Overcoming Model Limitations |
| Prompt engineering | wrong in format, tone, or reasoning | The input wording only; it adds no facts and retrains nothing | Prompt Engineering |
| Grounding and RAG | stale, private, or unable to cite a source | Which facts the model sees, by retrieving a source of truth at answer time | Grounding and RAG |