生产环境前的 LLM 评估指南

语言模型在干净的基准测试上表现良好，却仍可能在生产环境中那些真正重要的场景下遇到困难。

在基于大语言模型的系统原型开发阶段，基准测试和精心构建的数据集非常有用。它们帮助团队比较不同模型、验证初始提示，并判断某个想法在技术上是否可行。

但随着系统逐步走向生产，评估问题也随之发生变化。

真实输入往往存在歧义，标注可能不一致，重要上下文可能缺失或被截断。评估集未必能反映生产环境中的数据分布。那些在基准测试中罕见出现的边缘案例，却可能成为导致系统失效的常见原因。

即便离线指标有所提升，这些改进也未必能直接转化为生产行为上的改善。

我们在评估一个旨在降低 GitHub Secret Scanning 误报率的大语言模型系统时，就遇到了上述挑战。

Secret Scanning 能够识别出可能被提交到代码仓库中的凭据，如令牌和密钥。由于部分候选字符串看似像凭据，但实际上并非有效凭据，开发者可能会花费时间去排查那些无需修复的告警。

我们关注的并非单纯验证大语言模型能否正确分类一个字符串，而是要弄清楚：该系统是否能在大幅减少噪声告警的同时，保持足够的召回率，从而确保安全工作流的安全性。

本文将分享我们从颇具前景的原型结果迈向生产落地所采用的实践方法。这些经验对代码分析、开发者工具、安全、数据分析以及其他生产场景下的大语言模型驱动系统同样具有广泛借鉴意义。

1. 从产品决策出发，而非先聚焦模型

当一个基于大语言模型的系统表现不及预期时，人们的第一反应往往是调整其技术组件。

团队可能会重写提示词、增加上下文、引入额外的推理步骤、调整周边流水线，或者更换模型。但在做出任何此类改动之前，应首先明确评估所要支撑的产品决策是什么。

针对我们的 Secret Scanning 任务，我们提出的问题是：

该系统能否在降低误报的同时，维持足够高的召回率，以满足生产安全工作流的要求？

要回答这一问题，团队必须界定哪些错误是可以接受的，由哪些指标来指导产品决策，以及各项约束条件需控制在怎样的阈值范围内。

在 Secret Scanning 场景中，错误地抑制一条真实的凭据，其后果往往比让开发者多审查一条告警更为严重。因此，我们并未将精确率与召回率视为可以等价互换的指标。

我们的首要目标是降低误报并提升精确率，而召回率则作为一项安全约束：只有当召回率的下降幅度控制在预先设定的可接受范围内时，实验结果才被视为有效推进。

这为我们评估各种权衡提供了清晰的依据。最终我们选择了能够在满足召回要求并符合各项运营约束的前提下，实现最强误报削减效果的配置方案。

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

主要目标

用于衡量我们试图提升的用户价值：

• 误报率的降低
• 精确率

安全约束

防止表面的改进带来不可接受的安全风险：

• 召回率

运营约束

用于判断结果是否具备实际部署价值：

• 延迟
• 成本
• 可靠性
• 与现有生产系统的兼容性

这种区分避免了将所有指标简单等同对待。仅仅降低了误报但显著拉低了召回率的改动，并不自动算作进步；同样，虽然提升了质量，却使系统变得过于缓慢、昂贵或难以集成的调整，也不能被视为成功。

不妨设想两个假设性的实验结果：

若仅从精确率的角度看，实验 A 似乎更优；而实验 B 则更贴合产品目标——它在不突破召回约束的前提下，切实改善了开发者体验。

在评估一个大语言模型系统之前，请先明确对用户而言的成功意味着什么，以及系统必须遵守哪些关键约束。我们的目标是生成能够支撑产品决策的可靠证据。

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

基于大语言模型的系统在首次成功评估之后仍会持续迭代，因此评估绝非一次性活动。团队会不断修订提示词、选用新模型、调整输入与上下文的构造方式，并优化周边业务逻辑。

这些改动既可能带来提升，也可能引发回归，甚至使系统行为发生意料之外的变化。

正因如此，我们将离线评估视为一次端到端的集成测试。每当我们在提示词、模型、输入构造或整体系统逻辑方面作出重大变更时，都会重新运行评估。

此外，评估还必须足够可重复，以便每次新结果都能与已知基线进行对比。每次运行时，我们都记录下使用的提示词、模型、数据集版本及系统配置。

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

• 新的提示词是否在不降低召回率的情况下提升了精确率？
• 模型升级是在整个数据集上都带来了改善，还是仅限于某些特定类别？
• 输入或上下文的调整是否在修复了一类错误模式的同时，又引入了另一类新问题？
• 周边逻辑的改变是稳定地改善了整体效果，还是仅仅改变了错误出现的位置？

