很多 LLM 项目在演示阶段表现很好，接入真实工作流后却开始暴露问题。原因往往不在模型突然变差，而在演示数据过于干净，生产输入却充满歧义、缺失上下文和不一致的标签。8 月 25 日，GitHub 分享了他们评估 LLM secret scanning 系统的实践，其中最值得借鉴的一点是：上线前评测不应只回答“模型准不准”，还要回答“它是否在可接受的安全和运营边界内解决了真实问题”。
这套方法对代码分析、客服分流、风控审核和其他 LLM 应用同样适用。模型分数只是证据的一部分，能否支持一个清晰的产品决策，才是评测的落点。
背景：secret scanning 为什么需要更细的评测
secret scanning 会在代码仓库中寻找可能泄露的 token、密钥等凭据。问题在于，很多字符串只是看起来像凭据，实际上可能是文档示例、测试数据或占位符。误报太多，开发者就会花时间处理本来不需要修复的告警；漏掉真实凭据，则可能让安全风险继续存在。
GitHub 评估的系统，目标是降低误报，同时保留足够的召回率。这个目标比单纯判断一个字符串“是不是 secret”更接近生产需求，因为安全工作流通常无法把精确率和召回率当成同等重要的指标。
先决定要改善什么，再决定怎么调模型
GitHub 将评测指标分成三层，这个拆分很适合直接借鉴到自己的 LLM 项目中：
| 层级 | 要回答的问题 | 示例指标 |
|---|---|---|
| 主要目标 | 用户体验或业务结果改善了吗？ | 误报下降、精确率提高 |
| 安全约束 | 是否引入了不能接受的风险？ | 召回率不能跌破阈值 |
| 运营约束 | 系统是否值得上线？ | 延迟、成本、可靠性、兼容性 |
这样的指标结构能避免一个常见误区：只要精确率上升，就把实验当成成功。如果一个改动让误报减少很多，却把召回率降到了安全底线以下，它就不应该进入下一阶段。反过来，一个提升幅度稍小、但保住了召回率且成本可控的版本，可能更适合线上。
因此，评测开始前应该先写下一个具体的产品问题，例如：
在不突破召回率和延迟约束的前提下，系统能否减少开发者需要人工确认的告警？
这句话比“比较三个模型哪个更强”更有用。前者会决定数据、指标和发布门槛，后者很容易把评测变成模型排行榜。
把离线评测当成集成测试
LLM 系统不会因为第一次评测通过就保持不变。提示词、模型版本、上下文拼接方式和周边业务逻辑都会变化，其中任何一项都可能带来回归问题。GitHub 的做法是把离线评测当成端到端集成测试，在重要变更后重复执行，并记录每次运行的条件：
- 提示词版本；
- 模型版本；
- 数据集版本；
- 输入构造和系统配置；
- 精确率、召回率、延迟及备注。
实验时还应尽量一次只改变一个主要变量。先单独测试提示词修改，再单独测试模型升级，最后才测试组合效果。这样才能知道结果变化来自哪里，也方便回滚和复现。
GitHub 特别提醒，提示词和评测配置应该像代码一样管理。没有版本记录，就很难解释某次指标上涨究竟是模型变了、数据变了，还是测试条件变了。
评测集必须像生产现场，而不是像考试题
一个干净的测试样例，通常只有一个明确候选值；真实代码则可能同时包含示例 token、环境变量、测试数据和附近的相似字符串。模型如果被上下文中的另一个值吸引，即使给出了一段听起来合理的解释，也可能判断错了对象。
所以，离线评测至少要保留生产任务中的关键形状：
- 实际要判断的候选值；
- 模型在生产中能看到的周边代码和上下文；
- 相关但可能不完整的辅助信息；
- 真实系统使用的输入格式和约束；
- 模型前后的管道逻辑。
数据标签也不能直接当作真相。一个告警被关闭，可能是凭据已经轮换、风险被接受、告警需要被清理，也可能确实是误报。把这些结果全部归为“假阳性”，会让指标看起来整齐，却无法支撑安全决策。重要或含糊的样本需要人工复核，至少要先弄清标签是怎么产生的，以及它是否真的对应当前要评估的问题。
合成数据和公开数据仍然有价值，尤其适合补充罕见输入、缺失上下文和特殊格式。但它们应该用来填补覆盖缺口，不能完全替代生产形态的数据。一个能识别常见密钥格式的模型，不一定能在真实代码中正确判断某个候选值。
总体指标看不见的地方，要靠错误分析补上
精确率和召回率只能告诉我们整体变好了还是变坏了，不能解释错误是怎样发生的。GitHub 的实践是抽样检查误报和漏报，再按可能的来源分组：
- 模型理解错了；
- 提示词没有把候选目标说清楚；
- 输入或上下文构造不完整；
- 管道把信息放在了不合适的位置；
- 数据集没有覆盖这类情况；
- 标签本身不可靠。
这个分类会把“模型效果不好”变成更具体的工程任务。模型总在看错候选值，可能需要重写输入边界；上下文缺失，应该调整数据构造；标签混乱，则要先清理数据，而不是继续堆提示词。
对于大量样本，可以让另一个 LLM 做初步分流，但不能把 LLM-as-judge 的结果直接当成事实。更稳妥的用法是让它处理低风险、容易判断的样本，把低置信度、模型与标签冲突、以及影响较大的样本交给人工复核。同时，定期抽查它判定为“很有把握”的样本，防止系统性错误被自动化流程掩盖。评审模型自己的提示词和版本，也需要纳入同一套回归评测。
一套可以落地的上线门槛
结合 GitHub 的方法，一个 LLM 系统在进入线上实验前，可以先检查下面几件事：
1 | 产品目标：要改善的用户决策是什么？ |
线上实验也不应被理解为“离线分数够高就全量发布”。更合适的做法是先带着明确的 guardrail 小范围验证，继续观察误报、漏报、延迟和成本，再决定是否扩大流量。离线评测的作用，是把不确定性提前暴露出来，为可控实验提供依据，而不是替团队保证所有生产场景都不会出错。
这对开发者意味着什么
今天很多团队把 LLM 接入代码审查、日志分析、客服分流或运维自动化。它们的共同点是，错误代价并不对称：一次多余的人工确认可能只是浪费时间，一次漏掉的安全告警却可能带来更大的后果。
因此，接入 LLM 前不妨先做三件小事：
第一，把“用户最终要做的决定”写出来，而不是从模型能力出发设计指标。第二，保留一批真实、困难且经过复核的样本，持续加入新发现的失败案例。第三，把评测运行接入日常工程流程，模型、提示词或输入管道发生变化时自动回归。
这样做的收益不只是找到一个分数更高的模型。团队还能知道系统在哪些情况下可靠、哪些情况下必须交给人处理，以及下一次改动应该先动哪里。
结语
GitHub 在这次分享中给出的最终结果是：在其评估的离线数据集上，误报减少了 95%，同时召回率保持在预先定义的约束内。但文章也明确提醒，这并不能证明系统在所有生产场景都同样有效。它提供的是足够结构化的证据，让团队可以在理解风险和保留护栏的前提下进入线上实验。
这也是 LLM 生产化最值得重视的转变：评测不再是上线前的一次考试，而是持续伴随产品的工程环节。先定义决策，再构造接近生产的数据，接着用错误分析推动改动，最后在明确的边界内做线上验证。模型可以换，提示词可以改，但这套把不确定性变得可见、可测量、可管理的过程，应该留下来。