林师傅是“AI小馆”的主厨，他的招牌菜“智能红烧肉”远近闻名，可味道时好时坏——学徒们炒菜全凭手感，糖多一勺、火大三成，今天的招牌菜可能就砸了。直到林师傅立下规矩：每道菜出锅前必须填一张“菜品记录卡”，写下配料用量、火候大小、出锅时间和客人评分。从此，好味道不再是运气，而是可以照做的流程。 机器学习的模型训练，就像这一道道菜。学习率是火候大小，批量大小是每锅下多少料，训练轮数是翻炒次数——这些动手前就要定好的参数，就是超参数。它们决定了一道菜能不能做好。而超参数追踪，就是那张菜品记录卡：把每次实验的配方、环境和结果完整记下来，让任何一次训练都能被精确复现。接下来，我们看看这张“记录卡”该怎么写、怎么写好、怎么让整个团队都受益。

岗位关联

掌握超参数追踪，你就能让每次模型训练有据可查、一键复现、团队共享——这是从“调参侠”走向专业机器学习工程师的必修课。

目录
  1. 可视化演示
  2. 实验追踪认知
  3. 超参自动捕获
  4. 版本化存储
  5. 搜索空间管理
  6. 可视对比分析
  7. 复现与协作
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

超参追踪，记录每次训练运行的超参数配置与对应结果的核心实验管理能力。学习如何实现超参数自动捕获与版本化存储，超... 切换模式查看不同维度。

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

超参数自动捕：核心原理 动态展示关键流程与数据流动 交互控件调节参数实时渲染 f(x) = transform(x) 核心概念的可视化呈现

实验追踪认知

林师傅的“菜品记录卡”上只有三栏：用了什么调料（配方）、灶台是什么状态（环境）、客人打了几分（结果）。他告诉学徒，这三栏缺一不可——光写“糖 3 克”不够，还得写清明火还是小火；光说“味道不错”更不行，得有个分数。这三栏，恰好就是机器学习实验追踪要记录的三类信息。

机器学习训练就像做菜。开火之前，你要先定下“菜谱”：学习率是火候大小，批量大小是每锅炒多少料，训练轮数是翻炒次数，正则化强度是控油量。这些训练前由人设定、不会在训练中自动改变的外部配置，叫做超参数（hyperparameters）。与之相对，模型内部那些训练中自动学出来的权重，像揉面过程中自己形成的筋道，叫做模型参数。决定一道菜成败的，往往正是那份菜谱。

实验追踪（experiment tracking）做的就是把这张记录卡体系化：每次训练启动，它自动记下超参数配置、运行环境（Python 版本、CUDA 版本、GPU 型号）、结果指标（loss、accuracy）。为什么环境也要记？因为只有菜谱没有锅，换了灶台味道就可能变——这正是“复现”难题的根源之一。主流工具如 MLflow、Weights & Biases、Neptune 都在做这件事，只是记录和展示的形式各有侧重。

有了菜谱本，无论学徒换了几批，招牌菜的味道都能稳住。实验追踪做的正是这件事——让模型训练从“看缘分”变成“看记录”，让团队的每个人都能站在前人记录上继续调参，而不是重复踩同一个坑。

H={λ1,λ2,…,λn}\displaystyle H = \{ \lambda_1, \lambda_2, \ldots, \lambda_n \}
H 表示整份超参数集合，λ 是每个具体的超参数名称，n 是超参数的总个数——就像菜谱上的配料清单。
  1. H超参数集合：整份菜谱用一个大括号装起来，表示把所有配料归成一个整体。
    H={…}\displaystyle H = \{ \ldots \}
  2. λ单个超参数：如学习率、批量大小，每个 λ 对应菜谱上的一行配料。
    λ1,λ2,…\displaystyle \lambda_1, \lambda_2, \ldots
  3. n超参数总数：菜谱上一共有多少行配料记录。
    λn\displaystyle \lambda_n

超参自动捕获

手写记录卡总有疏漏。学徒一忙起来，往往忘了记“今天酱油放了多少”。林师傅于是给厨房装了一批“智能调料勺”：每舀一勺，克数自动记到卡片上；没动过的调料，就记一行“使用默认量”。从此记录零遗漏——这就是自动捕获的价值。

