如何在生产前评估法学硕士
这些是我们在评估法学硕士在现实世界秘密扫描方面的经验教训。如何在生产前评估法学硕士一文首先出现在 GitHub 博客上。
来自 GitHub AI 的官方动态，版本与适用范围以发布方说明为准。
GitHub AI · 查看官方发布中文机器翻译 · 原文附后
正文 · 来源原文
Mariko 是 Microsoft 的首席应用科学家，负责领导用于网络安全操作的代理 AI 工作流程的开发。她目前的兴趣集中在法学硕士驱动的系统、代理工作流程以及将前沿人工智能研究应用于现实世界的产品和运营。
语言模型可以在干净的基准上表现良好，但仍然难以处理生产中重要的情况。
在构建基于 LLM 的系统原型时，基准和精选数据集非常有用。他们帮助团队比较模型，测试初始提示，并确定一个想法在技术上是否可行。
但当系统接近生产时，评估问题就会发生变化。
真实的输入常常是不明确的。标签可能不一致。重要的上下文可能会丢失或被截断。评估集可能无法反映生产分布。基准测试中很少出现的边缘情况可能会成为常见的失败来源。即使离线指标有所改善，这些结果也可能无法完全转化为生产行为。
我们在评估旨在减少 GitHub 秘密扫描误报的基于 LLM 的系统时遇到了这些挑战。
秘密扫描可识别可能已提交到存储库的凭证，例如令牌和密钥。由于某些候选字符串类似于秘密，但实际上并不代表真正的凭据，因此开发人员可能会花时间调查不需要修复的警报。
我们需要了解系统是否可以减少噪音警报，同时保留足够的召回率以确保安全工作流程的安全，而不是确定法学硕士是否可以正确分类字符串。
在这篇文章中，我们分享了帮助我们从有希望的原型结果转向生产的实践。这些课程广泛适用于代码分析、开发人员工具、安全性、数据分析和其他生产工作流程中由法学硕士支持的系统。
1. 从产品决策开始，而不是从型号开始
当法学硕士系统没有达到预期效果时，第一反应通常是调整其技术组件。
团队可以重写提示、添加上下文、引入另一个推理步骤、调整周围的管道或切换模型。在进行任何这些更改之前，他们应该定义评估旨在支持的决策。
对于我们的秘密扫描工作，我们提出了以下要求：
系统能否减少误报，同时保留足够的召回率以保证生产安全工作流程的安全？
为了回答这个问题，团队必须决定哪些错误是可以接受的，哪些指标应该推动产品决策，以及哪些护栏必须保持在定义的阈值内。
在秘密扫描中，错误地隐藏真实凭据可能比要求开发人员查看附加警报更严重。因此，我们没有将精确度和召回率视为同等可互换的指标。
我们的主要目标是减少误报并提高精确度。召回作为安全约束：只有当任何减少保持在预定的可接受范围内时，实验才能继续进行。这为我们提供了一种评估权衡的清晰方法。我们选择的配置能够最大程度地减少误报，同时满足召回要求并满足我们的操作护栏。
我们将评价标准分为三个层次：
主要结果
这衡量了我们试图提高的用户利益：
假阳性减少精度
安全约束
查看英文原文
How to evaluate LLMs before production
These are the lessons we learned evaluating LLMs for real-world secret scanning. The post How to evaluate LLMs before production appeared first on The GitHub Blog .
正文 · 来源原文
Mariko is a Principal Applied Scientist at Microsoft, where she leads the development of agentic AI workflows for cybersecurity operations. Her current interests focus on LLM-powered systems, agentic workflows, and applying frontier AI research to real-world products and operations.
A language model can perform well on a clean benchmark and still struggle with the cases that matter in production.
Benchmarks and curated datasets are useful when prototyping an LLM-based system. They help teams compare models, test an initial prompt, and determine whether an idea is technically plausible.
But as a system moves closer to production, the evaluation problem changes.
Real inputs are often ambiguous. Labels may be inconsistent. Important context may be missing or truncated. The evaluation set may not reflect the production distribution. Edge cases that rarely appear in benchmarks can become common sources of failure. Even when offline metrics improve, those results may not translate cleanly into production behavior.
We encountered these challenges while evaluating an LLM-based system designed to reduce false positives in GitHub secret scanning.
Secret scanning identifies credentials such as tokens and keys that may have been committed to a repository. Because some candidate strings resemble secrets, but don’t actually represent real credentials, developers may spend time investigating alerts that don’t require remediation.