假如你是一档美食真人秀《王者厨房》的总评委。本期要从两位主厨中选出一位担任年度餐厅主厨：小红手脚麻利，20 分钟就能端出一桌菜；老张慢工出细活，磨蹭一小时才上菜。你会怎么公平地判断谁更强？只看菜好不好吃吗？小红 20 分钟出的菜和老张 1 小时出的菜，背后消耗的食材、灶台、人工成本完全不同。这正是 AutoML（自动机器学习）评估要回答的问题：我们选择一个自动机器学习框架时，不能只盯着模型准确率，还要比搜索效率、算资源消耗，并且用同一套基准数据和公平的规则来比赛，最后还要保证结果可以被任何人复现。本文就像一本评委手册，带你从性能、效率、资源三个维度，学会科学地给 AutoML 系统打分。

岗位关联

学会这套评估方法，是数据科学家正确选型 AutoML 平台、向业务方证明方案可信度的基本功——不学会评估，再好的调参功夫也只是盲人摸象。

目录
  1. 可视化演示
  2. 评估维度总览：三张成绩单
  3. 模型性能评估：菜好不好吃
  4. 搜索效率评估：出菜快不快
  5. 资源消耗度量：厨房账单
  6. 基准数据集：同一间厨房
  7. 对比方法设计：裁判手册
  8. 可重复性保障：能复制的菜谱
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示不同事务隔离级别下，两个并发事务T1与T2的读写交互过程，直观呈现脏读、不可重复读和幻读问题。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.dirty+'

评估维度总览：三张成绩单

评委走进《王者厨房》演播厅，桌上摆着三张表单：第一张是菜品评分表，记录每道菜的色香味——这是模型性能；第二张是计时员的上菜记录，看谁先端出拿手菜——这是搜索效率；第三张是财务的采购与水电账单——这是资源消耗。三张表缺一不可：一道菜再好吃，若花了三天三夜、烧掉半间厨房，谁家也请不起这位主厨。

AutoML 框架就像候选主厨：它自动在数据上搜索网络结构、超参数等“配方”，最终端出一份模型。要科学地评估它，必须同时回答三个问题：模型质量高不高（性能）、找到好模型快不快（效率）、整个过程烧了多少算力（资源）。

模型性能通常用准确率、F1 等指标衡量；搜索效率关注达到目标精度所需的采样次数与单轮耗时；资源消耗则统计峰值显存、计算成本与能耗。三者常常互相牵制：搜索时间越长精度往往越高，资源越充裕效率越高，所以业界常用加权综合得分来量化这种权衡。

评委把三张表钉在一起看，才敢下结论：没有绝对最强的框架，只有最适合你厨房的框架。接下来几节，我们就逐一细看这三张表该怎么填、怎么比。

S=λ1×Perf+λ2×1Tsearch+λ3×1Ccost\displaystyle S = \lambda_1 \times \text{Perf} + \lambda_2 \times \frac{1}{T_{\text{search}}} + \lambda_3 \times \frac{1}{C_{\text{cost}}}
综合得分 = 味道分 × 权重 + 速度倒数 × 权重 + 成本倒数 × 权重。你的业务更看重哪个维度，就把它的权重调大。
  1. 性能项λ₁ 是业务对精度的重视程度，Perf 是模型在验证集上的性能表现。
    λ1×Perf\displaystyle \lambda_1 \times \text{Perf}
  2. 效率项T_search 是搜索总耗时，时间越短这一项得分越高，所以取倒数。
    λ2×1Tsearch\displaystyle \lambda_2 \times \frac{1}{T_{\text{search}}}
  3. 资源项C_cost 是总成本，成本越低越好，故同样取倒数。
    λ3×1Ccost\displaystyle \lambda_3 \times \frac{1}{C_{\text{cost}}}

模型性能评估：菜好不好吃

试菜环节最激动人心。评委夹起一块红烧肉，嚼了嚼，在评分卡上打了个钩。总共试了 100 道菜，做对 85 道，得分就是 85 分——这就是准确率。它是最直观的“味道分”。

在机器学习里，模型对样本的预测有四种结果：正例预测对（TP）、负例预测对（TN）、正例被漏掉（FN）、负例被误报（FP）。准确率就是所有预测中做对的比例。它简单，但有一个陷阱：当“好吃的菜”和“难吃的菜”比例严重失衡时（比如 990 道素菜只配 10 道肉菜），厨师只会做素菜也能拿到 99 分。这时要用 F1 分数来综合精确率（端出来的菜里真正好吃的比例）和召回率（真正好吃的菜被端上来的比例），给偏科的主厨扣分。此外还有 AUC 曲线等指标，而所有指标最终都要在没被“偷看”过的测试集上计算，才能代表模型的泛化能力。