机器学习场景里，靠人手动把超参抄进实验记录，又慢又容易漏。工程上的做法是在训练脚本启动时，自动读取配置：配置文件、命令行参数、环境变量，统一打包成一条结构化记录写入追踪系统。常见的实现有 Hydra 管理配置、MLflow autolog 自动记录、以及自研的训练框架装饰器。捕获动作必须发生在训练开始的那一刻，而不是训练结束之后——因为训练随时可能崩溃，一旦崩溃，没来得及记录的超参就永远丢了。

捕获设计中最重要的一条原则是单一事实来源：超参数只在配置源里定义一次，代码通过统一入口读取并记录，避免“配置文件一套、代码里写死一套”的混乱。同时要处理两类边界：一是默认值（用户没指定也要记录“此处用了默认值”）；二是敏感信息（数据库密码、API Key 绝不能进记录本，就像菜谱本里不会写厨房保险柜密码）。

智能调料勺让记录既准又全。自动捕获的意义正在于此：无论配置多复杂、训练多匆忙，追踪系统里永远有一份完整准确的配置快照，为后续对比与复现打下地基。

C={(λi,vi)∣i=1,2,…,n}\displaystyle C = \{ (\lambda_i, v_i) \mid i = 1, 2, \ldots, n \}
C 是最终落库的“配置表”，每个超参数 λ 与它的取值 v 组成一个对子，一一对应，一行不缺。
  1. C配置表：一张完整记录下来的配料表。
    C={…}\displaystyle C = \{ \ldots \}
  2. (\lambda_i, v_i)参数名与取值配对：把“糖”和“3 克”绑成一个对子，名字与值一一对应。
    (λi,vi)\displaystyle (\lambda_i, v_i)
  3. i = 1 到 n逐行遍历：从第 1 个超参数到第 n 个，每个都生成一个配对。
    i=1,2,…,n\displaystyle i = 1, 2, \ldots, n

版本化存储

菜谱会迭代。林师傅的红烧肉配方三易其稿：v1.0 糖放太多、v1.1 火候太大、v2.0 加了一味陈皮后大获好评。菜谱本每一版都标好版本号，想回看 v1.1 随时翻得到，绝不在旧页上涂改覆盖。实验同样如此。

每次运行的配置快照都必须永久留存，不能用一个“config.json“反复覆盖。版本化存储要做的不只是存超参，还要把代码版本、数据版本、模型产物全部串起来。这样无论跑了多少次实验，每一次都是”历史档案”里可检索、可引用的一页，而不是被覆盖的草稿纸。

落地的存储方案有很多层级：小团队可以用本地目录加 JSON 文件；中型团队用 SQLite 或 MySQL 存元数据；大团队用对象存储配元数据库。无论哪种方案，核心是给每个实验生成唯一版本指纹：把配置 JSON、代码 commit hash、数据 hash 拼成一段文本，再做 SHA256 哈希取前 12 位。指纹相同说明是重复实验，可以自动去重；指纹不同，就代表“菜谱本上不同的一页”。

有页码、有版本号、有指纹的菜谱本，才是能传家的老物件。版本化存储保证了：哪怕半年后回来，也能精确锁定当初那盘菜对应的配方、做法和食材批次。

v=SHA256(config ∥ code_hash ∥ data_hash)\displaystyle v = \mathrm{SHA256}( \mathrm{config} \,\|\, \mathrm{code\_hash} \,\|\, \mathrm{data\_hash} )
v 是实验的唯一编号。把“配方、做法版本、食材批次”三样拼起来盖一个章，得到的印记就是指纹。
  1. config配置字符串：把整份超参配置序列化成一长段文本。
    config\displaystyle \mathrm{config}
  2. code_hash代码版本：Git commit 的哈希，代表“用的是哪一版做菜手法”。
    code_hash\displaystyle \mathrm{code\_hash}
  3. data_hash数据版本：训练数据集的哈希，代表“用的是哪一批食材”。
    data_hash\displaystyle \mathrm{data\_hash}
  4. SHA256指纹函数：把三样原料拼起来做加密哈希，输出固定长度的指纹。
    SHA256(⋅)\displaystyle \mathrm{SHA256}(\cdot)
  5. v版本指纹：最终得到的实验唯一编号。
    v\displaystyle v

