Techniques to improve gen AI model output practice questions

Grounding is the practice of connecting a foundation model's output to verifiable data sources — such as an organization's own documents or live search results — so responses reflect fact rather than only training-data patterns.

The defining idea of grounding is anchoring generated answers in trusted, checkable sources, which directly addresses hallucinations and the knowledge cutoff. Regional deployment is a compliance concern, frozen weights describe model usage rather than grounding, and temperature merely tunes randomness — a low-temperature model can still confidently state falsehoods.

1. Define grounding: linking model responses to verifiable data.
2. Connect it to the limitations it fixes: hallucinations and stale knowledge.
3. Distinguish it from unrelated controls like region selection and sampling parameters.

Exam tip: Grounding means anchoring model answers in verifiable data sources — it is the core defense against hallucination.

Fine-tuning and prompt engineering are both ways to improve foundation-model output, but they operate at different levels: one changes the model, the other changes the request.

Fine-tuning continues training the model on additional, curated examples so its internal parameters adapt to a domain, task, or style — a lasting change to the model. Prompt engineering instead crafts the instructions, context, and examples supplied in the prompt at request time, steering the existing model without modifying it. Option (a) swaps the definitions, (b) wrongly claims prompting changes weights, and (c) confuses fine-tuning with grounding and mischaracterizes prompt engineering.

1. Identify that fine-tuning is a training-time technique that updates the model's parameters.
2. Identify that prompt engineering is a request-time technique that changes only the input, not the model.
3. Match the correct option to that distinction and reject reversed or grounding-based descriptions.

Exam tip: Fine-tuning changes the model; prompt engineering changes the prompt — pick fine-tuning for durable domain/style adaptation, prompting for fast, low-cost output shaping.

Human in the loop (HITL) means deliberately placing human review, correction, or approval steps inside an AI workflow, especially where errors carry real consequences.

The essence of HITL is that a person validates model output before it takes effect — approving a generated legal clause, reviewing a medical summary, or correcting labels that then improve the system. It is not about the chat interface, caching, or automated retraining; in fact HITL trades some speed for accountability and safety, which is exactly why it is recommended for high-stakes uses.

1. Define HITL: humans review or approve model outputs at defined checkpoints.
2. Identify where it matters most: high-stakes or ambiguous decisions where model errors are costly.
3. Recognize the trade-off: slower throughput in exchange for accountability and higher-quality outcomes.

Exam tip: HITL puts human review inside the AI workflow so consequential outputs are verified by a person before they are used.

Fine-tuning trains a foundation model further on curated, domain-specific examples so that specialized vocabulary, tone, and style become part of the model's default behavior.

When the requirement is durable adaptation — always writing in a particular style with particular terminology — fine-tuning is the right tool, because the behavior is baked in rather than re-specified in every prompt. Token limits only change length, HITL rewriting does not scale and does not change the model, and drift monitoring is an observability practice, not an adaptation technique.

1. Identify the need: persistent domain style and terminology across large volumes of output.
2. Compare options: prompt instructions repeat per request, while fine-tuning changes the model's default behavior.
3. Choose fine-tuning when the adaptation must be durable and consistent at scale.

Exam tip: Use fine-tuning when the model must durably adopt domain-specific style and terminology, not just follow a one-off instruction.

Drift monitoring is a continuous-evaluation practice that watches for changes in model performance over time, typically caused by real-world data or user behavior diverging from the conditions the model was originally validated against.

Models that performed well at launch can degrade as the world changes — new products, new slang, new regulations, new user intents. Drift monitoring surfaces that degradation trend so teams can respond with grounding updates, fine-tuning, or model upgrades. Security logins, individual typos, and billing are all monitored by other disciplines.

1. Define drift: production conditions diverging from the data the model was built and evaluated on.
2. Recognize the symptom: a gradual decline in output quality or relevance over time.
3. Recall the response: alerting via KPIs, then remediation through updated grounding data, tuning, or a model version upgrade.

Exam tip: Drift monitoring catches gradual performance decay as real-world data shifts away from what the model was built for.

Data dependency is the limitation that a foundation model's knowledge, capability, and biases are all inherited from its training data — gaps or imbalances in that data become gaps or biases in the model.

The phrase "only as good as the data it was trained on" is the plain-language statement of data dependency. It explains why models underperform in domains poorly represented in training data and why biased data produces biased outputs. Context windows, latency, and prompt sensitivity are separate characteristics that do not concern training-data quality.

1. Parse the phrase: model quality is a function of training-data quality.
2. Name the limitation: data dependency.
3. Connect it to consequences: domain gaps, bias, and fairness issues all flow from the data the model learned from.

Exam tip: Data dependency means a model inherits both the strengths and the gaps of its training data.