AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
This post shows you how to pick the right generative AI customization approach for your workload without over-engineering or under-investing. AWS provides access to foundation models from Anthropic, Meta, Mistral, and Amazon through Amazon Bedrock, along with the infrastructure to build everything from chatbots and code assistants to document processors and autonomous agents. The models are available. The harder question is what to do with them for your specific problem. Having access to Anthropic Claude, Amazon Nova, or Llama does not automatically mean you know how to make them work for your specific use case. Should you write a better prompt? Plug in your documents with Retrieval Augmented Generation (RAG)? Fine-tune? Train something from scratch? The number of options creates decision paralysis, and choosing wrong is expensive. Teams often jump straight to fine-tuning when a well-structured prompt would have solved the problem in an afternoon. Other teams stay stuck on prompt engineering for weeks when their use case clearly needs domain-specific training data. Both mistakes cost real money in compute, real time in delayed launches, and real credibility when model outputs do not land with stakeholders. This post gives you an 8-step decision framework, the generative AI customization spectrum on AWS. You will walk away knowing which approach fits your use case, what it costs, how much data you need, and when to escalate to the next level. The core principle: start with the simplest approach and go deeper only when you must. Solution overview The customization spectrum, a visual staircase from simplest to most complex: Not every generative AI problem needs the same level of investment. The customization spectrum is a staircase where each step increases in effort, cost, and data requirements, but also in the degree of control and domain specificity you gain. Figure 1: The generative AI customization spectrum, from using a model as-is to training a custom model The spectrum breaks into three categories: USE: Don’t touch the model. Change how you talk to it. Steps 1–2: Use existing models as-is, or improve your prompts with system instructions, few-shot examples, and chain-of-thought reasoning. As you scale from one prompt to hundreds across production workloads, you can use prompt evaluation to measure prompt quality against accuracy and robustness metrics. Prompt optimization automatically rewrites prompts to perform better on your chosen model, removing manual trial-and-error from the process. ENHANCE (harness the model): Add things around the model. Weights stay frozen. Steps 3–5: Ground the model with your documents (RAG), cache expensive prompts, or distill a large model’s knowledge into a smaller, faster one. This is what the industry calls “harnessing” a model: wrapping it with external tools, data sources, and optimizations while leaving its weights untouched. TRAIN: Change the model itself. Steps 6–8: Update weights with your labeled data (fine-tuning), expand foundational knowledge with massive unlabeled corpora (continued pre-training), or build a fully custom model from scratch (Amazon Nova Forge). The rule: start at Step 1. Move up only when the current step fails your accuracy, latency, or domain requirements. Most workloads never need to go past Step 3. Architecture overview: AWS service mapping The following diagram maps each step of the spectrum to the AWS services that support it. Figure 2: How each step of the spectrum maps to Amazon Bedrock, Amazon SageMaker, and Amazon Nova Forge Decision flow The following diagrams summarize the escalation signals that tell you when to move from one step to the next. Figure 3: Escalation signals for each step, from as-is use through Amazon Nova Forge Analogy: The chef’s kitchen The chef analogy works well because it gives you a single protagonist (the chef is the model) to follow through all eight steps. It also makes the escalation cost obvious: writing sharper orders costs nothing, while sending a chef to culinary school costs months of investment and lost kitchen output. For distillation: “The head chef’s tasting menu is flawless but takes 45 minutes per plate and costs a fortune in ingredients. Teach the line cook the three bestsellers, serve them in 10 minutes at a third of the cost.” That maps directly to the distillation tradeoff: a smaller student model replicating the teacher’s outputs faster and cheaper for the specific tasks you have validated. Figure 4: The chef’s analogy for the customization spectrum Technical breakdown: the 8 steps of the spectrum The following sections cover each step in order: what it does, when to use it, and the signal that tells you to escalate to the next step. Step 1: Using existing models as-is (Amazon Bedrock: Claude, Nova, OpenAI, Llama) Call a foundation model (FM) directly through Amazon Bedrock with zero customization. Choose from Claude, Amazon Nova, Llama, Mistral, and others through a single API. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock. When to use: General-purpose tasks like summarization, translation, brainstorming, and code generation where off-the-shelf accuracy is acceptable. No training data needed, no setup required, only an API call. When to progress: Output is too generic, wrong format, or doesn’t follow your domain conventions. Real-world examples: Dovetail: Creates prototypes within a day and releases new generative AI features in only two weeks using Amazon Bedrock with no model customization. Step 2: Prompt engineering and in-context learning (system prompts, few-shot, chain-of-thought) Optimize how you instruct the model with system prompts, few-shot examples, chain-of-thought reasoning, without changing model weights. When to use: The model has the knowledge but needs guidance on format, tone, or reasoning path. This works for the majority of use cases. When to progress: Prompt exceeds approximately 2,000 tokens, still hallucinating domain-specific facts, or requires knowledge the model doesn’t have. Structuring effective prompts To get the most out of prompt engineering on Amazon Bedrock, structure every prompt using five building blocks: clear instructions (use action verbs and specify scope), sufficient context (current state, dependencies, constraints), specific requirements (functional and non-functional), output format (code only, step-by-step, comparison), and quality indicators (expected behavior, edge cases, performance targets). A common mistake is overloading instructions or dumping context without specificity. Instead, scale your prompt detail to the task complexity. Quick tasks need minimal context, while complex feature requests demand comprehensive specifications. Real-world examples: DoorDash: Built a fully voice-operated self-service generative AI contact center solution using Amazon Bedrock and Anthropic Claude, ready for live testing in only 2 months. Reference: Prompt Optimization in Amazon Bedrock Step 3: Retrieval-augmented generation (RAG) Supply the model with external knowledge at inference time using Amazon Bedrock Knowledge Bases, the fully managed RAG capability. The model generates answers grounded in your data, reducing hallucinations without retraining. When to use: The model needs access to private, frequently updated, or domain-specific data (internal docs, policies, product catalogs). When to progress: Retrieval latency exceeds requirements, context window overflows, or the model still can’t reason correctly over retrieved content. Real-world examples: Fractal Analytics: Built a unified knowledge base for call center agents using Amazon Bedrock and RAG, achieving 10–15 percent reduction in call handling time, 30 percent call deflection, and 200K+ monthly queries. EXL: Reduced insurance underwriting costs by 80 percent using a RAG-powered virtual assistant on Amazon Bedrock that processes and evaluates extensive documents. Reference: Guidance for Building Custom Chatbots Using RAG on Amazon Bedrock Step 4: Prompt caching and context optimization (reducing latency and cost for repeated queries) Pre-process and cache frequently used prompt prefixes (system instructions, few-shot examples, large context) so repeated queries skip redundant computation. Reduce latency and cost without changing output quality. When to use: High-volume, repetitive queries with shared context. For example, customer support bots, document Q&A, code assistants hitting the same system prompt. When to progress: You need a smaller, cheaper model that delivers the same quality, when caching alone can’t solve the model size/cost problem. Real-world example: inGenious.ai: Tested and validated multiple large language models (LLMs) to achieve chatbot responses in less than 1 second without sacrificing comprehension, improving chatbot comprehension by 80 percent using Amazon Nova. Reference: Effectively use prompt caching on Amazon Bedrock Step 5: Model distillation (training smaller models to mimic larger ones) Transfer knowledge from a larger “teacher” model to a smaller “student” model. The student learns to replicate the teacher’s outputs for your specific use case, delivering near-identical quality at a fraction of the cost and latency. When to use: You’ve validated quality with a large model but need it cheaper, faster, or deployable at the edge. Amazon Bedrock Model Distillation produces student models that are up to 500 percent faster and up to 75 percent less expensive than the teacher, with less than 2 percent accuracy loss (per the Amazon Bedrock Model Distillation general availability announcement, May 2025). When to progress: The distilled model can’t match the tone, format, or reasoning style you need, which means the model’s weights need direct updating through fine-tuning. Real-world example: Goodnotes: Transitioned from a self-hosted model on Amazon Elastic Kubernetes Service (Amazon EKS) to Anthropic Claude on Amazon Bedrock to improve scalability and cost-effectiveness for its AI-powered “Ask Goodnotes” feature. Reference: Amazon Bedrock Model Distillation Step 6: Fine-tuning Update model weights using your labeled data (input-output pairs) to permanently change the model’s behavior, style, or domain accuracy. Available as Parameter-Efficient Fine-Tuning (PEFT/LoRA) for smaller datasets or Full Fine-Tuning for comprehensive updates. When to use: Tone, format, or task-specific reasoning doesn’t match after prompt engineering and RAG. You have thousands of labeled examples showing desired behavior. When to progress: The model doesn’t understand domain terminology or concepts. It needs foundational knowledge, not only behavioral adjustment. Real-world example: Trellix (Cyber security): Built generative AI security tools using Amazon Bedrock and Anthropic Claude. They fine-tuned models for cyber security integration, saving over 40 hours of development time per integration and achieving a 90% reduction in time-to-market for new security integrations. Reinforcement fine-tuning (RFT): Standard fine-tuning (SFT) requires you to produce gold-standard labeled input-output pairs for every behavior you want the model to learn. For tasks like code generation, structured output accuracy, and multi-step reasoning, creating these perfect examples by hand is expensive and often impractical, because verifying correctness is far cheaper than demonstrating it. RFT solves this by letting you define a reward function that scores outputs, and the model learns to optimize against that signal. Without managed infrastructure, implementing RFT requires building custom training loops, managing GPU clusters, and orchestrating reward model serving alongside policy training. Amazon Bedrock makes this accessible as a fully managed service: you supply prompts (up to 20,000 per job) and a scoring function, and Bedro [truncated for AI cost control]