搜索空间管理

为了找到“最好吃的配方”，林师傅列了一张香料实验表：糖分三档、酱油分三档、火候分三档，共 27 种组合。他让学徒每种组合做一锅、填一张记录卡，全部做完后统一比较。这就是最朴素的网格搜索。

机器学习里的搜索空间，就是所有候选配置构成的集合。网格搜索（grid search）对每个超参取若干候选值，然后穷举所有组合，思路直白但组合数爆炸；随机搜索（random search）在每个参数取值范围内随机采样，实现简单、高维下覆盖更广；更聪明的是贝叶斯优化，它像一位有经验的老饕：尝过前几锅后，专挑最有可能出彩的配方组合去试。

定义搜索空间时要讲究“刻度”：学习率这类跨越数量级的参数用对数刻度（0.001 到 0.1），批量大小用整数离散值（16、32、64），有些参数则要果断固定不搜。每一轮搜索尝试，追踪系统都会自动生成一条实验记录；等全部跑完，用可视化统一对比，最优组合就浮出水面了。

有组织地试菜，比随手撒盐科学得多。搜索空间管理让“找好配方”变成系统工程，配合追踪系统，每一次失败的尝试也成了有价值的数据点，而不是被遗忘的黑历史。

Λ=Λ1×Λ2×⋯×Λn\displaystyle \Lambda = \Lambda_1 \times \Lambda_2 \times \cdots \times \Lambda_n
Λ 是所有候选配方的总集合。每个超参有自己的候选范围 Λᵢ，把它们组合起来（乘法关系），就是整个搜索空间。
  1. Λ整个搜索空间：所有可能菜谱构成的集合。
    Λ\displaystyle \Lambda
  2. Λᵢ单个超参的候选集：例如糖的取值为 {2g, 3g, 4g}。
    Λi\displaystyle \Lambda_i
  3. ×笛卡尔积：把各维度候选值两两搭出组合，数量相乘。
    Λ1×Λ2×⋯×Λn\displaystyle \Lambda_1 \times \Lambda_2 \times \cdots \times \Lambda_n
  4. n超参数个数：搜索空间的维度数。
    n\displaystyle n

可视对比分析

试吃结束，林师傅把 27 张记录卡在长桌上摊开：按糖量分列排开，旁边贴着每锅的“品相照片”（学习曲线图）。他一眼就看出，糖取 3 克、火候取中火那一列的卡片，分数普遍更高。

追踪系统最核心的价值，就是把多个实验结果放到同一坐标系里对比。最常见的可视化是学习曲线：训练和验证的 loss 随训练步数变化的曲线。把不同实验的曲线叠在一起，谁收敛快、谁过拟合了，一眼就能看清——就像把几锅菜的品相照片并排比较。

进阶武器是平行坐标图：每个超参占一根坐标轴，一根折线代表一个实验，高性能实验的折线往往在特定区间交织成束，帮你发现“损失低的实验倾向于什么样的配置组合”。散点图和箱线图则用来观察单个超参对指标的影响。别忘了给最优实验加高亮与注释，记录“是谁、在什么时候、基于什么判断选出了它”，让好决策可以被后人理解。

就像品鉴会把菜品一字排开，可视化让好配方“一眼可见”。对比分析把追踪数据从“档案”升级为“决策依据”，让团队不只是记录，更是用记录做判断。

mr=f(λ(r),θ(r)),r∈R\displaystyle m_r = f( \lambda^{(r)}, \theta^{(r)} ), \quad r \in \mathcal{R}
mᵣ 是第 r 次实验的指标得分。这道菜好不好吃，取决于用的菜谱 λ 和炒菜手法 θ；R 是所有已记录实验的集合。
  1. r ∈ R实验编号：第几锅菜，对应追踪系统里的一条记录。
    r∈R\displaystyle r \in \mathcal{R}
  2. λ⁽ʳ⁾该实验的超参配置：第 r 张记录卡上的配料表。
    λ(r)\displaystyle \lambda^{(r)}
  3. θ⁽ʳ⁾训练得到的模型参数：训练完成后模型内部的权重。
    θ(r)\displaystyle \theta^{(r)}
  4. f训练与评估流水线：从配置和参数算出最终指标的一整条流程。
    f(⋅)\displaystyle f(\cdot)
  5. m_r指标结果：如 loss、accuracy，相当于口味评分。
    mr\displaystyle m_r

