AWS 上生成式 AI 定制全谱：从 Prompt 工程到自定义模型实战决策框架

这篇博文向你展示如何为工作负载选择正确的生成式 AI 定制方案，避免过度工程化或投入不足。

AWS 通过 Amazon Bedrock 提供来自 Anthropic、Meta、Mistral 和 Amazon 的基础模型，以及构建聊天机器人、代码助手、文档处理系统和自主智能体等一切所需的基础设施。模型就在那里。更难回答的问题是：针对你的具体问题，该怎么使用它们。

能够调用 Anthropic Claude、Amazon Nova 或 Llama，并不意味着你自然知道如何让它们适配你的特定用例。应该写一个更好的提示词？用检索增强生成（RAG）接入文档？微调？从零训练一个模型？选项之多造成了决策瘫痪，选错了代价昂贵。

团队经常跳过微调直接去做，以为精心设计的提示词一下午就能解决问题。也有团队在提示词工程上卡了好几周，而他们的用例明显需要领域特定的训练数据。两种错误都是真金白银的浪费——计算资源浪费、发布延期、模型输出无法说服利益相关者而失去信任。

本文提供一个 8 步决策框架，即 AWS 上的生成式 AI 定制谱系。你将明确知道哪种方案适合你的用例、费用如何、需要多少数据，以及何时升级到下一层级。核心原则：从最简单的方法起步，只有在必须时再深入。

定制谱系：从最简单到最复杂的可视化阶梯

并非每个生成式 AI 问题都需要同等程度的投入。定制谱系就像一座阶梯，每上升一步，付出的努力、成本和数据要求都会增加，但同时你获得的控制力和领域特异性也更高。

图 1：生成式 AI 定制谱系，从直接使用模型到训练自定义模型

谱系分为三个大类：

USE（使用）： 不碰模型，改变你与它对话的方式。 步骤 1–2：直接使用现有模型，或通过系统指令、少样本示例和思维链推理改进提示词。当你在生产工作负载中从一条提示词扩展到数百条时，可以使用提示词评估来根据准确性和鲁棒性指标衡量提示词质量。提示词优化会自动重写提示词，使其在所选模型上表现更好，省去手动试错的过程。

ENHANCE（增强，利用模型）： 在模型周围添加东西。权重保持冻结。 步骤 3–5：用你的文档为模型提供 grounding（RAG）、缓存昂贵的提示词，或将大模型的知识蒸馏到更小更快的模型中。这就是业界所说的"利用"模型——在权重纹丝不动的前提下，用外部工具、数据源和优化手段包裹模型。

TRAIN（训练）： 改变模型本身。 步骤 6–8：用标注数据更新权重（微调）、用海量无标注语料扩展基础认知（继续预训练），或从零构建完全自定义的模型（Amazon Nova Forge）。

规则：从步骤 1 起步。只有当前步骤无法满足你的准确性、延迟或领域要求时，才向上升级。大多数工作负载永远不需要走到步骤 3 之后。

架构概览：AWS 服务映射

下图将谱系中的每一步映射到支持它的 AWS 服务。

图 2：谱系每一步如何映射到 Amazon Bedrock、Amazon SageMaker 和 Amazon Nova Forge

以下图表总结了升级信号——即告诉你何时该从某一步切换到下一步。

图 3：每一步的升级信号，从直接使用到 Amazon Nova Forge

类比：厨师厨房

厨师类比非常贴切，因为它为你提供了一个贯穿全部八步的单一主角（厨师就是模型）。它也让升级成本一目了然：写更精准的指令几乎零成本，而送厨师去烹饪学校则需要数月投入和厨房产出的损失。蒸馏的类比："主厨的品鉴菜单无可挑剔，但每道菜耗时 45 分钟，原材料成本高昂。让线厨学会三道最畅销的菜，10 分钟出餐，成本只有三分之一。"这直接映射到蒸馏的权衡：一个更小的学生模型在你已验证过的特定任务上，以更快的速度和更低的成本复现教师的输出。

图 4：定制谱系的厨师类比

技术详解：谱系的 8 个步骤

以下各节按顺序讲解每一步：它做什么、何时使用，以及告诉你升级到下一步的信号。

