语言模型可能在干净的基准测试中表现出色，但在实际应用的关键场景中仍会遇到困难。

以下评估实践帮助我们从有前景的原型成果推进到生产环境。✅ https://t.co/AIJyskqbZx

如何在生产环境前评估大语言模型

来源：https://github.blog/ai-and-ml/llms/how-to-evaluate-llms-before-production/ 语言模型可能在干净的基准测试中表现出色，但在生产环境的关键场景中仍会遇到困难。

基准测试和精选数据集在构建基于大语言模型系统的原型阶段很有用。它们帮助团队比较模型、测试初始提示词，并判断技术思路是否可行。

但随着系统逐渐接近生产环境，评估问题也随之变化。

真实输入通常存在歧义。标签可能不一致。重要的上下文可能缺失或被截断。评估数据集可能无法反映生产分布。基准测试中罕见的边界情况可能成为常见的故障来源。即使离线指标有所改善，这些结果也可能无法直接转化为生产行为中的表现。

我们在评估一个旨在减少GitHub密钥扫描误报的基于大语言模型系统时遇到了这些挑战。

密钥扫描会识别可能已提交到仓库的凭证，例如令牌和密钥。由于某些候选字符串与密钥相似但并非真实凭证，开发人员可能会花时间调查无需修复的警报。

我们需要评估的不是大语言模型能否正确分类字符串，而是系统能否在保持足够召回率以满足安全工作流要求的前提下减少噪声警报。

在本文中，我们将分享帮助我们从有前景的原型成果推进到生产环境的实践。这些经验广泛适用于代码分析、开发工具、安全、数据分析及其他生产工作流中的大语言模型系统。

图表标题为“大语言模型评估生命周期“，展示了七个通过箭头连接的阶段：产品决策、代表性数据集、离线评估、错误分析、针对性变更、回归评估和在线实验。一个标记为“迭代学习“的虚线反馈回路将回归评估连接回数据集和针对性变更阶段。## 1. 从产品决策出发，而非模型本身

当大语言模型系统表现不佳时，第一反应往往是调整其技术组件。

团队可能会重写提示词、添加上下文、引入另一个推理步骤、调整周边流程或切换模型。在做出这些更改之前，他们应该先明确评估所要支持的决策。

在我们的密钥扫描工作中，我们提出了这样的问题：

系统能否在保持足够召回率以满足生产安全工作流要求的前提下减少误报？

要回答这个问题，团队必须确定哪些错误是可接受的，哪些指标应该驱动产品决策，以及哪些安全护栏必须保持在定义的阈值范围内。

在密钥扫描中，错误地忽略真实凭证可能比要求开发人员审查额外警报的后果更严重。因此，我们没有将精确率和召回率视为同等可互换的指标。

我们的主要目标是减少误报并提高精确率。召回率作为安全约束：只有当下降幅度保持在预定义的可接受范围内时，实验才能推进。这为我们评估权衡提供了清晰的方法。我们选择了在满足召回要求和运营安全护栏的前提下，实现最强误报削减效果的配置。

我们将评估标准分为三个层次：

主要结果

衡量我们试图改善的用户收益：

• 误报削减
• 精确率

安全约束

防止看似改进却引入不可接受的安全风险：

• 召回率

运营护栏

决定结果是否可实际部署：

• 延迟
• 成本
• 可靠性
• 生产环境兼容性

这种区分防止我们视所有指标为可互换。一个减少误报但显著降低召回率的变更并非自动成为改进。同样，一个提升质量但使系统过慢、成本过高或难以集成的变更也不是改进。

考虑两个假设的实验结果：

实验精确率召回率延迟决策实验A大幅提升低于安全护栏可接受不推进实验B适度提升保持在护栏范围内可接受继续测试单独看精确率，实验A可能显得更强劲。但实验B更符合产品目标，因为它在不违反召回护栏的前提下改善了开发人员体验。

在评估大语言模型系统之前，请先确定成功对用户意味着什么，以及系统必须遵守哪些安全护栏。我们需要生成支持产品决策的证据。

2. 将离线评估视为集成测试

基于大语言模型的系统在首次成功评估后仍会持续变化，因此评估不应是一次性工作。团队会修订提示词、采用新模型、更改输入和上下文的构建方式，并完善周边业务逻辑。

