> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Fine Tuning Models Part 1 > Explains fine-tuning foundation models, when to use it, benefits over prompting, example workflow for customer support tone, alternatives, and deployment considerations. In this lesson we introduce fine-tuning: when you need it, why it helps, and a high-level workflow for making foundation models behave more consistently for your domain. We’ll contrast the limits of prompting with the benefits of fine-tuning, walk through an example (customer support tone), and summarize when to choose fine-tuning versus alternatives. A slide titled "Lecture Flow" showing a flowchart: Problem → Solution → Workflow → Results. Underneath it notes "Prompting has limitations" (Problem) and "Fine tune foundation model" (Solution). What prompting gets you — and what it doesn’t * Foundation model responses are probabilistic. The same prompt can produce different outputs across calls. * Prompting provides context for a single request; it does not change the model’s internal parameters or teach persistent behavior. * Maintaining consistent structure, tone, or strict output formats via prompts alone is often brittle and requires repeating detailed instructions every request. * As prompt complexity grows, so do maintenance costs, latency, and the risk of unexpected outputs. The result: relying only on prompting can make it difficult to achieve repeatable, domain-standard responses at scale. A presentation slide titled "Problem: Prompting Has Limitations." It shows four blue icons with captions listing limitations: outputs can vary, instructions must be repeated, structure/formatting and tone are hard to enforce, and prompting alone doesn't reliably teach new behaviors. Why fine-tuning Fine-tuning trains a foundation model on your examples so the model’s behavior aligns more closely with your expectations. Important points to clarify: * You are not pretraining the model from scratch. Full pretraining requires massive compute and data. * Fine-tuning updates only a subset of model parameters (or adds small task-specific updates), making the process feasible for customization. * You supply training examples (typically input → desired output pairs). The fine-tune job adjusts tunable parameters so the model learns to produce outputs consistent with your examples. * Outcomes: greater consistency, smaller runtime prompts, and outputs adapted to specific formats, styles, or domain language. A presentation slide titled "Solution: Use fine tuning" with four colorful icons. Each icon lists a benefit: train a model with your own examples, improve response consistency, reduce dependence on complex prompts, and adapt outputs to preferred formats. Example: customer support tone Suppose you want all customer service replies to be empathetic and consistent. During fine-tuning you provide prompt → desired response pairs so the model learns the preferred phrasing and structure. * Prompt: "My order still hasn't arrived, and nobody has updated me." * Desired response: "I'm sorry — your order has been delayed. We understand how frustrating this is. We'll check the shipping status now and work to resolve it quickly." * Prompt: "I was charged twice for my subscription this month." * Desired response: "I'm sorry about the duplicate charge. We'll review the billing and arrange a refund if an error occurred." By training on a dataset of such pairs, the model internalizes the style and reduces the need for long, repetitive instructions at runtime. An infographic titled "Workflow: Fine-Tuning Example Data — Customer Support Tone" showing two customer complaints (order not arrived; charged twice) in dark blue boxes with arrows leading to orange gradient boxes containing polite, apologetic desired support responses. When to consider fine-tuning Use fine-tuning when you need repeatable model behavior that prompt engineering cannot reliably deliver. The table below summarizes common indicators and recommended actions. | Indicator | Why it matters | Recommended action | | - | - | - | | Inconsistent outputs across requests | Probabilistic responses cause variability | Consider fine-tuning with representative examples | | Domain-specific language or policies | Base models may not follow internal terminology or rules | Fine-tune on labeled data that reflects your domain | | Prompt complexity is growing | Long prompts are harder to maintain and increase latency | Move core behavior into the model via fine-tuning | | Need to reduce runtime prompt size | Shorter runtime prompts improve performance and maintainability | Fine-tune to internalize repetitive instructions | A presentation slide titled "Workflow: When to Use Fine-Tuning" with four colored icons and brief reasons: "You need consistent outputs," "You have domain-specific data," "Prompting alone is not enough," and "You want to reduce prompt complexity." Alternatives to fine-tuning Fine-tuning is powerful but not always the most cost-effective or simplest choice. Evaluate the alternatives first. | Alternative | Use case | When to prefer | | - | - | - | | Prompt engineering | Small behavioral tweaks, instructional constraints | Quick experiments or low-volume use | | Knowledge bases / RAG | Up-to-date facts and long documents | Domain knowledge that changes frequently | | Different foundation model | Some models perform better for specific tasks without tuning | When another model already matches your needs | A slide titled "Workflow: Fine-Tuning Alternatives" showing four blue circular icons labeled: "Fine-tuning is not always required," "Prompt Engineering," "Knowledge Bases (RAG)," and "Better model selection." Try exhaustive prompt engineering, retrieval-augmented generation (RAG), and alternative model selection first — fine-tuning adds cost, operational complexity, and lifecycle management responsibilities. Model availability and platform notes * Not every foundation model supports fine-tuning. For example, in Amazon Bedrock fine-tuning is currently supported only for a subset of AWS-owned models (such as certain Titan variants). * Models provided by other vendors (e.g., Claude or some Llama-family variants exposed by third parties) may not be tunable via Bedrock; vendor-specific tooling is required for those models. * Check the target platform’s documentation and supported-model list before preparing data and jobs. Next steps — a practical checklist 1. Audit your prompts and collect failure examples (or inconsistent outputs). 2. Decide whether to try prompt engineering, RAG, or model selection first. 3. If fine-tuning is appropriate: * Prepare a representative training dataset of input → desired-output pairs. * Validate formats and dataset sizes against the platform’s fine-tuning requirements. * Configure and run a small pilot fine-tune job. * Evaluate results on holdout examples and iterate to avoid overfitting. 4. Deploy, monitor for drift, and maintain governance (bias checks, logging, and rollback plans). Links and references * [Amazon Bedrock — product page](https://aws.amazon.com/bedrock/) * [Prompt engineering course (example)](https://learn.kodekloud.com/user/courses/learn-by-doing-prompt-engineering-101) * [Fundamentals of RAG (example)](https://learn.kodekloud.com/user/courses/fundamentals-of-rag) If you want, I can draft a sample fine-tuning dataset format, show a minimal evaluation plan, or outline Bedrock-specific steps for preparing and submitting a fine-tuning job. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.