人工智能

如何在投入生产前评估语言模型系统?

GitHub 根据一项利用语言模型减少秘密扫描误报的系统评估实验,总结出一组在生产前评估 LLM 系统的实践。该实验强调,应将指标与产品决策关联起来,模拟实际运行环境,分析错误,并将离线评估视为一种结构化证据,而不是对系统在所有生产场景中行为的保证。

2026-08-25
2 分钟阅读
9 浏览量
فريق تحرير certi.news
如何在投入生产前评估语言模型系统?

语言模型可能在干净的基准测试中取得出色结果,却在生产环境中用户真正关心的模糊案例上表现不佳。这是 GitHub 在 Mariko Wakabayashi 和 Zixiao Chen 于 2026 年 8 月 25 日撰写的文章中提出的核心经验。文章基于一项评估实验:使用语言模型系统帮助减少 GitHub secret scanning 中的误报。

秘密扫描用于查找可能被提交到软件仓库中的凭据,例如令牌和密钥。但有些字符串虽然看起来像秘密,却并不是真实凭据,这会促使开发者审查不需要处理的警报。因此,对团队而言,问题并不是模型能否对单个字符串进行分类,而是它能否在保持足够召回率的同时降低噪声,从而确保敏感的安全工作流安全可用。

从产品决策开始,而不是从模型选择开始

GitHub 建议,在修改提示词、添加上下文或更换模型之前,先明确评估应支持的决策。在秘密扫描场景中,目标是减少误报并提高精确率,而召回率则被用作安全约束。误将真实凭据隐藏起来,可能比要求开发者额外审查一个警报更危险。

在实践中,评估标准被分为三层:衡量用户收益的基础结果,即减少误报和提高精确率;安全约束,即召回率;以及包括响应时间、成本、可靠性和与生产环境兼容性在内的运营护栏。因此,如果精确率提升伴随着召回率不可接受的下降,或使系统变得过慢、过于昂贵或难以集成,那么精确率的提升并不自动意味着成功。

让评估成为可重复的集成测试

评估并不是发布前的一次性步骤。提示词、模型、输入构建方式以及周围的系统逻辑都在持续变化,任何修改都可能带来改进、退化,或将错误模式转移到其他位置。因此,GitHub 在每次重要变更后重新运行评估,并记录每次使用的提示词版本、模型、数据集和系统设置。

团队还在每次实验中隔离一个主要变量:先将提示词修改与已知基线进行比较,再测试模型升级与该修改的组合。提示词和评估设置都按照代码进行管理:为其建立版本、记录变更,并保留重新运行和回滚旧设置的能力。这种做法能够帮助团队了解改进或退化的原因,而不是错误地将其归因于最近一次修改。

模拟生产任务,不要只依赖干净数据

当离线评估任务接近实际任务时,其结果才更有价值。在秘密扫描中,模型不一定只查看孤立的值,而是查看代码上下文中的候选项,以及可能缺失或分散的辅助信息。它可能会关注另一个看起来与安全更相关的值,例如代码中的测试令牌,而不是需要它评估的候选项。

因此,应保留生产任务的特征,包括待评估的候选项、周围上下文、辅助信息、输入格式和约束方式,以及更广泛的系统逻辑。如果评估使用了比现实更清晰的示例和更完整的上下文,那么结果可能反映的是一个比系统部署后将面对的任务更容易的问题。

将标签和数据视为可检查的证据

产品中的某个操作结果,并不意味着它代表可靠的真实标签。在秘密扫描中,关闭一个警报可能意味着凭据已经轮换、风险已被接受、警报被关闭是为了开启某项工作流,或者该警报被错误分类。这些情况在工作流数据中看起来相似,但在评估中回答的并不是同一个问题。

在使用生产数据之前,应了解标签是如何生成的、它是否对应评估问题,以及不同结果是否被合并到了同一类别中。GitHub 建议,对于重要或模糊的类别,应进行人工复核,而不是假定每个标签都正确。合成数据和公开基准可以弥补覆盖范围上的缺口,尤其是上下文缺失、格式异常以及接近凭据的相似值等罕见情况;但它们应当补充接近生产环境的数据,而不是取代这些数据。

分析错误,并谨慎使用评估模型

总体指标可以告诉团队系统是否有所改进,但无法解释下一步应改变什么。因此,GitHub 审查了误报和漏报样本,并将其可能原因归类为模型、提示词、输入、流水线、数据集或标签问题。这种分类将一般性的质量问题转化为明确的工程任务:改进输入构造、采用不同的上下文构建方式、清理数据,或制定更清晰的产品策略。

可以将另一个语言模型用作评估器,以减少人工审查负担,例如处理明确案例并排列模糊案例的优先级。但其输出并非事实依据;它可能出错,也可能出于错误原因而与被评估模型达成一致。更安全的模式是将低置信度、存在冲突或影响较大的案例交给人工处理,定期从评估器以高置信度分类的案例中抽样,并跟踪其与系统及人工审查者之间的差异,同时对其提示词进行版本管理和评估。

这项实验究竟证明了什么?

GitHub 表示,在所评估的离线数据集上,误报减少了 95%,同时召回率保持在既定的安全约束范围内。但公司并未将这一结果作为系统会在每种生产场景中以相同方式运行的证据。更重要的价值在于理解如何取得这一结果:更接近真实任务的评估、可重复的基线,以及经过记录的失败模式。

certi.news 的编辑解读:这里真正发生的变化并不是推出一个新模型,而是将 LLM 系统评估从一次基准测试转变为持续的工程流程,并将其与明确的决策、安全边界和运营边界关联起来。这一点对软件、安全和开发者工具团队都很重要,因为单一指标的改善可能掩盖召回率的危险下降或成本上升。另一方面,结果仍然受评估集、标签质量以及离线测试与生产行为之间无法完全消除的差距所限制。因此,评估是进入受控生产实验的基础,而不是发布后风险监控的替代品。

新闻来源
ف
作者

فريق تحرير certi.news

同一分类

你可能还喜欢

查看所有新闻