大模型跑偏问题

从“大模型训练/推理机制”的角度，这种“先答错、被你一句话纠正后回正”非常典型，通常不是知识缺失，而是 (1) 训练目标 + (2) 语境建模方式 + (3) 解码策略 共同作用的结果。

1) 训练目标：最大似然学的是“最像人说的话”，不是“先求真再回答”

大多数大模型的基础训练是 next-token prediction（最大似然）。它学到的是：在类似对话里，人们更常见的回答方式是什么。

当你说“洗车店离我家100米，开车还是走”，训练语料里常出现的“生活小建议”模板是：

• 距离近 → 走路更省事、更环保、更不用找车位

这类模板在语料里很高频，因此模型容易走向“社会常识式建议”，即使它隐含了一个关键前提：车不需要你开过去（比如店会挪车/上门/你只是去排队付钱）。

换句话说：它在做“最可能的对话续写”，而不是先做“约束满足/可行性检查”。

2) 语义歧义：问题本身缺少关键约束，模型会做“默认补全”

“去洗车”在自然语言里是歧义的：

• A：人去洗车店办事/等候（车可能已在那、或店会处理）
• B：把车开去洗（车必须移动）

人类也会默认补全，只是人类更容易在脑中做“物理可行性检查”。模型在没被显式要求“列出假设”时，会选择最贴近日常对话的解释，而不是最严格的解释。

这叫 underspecification（欠指定）：输入没有给足条件，系统必须猜。猜错就会“答错”。

3) 解码策略：一次性生成倾向“快速给结论”，而不是先自问自答

推理时通常用 greedy/beam/sampling 的解码方式，它倾向于：

• 迅速产出一个高概率、听起来合理的答案
• 不主动停下来问“车怎么过去？”这种澄清问题（除非系统被训练/指令强制这么做）

这在“短问题+生活建议”场景里尤其明显：模型会优先给一个顺口的建议，而不是先做约束核对。

4) 你的一句引导为何能“拉回正确路径”？——因为条件更新改变了后验

你补充的句子“不开车车子怎么拿过去洗”相当于给了一个硬约束：

约束 C：车必须由你驾驶到店（没有取送/代驾/瞬移）

在概率角度，这会把原本两种解释的后验概率重排：

• A（人去即可）概率骤降
• B（必须开车）概率骤升

模型不是“突然学会了新知识”，而是在同一个会话上下文里，依据新增证据更新了预测分布，于是输出改为“开车过去”。

这类现象在对话模型里很常见：上下文就是在线条件，你提供的信息越“硬”，模型越不容易跑偏。

5) RLHF/对话微调的副作用：更愿意“给建议”而不是“挑战前提”

对话模型在 RLHF/指令微调后，会更倾向于：

• 快速给有帮助的建议
• 避免频繁追问显得“啰嗦”

结果是：遇到欠指定问题时，它更可能“带着默认前提直接答”，而不是先澄清关键约束。这提升了大部分场景的体验，但在你这种“逻辑上必须满足的物理条件”问题上，就可能翻车。

6) 这说明什么？训练知识够不够 vs 推理习惯好不好

这更像是：

• 知识是够的（车要到店才能洗，这是常识）
• 但推理流程没有被强制成“先校验可行性/先列假设”，导致在歧义输入时被高频模板带偏

如果把系统改成“必须先列假设并检查可行性”，就会更稳，但也会更啰嗦、速度更慢、体验可能变差——这是产品权衡。

---

如果你想把这类错误在你自己的应用里降到最低，最有效的两招：

1. 在提示词里强制列出关键假设/约束检查（例如“先判断是否需要把车开过去”）
2. 对欠指定问题先提一个澄清问句（例如“洗车店会不会上门取送车？”）

你如果告诉我你是在用 LLaMA Factory 训练/微调对话模型，还是在做某种“助手建议”应用，我也可以把这套解释落到更工程化的：数据如何标注、奖励模型如何设计、以及如何写 system prompt 来减少这种“默认补全翻车”。