Recognize foundation model limitations and choose mitigations

Study guide for Generative AI Leader, Unit 3 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Identifying common limitations of foundation models (e.g., data dependency, the knowledge cutoff, bias, fairness, hallucinations, edge cases). Describing the Google Cloud-recommended practices to address limitations (e.g., grounding, retrieval-augmented generation [RAG], prompt engineering, fine-tuning, human in the loop [HITL]).

This hive's learning objectives for the topic:

Identify data dependency, knowledge cutoff, bias, fairness, hallucination and edge-case limitations in a described output.
Match grounding, retrieval-augmented generation, prompt engineering, fine-tuning and human review to the limitation each addresses.
Decide when human-in-the-loop review is required before an output reaches a customer or a decision.

Foundation model limitations

Name the limitation, match the practice, decide who checks

Name it — data dependency, knowledge cutoff, bias, fairness, hallucination, edge cases. Treat it — grounding, RAG, prompt engineering, fine-tuning or human review, each for the limitation it actually addresses. Check it — when an output can harm someone, a person reviews it before it lands.

Unit three is about improving what a foundation model produces, and it starts by being honest about what can go wrong. Google's responsible AI page puts it plainly: large language models can generate output that you don't expect, including text that's offensive, insensitive, or factually incorrect. A generative AI leader is not expected to fix the model, but is expected to recognise the failure and choose the right response. So this topic has three steps. First, name the limitation: the guide lists data dependency, the knowledge cutoff, bias, fairness, hallucinations and edge cases. Second, treat it: grounding, retrieval-augmented generation, prompt engineering, fine-tuning and human review each address some limitations and not others, and the exam rewards matching them precisely. Third, decide when a person must check an output before it reaches a customer or a decision. Keep the order — name, treat, check — and scenario questions about model limitations become much easier to read.

Six limitations to recognise in an output

Each limitation leaves a different fingerprint on the output

Data dependency: flawed or incomplete data teaches incorrect patterns
Knowledge cutoff: a model is limited to its pre-trained data
Bias and fairness: skewed data, worse results for some groups
Hallucination: incorrect or misleading results presented as fact
Edge cases: rare situations the training data barely covers

Worked example (synthetic). A travel assistant confidently quotes a visa rule that changed last year, ranks hotels in one neighbourhood lower for no stated reason, and misreads a request for a wheelchair-accessible ferry. Three outputs, three different limitations — outdated knowledge, bias and an edge case.

The first objective is recognition, and each limitation leaves its own fingerprint. Data dependency comes first because the others grow from it: Google says that if the training data is incomplete, biased or otherwise flawed, the model may learn incorrect patterns, leading to inaccurate predictions or hallucinations — and the quality, accuracy and bias of the prompt or data you put in matter too. The guide's knowledge cutoff is the time version of that dependency. In Google's words, large language models, or LLMs, are limited to their pre-trained data, and this leads to outdated and potentially inaccurate responses. Bias and fairness go together: generative models can inadvertently amplify biases in their training data, and an unfair model may perform worse for certain subsets of the data, so quality is uneven across users. A hallucination is an incorrect or misleading result the model generates, often stated with confidence. And edge cases are unusual, rare or exceptional situations that are not well represented in the training data; Google lists overconfidence, misinterpretation of context and inappropriate outputs as the result. The practical skill is reading a described output and naming which of these is showing.

Read the symptom, name the limitation

What you see in the output points to what went wrong

What the output shows	Limitation	Google's description
A fact that was true once but no longer is	Knowledge cutoff	Limited to pre-trained data, so responses can be outdated
A fluent, specific answer that is simply wrong	Hallucination	Incorrect or misleading results the model generates
Worse answers for one group of users	Bias and fairness	Biases amplified; worse results for some slices
A confident misreading of an unusual request	Edge case	Rare situations not well represented in training data
Errors that trace back to gaps in the data	Data dependency	Incomplete or flawed data teaches incorrect patterns

Worked example (synthetic). A bank's assistant explains a fee schedule that changed this quarter. The answer is fluent and internally consistent, which is exactly why it is dangerous: the symptom is outdated content, so the limitation is the knowledge cutoff, not a random error.

This table turns the definitions into diagnosis. Read across from the symptom. An answer that was true once but no longer is points to the knowledge cutoff, because Google says large language models are limited to their pre-trained data and that leads to outdated responses. A fluent, specific answer that is simply wrong is a hallucination — an incorrect or misleading result the model generates. Answers that are worse for one group of users point to bias and fairness: Google warns that models can amplify biases in their training data and that an unfair model may perform worse for certain slices of the data. A confident misreading of an unusual request is an edge case, a situation not well represented in the training data. And errors that trace back to what the model was trained on are data dependency. Two cautions. The rows overlap in real life — flawed data can produce a hallucination — so name the most specific cause the scenario gives you. And note that Google ties hallucinations to high-stakes use: they can be a problem for systems that make important decisions, such as medical diagnoses or financial trading.

