Amazon MLA-C01: 生成式 AI 与基础模型 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

属于 AWS Machine Learning Engineer Associate MLA-C01 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

核心概念

基础模型是大型的预训练网络——通常基于 Transformer——可提供通用的语言、视觉或多模态表示。实际的生产化需要通过三种独立的方法将这些广泛的能力转化为特定于应用的行为：推理时的提示工程、利用检索增强生成 (RAG) 将输出内容基于最新的或特定领域的知识，以及通过微调或参数高效技术进行模型定制。Amazon Bedrock 提供了一条托管路径，可通过统一的 API 调用第三方和 Amazon 提供的基础模型，在抽象化模型选择的同时，保留对输入、模型参数（temperature、top_p、max_output_tokens）和响应处理的控制。SageMaker JumpStart 通过打包预训练的模型工件、训练脚本和微调配方来对 Bedrock 进行补充，这些配方可在 SageMaker Training 或 Hugging Face 容器上运行，从而实现可复现的自适应工作流和模型注册表集成。

微调有多种类型，它们在计算和数据集需求与自适应的保真度之间进行权衡。全量微调会更新所有模型权重，通常能产生最高的特定任务性能，但需要大型 GPU 集群和用于存储检查点的空间。参数高效微调 (PEFT) 技术，如 LoRA（低秩适配器）、适配器模块或 QLoRA（量化低秩适配器），通过注入和训练少量额外参数，极大地减少了 GPU 内存和时间消耗，并与使用 Hugging Face 和 bitsandbytes 进行 8 位/4 位量化的 SageMaker 训练兼容。基于人类反馈的强化学习 (RLHF) 是一个更复杂的流程：收集成对的人类偏好标签，训练一个奖励模型（一个使用 SageMaker Training 和 ModelPackage 的监督学习步骤），并使用同策略强化学习（PPO 或类似算法）优化策略模型，同时将 rollout 和检查点存储在 S3 中，并使用 SageMaker Debugger 监控奖励信号。

RAG 架构将基础模型与最新的语料库连接起来，以减少幻觉。典型的 RAG 流程使用嵌入模型（Bedrock Embeddings API 或 SageMaker Hugging Face 嵌入器）来嵌入查询文本，在索引（带有 k-NN 的 Amazon OpenSearch Service、Amazon Kendra 或第三方向量数据库）中执行最近邻向量搜索，检索排名最前的 k 个文档，并通过提示模板和受控的解码参数，使用检索到的上下文来约束语言模型。管理新鲜度和相关性需要使用 AWS Glue 定期重新摄取和重新索引源数据，使用 AWS Lambda 进行流式更新，或使用 AWS DMS 处理事务性数据源，并将来源元数据（source_id、document_id、ingestion_time）与向量一同存储，以实现可审计性。

关键服务与配置

Amazon Bedrock 提供了 InvokeModel API，其请求中包含模型标识符和运行时参数：传递 modelId、contentType 和 accept 标头、包含提示或 inputText 的 body，以及模型参数如 temperature、topP 和 maxOutputTokens。使用结构化的系统和用户消息来分离基于角色的指令并约束输出格式；强制执行停止序列和 max_output_tokens 以限制延迟和成本。对于嵌入生成，使用 Bedrock 嵌入端点或 SageMaker Hugging Face 推理容器，并将向量持久化在 OpenSearch、Kendra 或外部向量数据库中。

SageMaker JumpStart 提供预构建的笔记本和微调管道，这些管道通过具体的 API 参数连接到 CreateTrainingJob：TrainingJobName、AlgorithmSpecification (TrainingImage, TrainingInputMode)、RoleArn、InputDataConfig (S3Uri, DataSource)、OutputDataConfig (S3OutputPath)、ResourceConfig (InstanceType, InstanceCount, VolumeSizeInGB) 和 StoppingCondition (MaxRuntimeInSeconds)。对于模型治理，使用 SageMaker Model Registry 和 CreateModelPackage/CreateModelPackageGroup，并将 ApprovalStatus 设置为 “PendingManualApproval”；通过将 ApprovalStatus 属性与 AWS CodePipeline 或 AWS Step Functions 以及一个 ManualApproval 操作结合使用来控制部署，从而将模型提升集成到 CI/CD 中。对于持续监控和偏差检测，通过带有 MonitoringScheduleConfig 和 BaselineConfig 的 CreateMonitoringSchedule 来部署 SageMaker Model Monitor；通过 ProcessingJob API（ClarifyProcessor.run_pre_training_bias 和 run_post_training_bias）使用 SageMaker Clarify 来计算数据集偏差指标并生成存储在 S3 中的基线。

对于向量搜索和 RAG，根据规模和查询延迟选择索引和搜索技术。Amazon OpenSearch Service 支持 k-NN 插件，并提供 REST API 和精细粒度的访问控制；Amazon Kendra 提供企业级语义搜索，并带有到 S3、SharePoint 和 RDS 的连接器。使用 AWS Glue 爬网程序构建一个中央数据目录，并使用 AWS Lake Formation 来强制执行对 S3 训练数据的精细粒度访问控制和隔离，确保应用了 IAM、存储桶策略和加密（SSE-S3 或 SSE-KMS）。

设计模式与权衡

在自定义基础模型时，需要在离线微调和运行时提示工程之间做出选择。全量微调可以最大化模型在特定任务上的性能，但会增加运维复杂性：训练任务需要大规模 GPU 集群、多节点分布式训练（在 Script Mode 中使用 SageMaker DistributedDataParallel 或 Horovod）、通过 UploadDirectory 将检查点保存到 S3，以及后续为实现高效推理而进行的量化和转换。像 LoRA 这样的 PEFT 方法会冻结大部分模型权重，从而显著减少训练时间，实现成本更低的超参数扫描，并简化回滚操作，因为基础模型保持不变。在推理方面，Bedrock 托管的端点减轻了第三方基础模型的运维负担，而 SageMaker 实时端点则提供了更深度的控制：使用 MultiModelEndpoints 从单个实例为多个模型提供服务，使用 Serverless Inference 应对不可预测的流量，或使用带有自动扩展和预置并发的预置端点来减少冷启动。

