实验管理与统计度量

被忽视的双重身份

Prompt 管理之所以混乱，是因为 prompt 同时具有代码和配置两种身份。

说它是代码，因为 prompt 的变更直接影响系统行为，其影响范围和修改一个核心函数没有本质区别。说它是配置，因为 prompt 的变更频率远高于代码，往往由非工程角色（产品经理、领域专家）发起，且同一套系统可能需要在不同场景下使用不同的 prompt 变体。

这种双重身份意味着，prompt 既不能用纯粹的代码管理方式（git commit、code review、CI/CD），也不能用纯粹的配置管理方式（配置中心、热更新、灰度发布）。它需要两者的结合——ML 的实验管理多年前就解决了这个问题。

在机器学习领域，模型的超参数具有完全相同的双重身份：它们是"代码"（直接决定模型行为），也是"配置"（需要在实验过程中频繁调整和对比）。ML 工程师不会把超参数硬编码在训练脚本里然后用 git 管理变更，也不会把它们扔进一个配置文件然后祈祷不出错。他们用 MLflow、Weights & Biases 这样的实验管理平台，将每一次实验的参数、结果、环境信息完整记录并关联。

Prompt 工程需要同样的纪律。

把 Prompt 当实验变量

将 prompt 管理从"版本控制"升级为"实验管理"，关键的认知转变是：每一次 prompt 的修改都是一次实验。称之为"实验"是因为它承认了不确定性——新版本可能更好，也可能更差，需要数据来判断。第二章讨论的不确定性管理原则在这里直接适用：在结果未经验证之前，任何 prompt 变更都只是假设。

一个合格的 prompt 实验记录至少包含以下要素：

记录要素	解决的问题
实验 ID	唯一标识，关联所有后续分析
父版本 ID	记录"从哪个版本改过来的"——不知道当前版本的来源，是实验管理最常见的混乱根源
假设	迫使实验者在修改前明确预期："这次修改预期解决什么问题"——没有假设的修改无法被证伪
Prompt 内容	实验的核心变量
模型与参数	model、temperature、max_tokens 等——环境变量必须固定，否则无法归因
评估数据集版本	确保不同实验之间的评估基准一致——用不同测试集评估然后得出不可比的结论，是另一个常见错误
评估指标	实验的量化结果
时间与作者	可追溯性

这些字段看似繁琐，但每一个都对应着实际工程中反复出现的问题。省略任何一个，都会在后续的变更追踪和效果归因中留下盲区。

实验设计：控制变量的纪律

ML 实验管理的核心纪律是控制变量：每次实验只改变一个因素，其他因素保持不变。这个纪律在 prompt 迭代中被普遍违反。

典型的反模式是：修改了 prompt 的措辞，同时升级了模型版本，同时调整了 temperature，然后发现输出质量变了——但无法归因到底是哪个变更导致的。数据科学里这算初学者错误，但在 prompt 工程中几乎人人都在犯。

操作化实现很简单：将实验配置（prompt 模板、模型、temperature、max_tokens、system message 等）结构化定义，每次实验变更前自动校验只有一个字段发生了变化。如果多个字段同时变更，拆分为多个独立实验。这个约束的价值不在于技术复杂度——它极其简单——而在于它把纪律变成自动检查。第四章讨论的"约束传播"原则在此适用：好的约束是对问题空间的精确建模。

变更追踪与效果溯源

版本控制回答"改了什么"，实验管理回答"改了之后怎么样"。两者的结合才能回答真正重要的问题："这次修改是否值得保留"。

效果归因的最低标准是：对于每一次被采纳的 prompt 变更，能够说出它在评估集上带来的量化改善，以及这个改善是否具有统计显著性。没有量化归因的变更决策，本质上是在掷骰子。

实践中的最小可行方案不需要复杂的平台。一个结构化的 JSON Lines 文件加上一个简单的 Python 脚本就能实现核心功能：记录每次实验的配置和结果，对比任意两个版本的指标差异，按时间线回溯 prompt 的演化路径。关键在于纪律的执行力度，工具本身够用即可。

