机器学习

在 Amazon Bedrock 中使用 Claude - 从模型选择到提示词设计与成本优化

介绍 Amazon Bedrock 中可用的 Anthropic Claude 模型特性对比、按使用场景的模型选择指南、提示词设计最佳实践以及成本优化方法。

約 2 分で読めます

Bedrock 中可用的 Claude 模型对比

Amazon Bedrock 提供 Anthropic 的多个 Claude 模型，支持最大 200K token 的上下文窗口。Claude 3.5 Sonnet 在推理精度、处理速度和成本之间取得了最佳平衡，是大多数使用场景的首选。在代码生成、文档摘要、数据分析、多语言翻译等广泛任务中表现出色。Claude 3.5 Haiku 是速度最快、成本最低的模型，适合需要实时响应的聊天机器人或大量文本分类提取的批处理。其每百万输入 token 的价格约为 Sonnet 的 1/12，在大量数据处理管道中具有显著的成本优势。Claude 3 Opus 是精度最高的模型，用于复杂的多步推理、高级数学分析、专业法律文档或医疗文档撰写等精度优先的任务。由于 Opus 的 token 单价约为 Sonnet 的 5 倍，应仅限于精度直接影响结果的少量任务。

提示词设计最佳实践

要充分发挥 Claude 模型的性能，提示词设计至关重要。Bedrock 的 API 支持将系统提示词和用户提示词分开发送。系统提示词中描述模型的角色、输出格式和约束条件，用户提示词中描述具体的任务指令。这种分离可以一致地控制模型行为。指定 JSON 输出格式时，在系统提示词中包含 schema 示例可稳定获得结构化输出。处理长文本输入时，使用 XML 标签明确输入数据的结构，有助于 Claude 准确把握上下文。温度参数 (temperature) 在创意文本生成时设为 0.7 到 1.0，在基于事实的回答或代码生成时设为 0 到 0.3。包含 few-shot 示例时，将其放在系统提示词的固定位置，用户提示词仅包含每次变化的输入，以最大化提示词缓存效率。

成本优化与 Guardrails

Claude 模型的使用成本与输入和输出 token 数量成正比。成本优化的第一步是选择与任务需求匹配的模型。不要对所有请求都使用 Opus，而是对简单分类任务使用 Haiku，通用任务使用 Sonnet，仅在需要高精度的任务中使用 Opus。利用提示词缓存可减少重复发送相同系统提示词时的 token 成本。在需要稳定吞吐量的生产环境中，签约预置吞吐量可降低 token 单价并减少响应时间波动。Guardrails 功能可在 API 层面设置不当内容生成防止、个人信息 (PII) 自动检测和脱敏、特定话题拒绝回答等，省去应用端的过滤实现。 如需拓展机器学习知识，可参考Amazon 的专业书籍。

按使用场景的模型路由设计

在生产环境中，与其固定使用单一模型，不如根据请求特性动态切换模型，实现成本与质量的平衡。例如，聊天机器人可以用 Haiku 进行首次响应以实现即时回复，仅在用户提出专业问题时升级到 Sonnet。实现方式是在 Lambda 中对传入请求进行分类 (Haiku 本身可完成分类)，根据结果切换 InvokeModel 的目标。使用跨区域推理配置文件 (Cross-Region Inference Profile) 调用 Bedrock 模型，可在特定区域容量不足时自动回退到其他区域，提高可用性。使用 Converse API 只需更改模型 ID 即可切换模型，最大限度减少应用代码更改。

定价体系与限制注意事项

Bedrock 的 Claude 模型提供按需计费和预置吞吐量两种定价体系。按需计费仅按消耗的输入输出 token 数收费，无固定费用，但响应时间受负载影响。预置吞吐量 (1 个月或 6 个月合约) 预留模型单元，获得稳定的响应时间和折扣单价。使用大上下文窗口时，输入 token 成本可能远超响应生成成本，需特别注意。提示词缓存可减少会话内重复系统提示词部分的成本，但缓存命中有最小 token 数阈值要求。各区域可用的模型不同 (Opus 的可用区域有限)，在规划多区域策略时需提前确认模型访问权限。每个模型都有账户级别的 TPM (每分钟 token 数) 配额，大规模运营可能需要申请配额提升。

