- 实施多层评估关卡，结合确定性检查、LLM 评判员和人工审核，以防止质量偏差。
- 通过使用 N 次运行平均和基于回归增量而不是绝对阈值进行门控来减轻非确定性方差。
- 采用双速方法构建流水线，每次提交时运行快速检查，并在合并和夜间周期期间运行完整套件。
- 利用有向无环图 (DAG) 指标将复杂、主观的标准转化为结构化的、确定性的决策树。
在演示环境中运行 LLM 轻而易举，但要在生产环境中保持其稳定性却难上加难。大多数团队都会陷入“凭感觉做工程”的陷阱，他们调整一下提示，运行几次，然后就因为输出看起来不错就认为它已经改进了。然而，LLM 的不稳定性是出了名的，如果要面向成千上万的用户发布，仅仅依靠一些手动检查无异于自取灭亡。
要真正摆脱猜测，你需要将 AI 评估视为 CI/CD 基础设施中的核心环节。这意味着要摒弃简单的字符串比较，转而采用分层评估机制，以便在模型出现偏差和退化之前就将其捕获并部署到生产环境中。这旨在将一个依赖经验的过程转变为一个严谨的科学控制系统，确保你的模型不仅能够一次性成功运行，而且能够长期保持可靠性。
CI/CD评估门的架构
一个合适的评估门并非仅仅是一个脚本；它是一个版本化的检查点，用于判断对提示、模型或数据集的更改是否可以安全地发布。与传统的二元单元测试（通过或失败）不同，LLM 的输出是分布的。这意味着相同的输入在不同的运行中可能会产生不同的结果，这使得评估门的任务更加困难。为了解决这个问题，系统应该采用分层结构，首先是确定性检查（例如模式验证或正则表达式验证），然后是受控的 LLM 评判器，最后是抽样的人工审核。
为了确保系统的可靠性，每个变量都必须精确定义。你不能只说“GPT-4”，你需要精确的模型检查点、温度和种子。这同样适用于你的真实数据集和评委使用的评分标准。当出现故障时，你应该能够重现完全相同的环境，从而了解模型退化的原因。版本化的工件是确保今天的“通过”与下个月的“通过”含义一致的唯一方法。
实现四环流水线
对每次提交都运行完整的评估套件会迅速耗尽 API 预算，并因构建速度缓慢而令开发人员沮丧。相比之下，双速流水线效率更高。第一轮循环发生在 Pull Request 阶段，专注于“边界切片”——一个用于触发已知故障模式的小型硬数据子集。这可以将延迟控制在三分钟以内，确保工程师不会绕过测试。
第二个循环在合并到主分支时触发。此时会进行完整的真实性测试，检查评分标准的每个维度。第三步，金丝雀部署会将一小部分真实流量路由到新版本，并实时进行评分。最后，持续的生产循环会监控静默漂移，捕捉由上游提供商变更或用户行为变化引起的静态数据集可能遗漏的问题。
利用 N 次运行平均法解决噪声问题
持续集成信任的最大杀手之一是“不稳定的测试”。如果开发人员重新运行一次失败的评估，结果突然通过，他们就会把所有红色检查结果都视为噪声。这是因为 LLM 和评判者都具有不确定性。解决方法是停止使用绝对阈值。如果自然噪声底限是 0.04，那么将硬性阈值设置为 0.85 就毫无意义；一次运行的结果完全有可能落在该阈值的两侧，纯粹是运气使然。
相反，你应该运行每个测试用例 N 次（通常为 3 到 5 次），并计算平均分。更重要的是，你应该根据与基线的偏差来判断结果。只有当回归结果超过特定容差（通常是噪声带的两个标准差）时，才判定构建失败。通过将 PR 结果与同一作业中新测量的基线进行比较，可以消除共享方差，确保“失败”确实表示质量出现了真实下降。
基于DAG指标的高级确定性
虽然LLM作为评判标准功能强大，但对于复杂任务而言，其主观性可能过强。例如，仅凭一个提示很难对摘要是否按正确顺序包含引言、正文和结论进行一致的评分。这时，有向无环图（DAG）指标就派上了用场。它不再使用单一的提示，而是将评估过程分解为一个决策树，该决策树包含特定类型的节点：用于提取信息的任务节点、用于判断是非的二元节点以及用于计算最终得分的判决节点。
这种结构化方法使评估完全确定，即使是更小、更便宜的模型也能进行高质量的判断，因为它们只处理任务的基本单元。它还使调试变得轻而易举；您可以追踪测试在图上的确切路径，从而准确地找到失败之处。通过将这些有向无环图 (DAG) 与语义相似度（而非精确的字符串匹配）相结合，您可以避免仅仅因为措辞与参考文本略有不同就将正确答案标记为错误答案。
数据集的操作化
评估的质量取决于数据的质量。一个常见的错误是将“黄金答案”硬编码到测试文件中，这使得同行评审无法查看这些答案。更好的方法是将数据集以版本化的 JSON Lines 文件形式存储在代码仓库中。这样，每次添加或更改都可以通过拉取请求进行跟踪。为了防止数据集过时，您必须不断地将生产环境中的失败案例和人工审核的样本反馈到真实数据集中。
当数据匮乏时，不要急于收集成千上万个样本。重点在于维度的广度而非数量。几个精心挑选的案例，例如接地、指令执行和安全性测试，就能发现整类故障。通过关注边界案例——那些介于合格与不合格之间的案例——你可以在无需庞大数据集的情况下，最大限度地提高测试套件的信号密度。
将LLM测试从繁琐的手动操作转变为严谨的持续集成（CI）流程，需要转变思维模式，从二元断言转向统计分布。通过采用分层流水线、多次运行取平均值以消除噪声，以及使用结构化的DAG指标，团队可以更有信心地快速发布变更和模型升级。其目标并非使LLM完全确定，而是使评估过程可预测，确保流水线中的每一个绿色标记都代表着可验证的质量标准。