复现与协作

半年后林师傅去外地交流，新来的二厨要复刻招牌红烧肉。只要菜谱本写着配方与火候，仓库记录着食材批次，灶台型号也标在卡片上，二厨就能做出八九不离十的味道。这就是“一键复现”。

在团队协作中，实验追踪系统就是共享的“云端菜谱本”。新同事登录系统，挑一条历史实验，点一下“复现”，系统自动拉取相同的代码版本、数据版本、超参配置和随机种子，重新训练一次。这个人甚至不需要认识当初做实验的同事——记录本身就是最好的交接文档。

复现有四个关键依赖：代码版本（Git commit hash）、数据版本（数据集哈希或版本号）、运行环境（requirements.txt 或 Docker 镜像）、随机种子（控制初始化与数据打乱的随机来源）。同时，追踪系统要有权限与生命周期管理：团队各自使用独立的 project 空间，实验状态（进行中、已完成、已归档）清晰可控，生产环境的实验只读不可删，满足审计要求——就像正式菜谱本不能随便撕页。

菜谱本是团队的共同财富，复现能力是团队的持续生产力。当所有人都用同一本“菜谱本”说话，模型实验才真正变成可积累、可交接、可审计的工程资产。

R=Repro(H,Dver,s,E)\displaystyle R = \mathrm{Repro}( H, D_{\mathrm{ver}}, s, E )
R 是复现出来的结果。Repro 是“照着记录再做一遍”的流水线；输入是超参 H、数据版本 D_ver、随机种子 s 和环境 E；只要输入完全一致，结果就应当与当初一致。
  1. Repro复现流水线：从配置到模型的一整套重放流程。
    Repro(⋅)\displaystyle \mathrm{Repro}(\cdot)
  2. H超参数配置：复现时使用的菜谱。
    H\displaystyle H
  3. D_ver数据版本：用哪个批次的食材训练。
    Dver\displaystyle D_{\mathrm{ver}}
  4. s随机种子：控制所有随机过程的“命运骰子”。
    s\displaystyle s
  5. E运行环境：Python、CUDA、GPU 等环境信息。
    E\displaystyle E
  6. R复现结果：重新训练得到的模型与指标。
    R\displaystyle R

AI 应用场景

场景一：电商推荐团队的调参流水线

阶段：模型训练与超参调优

解决的问题：推荐系统团队每天跑几十组实验，过去靠 Excel 记录超参与效果，字段混乱、版本对不上、对比全靠肉眼。接入实验追踪后，超参自动捕获、版本指纹去重、曲线自动对比，调优周期从三天缩短到半天。

具体案例：某电商推荐团队使用 MLflow 加自研配置中心，训练任务启动时自动把学习率、Embedding 维度等 20 余个超参写入追踪系统；候选实验在 Web 端用平行坐标图对比，最终选中的模型一键复制配置上线。

场景二：学术研究与论文复现

阶段：实验验证与结果追溯

解决的问题：科研实验中超参记录不全，导致论文结果无法复现；审稿人要求补实验时，作者自己也对不上号。追踪系统让每个实验都有据可查，复现不再是“玄学”。

具体案例：某高校实验室复现顶会论文时，从追踪系统中调出原始运行记录，发现原作者用了 0.3 的 weight decay，而论文正文只写了 0.03——正是这个“被漏记的秘密”导致结果差异，最终顺利复现并定位了问题。

场景三：金融风控模型审计

阶段：模型治理与合规审计

解决的问题：监管要求模型可解释、可追溯，必须回答“这个模型是用什么数据、什么超参训练出来的”。人工翻日志无法应对，完整追踪系统让审计成为一键操作。

具体案例：某银行风控团队把每一条模型实验都录入追踪系统，审计时按 run_id 一键导出：超参配置、数据版本、代码 commit、训练日志全链路可追溯，一次审计从两周缩短到一天。

