1. 从“对齐”这个词被用烂说起“对话对齐”这四个字最近两年在技术圈里几乎成了万能标签。产品经理说要对齐用户预期算法工程师说要做RLHF对齐连做客服系统的都在讲多轮对话对齐。但如果你真的去翻一翻认知科学和语言学的文献会发现“对齐”在人类对话研究里有一个非常具体的含义两个说话者在交互过程中逐渐形成一套彼此默契的、临时的表达约定。注意关键词——彼此、逐渐、临时。大语言模型现在做的事情和这个定义之间隔着一道很深的沟。模型确实能在单轮对话里表现得像一个“对齐了的”对话者你问它答语气合适格式规整。但一旦把两个LLM放在一起让它们互相聊或者让一个LLM和一个真人进行长程开放式对话事情就会变得微妙起来。它们各自都在“学习形成约定”但诡异的是它们并不是在和对方形成约定而是在各自和自己训练数据里那个模糊的“平均对话者”形成约定。这个现象值得认真拆一拆。它不只是一个学术八卦而是直接关系到我们怎么设计多智能体系统、怎么评估对话质量、怎么理解“模型说人话”这件事的边界。下面我会从几个角度把这个问题掰开先讲清楚人类对话中“约定形成”的机制再对比LLM在这件事上的实际表现然后落到工程实践里——如果你正在做多轮对话系统或者多智能体协作哪些坑是必须提前知道的。2. 人类对话里的“约定”到底是怎么长出来的2.1 约定不是事先定好的是聊出来的两个人第一次合作完成一个任务比如一起拼一张宜家桌子他们不会一开始就商量“螺丝刀这个词我们统一叫‘拧拧’”。但在拼装过程中如果一个人说“把那个拧拧递给我”另一个人大概率能懂。如果这个互动重复几次“拧拧”就成了他们之间的临时约定。这个过程有几个特征它是双向的、增量的、有反馈闭环的。A说了“拧拧”B如果没懂B会皱眉或者问“啥”A就会调整。下一次A可能就不说“拧拧”了或者说的时候会附带一个指的动作。认知科学里把这个过程叫做“交互对齐”interactive alignment。Pickering和Garrod在2004年那篇经典综述里讲得很清楚对话双方在词汇、句法、甚至韵律层面会自发地趋同但这种趋同不是单向模仿而是在共同任务目标驱动下的协商结果。你用一个奇怪的词我如果接受了这个词就进入我们的共同语库我如果不接受你就会换一个。约定的形成速度取决于反馈的即时性和清晰度。2.2 约定的三个必要条件把人类这套机制抽象一下要形成真正的“彼此约定”至少需要三个条件同时满足共享的感知语境双方看到的是同一个东西或者至少能通过指称行为把注意力引到同一个对象上。没有这个约定就是空中楼阁。即时的双向反馈一方发出信号另一方必须能给出“懂了”或“没懂”的反馈而且这个反馈要能影响下一轮的表达选择。持续互动的压力双方有动力继续聊下去因为任务没完成或者社交关系需要维持。这种压力迫使双方不断调整直到找到一个双方都能接受的表达方式。这三个条件在人类日常对话里几乎是自动满足的。你和一个陌生人聊天你们共享同一个物理空间你能看到对方的表情你有社交压力不让对话冷场。所以约定形成是自然而然发生的你甚至意识不到它在发生。2.3 为什么这件事对LLM来说特别难LLM的对话生成机制和上面这套东西几乎是正交的。模型没有共享的物理语境它只有文本。模型和用户之间的反馈是异步且稀疏的用户可能聊了十轮才点一次“踩”模型在生成每一轮回复时并不知道上一轮用户到底满不满意。更关键的是模型没有一个持续的“对话记忆”来追踪“我们之间已经形成了什么约定”——除非你显式地把对话历史塞进上下文窗口但即便如此模型也只是在“阅读”历史而不是在“经历”历史。这就导致一个根本性的错位模型在单轮生成时优化的是“在当前上下文下最可能的回复”而不是“在和这个特定对话者长期互动中最有利于形成共同约定的回复”。前者是一个条件概率问题后者是一个博弈论问题。这两件事在数学形式上和工程实现上都不是一回事。3. LLM之间的“对话”各说各话的平行宇宙3.1 两个模型互聊时发生了什么如果你把两个同源或者不同源的LLM放在一起让它们围绕一个话题自由对话前几轮通常看起来很合理。A说“我觉得远程办公提高了效率”B回“确实但沟通成本也增加了”。这种对话在表面上完全成立。但如果你仔细看十轮之后的对话会发现一个典型模式双方都在维持对话的“合理性”但没有任何一方在真正回应对方的具体用词和立场变化。我做过一个简单的实验让两个模型讨论“是否应该给小学生布置编程作业”。前五轮双方都在正反论证第六轮开始A说“考虑到认知发展阶段皮亚杰的理论认为具体运算阶段的孩子更适合具象任务”B回“是的编程中的抽象逻辑确实可能超出这个阶段的能力”。看起来B在回应A但B其实只是抓取了“皮亚杰”“具体运算”这些关键词然后生成了一个在训练数据里常见的、与这些关键词共现的回复。B并没有真的“理解”A为什么在这个时候引用皮亚杰也没有把这个引用纳入自己后续的论证策略里。3.2 约定形成的假象更微妙的是两个LLM互聊时会产生一种**“伪约定”。比如A用了“认知负荷”这个词B在下一轮也用了“认知负荷”。表面上看它们在对齐术语。但如果你把B的上下文窗口清空重新让B回复同一句话B可能就会用“认知负担”或者“心智负担”。也就是说B的用词选择并不是因为“和A形成了约定”而是因为“在当前上下文里‘认知负荷’这个词的激活概率被临时提高了”。这是一种上下文 priming 效应**不是约定形成。真正的约定形成需要跨对话的持续性。人类今天和你约定用“拧拧”指螺丝刀明天再合作时可能还会用这个词。LLM的“约定”在对话结束后就消失了除非你把它写进系统提示或者微调数据里。但一旦写进去它就不再是“和某个特定对话者形成的约定”而变成了一个全局的、对所有用户生效的规则。这又回到了“和平均对话者对齐”的老路。3.3 一个具体的失败模式礼貌用语升级螺旋在多智能体对话里有一个我见过很多次的失败模式礼貌用语升级螺旋。A说“请帮我分析一下这个问题”B回“好的我很乐意帮您分析”A下一轮说“非常感谢您的帮助如果您方便的话能否进一步解释”B回“当然可以非常荣幸能为您提供进一步的解释”。几轮之后双方的回复里充满了“非常感谢”“非常荣幸”“如果您不介意的话”而实质信息量趋近于零。这个现象的原因是每个模型都在根据上一轮的礼貌程度来校准自己的礼貌程度而训练数据里“高礼貌输入”对应的“高礼貌输出”是一个很强的统计规律。于是礼貌程度就像两个回声麦克风一样互相放大直到撞到上下文长度上限或者生成温度的上限。这不是约定形成这是统计共振。人类对话里也有礼貌升级但人类会用“咱别客气了”这种元沟通来打断螺旋。LLM不会因为元沟通在训练数据里相对稀少而且模型没有被明确鼓励去“打破对话模式”。4. 人机对话中的“单向约定”困境4.1 用户在学习模型的习惯模型没有在学习用户的习惯如果你长期使用同一个LLM你会发现自己不知不觉在调整提问方式。你知道它擅长什么格式你知道说什么话它会拒绝你知道怎么措辞能得到更详细的回答。用户在形成对模型的约定比如“如果我说‘简单说’它就会给要点如果我说‘展开讲’它就会给长文”。但反过来模型并没有在形成对你的约定。你换一个账号或者同一个账号开一个新对话模型对你的“了解”就归零了。这种不对称性带来一个很实际的后果人机对话的“对齐成本”几乎全部由用户承担。用户要花时间学习模型的脾气而模型不需要花任何成本来学习用户的脾气。在人类对话里这个成本是分摊的双方都会调整。但在人机对话里模型端的调整能力被架构性地限制了——除非产品层面做了用户画像和长期记忆但那又是另一回事而且涉及隐私和工程复杂度的权衡。4.2 为什么模型不能“记住”约定有人会说现在不是有长期记忆功能吗确实一些产品开始支持跨对话的记忆。但这里有一个关键区别记忆不等于约定形成。记忆是“存储事实”约定是“协商规则”。模型可以记住“这个用户是程序员”但模型不会和这个用户协商出“我们之间用‘那个东西’来指代某个特定API”这样的临时约定。因为约定形成需要模型在对话中主动提出、试探、接受反馈、调整而当前模型的训练目标里几乎没有这一项。RLHF训练的是“给定上下文生成人类评分高的回复”。人类评分高的回复通常是“有帮助的、准确的、安全的”而不是“积极和用户协商表达方式的”。一个模型如果频繁问“你刚才说的‘那个东西’是指什么我们能不能统一一下叫法”人类评分员大概率会觉得它啰嗦、不智能。所以模型被训练成了“尽量不追问尽量给出合理回复”这恰恰抑制了约定形成所需的那种“笨拙的协商行为”。4.3 一个反直觉的观察模型越强约定形成越难这听起来有点奇怪但逻辑是通的。模型越强它单轮生成“合理回复”的能力越强。这意味着即使它没有真正理解你的意思它也能生成一个看起来合理的回复。你得到这个回复觉得“它懂了”于是继续往下聊。但实际上你们之间的理解偏差没有被暴露出来也就没有被修正的机会。弱模型反而更容易暴露误解因为它的回复会明显跑偏你立刻就知道“它没懂”然后你会调整措辞。强模型把误解掩盖得更深约定形成的反馈闭环反而更难建立。这个观察对做对话系统评估的人特别重要。如果你只用“回复合理性”来评估模型强模型永远得分更高。但如果你评估的是“多轮对话中双方是否形成了有效的共同理解”强模型未必比弱模型好甚至可能更差因为它更擅长“糊弄过去”。5. 工程实践里怎么应对这个错位5.1 显式约定把隐含的协商变成显式的规则既然模型不会自发形成约定那就在系统层面帮它形成。最直接的做法是在对话开始时显式建立术语表。比如在一个客服场景里用户说“我要退那个东西”系统可以追问“您说的是订单A123里的商品吗我们接下来用‘订单A123’来指代它可以吗”用户确认后这个指代关系就被写入对话状态后续所有轮次都引用这个状态。这个做法看起来笨但它把“约定形成”从模型的隐式能力变成了系统的显式流程。代价是前几轮对话会多花一点时间但收益是后续几十轮对话的歧义率大幅下降。我在一个多轮任务型对话项目里用过这个策略把任务完成率从67%提到了89%主要提升就来自“指代消解错误”的大幅减少。5.2 双向反馈的工程化让模型学会说“我没懂”另一个关键是给模型一个明确的“请求澄清”的出口。当前很多模型被训练成“尽量不追问”但在多轮任务场景里追问是必要的。你可以通过系统提示或者微调让模型在置信度低的时候主动说“我不确定您指的是A还是B能确认一下吗”这比强行猜一个然后猜错要好得多。这里有一个实操细节追问的时机比追问的内容更重要。如果模型每轮都追问用户会烦。如果模型从来不追问错误会累积。我的经验是在检测到以下信号时触发追问用户输入里出现了模型词汇表之外的指代词“那个”“它”“上次说的”或者用户输入和上一轮模型回复的语义相似度低于某个阈值。这两个信号同时出现时追问的收益最大。5.3 多智能体系统里的“约定层”设计如果你在做多智能体协作比如让几个LLM分别扮演不同角色完成一个任务那“约定形成”就不能靠模型自发必须在架构里加一个约定层。这个层可以是一个共享的键值存储所有智能体在对话中形成的临时指代、缩写、任务分工都写进去。每个智能体在生成回复前先读这个存储生成后再把新的约定写回去。这个设计的核心思想是把约定从模型的隐式状态里抽出来变成系统的显式状态。模型不需要“记住”约定它只需要“读取”约定。这样即使模型换了、上下文清空了约定依然存在。代价是你需要设计一套约定表示和冲突解决机制比如两个智能体对同一个东西用了不同的缩写怎么办。但这比让模型自己去“悟”要可靠得多。6. 评估对话质量时容易踩的坑6.1 用“像人”来评估“对齐”是错的很多对话评估指标本质上在测“回复像不像人说的”。困惑度、流畅度、甚至一些基于人类评分的“自然度”指标都在往这个方向走。但“像人”和“对齐”是两件事。一个模型可以生成非常像人的回复但完全没有和对话者形成共同理解。反过来两个人类专家用大量术语和省略号交流在外人看来“不像正常对话”但他们之间的对齐程度极高。如果你要评估对话对齐需要看的是任务层面的指标双方是否在后续轮次里正确引用了之前形成的约定指代消解的成功率是多少任务完成过程中因为理解偏差导致的返工有多少这些指标比“回复自然度”更能反映对齐的真实水平。6.2 单轮评估的局限性单轮评估就像只看一张照片来判断一段关系好不好。你可以看这一轮回复是否相关、是否有帮助但你无法判断这一轮回复是否在“建立”或“破坏”双方之间的约定。一个在单轮评估里得分很高的回复可能在多轮语境里是灾难性的因为它可能引入了一个新的、和之前约定冲突的术语或者它可能回避了一个需要澄清的歧义点。我的建议是任何对话系统的评估都必须包含多轮指标。哪怕你只关心单轮质量也要至少看三轮的连贯性。具体做法可以是让评估者看三轮对话然后问“第三轮的回复是否表明模型理解了第一轮里用户定义的术语”这个问题比“第三轮回复好不好”更有诊断价值。6.3 一个实用的评估框架下面这个表格是我在实际项目里用过的一个简化评估框架用来区分“表面流畅”和“真正对齐”评估维度表面流畅真正对齐术语一致性同一轮内用词统一跨轮次引用同一术语指代同一对象指代消解代词不引起歧义代词正确指向之前协商过的对象澄清行为从不追问在歧义点主动追问并采纳用户确认约定持久性约定在下一轮消失约定在后续多轮持续生效任务完成单轮看起来有帮助多轮后任务实际完成且无返工这个框架的核心是把“对齐”从“感觉”变成“可观测的行为”。你不需要判断模型“是不是真的懂了”你只需要看它在后续轮次里有没有按照之前协商的方式行动。7. 这件事对做产品的人意味着什么如果你在做对话产品不管是客服、教育还是陪伴类上面这些分析落到产品决策上就是几条很具体的建议。第一不要指望模型自己学会和用户形成约定。当前架构下这件事不会自然发生。你需要显式地设计约定形成的流程哪怕只是简单的“确认指代”步骤。第二把对话状态和模型解耦。约定应该存在对话状态里而不是模型的上下文里。这样你可以换模型、可以清上下文、可以做多轮压缩而约定不会丢。第三评估指标要往多轮任务完成度上靠。单轮满意度是个很有欺骗性的指标。用户可能在每一轮都点了“满意”但任务最终没完成因为双方的理解偏差一直在累积但从未被暴露。第四给用户一个“重新协商”的入口。人类对话里如果发现对方理解错了会说“等等我刚才说的不是那个意思”。对话产品也应该允许用户随时说“我们重新定义一下刚才那个词”并且系统能够正确地重置约定状态。这个功能看起来小但在长对话里是救命的。8. 回到那个标题它们都在学只是没在跟对方学“LLMs and people both learn to form conventions – just not with each other”这个说法之所以精准是因为它点出了一个结构性的事实LLM确实在形成某种“约定”——它和训练数据里的平均对话者形成了约定和RLHF标注员的偏好形成了约定和系统提示里的角色设定形成了约定。人类用户也在形成约定——和这个特定模型的脾气、能力边界、输出格式形成了约定。但这两套约定是平行运行的它们没有在彼此之间形成交集。这不是一个可以通过“更大的模型”或者“更多的数据”自动解决的问题。它是一个架构问题当前的对话范式里模型和用户之间缺少一个持续的、双向的、有反馈闭环的协商通道。要解决它需要在系统层面显式地构建这个通道而不是指望模型在隐空间里自己悟出来。我在实际项目里越来越倾向于一个观点对话系统的“智能”不应该只体现在单轮生成的质量上更应该体现在它维护共同理解的能力上。一个能记住“我们刚才把那个东西叫做A”的简单系统在很多任务场景里比一个单轮生成惊艳但转头就忘的复杂模型更有用。这个判断不一定对所有人都成立但至少在我做过的任务型对话场景里它反复被验证。