Mariko是微软的首席应用科学家，负责为网络安全运营开发代理AI工作流程。她目前的兴趣集中在LLM驱动的系统、代理工作流程，以及将前沿人工智能研究应用于现实世界的产品和运营。语言模型可以在干净的基准上表现良好，但仍然难以处理生产中重要的案例。
在对基于LLM的系统进行原型设计时，基准测试和精选数据集非常有用。他们帮助团队比较模型，测试初始提示，并确定一个想法在技术上是否合理。但随着系统向生产靠拢，评估问题发生了变化。真实的输入往往是模棱两可的。标签可能不一致。重要上下文可能缺失或被截断。评估集可能无法反映生产分布。
很少出现在基准中的边缘案例可能成为常见的故障来源。即使离线指标有所改善，这些结果也可能无法完全转化为生产行为。我们在评估基于LLM的系统时遇到了这些挑战，该系统旨在减少GitHub秘密扫描中的误报。秘密扫描标识可能已提交到存储库的凭据，如令牌和密钥。
由于某些候选字符串类似于机密，但实际上并不代表真实的凭据，因此开发人员可能会花时间调查不需要修复的警报。我们不需要确定LLM是否可以正确地对字符串进行分类，而是需要了解系统是否可以减少噪音警报，同时保留足够的召回率，以确保安全工作流程的安全。
在这篇文章中，我们分享了帮助我们从有希望的原型结果转向生产的实践。这些经验教训广泛适用于代码分析、开发人员工具、安全、数据分析和其他生产工作流程中由LLM提供支持的系统。1.从产品决策开始，而不是模型当LLM系统不能按预期运行时，第一反应通常是调整其技术组件。