Applications of Foundation Models

This is the single most valuable idea in the domain: there is a ladder of ways to make a model work for you, and they differ enormously in cost. Climb it from the bottom and stop as soon as it works.

Approach	What it does	Relative cost
In-context learning	Put instructions and examples in the prompt	Lowest
Retrieval (RAG)	Fetch relevant documents and answer from them	Low
Fine-tuning	Further train on your examples to shape behavior	High
Continued pre-training	Extend base training on a large domain corpus	Very high
Pre-training	Train a model from scratch	Effectively out of reach

Distillation sits alongside these: training a smaller, cheaper model to reproduce a larger one's behavior. It reduces inference cost rather than improving capability.

The rule that prevents most expensive mistakes: if the problem is that the model does not know your information, the answer is retrieval, not fine-tuning. Fine-tuning shapes behavior, tone, and format. It does not reliably install facts, and it must be redone whenever the underlying content changes.

Fine-tuning methods worth distinguishing: instruction tuning teaches the model to follow a particular style of request; domain adaptation adjusts it to specializt vocabulary; transfer learning reuses a model trained on one task for a related one.

Preparing data to fine-tune is where the real cost sits: curation, governance, sufficient volume, accurate labeling, and representativeness. A fine-tuning proposal without a data-preparation plan is not a plan.

RAG in one line: search your content for the passages relevant to the question, attach them to the prompt, answer from them. Embeddings are stored in a vector store, and the exam-relevant point is that this is a component choice rather than a strategic one, several databases can serve the purpose.

Model selection criteria here add two beyond the usual list: input and output length limits, and prompt caching support, both of which shape what is architecturally possible.

The constructs: context (background the model needs), instruction (what to do), and negative prompting (what to avoid). Being explicit about which part of a prompt is doing which job makes prompts far easier to debug.

The techniques, chosen by observed failure:

• Zero-shot: no examples. Fine for common tasks.
• Single-shot / few-shot: one or several worked examples. The fix when format is wrong.
• Chain-of-thought: reason before answering. The fix when reasoning is wrong.
• Prompt templates: parameterised, reusable prompts. How you get consistency across a team.

Best practice is specificity and concision. Longer is not better: every token costs money and latency, and irrelevant context measurably degrades output.

The risks AWS names explicitly are the part most prep material skips:

• Exposure: sensitive information placed in a prompt persists in logs and history
• Poisoning: malicious content in the data a model retrieves or trains on
• Hijacking / prompt injection: instructions embedded in content the system reads, redirecting its behavior
• Jailbreaking: crafted input that circumvents the model's safety behavior

The defense against injection is architectural rather than textual: constrain what the system is permitted to do, so that a successful injection has nothing dangerous to reach. A prompt instruction saying "ignore malicious instructions" is a preference, not a control.

Prompt versioning and management. Prompts are production configuration that materially changes system behavior. They should be versioned, reviewed, and rolled back like code, not edited in place by whoever noticed a problem. Managed prompt-management tooling exists precisely because teams that skip this cannot answer "what changed?" when quality drops.

Approaches to evaluation, and production work uses all three:

• Benchmark datasets: standardized tests. Useful for comparing models, weak evidence about your data.
• Model-graded scoring: a model scores output against a rubric. Scales to qualities code cannot express; needs calibrating against human judgment, and a judge sharing the generator's blind spots will approve its errors.
• Human review: the ground truth and the bottleneck. Use it to calibrate the other two rather than as the primary loop.

The metrics AWS names for generated text: ROUGE measures overlap with a reference summary, BLEU does the same for translation, BERTScore compares meaning rather than exact wording, and LLM-as-a-judge uses a model to score against criteria.

The honest framing to carry into the exam: the overlap-based metrics reward resembling a reference answer, which is only loosely connected to being good. They are useful for detecting regression and poor for establishing quality.

Whether it meets the business objective is the separate question, and the one that decides go or no-go. AWS lists productivity, user engagement, task completion rate, user satisfaction, and cost per interaction. A model that scores well and does not move any of these has not succeeded.

Evaluating applications rather than models is the mature version of this and an explicit objective. A retrieval system can fail because retrieval returned the wrong passages while the model performed perfectly. An agent can fail at step four of six. Evaluating only the model tells you nothing about either, which is why the first diagnostic step in a retrieval system is always to look at what was actually retrieved.