像测试代码一样测试你的提示词

提示词是一段在生产环境中运行、塑造你用户所见之物的逻辑。我们绝不会发布这样一个函数:只在一个输入上跑过一次,瞄一眼输出,就宣布它没问题。然而大多数提示词恰恰就是这么开发出来的:调一调措辞,在眼前那个例子上试一试,看到点不错的,就发布。本文要谈的,是把我们对代码早已使用的那套纪律——测试用例、基线、回归检查——应用到提示词上,因为提示词配得上这套纪律,缺了它就会出问题。

为什么那个演示在骗你

提示词工作中单一最危险的习惯,是凭一个亮眼的输出来评判一条提示词。你写一条提示词,在一个精挑细选的输入上跑,得到一个很棒的答案,就觉得大功告成。但那一个输入,代表不了真实用户会发来的种种东西。下一个输入——措辞不同、缺了个字段、更长、更怪——可能产出垃圾,而你不会知道,直到某个用户替你发现了它。

那个演示有误导性,原因和单次通过的运行在代码里误导人是一样的:它测的是你心里设想的那条顺利路径,而非你没想到的那些情形。提示词尤其容易栽在这上头,因为输出即便错了也流畅而自信,所以一个糟糕的结果读起来貌似可信。唯一的防御,是停止信任单个输出,转而在一组真正像现实的输入上度量行为。

搭一个像现实的测试集

测试提示词,从汇集一组有代表性的输入开始——相当于测试用例。如果你有真实使用数据,就从中抽取,并确保这组输入覆盖你实际见到的多样性:典型请求,但也包括那些短的、畸形的、边界情形,以及那些"没有好答案"的情形。一组只有简单输入的测试集,只会告诉你你的提示词能处理简单输入,而这你早就知道了。

对每一个输入,判定一个好的输出长什么样。有时存在一个你能精确核对的唯一正确答案。更多时候,"好"是一组属性:格式对、相关事实包含在内、没有捏造、失败情形处理得当。在你跑任何东西之前先写下"好"意味着什么,正是把"那看起来不错"变成一个真正的通过或不通过判断的关键。测试集加上它的成功标准,就是你那条提示词的规格说明,被具体化了。

决定你将如何给输出评分

代码测试通常检查精确相等。提示词输出很少有唯一的精确正确答案,所以你需要一套贴合的评分方法。对于结构化输出——一个特定格式、一个必需字段、一个取自固定集合的值——你可以编程检查:它能否解析、字段在不在、值是否有效。这些检查很便宜,值得自动化,因为它们抓住的是应用里最要紧的那些机械性失败。

对于开放式输出,评分是基于判断的:答案是否覆盖了关键点、是否避免了捏造、是否切中了正确的语气。你可以靠阅读来做,而对于小规模的集合,阅读没问题,而且被低估了。在更大规模上,一种常见做法是让一个模型按你写的评分量表来给输出评分——有用,但只和那张量表一样好,值得对照你自己的阅读做抽查。要点是有意地挑选一种评分方法,而不是退回到"看起来还行",那不是一种方法。

在改动任何东西之前,先确立一条基线

在你开始改进一条提示词之前,拿你当前的提示词在整个测试集上跑一遍,记录它的表现。那个分数就是你的基线——每一次改动都要据以衡量的那个东西。没有基线,你就是在盲飞:你会做一个改动、看到一个输出变好,却完全不知道这条提示词整体上是变好了还是变坏了。一个修好一个情形、却悄悄弄坏另外三个的改动,看起来像进步,实则相反。

基线正是让提示词工作得以累积、而非沦为随机游走的东西。每一个候选改动都在同一组输入上跑,并与基线比较。如果它在整组上表现更好,它就成为新的基线。如果它表现更差,你就丢弃它,哪怕它产出过一个你爱不释手的输出。这是核心循环,也正是让重构代码变安全的同一个循环:一个你随时都能据以核对的已知良好参照。

一次只改一样东西

当一条提示词表现不佳时,诱惑在于一口气重写它一半——新指令、新示例、新格式,全都一起上。如果结果更好,你不会知道是哪个改动帮上了忙;如果更差,你不会知道是哪个改动坏了事。无论哪种情况,你都没学到任何可迁移的东西。改一个变量,跑测试集,与基线比较,记录结果。然后改下一个。

这样每次迭代更慢,整体上却快得多,因为你在积累关于你的提示词对什么有反应的真实知识。你会了解到,这个示例修好了格式问题、这条指令减少了捏造、这次重组毫无作用。那份知识会在整个项目以及未来的提示词之间复利累积。相比之下,散弹式重写产出的,是一条没人理解它为何能用、日后也没人能安全修改的提示词。

每次改动发布前都重跑测试集

最后一块,是把你的测试集当成一套回归套件来对待。模型会更新、需求会变,一条本来好用的提示词可能悄悄开始失败——包括在它过去能处理的情形上。每次你改动提示词时,以及理想情况下即便你没改动也按时间表定期,重跑整组并确认没有任何东西发生回归。一个在新情形上改善、却弄坏旧情形的改动,就是一次回归,而抓住它的唯一办法,就是持续跑那些旧情形。

这也在底层模型变化时保护你。因为你的测试集编码了你实际依赖的行为,重跑它会立即告诉你,一个新的模型版本是否仍满足你的要求,还是悄悄弄坏了什么。测试集成了一份耐久的资产:一个能熬过模型更替、团队更替,以及"为何这条提示词要这么写"这一记忆缓慢侵蚀的"可用"的定义。

总结

把一条提示词当成它本就是的生产代码来对待。搭一个像真实使用的测试集,边界情形包括在内,并为每个输入写下一个好的输出意味着什么。有意地挑选一种评分方法,在改动任何东西之前确立一条基线,然后一次改一个变量地改进提示词,同时在整组上对照那条基线度量。把这组输入留作一套回归套件,并在每次改动前、每次模型更新后重跑它。提示词民间偏方和提示词工程之间的差别,恰恰就在于此:一个凭单个演示评判,另一个在一整组上度量——而只有后者,能在输入、模型或需求发生变动时仍持续奏效。