Python 演示

python93 行
import hashlibimport itertoolsimport jsonimport mathimport randomimport time  class ExperimentTracker:    """菜谱本: 负责写入和读取实验记录"""     def __init__(self, storage_path="experiments.json"):        self.storage_path = storage_path        self.store = self.load_store()     def load_store(self):        try:            with open(self.storage_path, "r", encoding="utf-8") as f:                return json.load(f)        except FileNotFoundError:            return {"runs": []}     def save_store(self):        with open(self.storage_path, "w", encoding="utf-8") as f:            json.dump(self.store, f, indent=2, ensure_ascii=False)     def compute_version(self, config, code_hash, data_hash):        raw = json.dumps(config, sort_keys=True) + "|" + code_hash + "|" + data_hash        return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:12]     def log_run(self, config, metrics):        """记录一次实验: 配置 + 指标 + 版本指纹"""        run = {            "run_id": len(self.store["runs"]) + 1,            "config": config,            "metrics": metrics,            "version": self.compute_version(                config,                "demo-code-v1",                "demo-data-v1",            ),            "timestamp": time.strftime("%Y-%m-%d %H:%M:%S"),        }        self.store["runs"].append(run)        self.save_store()        return run  def train_and_eval(learning_rate, batch_size, epochs, seed):    """用迷你线性模型拟合正弦数据, 返回损失等指标"""    random.seed(seed)    xs = [i / 50.0 for i in range(200)]    ys = [math.sin(v * 4) for v in xs]    w, b = 0.0, 0.0    for _ in range(epochs):        for start in range(0, 200, batch_size):            end = min(start + batch_size, 200)            xb, yb = xs[start:end], ys[start:end]            grad_w = sum((w * xi + b - yi) * xi for xi, yi in zip(xb, yb)) / len(xb)            grad_b = sum(w * xi + b - yi for xi, yi in zip(xb, yb)) / len(xb)            w -= learning_rate * grad_w            b -= learning_rate * grad_b    loss = sum((w * xi + b - yi) ** 2 for xi, yi in zip(xs, ys)) / len(xs)    return {"loss": round(loss, 6), "w": round(w, 4), "b": round(b, 4)}  def grid_search(search_space):    """在搜索空间上做网格搜索, 逐条写入追踪系统"""    tracker = ExperimentTracker()    keys = list(search_space.keys())    combos = itertools.product(*search_space.values())    for combo in combos:        config = dict(zip(keys, combo))        metrics = train_and_eval(            learning_rate=config["learning_rate"],            batch_size=config["batch_size"],            epochs=config["epochs"],            seed=config["seed"],        )        run = tracker.log_run(config, metrics)        print("run {0}: {1} -> loss={2}".format(run["run_id"], config, metrics["loss"]))    return tracker  if __name__ == "__main__":    space = {        "learning_rate": [0.01, 0.05, 0.1],        "batch_size": [16, 32],        "epochs": [50],        "seed": [42],    }    tracker = grid_search(space)    print("total runs: {0}".format(len(tracker.store["runs"])))
目的：用一个迷你网格搜索演示超参数自动捕获、版本指纹与结果记录，跑完后会自动生成 experiments.json 实验档案。
  1. class ExperimentTracker:定义了“菜谱本”对象，负责记录实验的配置、指标与版本指纹。
  2. raw = json.dumps(config, sort_keys=True) + "|" + code_hash + "|" + data_hash把配置、代码版本、数据版本拼成一段文本，作为指纹的原料。
  3. return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:12]对原料做 SHA256 哈希并截取前 12 位，得到实验的唯一指纹。
  4. self.store["runs"].append(run)把本次实验追加进记录本并落盘保存。
  5. grad_w = sum((w * xi + b - yi) * xi for xi, yi in zip(xb, yb)) / len(xb)用一个小批次样本计算梯度，相当于试吃一口判断该往哪个方向调。
  6. w -= learning_rate * grad_w按学习率更新权重，学习率就是每次调整的步幅。
  7. combos = itertools.product(*search_space.values())对各超参候选值做笛卡尔积，展开网格搜索的全部组合。
  8. config = dict(zip(keys, combo))把参数名和取值一一配对，生成一组完整配置。
  9. run = tracker.log_run(config, metrics)把配置和指标写入追踪系统，返回带指纹的实验记录。
  10. print("run {0}: {1} -> loss={2}".format(run["run_id"], config, metrics["loss"]))打印每次实验的摘要，方便肉眼核对。

