提示词怎么迭代 | 提示词工程 | 做产品
提示词怎么迭代
前面几节讲了怎么写。但真实工作里,提示词很少一次写对——它是调出来的。而调的前提是:你得能判断这次改动是不是真的变好了。
你会遇到的现象
-
改完试了一条,感觉好了,上线后发现另一类输入变差了
-
提示词被反复修补,现在没人说得清每一句是为什么加的
-
换了个模型,不知道该不该改提示词,也不知道改完是好是坏
先有尺子
这一节只有一个核心动作:准备一组固定的测试样例。
20 到 50 条真实输入,每条配一个你认可的标准答案(或者至少是判断对错的标准)。这组东西是你所有提示词决策的尺子。
怎么挑:大部分是常见情况,留出五六条边界情况——特别长的输入、信息不全的、格式古怪的、以及那些你希望它回答「我不知道」的。边界情况最容易在改动中被牺牲掉,而它们恰恰是线上出事的地方。
这组样例有个额外好处:它和你要放进提示词的示例是同一份数据。挑出来的好样本进提示词当例子,剩下的当测试集——注意别用同一条既当例子又当测试,那等于开卷考试。
做这件事要花半天到一天。这是整个提示词工程里回报最高的一次性投入,因为之后每一次改提示词、换模型、加技巧,你都用它来判断。选型和降级那一节说的也是同一组样例。
一次只改一处
有了尺子,剩下的就是纪律。
**一、一次只改一个地方。**同时改三处,效果变好了你也不知道是哪一处起的作用——更糟的是,可能其中两处是好的、一处是坏的,净效果看起来只是微弱提升,你就把那个坏的一起留下了。
**二、每次改动记一句话。**改了什么、为了解决什么问题、跑分从多少变成多少。这句话以后会非常值钱——半年后有人问「这句限制能不能删」,你有答案。
**三、跑全套,不是跑一条。**这是最常被偷懒的一步。改完拿一条试试「感觉好了」,是提示词工作里最常见的自欺。必须全套跑完,看总分。
**四、没变好就改回去。**不要因为「花了时间写的」就留着。提示词里每多一句,都在增加成本、稀释重点、增加以后维护的负担。
关于顺序,建议按这个优先级试:**先补缺失的部件,再加例子,再调技巧,最后才动参数。**前面几步的收益通常远大于后面。
怎么读结果
拿到一组分数,有三件事别搞错。
**一、别只看总分。**总分从 38 提到 40,看起来是进步。但如果细看是「7 条变好、5 条变差」,那这次改动其实很危险——它可能只是把错误从一类挪到了另一类。逐条对比,看具体哪几条变了。
**二、区分「没写清楚」和「不稳定」。**这两种问题的解法完全不同。
同一条输入连续跑三次,如果三次都错、而且错得一样,那是提示词没写清楚,该补部件;如果三次结果飘忽不定,那是随机性问题,该调温度。拿不准的时候,把同一条跑三遍——这个小动作能省掉大量瞎调的时间。
**三、别过度拟合你的样例。**调到后期容易出现一种情况:为了让某两条特殊样例通过,加了很别扭的特殊说明。结果这两条过了,线上遇到的其他情况反而变差了。
信号是:**你开始为了单条样例写规则。**这时候该停下来问,这条样例是不是真的有代表性——如果它只是个孤例,不如接受它偶尔出错。
最后一句实在的:**提示词不需要完美,需要「足够好且稳定」。**把 85 分提到 90 分,往往比从 60 提到 85 花的时间还多。剩下那部分,用校验兜底或者人工复核来解决,通常更划算。
总分 38 → 40 看起来是进步。但逐条摊开是这样:
7 条变好 5 条变差 8 条没变 净 +2 —— 但这次改动其实很危险 它可能只是把错误从一类挪到了另一类。所以要逐条对比,看具体是哪几条变了。
分不清是「没写清楚」还是「不稳定」?把同一条跑三遍
三次都错,而且错得一样 → 缺部件,去补提示词
三次结果飘忽不定 → 随机性问题,去调温度
「改完拿一条试试,感觉好了」是提示词工作里最常见的自欺。必须全套跑完,而且不能只看总分——被牺牲掉的常常正是那几条边界样例,也正是线上出事的地方。
提示词的沉淀与版本 迭代出来的成果,怎么保存成能被维护的资产。
几个高杠杆技巧 按优先级试,技巧排在补部件和给例子之后。
选型与降级 同一组测试样例,换模型时也是用它来判断。