准确率只是第一道关。老张的菜得了 90 分，但用了一小时；下一节，我们看看计时员的记录如何改变评委的判断。

Accuracy=TP+TNTP+TN+FP+FN\displaystyle \text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN}
把 100 道菜的“做对/做错”画成四格盘子，准确率就是做对的豆子占整盘豆子的比例。
  1. 分子 TP + TN预测正确的样本总数，既包括正例猜对，也包括负例猜对。
    TP+TN\displaystyle TP + TN
  2. 分母四项之和数据集中全部样本的数量，无论猜对猜错都要算进去。
    TP+TN+FP+FN\displaystyle TP + TN + FP + FN
  3. 取比值用正确的数量除以全部数量，得到 0 到 1 之间的比例，乘以 100 就是百分制分数。
    正确数总样本数\displaystyle \frac{\text{正确数}}{\text{总样本数}}

搜索效率评估：出菜快不快

计时员老李有两个本子：一个记每道菜的平均上菜时间，一个记餐厅试到第几道菜才出现第一道拿手菜。他还画了一条“烹饪时间 vs 菜品得分”的曲线，看分数怎么从 60 分慢慢爬到 90 分——这条曲线就是收敛轨迹，它揭示了主厨的进步节奏。

AutoML 搜索过程也完全一样：框架反复采样超参数组合、训练候选模型，性能随时间上升。搜索效率的常用指标包括：平均单轮评估耗时（ATE），衡量每尝试一个配置要花多久；达到目标精度所需的采样次数，衡量搜索策略的“运气”与“智慧”；以及整条收敛曲线的形状——更快爬升、更早稳定的框架，说明它的搜索策略更高效。

快搜餐厅 20 分钟到 85 分就不动了，精搜餐厅 40 分钟才到 85 分，但继续涨到 92 分。只看终点觉得老张完胜，可如果你的预算只够等 30 分钟——效率指标瞬间变成决定性的一张表。

ATE=TtotalNtrials\displaystyle \text{ATE} = \frac{T_{\text{total}}}{N_{\text{trials}}}
平均每道菜耗时 = 后厨总时间 ÷ 出的菜数。数值低，说明这个框架每一轮评估都很轻快。
  1. T_total 总时间从搜索开始到结束的墙钟时间，包括训练模型与评估模型的全部时间。
    Ttotal\displaystyle T_{\text{total}}
  2. N_trials 搜索轮数框架尝试过的超参数组合数量，也就是采样次数。
    Ntrials\displaystyle N_{\text{trials}}
  3. 取比值总时间除以轮数，得到平均评估一个配置所需的时间，是衡量单步开销的核心指标。
    TtotalNtrials\displaystyle \frac{T_{\text{total}}}{N_{\text{trials}}}

资源消耗度量：厨房账单

会计算账了：租这么大的厨房要钱（显存占用），占着炉灶不放要钱（计算成本），水电燃气哗哗流也要钱（能耗开销）。即使菜再好吃、上菜再快，如果账单超预算，老板照样不买账。

资源消耗度量衡量 AutoML 搜索过程对硬件资源的占用。峰值显存决定你的 GPU 能不能装下任务，总计算时长决定排队要等多久、云账单有多高，能耗则关乎电费与碳排放。现实中有不少框架在小数据上表现惊艳，一上生产环境的资源预算就当场崩溃，所以资源是评估里隐藏的“一票否决项”。

资源是评估中的“隐藏关卡”。很多框架在同样的云预算下跑出的效果天差地别，因为账单上写的是算力而不是准确率。看完账单，下一节我们让所有参赛选手进同一间厨房。

Cost=a×TGPU+b×TCPU\displaystyle \text{Cost} = a \times T_{\text{GPU}} + b \times T_{\text{CPU}}
账单 = GPU 每小时单价 × GPU 使用小时数 + CPU 每小时单价 × CPU 使用小时数。a 和 b 就是两种资源的单价。
  1. GPU 费用项T_GPU 是 GPU 被占用的总时长，乘以单价 a 得到 GPU 开销。
    a×TGPU\displaystyle a \times T_{\text{GPU}}
  2. CPU 费用项T_CPU 是 CPU 辅助计算的总时长，乘以单价 b 得到 CPU 开销。
    b×TCPU\displaystyle b \times T_{\text{CPU}}
  3. 总成本两部分相加就是本次 AutoML 搜索的云账单。
    Cost=aTGPU+bTCPU\displaystyle \text{Cost} = aT_{\text{GPU}} + bT_{\text{CPU}}