常见误区

误区我训练的时候 print 一下超参数，再记一下 loss，这不就是实验追踪了吗？为什么还要搞一套系统？

正解只记超参和 loss 远远不够。完全复现还需要代码版本、数据版本、随机种子、环境依赖（Python/CUDA/GPU）。就像菜谱只写“糖 3 克”却没写用哪种糖，换成红糖味道就不同。追踪系统记录的是“配方 + 食材批次 + 灶台”的完整组合，并且支持查询、对比、一键复现，这是几个 print 语句做不到的。

为何常见：初学者往往只盯着“配置 → 指标”这条最短链路，忽略了训练结果还依赖代码和数据环境这些“隐藏变量”。

误区把所有超参数组合都穷举一遍，肯定比随机采样更全面，所以我只做网格搜索。

正解当搜索空间超过三维，网格搜索的试验数量随维度指数爆炸，每个维度上能分配的取值点数反而变少，覆盖率很低。随机搜索在同等预算下采样更分散，高维时往往能找到更好的结果。贝叶斯优化则更进一步，像有经验的老饕一样用历史结果指导下一步采样。

为何常见：“穷举 = 全面”的直觉在低维成立，但高维空间里穷举意味着每个维度只试很少几点，并不全面。

误区等训练结束了，我再去把配置文件抄到实验记录里，反正结果已经出来了。

正解训练过程可能崩溃、被系统杀掉、显存溢出（OOM）。如果结束后才记录，中途失败时配置就永远“蒸发”了。正确做法是在训练启动时自动捕获并立即写入追踪系统，每条 run 从一开始就有 id——失败也是重要的实验数据，同样要留档。

为何常见：把追踪当成“事后整理”，忽略了实验记录应该是过程产物，而不是结果总结。

误区我把每次训练的 log 存到一个文件夹里，整理得整整齐齐，这就是实验追踪了。

正解日志是难以检索的文本流：没法按超参过滤、没法跨实验画曲线、没法自动对比。追踪系统把实验信息结构化存储（配置、指标、版本指纹、血缘关系），查询、对比、复现都是秒级操作。菜谱本如果只是把纸条扔进箱子，就永远找不到“糖 3 克”那一锅菜。

为何常见：日志文件看得见摸得着，容易给人“已经记录了”的错觉，但缺少结构化能力，无法支撑对比与复现。

误区用一模一样的超参数重新训练，结果一定一模一样，误差应该是零。

正解深度学习训练充满了随机性：权重初始化、数据打乱顺序、GPU 并行时的浮点累积误差。不固定随机种子、不记录数据版本、甚至换一块 GPU，结果都会有差异。完整复现需要固定种子、记录代码与数据哈希，并对浮点误差有合理预期——复现追求的是“可信一致”，不是“逐位相等”。

为何常见：直觉上“同样输入 + 同样配置 = 同样输出”，忽略了训练过程的随机性与硬件影响。

面试题

Q1. 下列哪一项属于超参数？

单选题 · easy

  • A.模型训练中自动学到的权重
  • B.训练前人为预设的学习率← 正确答案
  • C.训练数据集中特征的取值
  • D.模型对样本输出的预测值

答案：B。超参数是训练前人为设定、不会在训练中自动改变的外部配置，如学习率，相当于做菜前定好的火候。模型权重是训练中自动学到的模型参数；特征取值属于数据；预测值是模型输出，三者都不是超参数。

Q2. 实验追踪系统最核心的三类记录信息是？

单选题 · easy

  • A.超参配置、环境信息、结果指标← 正确答案
  • B.代码注释、数据类型、图表样式
  • C.员工姓名、会议记录、需求文档
  • D.预算金额、服务器数量、机房位置

答案：A。类比菜品记录卡，三类信息缺一不可：配料表是超参配置，灶台状态是环境信息（Python、CUDA、GPU），口味评分是结果指标（loss、accuracy）。其余选项与复现实验毫无关系。