总结

在 Amazon Bedrock 中使用 Claude 模型需从模型选择、提示词设计和成本优化三个维度考虑。通用任务用 Sonnet，高速处理用 Haiku，高精度任务用 Opus，通过系统提示词与用户提示词的分离稳定输出质量。生产环境中根据请求特性进行动态路由以平衡成本与质量，通过预置吞吐量和提示词缓存实现可预测的成本结构。通过 Guardrails 确保安全性，同时考虑区域限制和 TPM 配额的设计，构建可扩展的生成式 AI 应用。

相关服务

Amazon Bedrock通过 API 使用主流基础模型的全托管生成式 AI 服务Amazon SageMaker覆盖机器学习全生命周期的综合平台AWS Lambda无需管理服务器即可运行代码的无服务器计算服务

相关文章

使用 Amazon Bedrock Knowledge Bases 构建 RAG 应用 - 检索增强生成的实现自动索引 S3 上的文档，通过 RetrieveAndGenerate API 整合检索与生成。介绍分块策略的选择以及通过 Guardrails 确保安全性的方法。用 Amazon SageMaker 构建 ML 平台 - 从模型构建到部署介绍从 Studio 开发到托管 Spot 训练、Pipelines 实现 MLOps、Model Monitor 数据漂移检测，整合 ML 全生命周期的方法。使用 AWS Lambda 开始无服务器开发 - 函数设计与事件源活用解析 Lambda 的函数设计、事件源映射、冷启动对策、Powertools 的活用。

本主题的更多内容

使用 AWS Batch 执行基于 GPU 的机器学习训练 - 高性价比的大规模训练方案利用现有 Docker 容器执行 GPU 训练，通过 Spot 实例与检查点机制将成本最高降低 90%。同时介绍与 SageMaker 的使用场景区分。使用 Amazon Bedrock Knowledge Bases 构建 RAG 应用 - 检索增强生成的实现自动索引 S3 上的文档，通过 RetrieveAndGenerate API 整合检索与生成。介绍分块策略的选择以及通过 Guardrails 确保安全性的方法。使用 Amazon Braket 入门量子计算 - 量子电路的设计与模拟在本地模拟器上免费进行原型开发，在 IonQ、Rigetti 的真实硬件上执行量子电路。介绍通过混合作业实现 VQE 和 QAOA 的方法。AWS Clean Rooms ML 隐私保护型机器学习 - 无需共享数据即可构建模型详细介绍通过 Clean Rooms ML 构建相似人群模型、应用差分隐私以及在广告定向投放中的实际应用。使用 Amazon Comprehend 实现自然语言处理 - 情感分析与实体提取的活用详解 Comprehend 的情感分析、实体提取以及自定义分类模型的构建。对话式机器人构建 - 使用 Amazon Lex 和 Polly 实现自然的会话界面详解使用 Amazon Lex 和 Amazon Polly 构建对话式机器人的方法。文档文本提取 - 通过 Amazon Textract 和 Comprehend 实现智能文档处理解说通过 Amazon Textract 从文档中自动提取文本、表格和表单数据，以及与 Comprehend 联动实现的自然语言处理集成。介绍从发票处理到合同分析的实践用例。边缘计算机视觉 - 使用 AWS Panorama 在现场对摄像头视频进行 AI 分析将计算机视觉模型部署到 Panorama 设备，实时分析现有 IP 摄像头视频。解析边缘推理降低延迟和节省带宽的设计模式。

相似的文章与服务

Amazon Bedrock通过 API 使用多个大语言模型的全托管服务，支持基于自有数据的定制和护栏配置生成式 AI 平台 - 通过 Amazon Bedrock 构建企业级 AI 基础设施介绍利用 Amazon Bedrock 构建生成式 AI 应用程序的方法，包括基础模型选择、RAG 模式实现、通过 Guardrails 确保安全性以及与 SageMaker 的集成等企业级 AI 基础设施设计。Amazon Bedrock Guardrails控制生成式 AI 应用程序输入输出的安全机制，执行有害内容过滤和个人信息脱敏使用 Amazon Comprehend 实现自然语言处理 - 情感分析与实体提取的活用详解 Comprehend 的情感分析、实体提取以及自定义分类模型的构建。