生成式 AI 项目最容易走偏的地方，不是模型调用，而是过早选择了过重的定制方案。很多问题用更好的提示词就能解决；有些问题需要接入企业知识库；只有当模型的行为、领域语言或任务能力仍然达不到要求时，才值得考虑微调、持续预训练，甚至构建更深度的自定义模型。
在 AWS 上，可以把这条路线理解为一条逐步升级的定制光谱：从提示词工程开始，经过 RAG、工具调用和模型选择，再进入微调、持续预训练，最终评估 Amazon Nova Forge 等更深度的模型定制能力。核心原则只有一句话：从最简单、最便宜、最容易回滚的方案开始，只有证据证明不够时才升级。
先把问题分成三类
选择方案前，先判断你要解决的到底是哪一种问题。不同问题对应的定制层级并不相同。
1. 模型不知道企业最新事实
例如模型不知道公司的产品目录、内部流程、库存状态或当天的政策。这通常不是模型能力问题，而是知识获取问题。优先考虑：
- RAG：检索企业文档，再把相关内容放入上下文；
- 工具调用：让模型查询数据库、搜索系统或业务 API；
- 结构化上下文：在请求中传入订单、用户或环境信息。
把事实写进模型参数并不能天然解决实时性问题，反而可能增加更新和合规成本。
2. 模型知道答案，但输出方式不稳定
如果模型已经理解任务，只是格式、语气、步骤或边界控制不稳定，通常可以从提示词工程开始：
- 明确角色、输入、输出格式和禁止事项；
- 提供少量高质量示例；
- 要求输出 JSON，并在应用侧做 schema 校验；
- 使用评测集比较不同提示词，而不是凭感觉修改。
3. 模型缺少稳定的领域能力
如果加入上下文和示例后，模型仍然无法稳定完成某类任务，例如领域术语理解、固定分类体系、特殊代码风格或复杂推理流程，再考虑微调或更深层的训练方案。
一个可执行的八步决策框架
下面这八步可以作为项目评审清单。它们不是必须线性执行的流程，而是一套用来避免“先训练再找问题”的判断顺序。
第一步：定义失败样例，而不是只定义愿景
收集真实输入，并明确什么叫失败：事实错误、格式错误、拒答不当、延迟过高，还是成本超标。至少准备一组固定评测集，包含正常样例、边界样例和恶意输入。
没有失败样例，就无法判断升级方案是否真的有效。
第二步：先尝试提示词工程
把任务拆成清晰的指令、约束、示例和输出格式。对需要结构化输出的场景，在模型返回后进行程序化校验；不要把所有可靠性要求都交给提示词。
这一层的优势是改动小、迭代快、容易回滚。代价是复杂任务可能需要较长上下文，而且输出稳定性受模型本身影响较大。
第三步：判断信息是否需要实时更新
如果答案依赖内部文档、数据库或实时业务状态，优先引入 RAG 或工具调用。RAG 适合搜索文档和知识片段，工具调用更适合查询结构化数据、执行动作或访问实时系统。
评估 RAG 时，不要只测试“检索到了没有”，还要分别测试：
- 检索召回是否覆盖正确文档；
- 上下文是否足够精确；
- 模型是否忠实使用检索结果；
- 没有答案时是否会明确表示不确定。
第四步：比较不同基础模型
在 AWS 上，可以根据任务、延迟、成本、语言覆盖和部署约束比较可用的基础模型。换一个更合适的模型，有时比微调当前模型更有效。
模型选择应使用同一套评测集和同一组业务指标。不要只看单次回答质量，还要关注吞吐、平均延迟、尾延迟和单位请求成本。
第五步：加入少量示例和工具工作流
如果模型具备基础能力，但执行步骤不稳定，可以通过 few-shot 示例、工具调用、函数编排或工作流状态机改善结果。对于多步骤业务，不要让模型独自维护所有状态；关键状态和权限应由应用程序控制。
第六步：评估微调是否值得
当任务模式相对稳定、训练样本质量较高，并且提示词加 RAG 仍无法达到目标时，可以评估微调。微调更适合改变模型的行为模式、输出风格、分类边界或特定任务表现，而不是替代实时知识库。
进入微调前，应确认：
- 样本经过人工审核，且覆盖真实分布；
- 训练集和测试集没有重复或泄漏；
- 有清晰的基线结果；
- 能够持续维护训练数据和模型版本；
- 有回滚和线上灰度方案。
第七步：只有在领域语言本身不足时，考虑持续预训练
持续预训练通常比微调更重，适合模型需要大量吸收某个领域的语言、术语、文档风格或知识分布的情况。它需要更多数据、算力、训练管理和评测工作，也更容易带来灾难性遗忘、数据治理和版本维护问题。
如果你的真实需求只是“回答公司内部文档”，持续预训练往往不是第一选择；RAG 通常更容易更新和审计。
第八步：评估 Amazon Nova Forge 等深度定制路径
当组织需要更深度地控制模型能力、领域适配或训练流程时，可以进一步评估 Amazon Nova Forge 等模型定制方案。此时问题已经不再是简单的应用集成，而是模型工程项目，需要同时考虑数据规模、训练资源、评测体系、模型安全、上线运维和长期成本。
这一级别不应因为“自定义模型听起来更强”就直接采用。只有当前面各层方案都经过测量，并且业务收益能够覆盖复杂度时，才值得进入候选范围。
一个可以直接改造的 Bedrock 调用示例
下面的示例演示最轻量的起点：使用明确的系统指令调用 Amazon Bedrock Runtime。它不包含 RAG 和训练，适合先建立基线。
运行前准备：安装 boto3，配置 AWS 凭证，并确认目标模型在所在区域可用。将环境变量中的模型 ID 换成你实际有权限调用的模型。
python -m pip install boto3
export AWS_REGION=us-east-1
export BEDROCK_MODEL_ID="your-model-id"
python baseline.py
# baseline.py
import os
import boto3
region = os.getenv("AWS_REGION", "us-east-1")
model_id = os.environ["BEDROCK_MODEL_ID"]
client = boto3.client("bedrock-runtime", region_name=region)
response = client.converse(
modelId=model_id,
system=[
{
"text": (
"你是企业客服助手。只根据用户提供的信息回答；"
"不确定时明确说明，不要编造订单状态。"
)
}
],
messages=[
{
"role": "user",
"content": [
{"text": "订单 A-1001 当前是什么状态？"}
],
}
],
inferenceConfig={
"temperature": 0.2,
"maxTokens": 300,
},
)
print(response["output"]["message"]["content"][0]["text"])
这个基线有两个用途：一是验证调用链、权限和延迟；二是建立“没有知识库、没有微调时”的可比较结果。后续加入 RAG、工具调用或微调时，都应尽量保持评测集和业务指标不变。
什么时候该从提示词升级到 RAG
可以用一个简单判断：如果内容会频繁变化，就不要优先把它固化到模型里。
例如，客服机器人需要回答产品手册和退货政策，可以先把文档切分、建立向量索引，再将检索结果作为上下文传给模型。实际系统还需要处理文档权限、版本、引用、过期内容和检索失败。对于订单状态、库存和账单，通常应通过受控工具查询，而不是把数据库内容批量塞进提示词。
RAG 的主要代价是检索链路带来的延迟和系统复杂度。它也不是“接上向量数据库就完成了”：分块策略、召回数量、重排序、上下文长度和引用验证都会影响最终效果。
微调和持续预训练的边界
可以把两者粗略区分为：
| 方案 | 更适合解决的问题 | 主要代价 |
|---|---|---|
| 提示词工程 | 指令理解、格式、语气、少量示例 | 依赖上下文，复杂任务可能不稳定 |
| RAG/工具调用 | 企业知识、实时数据、外部系统操作 | 需要维护检索和工具链路 |
| 微调 | 稳定的任务行为、风格、分类或格式 | 数据准备、训练和版本管理成本 |
| 持续预训练 | 深度领域语言和知识分布适配 | 算力、数据治理和评测成本更高 |
| Amazon Nova Forge 等深度定制 | 更大范围的模型能力与训练控制 | 接近完整模型工程项目 |
这张表不是严格的技术边界。一个生产系统可能同时使用 RAG、工具调用和微调；真正的决策依据仍然是评测结果、运营成本和风险要求。
落地时的四条约束
用评测驱动升级
每次升级只改变一个主要变量，并记录准确率、引用正确率、拒答率、格式通过率、延迟和成本。否则很难知道收益来自哪里。
把知识和行为分开管理
频繁变化的事实放在检索或业务系统中；稳定的行为模式才考虑通过提示词或训练固化。这样更容易审计，也更容易更新。
训练数据先治理，再训练
去除个人敏感信息、重复样本和错误答案，记录数据来源和版本。训练数据质量差时，微调可能只是把错误更稳定地复制出来。
为升级保留退路
无论采用哪种定制方案，都应保留基础模型或上一版本作为回退路径，并通过灰度流量验证线上表现。自定义程度越高，回滚和运维的重要性越高。
结语：把定制当成可测量的升级阶梯
生成式 AI 定制不是“提示词还是训练”的二选一，而是一条从轻到重的工程路线。先定义失败样例，再用提示词建立基线；遇到实时知识问题，引入 RAG 或工具；换模型仍不够时，再评估微调；只有领域语言和模型能力本身需要改变，才进入持续预训练或 Amazon Nova Forge 等深度定制路径。
发布前可以快速检查：
- 是否有固定评测集和清晰失败定义？
- 是否先验证过提示词、RAG、工具调用和其他基础模型？
- 选择训练方案是为了解决行为问题，还是误把知识问题当成训练问题？
- 是否计算了数据、算力、延迟、维护和回滚成本？
- 是否有安全、权限、数据治理和线上灰度方案？
能用简单方案稳定解决的问题，不必训练模型；确实需要更深定制的问题，也应在数据和指标都准备好之后再投入。