Q3. 实验版本指纹的主要用途是？

单选题 · mid

  • A.给模型参数做可视化展示
  • B.压缩训练日志的存储体积
  • C.唯一标识实验并自动去重← 正确答案
  • D.加密传输训练数据集文件

答案：C。版本指纹把配置、代码哈希、数据哈希拼起来做 SHA256，用于唯一标识一次实验；指纹相同说明是重复实验，可以自动去重。它不负责可视化、压缩日志或加密传输数据。

Q4. 网格搜索在高维搜索空间的主要问题是？

单选题 · mid

  • A.组合数量随维度指数增长← 正确答案
  • B.不需要定义搜索取值范围
  • C.结果之间无法相互比较
  • D.只适用于无监督学习任务

答案：A。网格搜索要对每个维度取若干候选值再求笛卡尔积，维度一多组合数呈指数爆炸，每个维度分到的取值点反而变少，覆盖率低。它同样需要定义范围、结果可对比，也适用于有监督任务。

Q5. 关于随机搜索，下列说法正确的是？

单选题 · hard

  • A.在范围内随机采样且高维覆盖更充分← 正确答案
  • B.必须遍历全部参数组合才能结束
  • C.只能用于一个超参数的搜索任务
  • D.搜索结束时一定找到全局最优解

答案：A。随机搜索在每个超参取值范围内随机采样，高维下样本之间几乎不重叠，同等预算覆盖更充分。它不需要遍历全部组合、可处理多参数，但也不保证找到全局最优解。

Q6. 要完全复现一次训练结果，下列哪项不是必需条件？

单选题 · hard

  • A.与原始实验相同的代码版本
  • B.与原始实验相同的数据版本
  • C.与原始实验相同的随机种子
  • D.与原始实验相同的显卡温度← 正确答案

答案：D。复现需要代码版本、数据版本、随机种子和环境依赖；显卡温度属于运行时物理状态，不影响训练逻辑，且温度本身不可控，不需要记录。就像复刻菜谱不需要记录当天的室温。

Q7. 实验追踪中“单一事实来源”原则的含义是？

单选题 · easy

  • A.超参只在配置源中定义一次← 正确答案
  • B.每次实验只训练一个模型
  • C.追踪系统只存储一份结果
  • D.训练数据只允许复制一次

答案：A。单一事实来源指超参数只在配置文件等唯一源头定义，代码统一读取并记录，避免“配置一套、代码写死一套”的冲突。与训练模型数量、结果份数、数据复制次数无关。

Q8. 一个完整的实验追踪系统应当支持哪些能力？

多选题 · mid

  • A.自动捕获超参数与默认值← 正确答案
  • B.版本指纹去重与历史回溯← 正确答案
  • C.跨实验的可视化对比分析← 正确答案
  • D.自动生成论文的参考文献

答案：ABC。自动捕获保证配置零遗漏；版本指纹去重与历史回溯让每个实验可定位；可视化对比让团队从数据中找规律。参考文献生成与实验追踪无关。

Q9. 关于版本化存储，下列说法正确的有？

多选题 · hard

  • A.用哈希指纹唯一标识一次实验← 正确答案
  • B.相同指纹的实验可以自动去重← 正确答案
  • C.只需保存最终模型权重文件
  • D.实验与代码数据版本相互关联← 正确答案

答案：ABD。哈希指纹由配置、代码、数据哈希生成，可唯一标识并去重；实验记录必须与代码、数据版本关联才能复现。只保存模型权重无法回答“模型是怎么训出来的”，因此 C 错。

Q10. 超参数搜索空间管理中常见的策略有？

多选题 · mid

  • A.网格搜索遍历所有参数组合← 正确答案
  • B.随机搜索在范围内随机采样← 正确答案
  • C.贝叶斯优化按历史结果采样← 正确答案
  • D.服务器数量决定参数范围

答案：ABC。网格搜索穷举组合、随机搜索随机采样、贝叶斯优化用历史结果智能引导下一轮，三者都是搜索空间管理的常见策略。服务器数量只是基础设施，与超参取值范围无关。