基准数据集：同一间厨房

比赛组委会宣布规则：不许自带厨房和食材。所有人使用统一的中央厨房、同一批采购清单——这就是公共基准数据集；并且训练、验证、测试三次取菜要用固定比例切分。否则小红说粤菜跑得快、老张说川菜跑得慢，争论永远没有尽头。

基准数据集是评估 AutoML 的“场地统一标准”。常用的公共数据集（如 CIFAR、ImageNet 子集、各类表格数据基准）让不同论文、不同框架能在同一批数据上较量。关键在于一致的划分协议：训练集用来训练，验证集用来早停和选超参数，测试集只许在最后碰一次。同时，要用图像、文本、表格等多任务考察框架的普适性——一道拿手菜不能证明全能主厨。

数据泄漏是基准评估最大的坑：如果测试集被提前用于调参，相当于把评委的味觉偏好泄露给主厨，成绩单会虚高，换一间厨房立刻露馅。场地一致了，裁判的判罚规则公平吗？下一节看裁判手册。

D=Dtrain∪Dvalid∪Dtest\displaystyle D = D_{\text{train}} \cup D_{\text{valid}} \cup D_{\text{test}}
数据这一块大蛋糕，必须按规矩切成三等份，每份各司其职，绝不能混着吃。
  1. 训练集主厨平时练习做菜的原料，模型在这里学习参数。
    Dtrain\displaystyle D_{\text{train}}
  2. 验证集试菜调整火候的原料，用于选择超参数和早停。
    Dvalid\displaystyle D_{\text{valid}}
  3. 测试集正式比赛打分的原料，只在最后使用一次，保证分数真实。
    Dtest\displaystyle D_{\text{test}}

对比方法设计：裁判手册

比赛进入正赛，裁判要确保三件事：每位主厨拿到相同的食材配额（相同搜索预算）、使用相同的炉灶（相同硬件）、拥有相同的比赛时间（相同轮数）。还要请一位“及格线厨师”——随机搜索——当基线，防止所有选手都太菜还互相吹捧。

在科研与工业选型中，对比 AutoML 框架需要三件套：一是基线选择，随机搜索和网格搜索是最低门槛，框架必须赢过它们才算有价值；二是公平配置，预算、数据划分、硬件三者必须一致，否则就是不同赛道比百米成绩；三是统计检验，单次胜负可能是运气，在多个数据集上 8:2 的总比分要经过显著性检验才算数。

裁判手册写完了：公平配置、基线对照、统计检验，赛果才能服众。但还有一个灵魂问题：换一位评委、换一个后厨，这场比赛的结果还能复现吗？

t=dˉsd/n\displaystyle t = \frac{\bar{d}}{s_d / \sqrt{n}}
把两位主厨在 n 个数据集上的得分差取平均，再除以这些差值的波动，得到的 t 值越大，说明领先越不可能是运气。
  1. 平均差异 d̄每个数据集上框架 A 减去框架 B 的得分差，再对这些差求平均。
    dˉ\displaystyle \bar{d}
  2. 波动 s_d这些差值的标准差，衡量胜负在不同数据集上的稳定性。
    sd\displaystyle s_d
  3. 样本量根号数据集个数开方，数据越多，证据越硬。
    n\displaystyle \sqrt{n}
  4. 信号噪声比平均优势除以波动，比值越大，越说明是真实力而非偶然。
    dˉsd/n\displaystyle \frac{\bar{d}}{s_d / \sqrt{n}}

可重复性保障：能复制的菜谱

节目最后，组委会要求每位主厨交出完整菜谱：第几步放几克盐、用什么锅、什么火候。如果照着菜谱在别处做不出同样的菜，那 95 分就只是舞台上的魔术，没有任何迁移价值。

AutoML 实验可重复性有三要素：固定随机种子，让数据采样、初始化、搜索过程都受同一种子控制；固定运行环境，锁定框架版本、CUDA 版本、依赖库版本；完整记录与开源，把搜索日志、配置、代码全部公开。实践中还会用多种子多次运行，报告均值与标准差，避免单次运行的偶然性——这就像同一个菜谱做十遍，记录平均得分和稳定程度。

