2 篇博文 含有标签「team-practices」

想要发现你的 AI 团队缺乏评测纪律，最快的方法就是分别在 Slack 私聊中询问三名工程师：“你上次的提示词（prompt）修改提升了质量吗？”——然后看着他们三个人都回答“是”，但给出的却是三个不同的数字，针对的是三个不同的切片（slice），在三台不同的笔记本电脑上运行，而且团队中没有其他人能复现这些结果。从教科书式的定义来看，这不单纯是评测问题。教科书会说你没有评测。而现实情况更糟：你有 太多 的评测，每个评测都是私有的，每个都能衡量一些真实的东西，但没有一个能汇总成组织可以据此制定计划的单一指标。

这就是“影子评测（shadow eval）”反模式，大多数 AI 团队在承认这一点之前，这种状态持续的时间比他们愿意承认的要长。它看起来效率很高——每个工程师都有一个 notebook，每个 PR 都附带一张通过率的截图，每次站会都会提到“在长尾切片上取得了胜利”——而且它能在季度评审中幸存下来，因为“我们做评测”的门槛太低了，只要运行任何内容都算。但组织得不到任何信号。领导层无法判断上个月的三次提示词修改是推动了产品进步还是原地踏步，因为三名工程师是根据三个私有切片进行衡量的，而且在切换文件的那一刻就停止了对之前基准（baseline）的追踪。

负责构建客户支持 AI 的工程师离职去迎接新工作了。在他们的最后一天，你进行了一次离职面谈，并要求他们记录下所知道的一切。他们写了几段文字来解释系统的工作原理。六个月后，客户满意度评分开始下降。有人建议微调系统提示词（system prompt）的语气。另一位工程师进行了修改，运行了几次手动测试，然后上线了。三周后，你发现原始系统提示词中的一个特定措辞其实起到了没人知道的关键支撑作用——它是防止模型在周五下午过度升级工单的唯一机制，这是最初的工程师注意到并用一句话悄悄修复的模式。

没有人知道那句话的存在是有原因的。它看起来像是实现细节，但实际上是组织知识（institutional knowledge）。