GitHub官方博客发布指南，介绍如何将LLM评估从基准测试转向生产场景，并以secret scanning系统为例，说明通过离线评估和错误分析将误报减少 95% 同时保持召回率。
AI解读：大型语言模型在基准测试中表现好，不代表能在真实生产环境中可靠工作。GitHub团队在开发用于减少secret scanning误报的LLM系统时发现，关键不是看模型能否分类正确，而是能否在真实工作流中降低噪音并保持安全召回率。他们的做法是：先定义产品决策和护栏指标（如召回率作为安全约束），再把离线评估当作集成测试反复运行，并让评估数据尽可能接近生产输入。据博客介绍，这套方法最终在离线数据集上将误报减少了 95%，同时召回率保持在设定范围内。对开发者而言，这意味着当你要在生产环境部署LLM时，不应只依赖基准分数，而应模拟真实输入、记录版本、分类错误原因。普通用户无需立即行动，但如果你是正在构建LLM工具的团队，可以按文中清单核对你的评估流程是否足够严谨，避免把实验室结果直接当成生产可靠性证明。
GitHub官方博客发布文章《How to evaluate LLMs before production》，介绍其在开发用于减少secret scanning误报的LLM系统时总结的评估实践。作者包括微软首席应用科学家Mariko Wakabayashi和高级应用科学家Zixiao。文章称，该方法帮助团队在离线评估数据集上将误报减少 95%，同时将召回率保持在预设护栏内，但未说明具体测试规模或线上实验结果。
评估从产品决策出发，而非模型调整
当LLM系统表现不佳时，团队的第一反应往往是调整技术组件，如重写提示词、添加上下文或更换模型。但博客建议，在改动前应先明确评估要支持的产品决策。
以secret scanning为例，团队提出的核心问题是：系统能否在保持足够召回率以确保安全的前提下减少误报？这里误报指类似凭据但并非真实凭据的字符串，可能导致开发者浪费时间调查无需修复的告警。
作者指出，错误抑制真实凭据比让开发者多查看一条告警更严重，因此没有将精确率和召回率视为同等可互换的指标。精确率作为主要目标，召回率则作为安全约束：只有召回率下降在预设可接受范围内，实验才可推进。
评估标准被分为三层：主要结果（误报减少、精确率）、安全约束（召回率）、运维护栏（延迟、成本、可靠性、生产兼容性）。例如，一个假设实验A在精确率上大幅提升但召回率跌破护栏，不应推进；实验B精确率中等提升但召回率在护栏内，则可继续测试。
将离线评估视为集成测试，并版本化记录
帖子强调，LLM系统在首次评估后仍会不断变化，因此评估应像端到端集成测试一样反复运行。每当提示词、模型、输入构建或业务逻辑发生重大变化时，团队都会重新运行评估，并记录每次运行的提示词版本、模型版本、数据集版本和系统配置。
这使团队能回答诸如“新提示词是否提升精确率而不降低召回率？”或“模型升级是否只在特定类别中有效？”等问题。作者建议一次只改变一个主要变量，并与已知基线比较。例如，将提示词修订和模型升级分开评估，而非同时进行，以明确结果归因。
博客还建议定期测试模型升级，因为新模型可能用更简单的提示词就能超越旧模型的复杂调优，但也可能引入回归或改变成本、延迟。任何对提示词、模型或管道的重大更改都应在进入生产前经过离线评估。
评估数据需贴近生产场景，生产标签只是信号
离线评估只有在接近生产任务时才有用。在secret scanning中，模型通常需要结合周围代码和上下文来评估候选项，而数据结构差异可能显著影响结果。帖子举例说明，如果评估数据只包含一个明显的候选值，模型可能会忽略真实目标而聚焦于名称更安全相关的变量（如example_token），导致失败但难以察觉。
因此，评估管道应保留生产任务的特征，包括候选项、周围上下文、输入格式和系统逻辑。理想情况下，离线管道越接近生产管道，评估越有效；若两者差异大，高分可能只是反映问题更简单。
关于生产数据，博客提醒其标签往往记录工作流结果而非可靠的真实情况。例如，开发人员解决或关闭secret scanning告警可能是因为凭据已轮换、风险被接受、为解除阻塞而清除，或告警分类错误。这些情况在数据中可能看起来相同，但对应不同的真实状态。团队应询问标签如何创建、是否匹配评估问题，并对重要或模糊的子集进行人工审查。
合成数据和开放数据集可以补充覆盖，尤其是罕见或难以收集的案例，如模糊输入、缺失上下文和异常格式。帖子给出的例子包括用凭据字符串列表测试格式识别，但这类数据无法评估模型在真实代码中的推理能力。
错误分析揭示聚合指标隐藏的问题，LLM-as-judge辅助人工审查
聚合指标只能说明系统是否整体改善，错误分析则能指导下一步调整。团队通过审查误报和漏报样本，按其可能来源分类：模型、提示词、输入、管道、数据集或标签。这有助于将模糊的质量问题转化为具体的工程任务，例如推理错误指向提示词或输入框架，上下文缺失指向构建方式，标签错误则需数据清理。
手动审查大量样本虽耗时，但常能加速进展。作者建议为每个错误询问“它来自模型、提示词、输入、管道、数据集还是标签？”，一旦识别出重复失败模式，团队可进行针对性更改并验证。
对于大规模审查，博客建议部署LLM-as-judge进行分诊：自动处理清晰且低风险的案例，将低置信度或高影响案例路由给人类审查，并定期抽样检查高置信度结果。法官的输出应视为预测而非事实，因为其可能犯错或错误地同意另一模型。这可以将人类注意力集中在最可能改变结果的案例上。
最终成果与建议清单
据此，团队在离线评估数据集上实现了误报减少 95%，召回率保持在定义护栏内。作者强调，离线评估并未证明系统在所有生产场景的行为，而是为进入在线实验提供了结构化证据，并明确了风险与护栏。
文章为开发团队提供了检查清单，涵盖产品目标（明确决策和主要指标）、数据与标签（是否贴近生产并包含困难案例）、评估严谨性（记录版本、隔离变更）以及错误分析和生产就绪状态。博客原文由Mariko Wakabayashi撰写，其介绍称她为微软首席应用科学家，领导网络安全运营中的agentic AI工作流；合著者Zixiao为微软高级应用科学家，研究方向包括秘密检测和token高效AI系统。