Why hallucinations and unfair outputs happen

Most limitations trace back to data the model learned from

Figure. Three cards name causes of hallucinations: insufficient training data, incorrect assumptions made by the model, and biased training data that can be amplified. A band beneath adds a fourth cause: shallow domain knowledge, which produces superficial or incorrect answers on highly specialised topics.

Worked example (synthetic). A clinic's assistant is asked about a rare drug interaction. Little public text covers it, so the model assembles a plausible answer from neighbouring facts. The cause is insufficient data on a specialised topic — and the answer reads just as confidently as a correct one.

Behind the symptoms sit a few causes, and Google names them. Hallucinations, it says, can be caused by a variety of factors, including insufficient training data, incorrect assumptions made by the model, or biases in the data used to train the model. Insufficient data means the model has seen too little about the subject and produces a plausible guess. Incorrect assumptions mean the model answers a question the prompt never asked. Biased data is learned rather than corrected, and Google warns that generative models can inadvertently amplify those biases, reinforcing unequal treatment of certain groups. The band beneath adds a fourth cause that matters for business use: limited domain expertise. Google says models can lack the depth of information required on highly specialized or technical topics, leading to superficial or incorrect information. Knowing the cause is what makes the next objective possible, because each mitigation works on a particular cause.

Match the practice to the limitation

Each mitigation treats a cause; none of them treats every cause

Grounding: tie output to verifiable sources, cutting invented content
RAG: supply up-to-date information the model was never trained on
Prompt engineering: guide the model toward the desired response
Fine-tuning: build depth in a specific domain from quality data
Human in the loop: judgment where the model is uncertain

Worked example (synthetic). An insurer's assistant quotes last year's policy terms. Fine-tuning on the old manuals would bake the stale terms in deeper; retrieving the current policy documents at question time fixes the cause.

The second objective is matching, and the guide names five practices. Grounding, in Google's definition, is the ability to connect model output to verifiable sources of information; when you give a model access to specific data sources, grounding tethers its output to that data and reduces the chances of inventing content — the direct treatment for hallucination, with links to sources for auditability. Retrieval-augmented generation, or RAG, is a way of grounding that fetches relevant information at question time; Google says it overcomes the pre-trained-data limit by providing up-to-date information, so it is the answer to a knowledge cutoff. Prompt engineering is the art and science of designing and optimizing prompts to guide the model toward the desired responses, and Google adds that careful prompting helps mitigate bias and inappropriate content. Fine-tuning builds depth: to create a model that excels in your specific domain, consider fine-tuning — though Google recommends starting with prompting first. And human-in-the-loop review brings judgment where the model lacks it. The mistake to avoid is a mismatch, such as tuning a model on old documents to fix answers that are out of date.

Which practice treats which limitation

Read each row as a match — and as a mismatch to avoid

Practice	Treats	Does not fix by itself
Grounding	Hallucination — output tied to verifiable sources	Irrelevant sources: grounded but off-topic
RAG	Knowledge cutoff — up-to-date information at question time	A poor retrieval step
Prompt engineering	Unclear tasks and some bias — guided toward the desired response	Missing domain knowledge
Fine-tuning	Shallow domain depth — a model that excels in your domain	Facts that change after tuning
Human in the loop	High-stakes and edge cases — judgment and context	Scale, if every output needs a person

Worked example (synthetic). A legal team's summariser cites the right statute but the wrong paragraph. It is grounded, yet the retrieval step returned an adjacent section — the 'grounded but off-topic' failure — so the fix is better retrieval, not more grounding.

Here the five practices sit beside what each treats and, just as important, what each does not fix on its own. Grounding treats hallucination by tying output to verifiable sources, but Google warns that if the retrieved information is irrelevant, the generation could be grounded but off-topic or incorrect — so grounding is only as good as what it is grounded on. Retrieval-augmented generation, or RAG, treats the knowledge cutoff by providing up-to-date information, and it depends on a retrieval step that finds the right material. Prompt engineering clarifies the task and, Google says, helps mitigate bias, but a prompt cannot supply knowledge the model does not have. Fine-tuning builds depth in a domain from high-quality, well-labeled data — which Google says matters more than quantity — but facts that change after tuning are still out of date. Human-in-the-loop review adds the judgment, contextual understanding and handling of incomplete information that models lack, at the cost of a person's time. Most exam distractors in this area are a real practice applied to the wrong limitation.

When a person must review the output

The higher the stakes for a person, the earlier a human checks

Required where an output can materially affect individual rights
Valuable where judgment, context or incomplete information matter
Human oversight raises accuracy, reliability and user trust
Low-stakes, reversible outputs can ship with monitoring and feedback