这些变更中的任何一项都可能改进系统、引入回归或意外改变其行为。

因此，我们像对待端到端集成测试一样对待离线评估。每当对提示词、模型、输入构建或更广泛的系统逻辑做出有意义的更改时，我们都会重新运行评估。

评估还需要具备足够的可重复性，以便每次新结果都能与已知基线进行比较。每次运行，我们都记录提示词、模型、数据集版本和系统配置。

这使我们能够回答诸如以下的问题：

• 新提示词是否在不降低召回率的前提下提高了精确率？
• 模型升级在整个数据集上都有帮助，还是仅在特定类别中有效？
• 对输入或上下文的更改是修复了一种错误模式，还是引入了另一种？
• 对周边逻辑的更改是持续改善结果，还是仅仅改变了错误出现的位置？

缺乏这种规范，团队很容易比较在不同条件下生成的结果，并将改进错误归因于某个变更。

一次只更改一个主要变量

仅有可重复性是不够的。实验还需要设计得使结果原因清晰。

我们一次只更改一个主要变量，并将每次运行与已知基线进行比较。例如，我们在同时测试两者之前，先单独评估了提示词修订和模型升级。

这一点很重要，因为即使是微小的提示词更改也可能改变模型行为，而模型升级则可能影响质量、成本、延迟或输出一致性。如果两者在同一实验中同时更改，我们将无法确定是哪一个导致了改进或回归。

我们将提示词和评估配置视为代码。我们对其进行版本控制，记录更改内容，保持先前配置的可重现性，并使其可回滚。

运行ID提示词版本模型版本精确率召回率延迟备注R-001v1模型A0.710.781.2s基线R-002v2模型A0.750.771.2s仅提示词变更R-003v1模型B0.740.801.0s仅模型变更上述评估运行跟踪表中的值是假设的，仅用于说明如何跟踪和比较评估运行结果。

定期测试模型升级

当大语言模型系统表现不佳时，开发人员通常会在提示词中添加更多指令来应对。有时这有帮助，但并非总是如此。例如，提示词可能承担了来自模型本身的复杂性。

更强的模型可能用更简单的提示词就能比旧模型经过大量调优表现更好。更简单的提示词也更容易理解、测试和维护。

模型升级仍需仔细评估。新模型可能在某个类别中提升性能，却在其他方面引入回归。它还可能影响成本、延迟、输出格式或与现有流程的兼容性。

评估过程应该足够低成本且可重复，使测试新模型成为常规操作。对提示词、模型或流程的任何有意义的更改，在投入生产前都应经过离线评估。

3. 使离线评估贴近生产环境

离线评估只有在模拟系统将在生产中执行的任务时才有用。

在密钥扫描工作流中，模型很少评估一个干净、孤立的值。它可能需要评估特定候选值及其周围的代码和其他相关、不完整或可能具有干扰性的信息。呈现这些信息的方式差异会实质上影响结果。

因此，我们的离线评估需要保留生产任务的重要特征，包括：

• 被评估的候选值
• 模型可用的周围上下文
• 相关的辅助信息
• 输入的格式和约束方式
• 围绕模型的更广泛系统逻辑

即使是微小的差异也可能扭曲结果。更干净的数据集可能排除了歧义情况、提供了更完整的上下文，或移除了可能干扰模型的附近值。

考虑一个简化的例子：

example_token = "sample_value_for_documentation" production_api_key = get_secret_from_environment() candidate_value = "flagged_value"

假设candidate_value是系统预期评估的值。模型可能反而关注example_token，因为其变量名看起来更具安全相关性，从而对错误的值产生看似合理的解释。

当评估示例只包含一个明显的候选值时，这类失败很容易被遗漏。它之所以暴露出来，是因为离线评估保留了真实密钥扫描工作流中存在的一些歧义和干扰。

离线流程越接近生产流程，评估就越有用。当两者不同时，较强的离线分数可能仅仅反映了比所部署问题更简单的场景。

4. 将生产标签视为信号，而非绝对真理

生产数据可以使评估更具代表性，但其标签通常反映的是工作流结果而非可靠的基准事实。例如，被关闭或解决的密钥扫描警报不一定代表误报。