对于已经达到一定规模的团队，MLflow 的实验追踪模块可以直接复用于 prompt 管理。prompt 内容作为参数记录，评估指标作为 metrics 记录，prompt 文件作为 artifact 存储。不需要为 prompt 管理专门搭建基础设施——ML 领域十年的工具积累已经足够成熟。

前提与成本

实验管理方法论有一个根本前提：评估函数是稳定且可信的。如果评估本身不可靠——评估标准模糊、评估数据不具代表性、评估指标与业务目标不对齐——那么再精细的实验管理也只是在追踪噪声。评估系统的可靠性是整个实验管理体系的地基，这也是下一篇文章讨论的起点。

另一个局限是成本。严格的控制变量和量化归因意味着更多的 API 调用、更长的评估周期、更高的人力投入。对于探索阶段的原型项目，这种纪律的投入产出比可能不合理。战略方向比分析细节重要——实验管理的精细程度应该匹配项目阶段，早期原型不需要生产级的实验基础设施。

输出质量的统计度量

实验管理解决了"改了什么"和"改了之后怎么样"的追踪问题。但要回答"改了之后是否真的更好"，需要统计度量——将模糊的"看起来不错"转化为可量化、可对比的指标。

"看起来不错"不是质量标准。人类对文本质量的主观判断具有高方差（同一人不同时间评价不同）、低一致性（不同人评价不同）和系统性偏差（倾向于高估流畅但错误的输出）。第二章确立的原则——不确定性是约束条件——换句话说：要管理不确定性，首先得量化它。

定义可度量的质量维度。 质量是多维概念。对于大多数 LLM 应用场景，质量维度大致分为五类：正确性（输出在事实层面是否正确）、完整性（输出是否覆盖了所有要求的内容）、格式符合度（输出是否遵循了指定的结构和格式约束）、一致性（多次运行对同一输入的输出是否稳定）、以及相关性（输出是否与输入的意图对齐）。每个维度都要落实为可以计算的指标。格式符合度最容易度量（符合 schema 与否是二元判据）；正确性和相关性的度量要困难得多，往往需要领域专家标注或 LLM-as-judge 方法——但即便使用不完美的度量，也好过没有度量。

建立评估基线。 基线是一个锚点：所有后续的改进都相对于基线来衡量。构建基线要注意三点：基于固定的评估数据集（如果每次评估都用不同的数据，指标的波动就无法归因）；包含多次运行的统计量，记录均值和标准差而非单一数值（LLM 输出的随机性意味着单次运行不能代表真实水平）；记录环境信息（模型版本、API 端点、运行时间），因为模型提供商的静默更新可能导致基线失效。

区分信号与噪声。 prompt 从 v1 改到 v2，准确率从 85% 变成 88%。这是真实的改进，还是随机波动？统计显著性检验的核心逻辑是：假设两个版本没有真实差异，观察到的指标差异纯粹由随机性导致的概率有多大？如果这个概率足够小，我们有理由认为差异是真实的。具体选择哪种检验方法取决于指标类型：二元指标（通过/不通过）使用配对二元分类检验，连续指标（评分）使用配对符号秩检验。关键的注意事项是：当评估数据集较小（少于 100 条）时，统计检验的功效很低，即使存在真实差异也可能检测不到。

常见陷阱。 用平均分掩盖分布信息（准确率 85% 可能意味着"所有用例都在 80%-90% 之间"，也可能意味着"一半 100%，另一半 70%"，两种分布对应完全不同的对策）。在同一数据集上反复评估导致过拟合（解决方案和 ML 中一样：分开发集和保留测试集）。忽视评估指标与业务目标的对齐（一个准确率从 90% 提升到 95% 的改进，如果集中在用户不关心的边缘场景，业务价值可能为零）。

统计度量方法的根本局限在于：它只能度量可量化的维度。LLM 输出的某些质量属性——比如语气是否得体、逻辑是否连贯——很难被还原为数值指标。此外，统计显著性不等于实际显著性——显著性和效果量都得看。