上线前如何评估 LLM：GitHub 在生产前评估大模型的实践方法

GitHub 官方博客发表文章，由 Mariko Wakabayashi 和 Zixiao Chen 撰写，分享为生产环境评估 LLM 的实践教训。背景：GitHub 评估一个基于 LLM 的系统，用于减少秘密扫描（secret scanning）的误报。语言模型可以在干净的基准上表现良好，却在生产场景中失败——基准和精选数据集适合原型阶段，但系统接近生产时，评估问题发生变化：真实输入往往模糊、标签可能不一致、重要上下文可能缺失或截断、评估集可能不反映生产分布、基准中罕见的边缘情况可能成为常见失败源。本文基于 GitHub 官方文章，系统解读五个评估实践。

1. 从产品决策开始，而不是从模型开始

当 LLM 系统表现不符预期时，第一反应往往是调整技术组件：重写提示词、添加上下文、增加推理步骤、调整管线或换模型。但在做这些之前，应定义评估要支撑的决策。

以秘密扫描为例，核心问题是：系统能否在保持足够召回率以保证安全的前提下减少误报？

决策框架：

• 确定哪些错误可以接受、哪些指标驱动产品决策、哪些护栏必须保持在阈值内
• 秘密扫描中，错误抑制真实凭证比让开发者多审查一个告警后果更严重——因此精确率和召回率不是可互换的指标
• 主要目标：减少误报、提高精确率
• 召回率作为安全约束：只有减少在预定可接受范围内才能推进实验

三级评估标准

示例：实验 A 精确率大幅提升但召回率跌破安全护栏——不推进；实验 B 精确率中等提升且召回率在护栏内——继续测试。B 更符合产品目标。

2. 把离线评估当作集成测试

LLM 系统在首次成功评估后仍持续变化：团队修改提示词、采用新模型、改变输入和上下文构建、改进业务逻辑。任何变更都可能改进系统、引入回归或意外改变行为。

做法：

• 每当提示词、模型、输入构建或系统逻辑有意义的变更时，重跑离线评估
• 评估要可重复，每次结果可与已知基线比较
• 每次运行记录：提示词、模型、数据集版本、系统配置
• 可回答：新提示词是否在不降低召回率的情况下提升精确率？模型升级是全面改进还是只改进了某些类别？变更修复一种错误模式是否引入另一种？

一次只改一个主要变量

• 可重复性不够，实验设计还要让结果成因清晰
• 一次只改一个主要变量，与已知基线比较
• 示例：先分别评估提示词修订和模型升级，再一起测试
• 提示词和评估配置像代码一样管理：版本化、记录变更、保留可复现性、可回滚

定期测试模型升级

• 模型欠佳时开发者常给提示词加指令，有时有效但不总是
• 提示词可能承载来自模型本身的复杂性：更强模型可能用更简单提示词比旧模型用大量调优表现更好
• 更简单的提示词也更易理解、测试和维护
• 新模型可能在某个类别改进、其他类别回归，还影响成本、延迟、输出格式、管线兼容性
• 评估流程应便宜且可重复，让测试新模型成为常规

3. 让离线评估贴近生产

离线评估只有像生产任务才有用。秘密扫描中模型很少评估一个干净、孤立的值：它可能需要结合周围代码和其他相关信息评估候选——这些信息可能相关、不完整或分散注意力。呈现方式的差异会实质影响结果。

离线评估需保留生产任务的重要特征：

• 被评估的候选
• 模型可用的周围上下文
• 相关的支持信息
• 输入格式化和约束方式
• 模型周围的系统逻辑

示例：candidate_value 是系统应评估的值，但模型可能因 example_token 的变量名看起来更安全相关而聚焦它。这类失败在评估示例只含一个明显候选时容易被忽略——正是因为离线评估保留了一些真实秘密扫描工作流中的模糊性和干扰，问题才暴露。

离线管线越接近生产管线，评估越有用。两者不同时，强离线分数可能只是反映了比部署场景更简单的问题。

4. 把生产标签当作信号，而非不证自明的真相

生产数据能让评估更有代表性，但其标签往往捕捉工作流结果而非可靠的真实标记。已关闭或已解决的秘密扫描告警不一定代表误报：

• 凭证可能已轮换
• 风险可能被接受
• 告警可能需要清除以解除工作流阻塞
• 告警可能被错误分类

这些结果在产品数据中看起来相似，却代表不同的真实状态。使用生产标签前要问：

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

对重要或模糊子集，可能需要人工审查。目标不是消除每个不完美标签，而是确保评估数据足够准确以支撑决策。

5. 用合成和开放数据集填补覆盖缺口

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

• 合成示例对测试稀有或难以收集的用例很有价值：模糊输入、缺失上下文、异常格式、代表性不足的失败模式
• 凭据字符串列表可测试模型是否识别常见格式，但不能完全评估模型如何在真实代码中推理候选
• 适配外部示例以匹配任务，审查不一致的标签

总结

GitHub 上线前评估 LLM 的五条实践：一、从产品决策开始——定义评估支撑的决策、哪些错误可接受、哪些指标驱动决策、哪些护栏必须满足（秘密扫描中精确率是主目标、召回率是安全约束，两者不可互换）；二、把离线评估当集成测试——每次有意义变更重跑、记录提示词/模型/数据集/配置、一次只改一个变量、提示词和配置像代码一样版本化、定期测试模型升级；三、让离线评估贴近生产——保留生产任务的候选、上下文、格式和系统逻辑特征，管线越接近生产评估越有用；四、生产标签是信号而非真相——关闭/解决的告警不代表误报（可能轮换、接受风险、清除阻塞、误分类），使用前问标签如何创建、是否匹配问题、是否混类，重要子集人工审查；五、用合成和开放数据填补缺口——合成示例补充而非替代生产类数据。核心原则：评估的目的是产生支撑产品决策的证据，而不是追求技术指标的最优。

来源：https://github.blog/ai-and-ml/llms/how-to-evaluate-llms-before-production/