步骤 1：直接使用现有模型（Amazon Bedrock：Claude、Nova、OpenAI、Llama）

通过 Amazon Bedrock 直接调用基础模型（FM），零定制。通过单一 API 从 Claude、Amazon Nova、Llama、Mistral 等中选择。关于 AWS 区域支持的模型型号，请参阅 Amazon Bedrock 中的按 AWS 区域支持的模型。

何时使用：通用任务，如摘要、翻译、脑暴和代码生成，且开箱即用的准确率可以接受。无需训练数据，无需设置，只需要一个 API 调用。

何时升级：输出过于通用、格式不符，或不遵循你的领域约定。

案例：Dovetail —— 使用 Amazon Bedrock 且无模型定制，在一天内创建原型，两周内上线新的生成式 AI 功能。

步骤 2：提示词工程与上下文学习（系统提示词、少样本、思维链）

通过系统提示词、少样本示例、思维链推理来优化你给模型的指令，不改变模型权重。

何时使用：模型具备知识，但需要在格式、语气或推理路径上获得引导。这适用于大多数用例。

何时升级：提示词超过约 2000 token、仍然出现领域特定事实的幻觉，或需要模型不具备的知识。

要想在 Amazon Bedrock 上充分发挥提示词工程的威力，请使用以下五个构建块来结构化每条提示词：清晰的指令（使用动作动词并指定范围）、充足的上下文（当前状态、依赖项、约束条件）、具体的要求（功能性和非功能性）、输出格式（仅代码、分步骤、对比）以及质量指标（预期行为、边界情况、性能目标）。

一个常见错误是指令过载或堆砌上下文但缺乏针对性。正确做法是根据任务复杂度调整提示词的详细程度。快速任务只需最少上下文，而复杂功能请求则需要全面的规格说明。

案例：DoorDash —— 使用 Amazon Bedrock 和 Anthropic Claude 构建了全语音驱动的自助服务生成式 AI 联络中心解决方案，仅用 2 个月就准备好进行实时测试。

参考：Amazon Bedrock 中的提示词优化

步骤 3：检索增强生成（RAG）

在推理时通过 Amazon Bedrock Knowledge Bases（完全托管的 RAG 能力）向模型提供外部知识。模型基于你的数据生成答案，减少幻觉，无需重新训练。

何时使用：模型需要访问私有的、频繁更新的或领域特定的数据（内部文档、政策、产品目录）。

何时升级：检索延迟超过要求、上下文窗口溢出，或模型仍然无法对检索到的内容进行正确推理。

案例：Fractal Analytics —— 使用 Amazon Bedrock 和 RAG 为呼叫中心客服构建了统一知识库，实现呼叫处理时间减少 10–15%、呼叫分流率 30%、月查询量超过 20 万次。

案例：EXL —— 在 Amazon Bedrock 上使用 RAG 驱动的虚拟助手处理和评估大量文档，将保险承保成本降低 80%。

参考：在 Amazon Bedrock 上使用 RAG 构建自定义聊天机器人的指南

步骤 4：提示词缓存与上下文优化（降低重复查询的延迟和成本）

对频繁使用的提示词前缀（系统指令、少样本示例、大型上下文）进行预处理和缓存，使重复查询跳过冗余计算。在不改变输出质量的前提下降低延迟和成本。

何时使用：大量重复查询且共享上下文。例如，客服机器人、文档问答、代码助手频繁访问相同的系统提示词。

何时升级：你需要一个更小、更便宜的模型来提供相同的质量，而仅靠缓存无法解决模型规模/成本问题。

案例：inGenious.ai —— 测试并验证了多种大语言模型（LLM），实现聊天机器人响应时间低于 1 秒且不牺牲理解能力，使用 Amazon Nova 将聊天机器人理解能力提升 80%。

参考：在 Amazon Bedrock 上有效使用提示词缓存

步骤 5：模型蒸馏（训练小模型模仿大模型）

将知识从较大的"教师"模型迁移到较小的"学生"模型。学生学习复制教师在特定用例中的输出，以极低的成本和延迟提供几乎相同质量的结果。

