工程 / 工程
将LLM推向生产前，GitHub工程师总结了这些评估经验
GitHub工程师Mariko Wakabayashi与Zixiao Chen在为Secret Scanning功能评估LLM系统的过程中，发现了一个普遍存在的问题：模型在干净的基准数据集上表现良好，却在真实生产输入中频繁失效。真实数据往往存在歧义、标注不一致、上下文缺失等问题，而基准测试中罕见的边缘案例在生产中可能成为主要失败来源。该团队的目标并非单纯判断模型能否正确分类字符串，而是要在降低误报率的同时，保持足够高的召回率以满足安全工作流的要求。为此，他们建立了一套以产品决策为核心的评估框架，将指标分为主要目标、安全约束和运营护栏三个层级，并将离线评估视同集成测试，每次变更均重新运行并与基线对比。这套方法论适用于代码分析、开发者工具、安全审计等多类LLM生产系统。
在GitHub的Secret Scanning项目中，工程团队需要判断一个LLM系统能否在减少误报的同时，保持足够的召回率以确保安全工作流的可靠性。这个问题的本质不是技术性的，而是产品性的。团队首先明确了评估要支持的决策：哪些错误是可以接受的，哪些指标应该驱动产品决策，哪些护栏必须始终保持在预设阈值之内。这一前置步骤避免了团队在没有清晰目标的情况下盲目调整提示词或切换模型。
在指标体系的设计上，团队将精确率和召回率区别对待，而非视为同等重要的可互换指标。降低误报、提升精确率是首要目标；召回率则作为安全约束存在——任何实验方案只有在召回率下降幅度不超过预设范围时才能推进。此外，延迟、成本、可靠性和生产兼容性构成运营护栏，决定结果是否具备实际部署价值。这种三层评估结构使团队能够清晰地权衡不同实验方案的利弊。
团队将离线评估视同端到端集成测试，而非一次性工作。每当提示词、模型、输入构建方式或业务逻辑发生有意义的变更时，评估就会重新运行。每次运行都记录提示词版本、模型版本、数据集版本和系统配置，以确保结果可与已知基线进行比较。这种做法使团队能够回答诸如「新提示词是否在不降低召回率的前提下提升了精确率」或「模型升级是否在整个数据集上均有改善」等具体问题。
为了确保实验结论的因果清晰性，团队坚持每次只改变一个主要变量，并将每次运行与已知基线对比。例如，提示词修订和模型升级会分别独立评估，再测试两者组合效果。这是因为即使是细微的提示词改动也可能显著影响模型行为，而模型升级则可能同时影响质量、成本、延迟和输出一致性。若两者同时变更，则无法判断改善或回归究竟源于哪一因素。提示词和评估配置被像代码一样管理，支持版本控制和回滚。
这套评估方法论的核心洞察在于：评估的目的是为产品决策提供证据，而非单纯追求指标数字的提升。一个大幅提升精确率但使召回率跌破安全阈值的方案，并不构成真正的改进；同样，一个提升质量但导致系统过慢、过贵或难以集成的方案也不应被采纳。GitHub团队的经验表明，在将LLM系统推向生产之前，清晰定义成功标准、建立可重复的评估流程，是从原型走向可靠生产系统的关键路径。
要点
- 评估应以产品决策为起点，在开始调整模型或提示词之前，先明确哪些指标是目标、哪些是约束、哪些是护栏
- 精确率与召回率不应被视为同等可互换的指标，在安全敏感场景中召回率应作为硬性约束而非优化目标
- 离线评估应像集成测试一样持续运行，每次有意义的系统变更后都需重新评估并与基线对比
- 每次实验只改变一个主要变量，提示词和评估配置应像代码一样进行版本管理，确保结果可归因
- 生产环境中的真实输入往往存在歧义和边缘案例，基准测试表现无法直接预测生产行为
原始标题：How to evaluate LLMs before production
本文由 DataHub 基于公开来源整理，用于信息发现与摘要阅读；具体事实、数据和后续更新以原始来源为准。