跳到正文
Hacker News· kinabalu76·· 8 天前AI 评分23

为什么 LLM 会「听」得太快:过早下结论的代价与解法

Listening Too Fast

AI 导读

文章指出,人类听者往往在说话者讲完前就形成判断,而大语言模型同样会过早「承诺」结论——它把收到的第一条消息当作完整规格,若首条是背景或否定表述,模型就会围绕它作答。作者借用代码开发中的 red/green 测试提出「承诺门」:在提出修复方案前,先用一个可运行且失败的测试具体复现问题,以此约束模型的过早承诺。

正文 · AI 翻译

关于人类心理学的一个有趣事实:听者在说话者说完之前就已经做出了推断。

每个人都会这样。我会这样,你会这样1,你的朋友会这样,你的团队也会这样——当你用一堆平淡无奇的细节开始一个站会,只是为了把它们打发掉,等到你讲到真正有趣的内容时,你的同事早已心不在焉,因为他们认为那些平淡无奇的东西就是全部了。

这种推断中唯一的变量是推断落定得有多早,以及一旦落定后有多难被推翻。

这是接收者的特性,而非发送者的,而我们教的所有关于清晰沟通的内容几乎都是针对发送者的。

把结论放在前面。不要把重点埋起来。在解释理由之前先说明请求。军队称之为BLUF,即“底线在前”,新闻业称之为倒金字塔结构,两者都是好建议,但从未有一次能阻止听者在从你那里听到大约七个词后就决定你的意思。2

注意

我最喜欢的打磨练习之一是根据搞笑诺贝尔奖的24/7讲座规则要求做总结。你要用两种方式总结:用七个词,以及用二十四秒。这是一个很棒的练习,而且很难。

极端的例子是约翰·冯·诺伊曼。他的同事讲述的关于他的故事在一个点上是一致的:他会在你还没说完前提之前就得出你论证的结论,有时甚至在你还没说完第一句话之前。

通常的解读把这当作衡量他有多聪明的标准,而他确实极其聪明——聪明到我无法评估他——但这些故事实际描述的是延迟。他内心的听者几乎立即做出推断,而且通常是对的,这是它显得像才华而非无礼的唯一原因。同样的机制如果命中率更低,就只是打断而已。

大多数人都是这样,用同样的机制,但命中率低得多。打断不是问题。打断是已经发生的推断的可见症状。听者根据到目前为止听到的内容构建了一个结构,认定它已经完整,然后开始对这个结构做出回应,而不是对说话者。我们中的一些人——希望是大多数人,我总有一天也会加入你们——学会了不再出声打断。这并没有阻止推断;它只是把推断移到了内部,在那里它看起来像耐心,但其实不是。

顺序会以一种特定的方式让情况更糟。如果说话者先讲背景、注意事项,或者他们不是什么意思,听者会把这些材料当作核心内容来消费,因为它先到达,而接收者在结束之前并不知道什么才是真正相关的3。等到真正的要点出现时,听者已经有了一个错误的结构,现在正在用这个结构来调和要点,而不是接收它。说话者体验到的是没被听到。听者体验到的是听得清清楚楚,谢谢。双方说的都是实话。

这些都不是新问题,也没有方便、简单的解决办法,因为你无法配置另一个人的听者。最多,你可以请他们等待。你无法让他们不做决定。

接受指令的接收者

语言模型也会过早承诺,但原因不同。它没有打断别人的社交压力,也没有八秒的注意力预算。它拥有的是一条消息,并且它把收到的这条消息当作完整的规格说明,因为从它所处的位置来看,它就是。如果你的第一条消息是背景,模型就回答背景。如果你的第一条消息是一个约束,模型就只针对那个约束求解,别的什么都不管。它比人类更早、更用力地承诺,默认如此,完全没有人类可能会有的那种犹豫——对于回答一个尚未被提出的问题4。

并不是说模型比它所替代的对话者更快或更慢,更聪明或更笨。而是它的承诺点是一个参数。有史以来第一次,对话的接收方可以被指示。你可以告诉它何时做决定。

过早承诺的代价

这些失败是可以识别的,任何使用这些工具超过一周的人都见过其中大部分,或者读过关于它们的恐怖故事。

你描述一个系统的当前状态,模型在你还没说出它到底哪里有问题之前就开始提出修改建议。

你以“我们不想用 X”开头,结果 X 出现在答案里,因为否定词被当成了话题。