何时使用：已用大模型验证了质量，但需要更便宜、更快或可部署在边缘的模型。Amazon Bedrock Model Distillation 生成的学生模型比教师模型快最高 500%、成本降低最高 75%，同时准确率损失低于 2%（据 Amazon Bedrock Model Distillation 正式发布公告，2025 年 5 月）。

何时推进：蒸馏模型无法匹配你所需的语气、格式或推理风格，这意味着需要通过微调直接更新模型的权重。

Goodnotes：从 Amazon Elastic Kubernetes Service（Amazon EKS）上的自托管模型迁移到 Amazon Bedrock 上的 Anthropic Claude，以提升 AI 驱动的"Ask Goodnotes"功能的可扩展性和成本效益。

参考：Amazon Bedrock Model Distillation

使用标注数据（输入-输出对）更新模型权重，以永久改变模型的行为、风格或领域准确性。作为参数高效微调（PEFT/LoRA）用于较小数据集，或作为全量微调用于全面更新。

何时使用：提示工程和 RAG 之后，语气、格式或特定任务的推理仍不匹配。你有数千个展示期望行为的标注示例。

何时推进：模型不理解领域术语或概念。它需要的是基础知识，而不仅仅是行为调整。

Trellix（网络安全）：使用 Amazon Bedrock 和 Anthropic Claude 构建生成式 AI 安全工具。他们为网络安全集成微调了模型，每个集成节省了超过 40 小时的开发时间，新安全集成的上市时间缩短了 90%。

强化微调（RFT）：标准微调（SFT）要求你为模型想要学习的每种行为生成黄金标准的标注输入-输出对。对于代码生成、结构化输出准确性和多步推理等任务，手动创建这些完美示例既昂贵又不切实际，因为验证正确性比演示它要便宜得多。RFT 通过让你定义一个对输出评分的奖励函数来解决这个问题，模型学习根据该信号进行优化。如果没有托管基础设施，实现 RFT 需要构建自定义训练循环、管理 GPU 集群，以及协调奖励模型服务和策略训练。Amazon Bedrock 使其成为完全托管服务：你提供提示（每个任务最多 20,000 个）和评分函数，Bedrock 端到端处理强化学习管道。RFT 于 2025 年 12 月在 Amazon Nova 模型上可用，并于 2026 年 2 月扩展到开源模型，包括 OpenAI GPT OSS 20B 和 Qwen 3 32B。有关完整实现教程，请参阅 AWS Machine Learning Blog 上的《使用 OpenAI 兼容 API 在 Amazon Bedrock 上进行强化微调》（2026 年 3 月）。

参考：Amazon Bedrock 微调

直接偏好优化（DPO）通过直接在首选和非首选响应对上训练，使模型输出与人类偏好对齐，从而无需单独的奖励模型。有关实现细节，请参阅《在 Amazon SageMaker AI 中使用直接偏好优化自定义 Amazon Nova》。

步骤 7：持续预训练（大规模无标注领域语料库）

通过在大规模无标注、特定领域数据（文档、转录、代码、研究论文）上进行训练来扩展模型的基础知识。这是自监督学习，模型在基本层面上学习你领域的语言、概念和关系。

何时使用：即使经过微调后，模型仍不理解你领域的术语。你有大规模专有语料库（10 亿+ tokens），其中包含任何公共模型都未曾见过的知识。

持续预训练（CPT）的历史性挑战是灾难性遗忘：在特定领域数据上训练会提升领域性能，同时降低通用推理、指令遵循和安全对齐能力。Amazon Nova Forge 通过数据混合来解决这个问题，在每个训练阶段将你的专有语料库与 Amazon Nova 策划的训练数据混合。策划的数据集按领域组织，旨在保持通用性能，而你的数据则重塑模型的领域专业知识。有关实现细节，请参阅 Amazon Nova Forge 用户指南中的持续预训练和中训练文档。

RAG 检索返回了正确的文档块，但模型仍然产生不连贯的综合内容。当检索器找到了正确的段落但模型仍无法将它们组合成有效响应时，问题在于理解能力，而非信息获取。额外的提示工程无法弥合这一差距，因为缺失的知识是架构性的，而非事实性的。

即使单个事实正确，对领域结构的推理仍然失败。在保险索赔数据上微调的模型可以学习填写标准化表格，但无法推理代位追偿链或多方面责任级联，因为这些关系模式从未出现在其预训练数据中。通过 CPT 输入大量非结构化领域文档，可以建立标记微调示例无法复制的结构化理解能力。