缺乏这样的规范，团队很容易在不同条件下产生的结果之间进行比较，并将改进归因于错误的改动。

每次只变更一个主要变量

仅有可重复性还不够。实验的设计还应确保结果的原因清晰可辨。

我们每次只变更一个主要变量，并将每次运行的结果与已知基线对比。例如，在同时测试提示词修订与模型升级之前，我们会分别评估这两项改动的效果。

这一点至关重要，因为即使是细微的提示词调整也可能改变模型的行为，而模型升级则可能影响质量、成本、延迟或输出一致性。如果两项改动同时出现在同一个实验中，我们就无法确定究竟是哪一项促成了改进或引发了退步。

我们把提示词和评估配置当作代码来管理：为其打上版本标签、记录变更内容、确保旧配置可复现，并支持回滚。

上文评估运行跟踪表中的数值均为虚构，仅用于说明如何记录和比较评估结果。

定期测试模型升级

当基于大语言模型的系统性能不佳时，开发者常常通过向提示词中添加更多指令来应对。有时这确实有效，但并非总是如此。例如，提示词中可能已经包含了源自模型本身的复杂性。

更强的模型或许只需一个更简洁的提示词就能取得优于旧模型在深度调优后才能达到的效果。而且，简化的提示词也更容易理解、测试和维护。

模型升级仍需谨慎评估。新模型可能在某一领域表现更好，却在其他地方引发退步；它还可能影响成本、延迟、输出格式，或与现有流水线的兼容性。

评估流程应当经济且可重复，使测试新模型成为一项常规操作。任何涉及提示词、模型或流水线的重大变更，在投入生产之前都应经过离线评估。

3. 让离线评估贴近生产

只有当离线评估尽可能模拟系统在生产环境中将要执行的任务时，它才是有意义的。

在 Secret Scanning 工作流中，模型很少单独评估一个干净、孤立的值。它往往需要结合周围的代码及其他相关信息一起进行判断，而这些信息可能是相关的、不完整的，甚至是潜在的干扰源。

信息呈现方式的差异会对结果产生实质性影响。

因此，我们的离线评估必须保留生产任务的关键特征，包括：

• 待评估的候选值
• 模型可用的周边上下文
• 相关辅助信息
• 输入的格式与约束条件
• 围绕模型的更高层级系统逻辑

即便是细微的差异也会扭曲评估结果。一个更干净的数据集可能会排除歧义案例，提供更完整的上下文，或移除可能分散模型注意力的邻近值。

举个简化的例子：

example_token = "用于文档的示例值" 
production_api_key = get_secret_from_environment() 
candidate_value = "被标记的值"

假设candidate_value是我们期望系统评估的目标。但由于example_token的变量名看起来更具安全相关性，模型可能反而将其作为重点，从而对错误的值给出看似合理的解释。

这类失误在评估样本仅包含一个明显候选时很容易被忽视。而正是离线评估保留了真实 Secret Scanning 工作流中存在的一些歧义与干扰，才使这一问题得以暴露。

离线流程越接近生产流程，评估就越有价值。一旦两者出现较大差异，再高的离线分数也可能只是反映出所测试的问题远比实际部署的场景要简单得多。

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

生产数据能使评估更具代表性，但其标注往往反映的是工作流的实际结果，而非可靠的“真相”。例如，一条被忽略或已解决的 Secret Scanning 告警，并不一定代表它是误报。

开发者之所以解决一条告警，可能是因为：

• 凭据已被轮换
• 风险已被接受
• 为疏通工作流不得不清除该告警
• 该告警被错误地分类了

这些不同的处理结果在产品数据中可能看起来相似，却对应着完全不同的“真相”状态。

在使用生产标注之前，请先自问：

• 这条标注是如何产生的？
• 它是否与评估所要回答的问题相匹配？
• 不同工作流结果是否被归入了同一类别？

对于重要或模糊的子集，可能还需要辅以人工审核。我们并非要消除所有不完美的标注，而是要确保评估数据足够准确，足以支撑正在作出的决策。

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

在开发早期，具有代表性的生产数据可能有限、敏感或无法获取。合成样本、学术基准以及开放数据集可以帮助开发者启动评估并扩大覆盖范围，但这些样本应作为补充，而非替代生产类似数据。

考虑到这一点，合成样本尤其有助于填补那些罕见或难以收集的测试场景的空白，比如歧义输入、缺失上下文、异常格式，以及未充分表征的故障模式。