你在三条消息里给出三个约束,模型独自自信地解决了第一个,而第二个和第三个现在成了对一个没有考虑它们的设计的补丁。

你提供背景来引出问题,模型却把背景当成了问题。

这些都是同一个失败,以同样的方式表达,只是层次不同。接收方在一个不完整的结构上做出了承诺。

代价不是错误答案本身;错误答案很廉价。但现在你是在审计一个自信、流畅、内部自洽的错误答案,而不是朝着正确答案构建,而审计可能比答案本身花的时间更长。

我在这上面浪费了大量时间,时间是在承诺的那一刻丢失的,而不是在我注意到的那一刻。我是在最初与模型协作的方式上丢失了时间,就像一个棋手在还不知道自己想怎么用马之前就动了马。这是一个糟糕的开局,而不是糟糕的中局。

闸门

解决这个问题的指令,我早就用在代码上了,而它原来根本不是一条编码规则。

对于代码,就是红/绿测试:在你修复任何东西之前,先具体地复现问题,作为一个失败的测试。失败的测试是对问题的重述,它不可能含糊。它命名输入、预期行为和当前的错误行为,并且它必须运行并失败,然后任何人或任何东西才被允许提出修复方案。

这就是承诺闸门,被做成了可执行的。复现就是那个完整的结构。它之所以有效,是因为它迫使接收方在获准行动之前证明自己听到了问题,而在修复之前写下的复现无法被事后修改以匹配接收方想构建的任何东西。

它阻止了草率的修复,即症状消失了而问题没有(禁用测试、吞掉异常、对输入做特殊处理)。

它阻止了不兼容的修复,即一个邻近的问题被解决了,因为接收方推断出了它,而不是听到了所陈述的那个问题。

我在别处写过模型是如何学会用尽一切手段让测试变绿的;先红是对策,而它出于同样的原因也是同样的对策。

在对话中、代码之外,这条规则可以毫无压力地推广:在你提出任何东西之前,先把问题复述成一个当前会失败的东西。如果复述错了,我会在复述处就抓住它5。

那只是一次交流,而不是深入三个回答。我对我合作的模型的指令以各种方式说明了这一点,而共同点是模型在形成观点之前先形成结构,并先把结构展示给我。

这并不完美。这道门有时会失效,模型还是照旧下结论,而我知道得比我想要的更晚。但我在复述处发现问题的频率比过去高得多,浪费的时间段也更短,往往短得多。

它做不到的是迁移。你没法把一份失败的测试交给一个人,让他在回答你之前先运行它。对模型有效的指令用在人身上会显得粗鲁,或者没用,或者两者兼有。

所以这种不对称依然存在:接受指令的接收者不是人,而那个是人的接收者在你说了整整八秒左右之后还在做决定。对此我没有什么办法。我不确定有谁有。

我希望他们有:那会让世界在很多领域运转得好得多。


  1. 事实上,你很可能已经决定了这篇文章讲的是什么,而且你可能已经因为觉得我错了而怒气冲冲。也许我确实错了,但在那条路上走得太远之前,你也许想先等等,看看我到底怎么错,嗯?

    ↩
  2. 在他的一本《爱的五种语言》书中,Gary Chapman 声称人们通常会在十七秒后打断。在我读的那本书里,他没有提供这一说法所用研究的链接,而我好奇人们什么时候停止倾听,所以我自己测试了一下,我发现截止点要接近那个时间的一半,也就是八秒。我不知道我的方法是否比 Chapman 引用的任何东西更好,但那个八秒让我印象深刻,老实说,也让我感到恐惧。

    ↩
  3. 想象一下“你想去哪里吃饭?”得到的回答是“不去麦当劳,不去街那头的墨西哥餐厅,不去意大利餐厅,不想要三明治,肯定对印度菜或地中海菜不感兴趣……”——过一会儿,你就会被所有这些排除项弄得筋疲力尽,拼命想要一个单一、简单的包含项。

    ↩
  4. 谄媚会加剧这一点。模型被训练成倾向于认可,而认可会奖励快速、自信、令人愉快的回答,所以它在拥有前提之前就被拉向结论。

    ↩
  5. 在编辑阶段,我让我使用的模型告诉我我说了什么——如果模型告诉我的东西不符合我的预期,那就是有人做错了什么。通常是我,写得不够清楚,但这就是编辑阶段的红色测试。

    ↩

来源:Hacker News · bytecode.news