即使 Amazon Bedrock Knowledge Bases 检索到正确的上下文且微调示例展示了正确用法，模型仍持续误解特定领域术语。法律合同、专利申请、药物化合物命名和金融监管文件使用的语言在模型原始预训练语料库中代表性不足，因此其内部 token 表示缺乏解析这些领域所需的结构性基础。

何时推进：没有现有模型架构符合你的要求，你需要对训练数据、检查点和模型设计拥有完全控制权。

Sonrai：通过使用 Amazon Bedrock 进行单细胞 RNA-seq 数据分析与特定领域模型定制，将精准医学研究速度提升 50%，错误率降低 5 倍，每次实验节省高达 20,000 美元。

数据需求：中训练需要 10 亿+ tokens 的无标注领域内容，全量持续预训练需要 1T+ tokens。

步骤 8：自定义模型训练，Amazon Nova Forge（完全自定义基础模型）

使用 Amazon Nova 架构、中间检查点和与你的专有数据混合的 Amazon 策划训练数据，构建你自己的前沿基础模型。这是"开放训练"范式：你从早期模型检查点开始，混合专有数据，并从头开始为你的领域训练一个模型。

何时使用：现成模型和所有先前的定制步骤都无法满足你的准确率要求。你拥有机器学习（ML）专业知识、大规模专有数据集，并且需要持久的竞争优势。当你打算将模型作为核心产品或服务产品货币化时，这通常是必经之路。Amazon Nova Forge 通过提供托管训练基础设施、Amazon 策划的数据混合和中间检查点，使这项投资变得更有价值，显著减少了构建生产就绪自定义基础模型的时间和成本。

何时不使用：对于大多数客户，步骤 1-7 已足够。Nova Forge 适用于需要深度领域专业知识的专门行业，如制药、机器人技术、金融、制造。

Nimbus Therapeutics：使用 Amazon SageMaker 在专有分子数据上训练自定义模型，以加速候选药物的设计。

是什么让 Forge 与众不同：

访问中间模型检查点（预训练、中训练、后训练）。

与 Amazon 策划数据集的数据混合（有助于防止灾难性遗忘）。

在客户自有环境中进行多轮 RFT（机器人模拟器、代码验证器）。

参考：构建专用 AI 而不牺牲智能：Nova Forge 数据混合实战

使用自定义奖励函数的 RL：Amazon Nova Forge 支持强化学习（RL），你可以在其中将自己的环境作为奖励信号连接起来。化学模拟器对分子设计评分、机器人物理引擎惩罚碰撞、代码验证器检查编译成功：这些直接连接到训练循环，使模型学习根据你的业务特定评估标准而非通用人类偏好标签进行优化。Nova Forge 还支持多轮展开，用于训练复杂的 AI 智能体工作流和顺序决策任务。

自定义模型的按需推理：2025 年 7 月之后训练的自定义 Amazon Nova 模型支持在 Amazon Bedrock 上按 Token 计费的推理，无需预留吞吐量。你可以训练一个自定义模型并以标准按调用次数计费的方式提供服务，与非定制 Amazon Bedrock 模型推理的定价模式相同。这大幅改变了第 6-8 步的成本计算方式，因为你不再需要在验证生产流量之前预先承诺分配好的容量。

为什么选择 Nova Forge 而非在 Amazon SageMaker 上构建自定义流水线：Amazon SageMaker 提供的是底层基础设施——GPU 集群、分布式训练库和自定义容器，完全控制每一个训练参数。Amazon Nova Forge 是一项完全托管的服务，提供一条精心策划的路径。你从 Amazon 已经在数十亿 Token 上预训练好的模型检查点出发，将你的数据与 Amazon 按领域组织的精选语料库混合，然后运行针对 Nova 架构优化的按键式配方（recipes）。实际差异在于时间线和团队规模。一个原本需要专属 ML 团队和数月迭代的自定义训练项目，可以压缩成一个托管工作流，在数周内产出一个可部署的模型，因为基础设施决策、配方调优和数据混合比例已经被解决了。这缩短了你的上市时间，让你能够专注于领域数据和用例，而不是构建和维护训练基础设施。