例如，一份凭据字符串列表可以检验模型是否能识别常见格式，却无法全面评估模型在真实代码背景下对候选凭据的推理能力。

我们根据自身任务调整了外部样本，并仔细审视那些与产品定义不符的标注。同时，我们还利用真实的失败模式，针对性地构造了包含邻近类凭据值、测试代码、占位符、间接引用以及缺失上下文的合成案例。

6. 通过错误分析揭示聚合指标掩盖的问题

聚合指标只能告诉你系统总体是否有所改善，而错误分析则能指出下一步该做些什么。

更高的精确率并不能说明剩余的错误究竟源于歧义输入、提示词表述不当、上下文缺失、噪声标注，还是受限的数据集。

要理解这些问题，就必须深入检视那些失败案例。

我们梳理了误报与误删的样本，并按其可能来源进行归类：模型、提示词、输入、流水线、数据集或标注。反复出现的问题包括一些此前已讨论过的现象，如对错误候选的推理、上下文缺失，以及与评估定义不符的标注。

每一类问题都指向不同的应对方向：对错误对象的推理指向提示词或输入的改写，证据不足则指向上下文的补全，标注不当需要清理数据，而反复出现的领域特异性歧义则可能提示我们需要更清晰的产品策略，或设立专门的评估类别。

手动审查数十乃至数百个案例固然耗时，但却往往能加速进展。一旦某种反复出现的失败模式被厘清，团队就可以有针对性地作出调整，并评估其是否解决了问题。

针对每个错误，不妨问一句：这个失败是由模型、提示词、输入、流水线、数据集，还是标注造成的？

这样的归因分析能够将模糊的质量问题转化为具体的工程任务。

7. 利用“LLM 作为裁判”聚焦人工审核

逐一手动审核每一条评估样本显然难以规模化。而“LLM 作为裁判”则可以通过分类那些显而易见的案例、识别可能被误标的样本，并将最具争议的案例优先交由人工审核来减轻这一负担。

不过，鉴于裁判本身也可能犯错，或因错误理由与其他模型达成一致，其输出应被视为又一种预测，而非“真相”。

更稳妥的做法是将裁判用于分诊：

1. 自动处理那些清晰且风险较低的案例。
2. 将置信度低、存在冲突，或影响较大的案例转交人工审核。
3. 定期抽样高置信度案例，检查是否存在系统性偏差。
4. 记录裁判、被评估系统与人工审核之间的分歧。
5. 像管理其他模型组件一样，对裁判的提示词进行版本管理和评估。

如此使用，裁判能够将人力集中于最有可能通过审核带来实质改变的案例。

8. Secret Scanning 带给我们的启示

我们的目标是在保障安全敏感工作流召回率的前提下，降低误报率。离线评估为我们提供了一个可控的平台，让我们能够在开启线上试验之前，比较提示词、模型、输入与流水线的各项改动。

经过反复评估与针对性的错误分析，我们在所评估的离线数据集上实现了 95% 的误报削减，同时将召回率稳定在我们设定的约束范围内。

更重要的是，我们清楚地了解了这一结果的成因：评估更贴近生产任务，各项改动均对照可复现的基线进行衡量，剩余的失败模式也被完整记录。

离线评估并未证明系统在所有生产场景下的表现，但它提供了充分的结构化证据，足以支撑我们带着清晰的风险认知与约束条件，进入线上试验阶段。

清单：在将 LLM 系统推向生产前

请使用这份清单来评估您的评估是否已为系统向前推进提供了充足证据。逐项核对，确保目标、数据、实验以及剩余的生产风险均已清晰明确。

产品目标

• 产品决策与主要成功指标是否明确？
• 安全与运营约束是否已划定？

数据与标注

• 评估数据是否贴近生产工作流，并涵盖各类难点案例？
• 我们是否清楚标注的形成过程，以及何处需要人工审核？

评估严谨性

• 提示词、模型、数据集与流水线的版本是否均已记录？
• 重大变更是否被单独隔离，并与已知基线对比？

错误分析与生产就绪

• 误报与误删是否已按类别完成审核？
• 我们是否能够重新运行评估，并说明离线结果与生产之间可能存在的差异？

先评估，再信任

随着基于大语言模型的系统逐步投入生产，评估应成为日常工程流程的一部分。一份严谨的离线评估能够展示产品目标是否在具有代表性的条件下得以实现，揭示尚存的不确定性，并判断系统是否已准备好进行受控的生产上线。

生产中的不确定性不可避免，而评估则让这些不确定性变得可见、可测且可控。

探索秘密扫描文档 >