到这里，评委完成了从口味到速度、从账单到菜谱的全方位考核。有了这本手册，下一届大赛的规则会越来越严谨，选出的“年度餐厅”也才真正经得起市场检验。

μˉ=1K∑k=1Kμk,σ=1K−1∑k=1K(μk−μˉ)2\displaystyle \bar{\mu} = \frac{1}{K} \sum_{k=1}^{K} \mu_k, \qquad \sigma = \sqrt{\frac{1}{K-1} \sum_{k=1}^{K} (\mu_k - \bar{\mu})^2}
同一个菜谱做 K 遍，把 K 次得分取平均得到 μ̄，再算它们之间的波动 σ。平均分越高且波动越小，这门手艺越稳。
  1. 单次运行得分第 k 次运行得到的模型性能，比如多次搜索中某一次的最高准确率。
    μk\displaystyle \mu_k
  2. 平均得分K 次运行的平均，代表这个框架的期望水平。
    μˉ=1K∑k=1Kμk\displaystyle \bar{\mu} = \frac{1}{K} \sum_{k=1}^{K} \mu_k
  3. 标准差衡量不同种子下结果的波动，波动小说明结果稳定、可信。
    σ=1K−1∑k=1K(μk−μˉ)2\displaystyle \sigma = \sqrt{\frac{1}{K-1} \sum_{k=1}^{K} (\mu_k - \bar{\mu})^2}

AI 应用场景

数据团队选型 AutoML 平台

阶段：模型开发与框架选型阶段

解决的问题：传统上团队靠试用时的“第一印象”或行业小道消息选框架，容易选出性能好看但部署时资源爆炸的方案。用本文的三张成绩单方法，在统一基准数据集和固定硬件上对候选框架做多轮搜索，同时记录性能、耗时、显存与能耗，再按业务权重加权决策。

具体案例：某金融公司要在 CPU 上做每日批量建模，测试了两个 AutoML 框架与原有手工管道。团队使用相同的数据切分与搜索预算，测得框架 A 精度最高但强依赖 GPU，框架 B 精度仅低 0.2% 但 CPU 即可运行——最终选择 B，云账单节省约 60%。

社区基准榜单与论文复现

阶段：研究评估与发布阶段

解决的问题：论文里各说各话、复现困难是 AutoML 社区的长期痛点。用基准数据集与统一评估协议建设开放榜单，让所有框架在同一起跑线上竞争。

具体案例：OpenML 上的 AutoML Benchmark 提供标准数据集族与统一时间预算，任何研究者提交容器化框架即可上榜，后续贡献者能直接对照榜单改进算法，社区因此形成了“可复现的进步”。

模型上线前的部署评估

阶段：模型部署与运维阶段

解决的问题：AutoML 搜索出的模型要真正上线，必须评估推理阶段的资源消耗，而不只是训练阶段。用资源消耗度量的思路对最终模型做压测，决定上云还是端侧部署。

具体案例：某手机 APP 团队从 AutoML 搜索出的候选模型池里，用“准确率—显存—延迟”三维对比筛选，淘汰了显存超标的云端大模型，选出在手机端能实时运行的最高精度模型，投诉率下降 35%。

Python 演示