Nova Forge SDK（pip install amzn-nova-forge）：该 SDK 于 2026 年 3 月在 GitHub 上发布，提供了一个统一的 Python 接口，覆盖完整的定制生命周期。ForgeTrainer 管理训练作业配置和执行，ForgeEvaluator 针对你的基准测试运行模型评估，ForgeDeployer 处理部署到 Amazon Bedrock 或 Amazon SageMaker 端点，ForgeInference 封装了对自定义模型的推理调用。该 SDK 运行在 Amazon SageMaker Training Jobs 或 Amazon SageMaker HyperPod 上，无需管理分布式训练配置、梯度检查点策略或集群容错。

图 6：快速参考，比较各步骤的工作量、数据、时间及所需 AWS 服务

这个谱系是一个诊断过程，而不是一份菜单——不是挑预算允许的最先进方案。从第 1 步开始，验证输出是否符合你的需求，如果不符，找出原因。这个具体的失败模式会精确映射到谱系上的下一个步骤。

生产系统通常会将多个步骤叠加在一起，因为实际工作负载有复合需求。RAG 加上微调是最常见的混合方式：用微调让模型在行为对齐和领域特定格式上达标，然后用 RAG 来处理动态知识——这类知识的更新速度是任何训练周期都跟不上的。团队也经常将微调后的模型蒸馏，以在单一服务配置中同时实现行为对齐和生产级延迟。这个谱系帮助你识别系统需要哪些能力。最终的架构结合了所有能解决你具体失败模式的步骤。

需要避免的常见错误

在生产环境中直接服务大尺寸教师模型而不做蒸馏。如果在原型验证阶段用大模型验证了质量，在扩展到生产流量之前要蒸馏成更小的学生模型。

因为"我们有很多数据"就选择继续预训练。单纯的数据量并不能作为 CPT 的依据。如果你的数据由事实性参考资料组成，如产品规格或策略文档，RAG 能以更低成本处理这类信息——因为这些信息变化频繁，模型只需要引用它，而不需要将其内化。

因为"RAG 太慢"就跳到微调。微调改变的是模型行为，而非推理速度。如果检索延迟是瓶颈，解决方案是更好的分块策略、混合搜索配置或提示缓存。

何时升级：把你的问题匹配到正确的步骤

没有现有模型架构能满足你的需求，或者你需要对训练阶段拥有完全控制权并使用专有奖励环境？通过 Amazon Nova Forge（第 8 步）从早期检查点开始构建，使用数据混合和自定义 RL。

即使使用代表性示例进行微调后，模型仍然无法理解领域语言或结构模式？差距在于理解能力，而非行为能力。使用你的原始领域语料库进行继续预训练（第 7 步），建立微调无法弥补的基础理解能力。

尽管知识正确，但模型的语气、推理风格或任务执行与你的需求不符？微调（第 6 步）。当你可以通过标注示例演示正确行为时使用 SFT，当你可以将正确性定义为奖励函数时使用 RFT。

你用大模型验证了质量，但需要更便宜、更快地用于生产？蒸馏（第 5 步）。Amazon Bedrock Model Distillation 使用教师模型生成合成训练数据，然后微调一个较小的学生模型来复现教师在你特定用例上的输出。

RAG 可用，但生产量下的延迟或成本过高？缓存重复的提示前缀（第 4 步）。Amazon Bedrock 提示缓存预计算每个请求的静态部分，使重复查询跳过冗余计算。

模型产生领域特定事实的幻觉？模型缺少它从未被训练过的知识。通过 Amazon Bedrock Knowledge Bases（第 3 步）用你的数据为模型提供 grounding，因为在推理时提供知识比任何形式的模型训练都更便宜、更快。

输出过于通用或格式不佳？模型需要更好的指令。通过改进提示（第 2 步）——添加系统指令、指定输出格式，并包含 few-shot 示例来演示你想要的结构。

现在你有一条从"我们有一个基础模型"到"我们有一个适用于我们特定用例的模型"的清晰路径。这个谱系不是为了使用最先进的技术，而是为了使用满足你准确性、延迟和领域需求的最简单技术。

简而言之：Amazon Bedrock 处理 S