简介这是一份围绕AWS机器学习专项认证MLS-C01整理的备考资料面向计划获取AWS认证的机器学习工程师、数据科学家及解决方案架构师。内容由三道典型真题展开先以移动运营商客户流失预测为背景拆解混淆矩阵中准确率、精准率、误报与漏报成本的计算逻辑说明为什么在业务代价不对等时86%准确率的模型仍可上线随后对比基于内容、基于用户、基于物品及混合过滤推荐的特点给出在Amazon EMR上利用Apache Spark ML构建协同过滤推荐引擎的完整思路最后结合“AWS认证”标签提示认证类别与备考方法。资源还整理了每题的正确选项、解析和社区投票分布能直观看到易错项和争议点便于针对性复习。压缩包内仅含1个PDF文件大小3.59MB可离线阅读或打印。目前已有123人浏览学习适合正在备考AWS机器学习专项认证、需要系统梳理模型评估与推荐系统核心考点的读者。1. 拿到这份 Machine Learning MLS-C01 真题集先别急着背答案考 AWS 机器学习专项认证MLS-C01的人大多不是倒在技术上而是倒在“题感”上服务太多选项太像一换场景就选错。这份 Machine Learning MLS-C01.pdf 整理的是社区流传的真题与讨论覆盖混淆矩阵、协同过滤、时间序列、SageMaker 数据管道和 VPC 数据安全等高频考点。它的价值不在标准答案而在帮你建立“看到题面 → 说出考点 → 排除错误服务”的反射。适合考前刷题验证的考生也适合想搞懂 SageMaker 选型边界的工程师。第一题就很有意思模型准确率只有 86%结论却是能上生产——因为成本权衡比准确率更关键。这种反直觉判断恰恰是考试和项目落地之间最大的坑。2. 混淆矩阵与成本权衡为什么 86% 准确率就能上生产题目 #1 是这份 PDF 里争议最大的一题也是 MLS-C01 里“模型评估”模块最典型的考法。场景是移动运营商要预测哪些客户会离网提前发激励挽留模型在 100 人的测试集上跑出 86% 准确率。题目问为什么这个模型可以上生产四个选项里两个讲准确率、两个讲精确率正确答案却不在精确率上。2.1 混淆矩阵四象限别让准确率骗了你先用最直白的方式过一遍混淆矩阵。二分类问题的预测结果可以落进四个格子预测为流失且实际真的流失真阳性 TP预测为流失但实际没流失假阳性 FP预测为不流失但实际流失了假阴性 FN预测为不流失且实际也没流失真阴性 TN。象限实际流失实际不流失预测流失TP挽留成功FP发错激励预测不流失FN漏网之鱼TN正常客户准确率的计算公式是 (TPTN) / (TPTNFPFN)这道题里等于 86/100。但准确率掩盖了两个重要问题FN 和 FP 的代价不一样默认 0.5 阈值下算出的准确率不等于业务上最优的准确率。提示考试里看到“模型准确率高是否适合上线”第一反应不应该是看数字大小而是看题目给了什么业务成本信息。没有成本信息的准确率只是一道算术题。我一般会用 sklearn 的 confusion_matrix 和 classification_report 把四个指标一次打全再做业务判断。from sklearn.metrics import confusion_matrix, classification_report y_true [churn] * 64 [stay] * 36 # 实际64 流失36 不流失 y_pred [churn] * 60 [stay] * 4 [churn] * 10 [stay] * 26 # 构造混淆矩阵TP60, FN4, FP10, TN26 cm confusion_matrix(y_true, y_pred, labels[churn, stay]) print(cm) print(classification_report(y_true, y_pred, labels[churn, stay]))代码逻辑说明y_true 和 y_pred 是两个列表我按“前 64 个真流失、后 36 个真不流失”构造预测结果让混淆矩阵刚好是 [[60,4],[10,26]]。classification_report 会直接给出 precision、recall、f1-score比手算省事。参数说明labels 参数必须把正负类顺序固定否则 sklearn 默认按字母排序churn 和 stay 的顺序一变后面看 TP/FN 就全反了。这个顺序问题我在实际项目里踩过不止一次。矩阵给出来后能算出几个关键数精确率 Precision TP/(TPFP) 60/70 ≈ 85.7%召回率 Recall TP/(TPFN) 60/64 93.75%F1 约 89.6%。召回率远高于精确率说明模型更“敢抓”代价是误报较多。对挽留场景来说多抓几个不流失的客户损失只是激励成本漏抓一个流失客户损失是整单收入。两者成本明显不对称。2.2 成本矩阵业务成本比准确率优先考试里遇到“是否上生产”这类题正确的分析姿势是把成本矩阵列出来再去定阈值。假设一个流失客户年均消费 500 元一次挽留激励成本 50 元那么预测结果实际流失实际不流失预测流失花 50 元激励保住 500 元净收益 450花 50 元激励客户本来就留净亏 50预测不流失客户流失公司损失 500 元无动作无损失在这个成本矩阵下FN 的单位成本是 FP 的 10 倍。所以评估模型好坏的标准不是准确率 86%而是总期望成本是否低于“什么都不做”的成本。什么都不做时所有流失客户都变成漏网总成本是 64 × 500 32000 元用上面那个阈值总期望成本是 FN×500 FP×50 4×500 10×50 2500 元。差一个数量级这才是它能上生产的理由。import numpy as np cm np.array([[60, 4], [10, 26]]) # 行实际, 列预测 cost np.array([[0, 500], [50, 0]]) # cost[实际][预测]FN500, FP50 total_cost np.sum(cm * cost) do_nothing_cost (cm[0,0] cm[0,1]) * 500 print(f当前模型总期望成本: {total_cost} 元) print(f什么都不做总成本: {do_nothing_cost} 元)逻辑说明cm * cost 是把每个格子的人数乘上对应成本四个格子相加得到该阈值下的总期望成本do_nothing_cost 把所有实际流失客户都当成漏网处理。参数说明500 和 50 是业务给的估算值不是模型输出的实际做的时候这两个数字应该来自财务或运营而不是拍脑袋。真正上线前还要做一件事把阈值从 0.5 往下调多抓 FP 少放 FN重新算总成本找一个成本最低的阈值。这段扫描阈值的代码不难写但思路才是考点。这里有一个容易被忽略的细节阈值调整是生产部署里的常规操作考试里很少直接考但面试一定会问。你可以用sklearn.metrics.precision_recall_curve或自己遍历 0.1 到 0.9对每个阈值算一遍总成本选最小的那个。不要默认用 0.50.5 只是“无成本假设下”的最优。2.3 真题 #1 为什么吵翻天官方答案和业务逻辑打架这道题 PDF 里标的是 A“模型 86% 准确且 FN 造成的成本小于 FP”。但你自己对照上面的成本矩阵算一下FN 是流失 500 元FP 是激励 50 元FN 明显大于 FP。所以按业务常理C 选项FP 成本小于 FN才是对的这也是社区投票里 C 拿到 59% 的原因。我的判断是这份 PDF 在整理时很可能把 A/C 两个选项的措辞弄反了或者原始题目本身就是一道争议题。备考时最稳妥的处理方式是记住“成本不对称”这个分析框架而不是背字母。从应试角度你复习资料标 A 就按 A 背从理解角度C 的业务逻辑更通。我会建议你把重心放在成本矩阵上而不是纠结该背 A 还是 C。这种“官方答案与业务逻辑矛盾”的情况在社区整理的题库里不罕见也是这类 PDF 最需要警惕的地方。这道题真正想传递的是准确率 86% 本身没有任何参考价值参考价值在于你有没有把成本矩阵想清楚。MLS-C01 的模型评估题几乎都围绕“指标怎么算、阈值怎么定、成本怎么权衡”三个点展开第一题刚好把三点全串起来了。3. 推荐引擎与时间序列选错服务就翻车MLS-C01 的推荐系统题型有个规律题目会给你“用户行为数据 用户相似度 某产品推荐”三个关键词正确答案几乎都是协同过滤。时间序列题型则相反考的是“为什么不能用异常检测或记忆型模型”。这一章把这两类高频题放在一起因为它们都在考“算法能力和业务目标的匹配”。3.1 协同过滤为什么是“买了又买”的标配题目 #2 的场景是公司有用户行为数据、产品偏好数据要预测用户根据“用户相似性”想买什么。四个选项分别是内容型、协同型、模型型、组合型过滤正确答案是 B协同过滤。先区分三个概念。内容型过滤Content-Based Filtering根据用户自己历史看过的商品特征推荐相似商品比如一个人常买科幻小说就推更多科幻小说问题是没有用户间对比推荐结果越来越窄。协同过滤Collaborative Filtering根据“其他相似用户的行为”推荐Amazon 当年经典的“买了 A 的人还买了 B”就是它。模型型过滤不是行业的稳定叫法一般指把矩阵分解、深度学习等方法套进推荐场景本质还是协同过滤的变体。混合过滤是前两者的组合。MLS-C01 不会让你手写推荐算法而是让你从题干里抓关键词“users similarity to other users”——用户相似性这是协同过滤的标志。实现层面题目要你选 AWS 上的落地途径正确答案是 Apache Spark ML on Amazon EMR而不是自己写 MapReduce也不是用 SageMaker 内置 kNN。from pyspark.ml.recommendation import ALS from pyspark.sql import SparkSession spark SparkSession.builder.appName(cf_rec).getOrCreate() ratings spark.read.csv( s3://bucket/ratings.csv, headerTrue, inferSchemaTrue ).select(user_id, product_id, rating) als ALS( maxIter10, regParam0.1, rank10, userColuser_id, itemColproduct_id, ratingColrating, coldStartStrategydrop ) model als.fit(ratings) users ratings.select(user_id).distinct() recommendations model.recommendForUserSubset(users, 5) recommendations.show(10, truncateFalse)逻辑说明ALS交替最小二乘是 Spark ML 里最常用的协同过滤实现它把 user-item 矩阵分解成两个低维隐因子矩阵再用隐因子向量点积预测打分。recommendForUserSubset 是标准的“为指定用户取 Top N 推荐”接口比先 predict 再排序省事得多。参数说明rank 是隐因子维度一般 8~15 起步太小学不到关系太大容易过拟合regParam 是正则化系数稀疏数据下可以调到 0.5 或 1coldStartStrategy 建议直接写 drop否则 ALS 遇到训练时没见过的新用户或新商品会预测出 NaN下游排序会崩。我在 EMR 上跑的时候除了看 RMSE还会对推荐列表做人工抽检光看 RMSE 低不代表推荐结果有人味。3.2 时间序列预测Linear Learner 才是“最不坏”的选择题目 #4 是城市要预测未来 2 天空气污染物浓度只有过去一年的日度数据问在 SageMaker 上用哪个算法“最可能给出最好结果”。正确答案是 CLinear Learnerpredictor_type 为 regressor。这道题很多人不服气都深度学习时代了为什么不用 LSTM原因在题干里写着——prototype 和 only daily data from the last year365 个点、单变量序列喂给 LSTM 只会学到噪声。四个选项的排除逻辑是这样的kNN 是记忆型模型它预测的本质是从历史里找最相似的邻居时间序列外推时它只会把答案逼近最近一天谈不上外推。Random Cut ForestRCF是异常检测算法用来找离群点拿它做预测属于题不对文。Linear Learner 是线性模型可以用 lag 特征把时间序列转成监督学习虽然表达能力有限但 365 个数据点下不会过拟合结果是四个选项里最稳的。from sagemaker import LinearLearner from sagemaker.serializers import CSVSerializer linear LinearLearner( rolerole, instance_count1, instance_typeml.c5.xlarge, predictor_typeregressor, mini_batch_size128, epochs30, learning_rate0.001, normalize_dataTrue ) linear.fit({train: train_s3_uri, validation: val_s3_uri}) predictor linear.deploy(initial_instance_count1, instance_typeml.c5.large) # 输入[昨天浓度, 前天浓度, 是否周末, 滞后7天浓度] result predictor.predict([[0.21, 0.18, 1.0, 0.22]], serializerCSVSerializer()) print(result)逻辑说明LinearLearner 是 SageMaker 内置的线性模型predictor_type 必须写成 regressor 而不是 classifier这是题目直接考的参数组合。把时间序列转成监督学习后训练输入特征是“昨天、前天的浓度 星期几 一周前同期浓度”输出是“今天的浓度”。参数说明mini_batch_size 控制每次迭代样本数小数据集建议 128 以下避免梯度震荡epochs 对 365 条数据 30 就够再大也只是过拟合normalize_dataTrue 让 SageMaker 自动归一化省去手动做特征缩放的步骤。真正做空气质量这类物理量预测我一般还会对比 DeepAR毕竟 DeepAR 是专门为时间序列设计的但考试里没有 DeepAR 这个选项Linear Learner 就是“最不坏”的答案。这道题真正的考点是“算法和能力边界”预测和异常检测是两回事外推和插值是两回事。MLS-C01 反复考这种边界因为 AWS 文档里算法列表太长了只会背名字的人一定挂。3.3 分类、聚类、强化学习别把题面看一半题目 #12 说公司要把客户按“未来 6 个月会不会流失”分组而且已有历史标签数据问用什么模型。四个选项跨了线性回归、分类、聚类、强化学习。正确答案是分类因为有标签、二分类、要预测类别。这道题看着简单但它考察的是“有没有看到 labeled data”这个关键词。没有标签就只能聚类有标签就必须往监督学习方向想。题目 #14 是二维平面上 fraud 和 normal 两类样本特征是账户年龄和交易月份要选最高准确率的模型。正确答案是 SVM with non-linear kernel因为从题目配图看两类样本非线性可分。排除项也很有意思LSTM 有记忆能力但不是为这种小表格数据设计的单层感知机是线性分类器逻辑回归也是线性的。这种题不存在练代码的部分训练的是审题速度。题目 #11 又回到推荐场景电商网站有用户人口统计、访问历史、位置信息要识别购物模式并做推荐四个选项给了 LDA、三层神经网络、协同过滤、RCF。正确答案是协同过滤。LDA 是文本主题模型适合文档集合不适合客户行为RCF 是异常检测三层随机初始化神经网络在这个场景里没有任何先验优势。这种题的经验是看到“用户行为 推荐”先别想深度学习优先考虑协同过滤除非题干明确给了用户画像特征。4. 数据管道与 SageMaker 训练从 CSV 到模型的全链路MLS-C01 不只考算法还考数据管道数据在 S3、Kinesis、RDS、Glue、Athena 之间怎么流转训练数据怎么喂给 SageMaker。这一章把 PDF 里三个最典型的管道题拆开每道题都对应一个 AWS 推荐路径。4.1 实时 CSV 转 ParquetAWS Glue 是最稳的“中间人”题目 #3 的场景是移动运营商要把实时产生的 CSV 数据落地到 S3数据工程团队想先转成 Parquet 再存问哪个方案工作量最小。四个选项分别是Kafka Streams on EC2、Kinesis Data Streams AWS Glue、Spark Structured Streaming on EMR、Kinesis Data Streams Kinesis Data Firehose。官方标 BKinesis Data Streams 接 AWS Glue 转 Parquet。为什么不是 Firehose社区里有 33% 的人选 D因为 Firehose 本身支持在 S3 输出时转成 Parquet/ORC看起来更省事。但注意题干前半句源系统是实时把 CSV 发到 Kinesis Data StreamsFirehose 虽然能把数据从 Data Streams 拉过来但转换这一步的 schema 得先在 Glue Data Catalog 里定义好严格说仍然要经过 Glue 那一层。AWS Glue 的方案能对 CSV 做 schema 校验、清洗、格式转换是一条更通用的 ETL 路径也是官方答案偏好。from awsglue.context import GlueContext from awsglue.job import Job from pyspark.context import SparkContext from pyspark.sql.functions import year, month sc SparkContext() glueContext GlueContext(sc) job Job(glueContext) source glueContext.create_dynamic_frame.from_options( connection_types3, connection_options{paths: [s3://data-lake/csv/]}, formatcsv, format_options{withHeader: True, separator: ,} ) partitioned source.toDF().withColumn(year, year(event_date)).withColumn(month, month(event_date)) sink glueContext.getSink( connection_types3, paths3://data-lake/parquet/, formatparquet, partitionKeys[year, month] ) sink.write(partitioned) job.commit()逻辑说明这段是 Glue Job 的标准写法create_dynamic_frame 把 S3 里的 CSV 读进来再通过 partitionKeys 按日期分区写回 Parquet。分区是关键没有分区的 Parquet 表Athena 全表扫描的代价几乎和 CSV 一样。参数说明withHeaderTrue 告诉解析器第一行是表头separator 指定分隔符partitionKeys 是 Glue 写 Sink 时的专用参数放在 connection_options 里不会生效。跑这个 Job 之前先拿一个小目录做冒烟测试确认字段类型推断正确否则 Glue 对“全是数字字符串”的列会推出 int后面 Athena 查询时再改类型就麻烦了。4.2 大数据训练File 模式 vs Pipe 模式题目 #9 是视频推荐模型训练数据几百万条、存在 S3SageMaker notebook 实例只有 5GB EBS不能把数据全加载进去。正确答案是先在 notebook 上用子集本地训练确认代码再起 SageMaker Training Job 用 Pipe 模式读 S3 全量数据。这道题踩的坑是“以为必须把数据放进实例”。File 模式和 Pipe 模式的区别File 模式是训练容器先从 S3 把数据下载到本地 EBS再开始训练大数据集会等很久而且 EBS 不够就失败Pipe 模式是训练容器直接从 S3 通过 Linux 管道流式读取边读边训练不占本地磁盘。对比项File 模式Pipe 模式数据加载先下载后训练边流式读取边训练本地磁盘占用全量占用几乎不占用启动延迟拷贝完才启动秒级开始适用数据量小到中等大到超大失败恢复重下全量重新流式读from sagemaker.estimator import Estimator est Estimator( image_uriaccount-id.dkr.ecr.region.amazonaws.com/my-training-image:latest, rolerole, instance_count4, instance_typeml.p3.2xlarge, input_modePipe, volume_size_gb30 ) est.fit({train: s3://bucket/video-recs/train, validation: s3://bucket/video-recs/val})逻辑说明input_modePipe 是关键参数它让 SageMaker 训练容器用 FIFO 命名管道消费 S3 数据而不是先拷到 EBS。volume_size_gb30 是给其他中间文件留的空间比如 checkpoint、临时排序结果。参数说明instance_count4 说明用的是分布式训练Pipe 模式下每个节点读自己那份 shard如果数据是 CSV 格式还要配 recordio 或 text/csv 的 ContentType否则管道解析会失败。这道题正确答案强调了两步本地小样本验证代码逻辑然后才上全量顺序反了就是浪费时间。我是每次都会把这个“小样本验证 全量训练”的流程固化下来纯属用钱买来的教训。4.3 RDS 里的历史数据别让 Notebook 直连业务库题目 #10 的场景小样本 POC 已经做完要用 RDSMicrosoft SQL Server里的历史数据做端到端训练问怎么开始。四个选项里直接连 SQL 数据库拉数据、把数据搬到 DynamoDB、搬到 ElastiCache 都被排除正确答案是用 AWS Data Pipeline 把数据从 SQL Server 推到 S3再在 SageMaker 里引用 S3 路径。这条路径背后的原则很简单训练数据最好落在 S3而不是让训练环境去连生产库。直接连库的问题有几个生产库的访问凭证要暴露给训练环境全量数据查询会拖垮业务库SageMaker 训练任务的生命周期短如果失败要重跑连库方案很难重放。搬到 DynamoDB 或 ElastiCache 属于“为了绕而绕”对批量训练帮助不大。SELECT customer_id, churn_label, age, monthly_charges, tenure, contract_type FROM dbo.customers WHERE churn_label IS NOT NULL AND signup_date DATEADD(year, -1, GETDATE());逻辑说明这是 SQL Server 侧的提取查询先把需要的列和 label 过滤出来而不是整表搬运。Data Pipeline 在题目语境里承担调度和重试真正的导出动作是跑完这条 SQL 后把结果写到 S3再交给 SageMaker。参数说明WHERE churn_label IS NOT NULL 用来丢掉无标签样本日期过滤条件按业务场景加减少训练数据量的同时也能控制数据时效性。落到 S3 后先用 Athena 跑一条 SELECT COUNT(*) 和几条分组统计确认数据没有诡异的 NULL 或乱码再丢给 SageMaker。别跳过这一步我在导出的数据上翻过车CSV 里带着 SQL Server 的 BOM 头训练脚本被坑了一天。管道题的共同点是“数据必须先到 S3再进训练”。MLS-C01 的管道题几乎都是这个套路只是换着方式考中间人是谁Glue、Data Pipeline、Firehose 都是中间人选型依据是“现有架构 最少工作量”。5. 避坑手册刷这套题最容易踩的五个坑社区整理的题目集有个通病答案和解释可能来自不同渠道甚至答案本身就有争议。我把这套 PDF 里最典型、也是考试真会考的坑整理成五条按“现象 → 原因 → 解决”写清楚。前三条集中在网络、存储和数据访问后两条在算法选型和训练配置。5.1 VPC、S3 与 Athena 的隐蔽陷阱第一条SageMaker notebook 实例在 VPC 里找不到对应的 EC2。现象你把 notebook 实例建在私有子网里却在 EC2 控制台搜不到任何实例EBS 卷也看不到怀疑自己建错了环境。原因SageMaker notebook 实例确实跑在 EC2 上但这个 EC2 在 AWS 服务账户里不在你的 AWS 账户和 VPC 里。控制台里的 Notebook instance 只是管理面底层计算资源对用户不可见。解决不要尝试从 VPC 里找实例需要备份数据时直接用 SageMaker 控制台的 Create image 或 EBS snapshot 功能需要访问 VPC 内的数据库或内网服务时为 notebook 配置 VPC interface endpoint而不是找 EC2。题目 #6 考的就是这个知识点选项 C 说明“它们跑在 AWS 服务账户内的 EC2 实例上”属于概念题。很多人栽在这道题上是因为平时习惯了 EC2 在账户里随处可见的直觉。第二条S3 里含 PII 的训练集配了 VPC endpoint结果公网照样能访问。现象你创建了 VPC endpoint自以为数据已经私有化了换一台普通电脑却能用公网地址直接读桶里的文件。原因VPC endpoint 只是给 VPC 内流量开了一条到 S3 的私有通路它本身不拒绝来自公网的请求。如果桶策略是默认的 Allow *那么公网照样可以访问。题目 #15 把 PII、VPC-only、不能走公网三个条件全摆出来就是要考这个组合。解决先通过 S3 控制台关闭桶的公共访问Block Public Access再给桶策略加上 aws:SourceVpce 条件限制只放行来自指定 VPC endpoint 的请求{ Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: *, Action: s3:GetObject, Resource: arn:aws:s3:::my-pii-bucket/*, Condition: { StringEquals: { aws:SourceVpce: vpce-12345678 } } } ] }逻辑说明这条策略的意思是“允许所有主体通过指定 VPC endpoint 读取桶内对象”配合桶的 Block Public Access公网请求就会在桶策略层被拒绝。参数说明aws:SourceVpce 的值要填实际 endpoint ID 而不是 VPC ID写错这个条件会直接导致私网也读不了数据。题目 #15 的正确答案就是这种组合很多第一次考 AWS 的人不知道 endpoint 和桶策略缺一不可。如果题目再叠加“加密”要求还要记得用 AWS KMS 做服务端加密并把 KMS key 的权限策略也限制到 VPC 内题目 #5 就是这条线。第三条Athena 直接查 S3 里的 CSV又慢又贵。现象同样的 SQL在 CSV 上跑要十秒转成 Parquet 后只要一秒看账单扫描量差好几倍。原因CSV 是行式存储Athena 查它需要全表扫描Parquet 是列式存储且有分区和 min/max 统计信息查询时可以只读需要的行组和列。解决先用 Glue Crawler 建立数据目录再通过 Glue Job 把 CSV 转成 Parquet 并按日期分区。之后在 Athena 里建分区表查询语句带上分区过滤条件。这不是考试专属操作是所有 S3 数据湖的日常流程。题目 #8 问“S3 上有结构和非结构化数据想用 SQL 查询最少工作量是什么”答案是 Glue 建目录 Athena 查询原因就是 Athena 依赖 Glue Data Catalog不建目录就得自己写表定义等于把所有解析工作都揽到自己身上。5.2 算法选型与训练配置的隐藏雷区第四条拿 kNN 做时间序列预测预测结果等于最近一天。现象训练完模型预测未来 2 天输出值和最近一天几乎一模一样图上看就是一条平移线。原因kNN 是记忆型模型它只会在历史样本里找相似邻居然后取均值或多数本质上做的是插值不是外推。时间序列预测要求模型推演趋势kNN 没有这个能力。Random Cut Forest 更不用谈它是异常检测算法压根不是干预测的。解决小样本单变量序列优先 Linear Learnerregressor或 DeepAR。题目 #4 的题干写得很清楚prototype last year daily data365 个点是典型的“小数据 线性模型够用”场景。如果你在实际项目里确实要用深度模型至少准备 3 年以上按小时采样的数据否则 LSTM 只会过拟合。我见过有人把 kNN 硬套在销售预测上结果今年 1 月的预测值直接等于去年 1 月的销量完全没考虑促销和增长这种模型上线等于摆设。第五条训练任务跑一半报磁盘满5GB EBS 瞬间用完。现象SageMaker 训练任务开始几分钟就报 No space left on device或者 notebook 本地复制数据中途失败。原因估计算法默认 File 模式训练容器先把 S3 数据全部下载到本地卷数据集超过 EBS 大小磁盘就被写满。5GB 的 notebook 实例更明显几百万条数据根本塞不下。解决大训练集改用 Pipe 模式input_modePipe让数据从 S3 流式进入训练容器如果模型代码依赖随机访问文件那就加大 Estimator 的 volume_size_gb。此外还有一个配套规范先在本地用千条样本验证代码和超参再切全量训练。题目 #9 的官方答案就是这条路径本地验证 全量 Pipe 训练。顺序不能反我是真见过有人直接拿全量跑代码崩了三次才发现是数据格式问题每次都要重下几十 GB时间和钱都搭进去了。还有一个变体用 File 模式小数据跑通后直接切大数据不换模式结局一样。换数据量之前先想想模式要不要换这步不花时间但能省下整个下午的排查。6. 真题集二刷法把选择题变成考点地图刷完一遍后这套 PDF 的价值不在“记住了答案”而在你能把每题拆成“考点 选型理由 边界条件”。我一般做三遍第一遍按顺序做边做边标注每个选项对应哪个 AWS 服务第二遍只看错题的解析回到 AWS 官方开发者指南查对应服务第三遍做时间压力测试按考试节奏过一遍。二刷时用一个错题表格比反复看解析管用题号我选的答案官方答案考点一句话教训#1CA存疑成本矩阵准确率不如成本权衡有说服力#4AC时间序列kNN 不能外推#9AAPipe 模式大数据别塞本地盘#15BAVPC endpointendpoint 要配桶策略才设防表格不是为了让你背答案而是让你在考前一眼看到“我的错题集中在哪个考点”。如果错题都在网络和数据访问类就别再刷算法题了去把 VPC endpoint 和 S3 权限这章文档读懂。说一个我的固定动作每次碰到代码块里的 API 参数我会顺手在 AWS 文档里查一遍它是不是考试当年的默认值。比如 LinearLearner 的 predictor_type、ALS 的 coldStartStrategy、Pipe 模式的 input_mode这些参数名本身就是考点。把参数和场景对上的过程比背十道题都值。这套题集我至少刷过三遍每一遍都会发现新的理解偏差第一遍以为第一题答案是 C 就完了第二遍才发现 A/C 的争议说明“成本矩阵”才是核心第三遍才意识到所有题都在考“AWS 服务边界”没有一题是纯算法推导。从那以后我每次做套题都强制自己写“考点 选型理由 一句话教训”考前只复盘这张表效果比翻原题好得多。希望帮到你。本文还有配套的精品资源点击获取