python57 行
"""Simulate evaluating two AutoML frameworks on three dimensions."""import random SIM_SPEED = 50.0  # virtual trials per simulated second  def evaluate_framework(name, n_trials, ceiling, seed):    """Run a simulated hyperparameter search and return the report dict."""    rng = random.Random(seed)    best_acc = 0.0    history = []    for i in range(n_trials):        # each trial samples 20 candidate configurations, keep the best        for _ in range(20):            cand = ceiling * (0.96 + 0.04 * rng.random())            if cand > best_acc:                best_acc = cand        history.append(best_acc)    time_sec = round(n_trials / SIM_SPEED, 2)    memory_mb = 180 + n_trials * 8    return {        "name": name,        "best_acc": round(best_acc, 3),        "n_trials": n_trials,        "time_sec": time_sec,        "memory_mb": memory_mb,        "history": history,    }  def main():    reports = [        evaluate_framework("QuickAuto", n_trials=30, ceiling=0.88, seed=7),        evaluate_framework("ThoroughML", n_trials=90, ceiling=0.90, seed=11),    ]    header = "framework   best_acc  trials  time_sec  memory_mb"    print(header)    print("-" * len(header))    for r in reports:        print("%-11s %.3f  %6d  %8.2f  %9d"              % (r["name"], r["best_acc"], r["n_trials"],                 r["time_sec"], r["memory_mb"]))    print()    # efficiency: best accuracy gained per simulated second    for r in reports:        eff = round(r["best_acc"] / r["time_sec"], 3)        print("%s efficiency (acc/sec): %s" % (r["name"], eff))    # conclusion: different dimensions give different winners    fast = min(reports, key=lambda x: x["memory_mb"])    accurate = max(reports, key=lambda x: x["best_acc"])    print("Higher accuracy: %s, lower cost: %s"          % (accurate["name"], fast["name"]))    print("Moral: pick by weighted score, not accuracy alone.")  if __name__ == "__main__":    main()
目的：模拟两个 AutoML 框架在相同“厨房”里的搜索比赛，输出性能、效率、资源三张成绩单，演示为什么只看准确率会选错框架。
  1. def evaluate_framework(name, n_trials, ceiling, seed):定义一次模拟考核：框架名、搜索轮数、性能天花板和随机种子是四张入场券。
  2. cand = ceiling * (0.96 + 0.04 * rng.random())每次采样一个候选模型，准确率在天花板的 96%~100% 之间随机浮动。
  3. if cand > best_acc:只记住当前最好成绩，模拟 AutoML 搜索中“精英保留”的更新逻辑。
  4. history.append(best_acc)记录每轮后的最优精度，相当于记录收敛轨迹，画出来就是一条上升曲线。
  5. time_sec = round(n_trials / SIM_SPEED, 2)用虚拟速度换算搜索耗时，保证演示结果稳定可复现。
  6. eff = round(r["best_acc"] / r["time_sec"], 3)效率指标：每秒获得的准确率，时间越短越高效。
  7. print("Moral: pick by weighted score, not accuracy alone.")点题：选框架要看三张成绩单的加权总分，而不是准确率一锤定音。

常见误区

误区“我选 AutoML 框架从来只看最终准确率，哪个最高就用哪个，其他指标都是虚的。”

正解准确率只是“味道分”。一个框架要跑三天、烧掉八张显卡，才换回 0.5% 的提升，在生产环境中根本不可用。要像评委一样同时看速度（搜索效率）和账单（资源消耗），把三个维度按业务权重加权后再决策。

为何常见：排行榜默认把准确率放在第一列，人的注意力天然被第一列吸引，于是形成了“性能唯一论”。

误区“只要我用同一个框架跑两个数据集，结果就能直接和别人的论文对比。”

正解数据划分、预处理、验证集早停策略不同，跑出来的分数没有可比性。必须使用相同的数据划分（训练/验证/测试）和相同的评估次数限制，否则就像在不同长度的赛道上比百米成绩。

为何常见：论文附表通常只写“在某数据集上达到某精度”，读者很容易忽略划分与预处理细节的差异。

误区“我在代码里设了 `random.seed(42)`，别人照着跑一定能得到一模一样的数字。”

正解随机种子只是“盐罐子固定了”。框架版本、CUDA 版本、GPU 型号、数据读取顺序，甚至浮点运算次序都会影响结果。要真正可复现，还需要记录环境、固定依赖版本并开源代码，最好多种子多次运行报告均值与标准差。

为何常见：教程总把 seed 和“可复现”绑在一起讲，让人误以为一个种子就能锁死全部随机性。

误区“框架耗时最短，就说明它最省资源，选它准没错。”

正解时间只是资源账单的一行。峰值显存决定 GPU 能不能装下任务，能耗决定电费与碳排放，推理阶段的延迟与内存还影响线上部署。云端计费公式里，GPU 时数与显存规格往往是分开算的。

为何常见：程序跑完后大家最直观的感受是“用了多长时间”，看不见的显存与能耗自然容易被忽略。

误区“框架 A 在 CIFAR-10 上比框架 B 高 2 个点，所以 A 全面碾压 B。”

正解单个数据集上的胜负可能是运气。要在图像、文本、表格等多个任务上重复实验，并做配对检验判断 8:2 的总比分是否显著。就像一道拿手菜不能证明全能主厨，厨艺大赛要多轮多菜品综合评分。

为何常见：单数据集实验成本低、周期短，研究者习惯于用最顺手的数据集快速验证想法，忽略了统计代表性。

面试题

Q1. AutoML 评估中最常用的模型性能指标是？

单选题 · easy

  • A.训练总时长
  • B.识别准确率← 正确答案
  • C.显存占用值
  • D.代码行数量

答案：B。准确率是最直观的“味道分”，衡量预测做对的比例。训练时长属于搜索效率维度，显存占用属于资源消耗维度，代码行数更是与性能无关，故选 B。