RAG 的复杂性在于保持索引的实时性以及在检索与幻觉之间取得平衡。一种简单的模式是混合检索：首先进行向量搜索（语义），然后使用关键词过滤器来确保精确度。存储文档块的元数据，以便生成步骤可以引用来源，并便于 Model Monitor 检查幻觉出现的频率。对于延迟敏感的应用，将嵌入计算和索引部署在同一位置（例如在同一个 VPC 中的 SageMaker 推理和 OpenSearch），并使用近似最近邻（ANN）索引，以牺牲召回率来换取速度。

RLHF 的实施成本高，但当需要与人类价值观或安全性对齐时，它又是必不可少的。该流程需要用于数据标注的工具、通过 SageMaker Estimator APIs 实现的可复现奖励模型训练，以及稳定的强化学习优化器（例如 RLlib 或 Stable Baselines 系列中的 PPO 实现）。必须权衡 RLHF 的成本和不稳定性，与其能够纠正无法被编码为静态损失函数的行为这一能力。

常见误区与决策标准

一个常见的错误是，完全依赖提示词来修复需要模型层面进行调整的系统性错误；提示词能提供帮助，但无法替代微调或 RAG 来进行领域知识注入。另一个误区是低估了治理的重要性：将生成式系统投入生产需要模型血缘（SageMaker Model Registry）、自动漂移检测（Model Monitor 基线和 Clarify）以及审批工作流（ApprovalStatus + CodePipeline 手动审批）。对于嵌入存储，选择一个没有元数据或来源信息的向量索引，会使日后的审计和错误分析成本高昂。

在决定模型托管方式时，需要在控制权与运营开销之间取得平衡。当您希望以托管方式访问多样化、高性能的基础模型，而无需管理推理集群时，请使用 Bedrock。当您需要自定义推理堆栈、VPC 隔离，或与 Model Registry 和 Model Monitor 完全集成时，请使用 SageMaker 端点。对于微调方法，当数据集规模适中且快速迭代至关重要时，选择 PEFT；当领域需要深度的表示层变更且您有足够的 GPU 预算时，选择全量微调。

实践问题：用例场景

公司名称：AuroraPayments — 挑战：部署一个低延迟、可审计的欺诈检测助手，该助手能综合交易上下文和政策文档来解释可疑分数，并支持受控的模型更新。

数据聚合与存储：使用 AWS Glue 爬取 S3 交易日志，并设置 AWS DMS 将本地 MySQL 表复制到 Amazon RDS 或 S3。在 AWS Glue Data Catalog 中注册所有数据源，并应用 Lake Formation 策略。理由：Glue 提供无服务器 ETL 和统一的目录供下游检索，而 Lake Formation 强制执行 S3 访问隔离。
特征工程与异常检测：将特征注入 SageMaker Feature Store 以保证离线/在线一致性。使用 Amazon Lookout for Metrics 对交易时间序列运行自动异常检测，并在 Amazon QuickSight 中呈现仪表板。理由：Feature Store 保证了用于训练和服务的特征的可复现性；Lookout for Metrics 自动化了异常检测，而 QuickSight 为业务分析师提供了可视化。
模型训练与不平衡处理：使用 SageMaker 内置的 XGBoost 训练一个 XGBoost 分类器，并配置超参数，将 scale_pos_weight 设置为 (num_negative/num_positive) 来纠正类别不平衡。使用 SageMaker Training CreateTrainingJob，其 ResourceConfig 根据训练规模进行调整，并启用 S3 检查点以实现容错。理由：XGBoost 对表格型欺诈任务非常有效；与合成过采样相比，scale_pos_weight 需要的运营开销最小。
模型注册、审批与部署：使用 CreateModelPackage/ModelPackageGroupName 将模型构件注册到 SageMaker Model Registry，并将 ApprovalStatus 设置为 “PendingManualApproval”。实现一个 CodePipeline，它会触发一个审批操作，然后将批准的版本部署到 SageMaker 实时端点，使用 MultiModel 端点或置于 Auto Scaling 后的 Provisioned Instances。理由：Model Registry 维护了中央版本控制和治理；通过 CodePipeline 进行手动审批强制执行了授权发布。
可解释性与用于策略依据的 RAG：使用 Bedrock 或 SageMaker Hugging Face embedder 创建策略文档的嵌入，将它们连同元数据一起索引到 Amazon OpenSearch k-NN 中，并实现一个 RAG 流程，其中针对可疑交易的提示词包含检索到的 top-k 策略片段，外加一个模板，指示基础模型引用来源并生成人类可读的解释。理由：RAG 将解释建立在权威文档的基础上，而 OpenSearch 在安全边界内提供了可扩展的向量搜索。
监控与再训练：启用 SageMaker Model Monitor，并使用初始验证阶段的基线，同时安排按需的 Clarify ProcessingJobs 来运行部署后的偏见检查。如果 Model Monitor 发出漂移信号（特征或标签的分布变化），则触发一个 SageMaker Pipeline，该 Pipeline 会运行数据摄取，如果使用基础模型编码器处理文本特征则使用 LoRA 微调进行再训练，评估模型，然后将新模型放入注册表并设置为 PendingManualApproval。理由：通过自动化管道进行持续监控，可以确保模型的性能和合规性，同时保留对生产变更的手动控制权。

← 安全性、治理与合规性 · 所有领域 · ML 工作负载的成本优化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →