Applications of Foundation Models
The customization ladder: prompt-engineer first, add RAG for facts, fine-tune for durable behavior
Assuming you can already name a foundation model from Domain 2, this domain teaches you to choose how far to adapt one. The four subtopics in this domain are not four separate tools: they are rungs on a single adaptation ladder you climb only as far as the problem forces you. Start with prompt engineering, because it changes nothing about the model and is the cheapest, fastest lever: better instructions, examples, and inference parameters guide a frozen model at request time, and supplying example input-output pairs inside the prompt is the technique known as in-context learning (What is prompt engineering?). Climb to Retrieval Augmented Generation (RAG) only when the answer must come from private or frequently changing data the model never saw. RAG still leaves the weights untouched and instead injects retrieved context into the prompt at query time (What is RAG?). Climb to fine-tuning only when you need a durable change to how the model behaves: a tone, format, or domain skill baked permanently into the weights (Customize your model). The decisive test is what you are trying to change: behavior at inference time (prompt), the facts available (RAG), or the model itself (fine-tune). Skipping rungs is the classic AIF-C01 trap: reaching for fine-tuning when the real fix was a better prompt or a knowledge base wastes the most money for the least benefit.
Evaluation is the throughline that decides which rung you actually needed
Climbing the customization ladder is only half the discipline; the other half is proving the rung worked, and that throughline is FM evaluation. Every adaptation choice (a reworded prompt, a new knowledge base, a fine-tuning run) is a hypothesis that must be measured, not assumed. Use fast, cheap automated metrics (ROUGE for summarization, BLEU for translation, BERTScore for meaning-preserving paraphrase, perplexity for fluency) to compare many candidates and to catch regressions as prompts and models change, and reserve slow, expensive human evaluation for the subjective and high-stakes dimensions (helpfulness, tone, factual correctness, safety) that no metric reliably scores (Evaluate the performance of Amazon Bedrock resources). Amazon Bedrock model evaluation runs both automatic and human workflows on your own dataset, so model selection rests on measured results rather than vendor claims or generic leaderboards (Amazon Bedrock Evaluations). The non-negotiable rule that closes the loop: a strong technical score only matters if it moves a business outcome (productivity, engagement, conversion, ROI). The right model is the one whose quality translates into the KPI the application exists to improve, not the one with the best benchmark number.
Selection and orchestration frame the whole domain: choose the model, then decide if it acts
Before and around the customization ladder sit two design decisions that recur across every subtopic. First, model selection is always a multi-criteria trade-off, never a search for one 'best' model: you weigh token-based cost, latency, the required modality and languages, model size and complexity, the available customization paths, and (a hard ceiling that catches people) the context window, since the prompt and the generated completion share one finite token budget. A larger model usually wins on hard tasks but costs more per token and responds more slowly, so a smaller or distilled model (a compact model trained to mimic a larger one) can be the correct business choice. Amazon Bedrock exposes many FMs behind one API precisely so you can compare these axes without managing infrastructure (What is Amazon Bedrock?). Second, decide whether the application merely generates text or must take action: a plain FM call answers one prompt, but an agent plans a sequence of steps, calls tools and APIs, queries knowledge bases, and reasons over intermediate results before answering. Amazon Bedrock Agents is the managed capability for this multi-step, tool-using pattern (Automate tasks using AI agents). Agents are where selection, RAG, prompting, and evaluation converge: an agent is built from a chosen model, grounded by RAG, steered by prompts, and judged by application-level evaluation of the whole workflow, not just a single response.
FM customization approaches across this domain
| Aspect | Prompt engineering / in-context learning | Retrieval Augmented Generation (RAG) | Fine-tuning |
|---|---|---|---|
| What it changes | Only the prompt at inference time; model weights untouched | Adds retrieved external context to the prompt; weights untouched | Updates the model's weights on your curated examples |
| Data needs | Just the instructions, examples, and context you type in | A knowledge source chunked, embedded, and stored in a vector store | A sizable, curated, correctly labeled prompt-and-completion dataset |
| Data freshness | Limited to what is in each prompt | Always current: answers from the live vector store you keep updated | Frozen at training time; stale until you retrain |
| Relative cost / effort | Lowest; no extra infrastructure, try it first | Moderate; needs embeddings plus a vector store (e.g. Bedrock Knowledge Bases) | Highest; needs labeled data and a per-token training run plus model storage |
| Best for | Steering format, tone, and reasoning on a capable model | Answering from private, large, or frequently changing knowledge | Durable tone, format, or domain behavior baked into the model |