我们不知怎的最终在生产环境中有了同一提示词的三个不同版本
摘要
一位开发者讲述了追踪一个模型回归问题,结果发现是由于热修复和不完整的合并导致生产环境中运行了同一提示词的三个不同版本,最终采用了提示词管理工具(OrqAI)以获得版本可见性。
花了整整两天时间追踪一个我以为的模型回归问题。结果发现只是生产环境中运行了同一提示词的三个不同版本。奇怪的是,只有一支团队在抱怨。其他人都说输出看起来正常。起初我忽略了这一点,因为我想如果模型变了,最终所有人都会受到影响。我重写了几次提示词,重新运行了评估,所有结果都通过了。这让我更加困惑,因为如果质量真的下降了,评估应该也会失败才对。最后我拉取了抱怨团队的追踪数据,与其他人做了对比。提示词不同。但不是天壤之别。只是少了一条指令。进一步挖掘后发现,有人几个月前为了那支团队的数据,在预发布环境做了热修复。本应是临时方案。但从未合并回代码库。与此同时,另一个小改动后来因为完全无关的原因被推送到了生产环境。所以最终我们有了三个版本:代码库、生产环境、预发布环境。唯一命中最早版本的人就是提交支持工单的团队。这有点尴尬,因为没人真的做错什么。我们只是没有一个统一的地方回答'当前实际运行的是哪个提示词?'这个问题。在那之后,我们不再把提示词放在代码库里。转而使用 OrqAI 来管理提示词,主要因为我厌倦了每次出问题都要扮演 Git 侦探。至少现在我能清楚看到哪个版本部署在哪里,而不是猜测是哪个分支或环境在六个月前被人编辑过。我很好奇有没有人能自动检测提示词漂移的好方法。不是模型漂移,而是提示词漂移。感觉这应该是一个大家都在多年前就解决掉的问题,但我似乎还没见过一套干净利落的方案。
相似文章
是否有人也弄不清哪个版本的提示词是“好的”?我最终为提示词构建了版本控制
作者描述了构建AI提示词版本控制系统以解决追踪哪个提示词版本最好的问题。
我们发现系统提示词有四个不同版本的“the”,但没人能确定哪个是正在使用的
研究人员发现一个实时AI模型中有四个不同版本的“the”系统提示词,突显出对实际部署版本的困惑。
你是如何让非工程师团队成员在生产环境中编辑提示词的?
作者讨论了在受监管领域中允许领域专家对AI代理的生产提示进行编辑所面临的挑战,并分享了一种使用带有GitHub后端的提示编辑器进行版本控制的解决方案。
团队如何大规模处理提示词质量保障?
一位处理约4万次对话/月的公司从业者描述了手动提示词质量保障的瓶颈,并询问团队如何利用自动化系统在生产中检测回归问题和用户挫败感。
一次提示注入测试抓住了我们差一点就发布的问题
一个团队描述了他们的提示注入评估套件如何在发布前发现文档助手的回归问题,并强调了在系统指令与检索数据之间保持严格层级的重要性。