Q2. 类别严重不平衡的分类任务更适合看哪个指标？

单选题 · mid

  • A.准确率只有参考价值
  • B.F1 分数综合更可靠← 正确答案
  • C.推理延迟越低越好
  • D.参数量小便于部署

答案：B。当正负样本比例悬殊时，厨师只会做“多数派”的菜也能拿高准确率。F1 分数综合了精确率与召回率，能惩罚这种偏科，像评委既看端上来的菜对不对，又看没端上来的好菜漏了多少，故选 B。

Q3. 评估 AutoML 搜索效率时应该关注哪些信息？

多选题 · mid

  • A.达到目标精度的轮数← 正确答案
  • B.每一轮搜索的耗时← 正确答案
  • C.论文作者所在机构
  • D.收敛曲线的形状← 正确答案

答案：ABD。搜索效率看的是达到目标精度需要多少次采样（轮数）、平均每轮耗时，以及整条收敛曲线是否快速爬升。作者机构与算法效率无关，如同不会因为主厨师出名门就认定他出菜快。

Q4. 基准数据集在 AutoML 评估中的核心作用是？

单选题 · mid

  • A.让各框架同场竞技← 正确答案
  • B.让模型自动变强
  • C.减少搜索计算量
  • D.替代人工调参

答案：A。基准数据集提供统一的“中央厨房与食材清单”，让不同框架在同一批数据、同一套划分下比赛，结果才可对比。它不会自动提升模型、减少计算或替代调参，故选 A。

Q5. 框架 A 在 10 个数据集上 8 胜 2 负，如何科学下结论？

单选题 · hard

  • A.直接宣布 A 全面取胜
  • B.做配对检验再下结论← 正确答案
  • C.再跑一次取最好结果
  • D.换成更大的模型复验

答案：B。8:2 的比分可能来自运气，需要配对 t 检验计算平均差异与波动，判断优势是否显著。直接宣布、取最好结果或换模型都不能排除偶然性，就像不能因为主厨某几道菜超常发挥就认定他稳赢。

Q6. 下列哪些措施能提升 AutoML 实验可重复性？

多选题 · hard

  • A.固定所有随机种子← 正确答案
  • B.记录依赖库版本号← 正确答案
  • C.只保留最好一次的日志
  • D.开源搜索配置与代码← 正确答案

答案：ABD。固定种子控制随机性，记录版本锁定环境，开源代码让别人能照着菜谱复刻。只保留最好日志反而丢弃了波动信息，无法报告均值与标准差，是典型的“报喜不报忧”。

Q7. 资源消耗评估中以下哪项通常不被关注？

单选题 · easy

  • A.峰值显存占用
  • B.GPU 总耗时
  • C.模型预测准确率← 正确答案
  • D.训练能耗开销

答案：C。峰值显存、GPU 耗时、能耗都属于“厨房账单”即资源消耗范畴。准确率是“味道分”，属于模型性能维度，评估资源时不看它，故选 C。

Q8. 数据泄漏会导致 AutoML 评估出现什么问题？

单选题 · mid

  • A.评估结果虚高← 正确答案
  • B.训练速度变慢
  • C.显存占用变大
  • D.模型结构变大

答案：A。数据泄漏等于把测试集答案提前泄露给主厨，他在正式比赛前就“尝过”评委的评分标准，成绩自然虚高。训练速度、显存、结构都不会因此改变，但换一份数据立刻现出原形。

Q9. 保证 AutoML 对比实验公平的配置包括？

多选题 · mid

  • A.相同的数据划分方式← 正确答案
  • B.相同的搜索时间预算← 正确答案
  • C.给强者更好的 GPU
  • D.相同的随机种子范围← 正确答案

答案：ABD。公平比赛要求相同食材（数据划分）、相同时间（搜索预算）、相同厨房设备（硬件）。给强者更好的 GPU 是明显的偏袒，会让胜负失去说服力，像给某位主厨偷偷换一口更快的锅。

Q10. 为什么报告结果要同时给出均值与标准差？

单选题 · hard

  • A.均值看水平波动看稳定性← 正确答案
  • B.均值好看标准差更高
  • C.标准差大说明模型很强
  • D.两个数字看着更专业

答案：A。均值代表多次运行的期望水平，标准差代表不同随机种子下的波动。方差大说明结果像“看心情发挥”的主厨，时而惊艳时而翻车，不可靠。标准差大不是强的表现，选项 B、C 方向完全说反了。