开发人员关闭警报可能是因为：

• 凭证已轮换
• 风险已被接受
• 需要解除警报以避免阻塞工作流
• 警报被错误分类

这些结果在产品数据中可能看起来相似，但代表不同的基准事实状态。

在使用生产标签之前，请问：

• 标签是如何创建的？
• 它是否与评估试图回答的问题相匹配？
• 不同的工作流结果是否被归入了同一类别？

对于重要或存在歧义的子集，你可能需要进行人工审核。你的目标不是消除每一个不完美的标签，而是确保评估数据足够准确，以支持所做出的决策。

5. 使用合成数据和开放数据集填补覆盖空白

具有代表性的生产数据可能有限、敏感，或在开发早期不可用。合成示例、学术基准和开放数据集可以帮助开发人员引导评估并扩大覆盖范围，但这些示例应作为生产类数据的补充而非替代。

考虑到这一点，合成示例可以极大地帮助填补测试罕见或难以收集案例的空白，例如模糊输入、缺失上下文、异常格式和未被充分代表的故障模式。例如，一组凭证字符串可以测试模型是否识别常见格式，但无法完全评估模型如何在真实代码中推理候选值。

我们调整了外部示例以匹配我们的任务，并审核了与我们产品定义不符的标签。我们还使用真实的故障模式创建了针对性的合成案例，涉及附近的类凭证值、测试代码、占位符、间接引用和缺失上下文。

6. 使用错误分析发现聚合指标隐藏的问题

聚合指标告诉你系统整体是否改进。错误分析告诉你下一步该改变什么。

更高的精确率分数无法揭示剩余错误是来自模糊输入、糟糕的提示词框架、缺失上下文、噪声标签还是狭窄的数据集。

要理解这些问题，请检查失败案例。

我们审查了误报和漏报的样本，并按可能来源分组：模型、提示词、输入、流程、数据集或标签。反复出现的问题包括前面讨论过的几个，例如对错误候选值的推理、缺失上下文以及不符合评估定义的标签。

每个类别都暗示了不同的应对措施。对错误值的推理指向提示词或输入框架，缺失证据指向上下文构建，而错误标签则需要数据清理。反复出现的特定领域歧义可能表明需要更清晰的产品政策或专门的评估类别。

手动审查数十或数百个示例需要时间，但通常能带来更快的进展。一旦反复出现的故障模式变得清晰，团队就可以进行针对性的更改并衡量是否解决了问题。

对每个错误有一个有用的问题是：这个失败来自模型、提示词、输入、流程、数据集还是标签？

这种分类将模糊的质量问题转变为具体的工程任务。

7. 使用大语言模型作为评估者来聚焦人工审核

手动审核每一个评估示例可能难以扩展。大语言模型作为评估者可以通过分类明确案例、识别可能标记错误的示例以及优先处理存在歧义的案例供人工审核来减轻这种负担。由于评估者也可能出错或出于错误原因同意另一个模型的观点，其输出应被视为另一种预测，而非基准事实。

更安全的模式是使用评估者进行分流：

1. 自动处理明确、低风险的案例。
2. 将低置信度、冲突或高影响的案例路由给人工审核员。
3. 定期抽样高置信度案例，检查是否存在系统性错误。
4. 跟踪评估者、被评估系统和人工审核员之间的分歧。
5. 像对待任何其他模型组件一样对评估者提示词进行版本控制和评估。

通过这种方式使用评估者，可以将人工注意力集中在最可能改变审核结果的案例上。

图表标题为“人工审核分流漏斗“。所有评估示例进入漏斗，被分为四组：明确一致、低置信度、模型与标签不一致以及高影响案例。明确一致的案例进入自动处理，而其他三组则转交人工审核，进行结果决策和标签修正。已审核的示例、修正后的标签和新的测试案例会反馈到评估数据集中。## 8. 密钥扫描教会我们的

我们的目标是在安全敏感的工作流中减少误报的同时保持召回率。离线评估为我们提供了一种可控的方式，可以在开始在线实验之前比较提示词、模型、输入和流程的变更。

通过反复评估和针对性错误分析，我们实现了95%的误报减少。