Worked example (synthetic). A lender's assistant drafts loan decline letters. Because each letter affects an applicant's access to credit, an underwriter approves every one before it is sent; the same bank's internal meeting summaries go out unreviewed, with a feedback button.

The third objective is a decision: when must a human check an output before it reaches a customer or a decision? Google gives the firmest rule on its responsible AI page: for specialized, complex use cases, models should be tuned on domain-specific data, and there must be meaningful human supervision in contexts with the potential to materially impact individual rights. Credit, employment, health and legal standing are the obvious examples. More generally, Google describes human-in-the-loop, or HITL, as a collaborative approach that integrates human input and expertise into machine learning and AI systems, and says models benefit from human expertise in areas requiring judgment, contextual understanding and handling incomplete information. The benefits it lists are higher accuracy and reliability and greater user trust. Not every output needs a reviewer, though. Where an error is low-stakes and easy to reverse, Google's recommended practices still apply — perform safety testing appropriate to your use case, and solicit user feedback and monitor content — but a person need not approve each output. The skill is placing a use case on that scale.

A review decision in three questions

Ask about impact, then judgment, then reversibility

Loading Diagram...

Figure 1 — Mermaid diagram

Figure: A left-to-right flowchart. A model output meets three questions in turn: could it materially affect someone's rights; does it need judgment or missing context; is an error easy to spot and reverse. A yes to either of the first two, or a no to the third, leads to human review before release. Otherwise the output is released, then monitored with user feedback collected.

Worked example (synthetic). A retailer's product-description generator fails no question: no one's rights are affected, the copy needs no special judgment, and a bad description is easy to spot and edit. It ships with sampling and a report button; its refund-dispute replies do not.

Drawn as a decision, the review question has three parts. First, impact: could the output materially affect someone's rights? If so, Google's guidance requires meaningful human supervision, and a person reviews before release. Second, judgment: does the output depend on judgment, contextual understanding or information the model does not have? Those are exactly the areas where Google says models benefit from human expertise, so again a person checks. Third, reversibility: if an error would be hard to notice or hard to undo, review it first. Only an output that is low impact, needs no special judgment and is easy to correct goes straight out — and even then Google's recommended practice is to solicit user feedback and monitor content, so problems surface quickly. Notice the direction of the flow: the questions get cheaper to answer as you go, and any single answer pointing at risk is enough to route the output to a person.

Placing use cases on the review scale

Same model, different stakes, different review

Use case	Why	Review
Benefit-eligibility letters	Affects a person's rights	Before release, every output
Clinical note summaries	Specialised; judgment needed	Before use by a clinician
Support chat suggestions	An agent sends or edits them	Agent decides each reply
Internal meeting summaries	Low stakes, easy to correct	After release — feedback, sampling

Worked example (synthetic). Invented use cases for one organisation. The model is the same in every row; what changes the answer is who is affected and how easily a mistake is caught.

These four invented use cases share a model and differ only in stakes. Benefit-eligibility letters can materially affect a person's rights, so under Google's guidance there must be meaningful human supervision: a person approves every letter before it is released. Clinical note summaries are specialized, and Google notes that models can lack depth on highly specialized topics and that humans add judgment and context, so a clinician reviews before relying on them. Support chat suggestions build the review into the workflow: the model drafts, and a human agent decides what to send — human-in-the-loop in its most practical form, which Google says improves accuracy, reliability and user trust. Internal meeting summaries are low stakes and easy to correct, so they ship, and quality is managed afterwards by sampling, monitoring and user feedback. When an exam scenario asks whether a human should review, look first for the people affected and the cost of an error that nobody catches.

What this topic actually tests

Name it, treat it, check it

Name it: outdated → knowledge cutoff; confidently wrong → hallucination; uneven across groups → bias and fairness; rare request misread → edge case. Treat it: grounding and RAG for facts, prompting for direction, fine-tuning for depth. Check it: rights at stake means a human reviews first.

Close on three moves. Name it: an answer that used to be true is the knowledge cutoff, because models are limited to their pre-trained data; a confidently wrong answer is a hallucination; answers that are worse for some groups are bias and fairness; a misread unusual request is an edge case; and behind many of these sits data dependency. Treat it: grounding ties output to verifiable sources and retrieval-augmented generation, or RAG, supplies up-to-date information, so those answer factual and freshness problems; prompt engineering guides the model toward the response you want; fine-tuning builds depth in a domain. Check it: where an output can materially affect someone's rights, there must be meaningful human supervision before it is used, and everywhere else, test for safety and keep collecting feedback. The next topic follows the model into production, where these limitations have to be watched for continuously rather than just designed around.

Unit 3.1 study guide — Recognize foundation model limitations and choose mitigations