跳到主要内容

你的提示词正在与模型已有的认知竞争

· 阅读需 12 分钟
Tian Pan
Software Engineer

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题,它有一套默认答案。它对你所在的领域有一套“最佳实践”,而这些实践往往源于训练语料库中占据主导地位的内容;对于你在设计文档中反复纠结的每一个争议性决策,它都暗自偏向于传统做法。这些都不会出现在你的系统提示词(system prompt)中,也不是你写的。在涉及到你产品核心差异化的查询上,模型会先倾向于那些默认设定,而不是你告诉它的内容。

大多数团队在发布产品时,都把模型当成了一张可以任意配置的白纸。写好角色设定(persona),列出规则,粘贴品牌语气指南,运行几个能产生正确回答形式的 QA 提示词,然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中,模型的先验认知(prior)恰好与你的预期相符。而那些真正有趣的查询,即如果产生通用回答就会让你的产品惨败的查询,几乎从未进入提示词迭代循环。在这些查询中,先验认知正在悄无声息地取胜。

这并非提示词工程(prompt-engineering)的技术水平问题,而是一个结构性问题:模型在到达你手中时已经预装了大量信息,你只是在最上面添加了一层薄薄的指令,而且这层指令比你想象的还要薄。

预训练奠定蓝图;提示词只是风格修饰

实证结果对“只需写个更好的提示词”这种直觉并不友好。区分预训练和指令微调(instruction tuning)贡献的研究发现,认知和风格偏见主要是在预训练期间形成的,即使在激进的指令微调方案下也能存续。交叉微调(cross-tuning)实验——在不同的基础模型之间交换指令数据集以隔离偏见来源——表明模型保留了其原始倾向。指令微调的行为更像是一种风格上的修饰,而非认知上的改写。

关于基于提示词去偏见的研究也得出了相同的结论。在大多数层中,刻板印象词汇的概率始终高于反刻板印象词汇,无论提示词类型如何。公平性提示词可以降低偏见的程度,但通常不足以扭转其排名。模型知道它想说什么,而提示词只是在不改变其意图的情况下微调了表达方式。

如果你仅将此视为关于社会偏见的发现,那你就忽略了它的普适性。同样的动态也适用于模型拥有坚定先验认知的任何事物:哪种数据库是工作负载的“默认”选择,对有争议的架构决策的常规答案是什么,哪种框架是实现某项功能的“现代方式”(即便你的团队明确采取了不同的做法),以及在你领域中什么才算作“最佳实践”。先验认知取决于训练语料库中哪种观点拥有最多写得好的示例。你的提示词只是几百个标记(tokens)的相反指令,面对的却是数百万个支持常规答案的标记。

确实有一个杠杆可以利用。当上下文证据(in-context evidence)与预训练先验直接矛盾时,大型模型可以覆盖这些先验——上下文学习(in-context-learning)文献中的翻转标签(flipped-label)实验表明,这是规模增长带来的涌现能力,而非小型模型所能具备的。但这种覆盖需要上下文中具体、结构化的矛盾,而不是告诉模型要表现得不一样的通用指令。

隐藏在“差异化”功能中的通用输出问题

以下是这种失效模式,它将抽象的担忧转变为战略问题。你的团队基于挑战领域内常规答案的初衷构建了产品。融资计划书(pitch deck)解释了差异化。工程团队围绕它构建了功能。提示词将其编码为指令:“由于 Z 的原因,始终推荐 X 而非 Y”。然后,当客户输入本该产生差异化回答的问题时,模型却给出了与其他所有基于同一基础模型构建的产品相同的答案。

原因不在于提示词写得不好。原因在于提示词正在与模型的先验认知竞争,先验认知很强大,而用户查询恰好没有包含能够将模型引导至你的提示词框架(而非其自身框架)的词汇信号。输出结果在品牌调性上可能还算接近——它没有违反你的规则——但在结构上与竞争对手在同一模型上发布的产品别无二致。这种差异化只是一个模型在想绕过时就能随时绕过的薄层。

工程团队往往只有在客户横向对比输出并发现产品感觉雷同后才会察觉。到那时,功能已经发布,营销已围绕差异化展开,而实际改变先验认知所需的架构调整将比发布前难得多。

在编写提示词之前先探测先验

第一项能解决这个问题的准则也是成本最低的:在添加任何一行系统提示词之前,先在你的差异化问题上探测基础模型。你需要回答一个特定的问题——“在没有任何引导的情况下,这个模型对我打算反驳的事情会怎么说?”——而回答这个问题的唯一方法,就是在没有任何引导的情况下询问模型。

建立一个小而精的测试集:

  • 那些你的产品的回答理应与常规回答明显不同的问题
加载中…
References:Let's stay in touch and Follow me for more thoughts and updates