语言模型真的会偏好某些词序吗这个问题的答案比“语法对不对”要复杂得多。最近围绕“Language Models Generalize to Human-like Word Order Preferences”的讨论把语言学里一个经典话题——人类为什么天然偏爱某种语序比如主语通常出现在宾语之前、修饰语尽量靠近中心词——正式搬到了模型评测桌上。这类工作解决的实际问题不是“教模型背语法规则”而是判断一个无监督或自监督训练出来的模型能否在没有显式标签的情况下自主习得类似人类语言加工的词序偏好。听起来抽象但落地价值很直接做自然语言生成、机器翻译、多语言模型评测和微调时如果你只看 loss、BLEU 或流畅度根本看不出模型是否有语言结构上的偏好而词序偏好恰恰是影响长句可读性、信息结构和检索质量的重要因素。谁适合看这篇我建议这几类人都值得往下读做语言模型评测和 benchmark 设计的做多语言模型微调和数据清洗的研究 prompt 和 agent 框架的以及单纯好奇“大模型内部到底有没有语言学知识”的。最值得关注的点是模型的词序偏好必须通过受控实验才能分辨不能用一两个生成样例下结论。1. 词序偏好到底是什么为什么要关注它1.1 从人类的“默认语序”说起人类语言在词序上有一个明显特征绝大多数语言倾向于把主语放在宾语之前。SVO主谓宾和 SOV主宾谓是最常见的两种语序灵活性高的语言往往也有一个“默认语序”。从认知角度看这种偏好不是随意的主语先出现能让听者更快建立“谁在做动作”的框架宾语放在后面则降低了工作记忆的负担。人类在阅读和听句子时会表现出加工难度差异。同一个意思换一种语序表达可能仍然符合语法但处理起来更费力。这就是所谓的“偏好”——不是对错问题而是加工成本问题。词序偏好研究的核心就是找到这种加工成本在模型里有没有对应物。举个例子英语里“The dog chased the cat”和“The cat the dog chased”前者明显更自然。后者虽然在特定语境下可以出现但单独呈现时大多数人的处理速度会变慢。语言模型如果要在机器翻译或文本生成中输出流畅内容就必须隐式掌握这类“哪个词序更自然”的知识。1.2 模型没有语法课却出现了偏好预训练语言模型在训练时只做预测下一个词这类自监督任务没有人给它们标注“这个句子语序更自然”。但大量实验发现模型确实会给不同语序的句子分配不同概率。比如把“猫追了狗”和“狗追了猫”这种语义和论元角色不同的一对放在一起比较模型可能会因为世界常识给出不同判断但更值得研究的是像日语、韩语这类语序相对自由的语言里模型是否仍然默认某种语序更自然。“泛化到类人词序偏好”这个表述重点在“泛化”。它不只是说模型在常见语序上表现好而是说模型可以把训练中学到的语序倾向迁移到新的结构、新的词汇组合、甚至跨语言场景中。这正是衡量模型是否具备抽象语言知识的一个信号。这里要说清楚模型表现出偏好不等于模型理解语法。偏好可能来自统计共现、上下文重叠、甚至是词向量里的位置偏差。判断它是否“类人”需要把多种解释路径放在一起对照。那为什么这件事重要因为很多下游任务都依赖“结构偏好”而不是“单个词义”。比如指代消解、事件抽取、关系抽取模型如果对论元顺序不敏感就很容易把主语和宾语搞反。词序偏好说是语言学问题实际上直接关系到模型在结构化任务上的上限。2. 模型怎么表现出“类人式”词序偏好2.1 最小差异句是最常用的测量工具想测词序偏好最直接的方法是构造最小差异句对。两个句子在词汇上尽量一致只改变词序或论元顺序然后看模型对哪一句给出更高概率。比如猫追了狗狗追了猫这个例子其实混入了语义因素模型会因为“猫通常追狗”的常识给出判断所以更严格的设计是使用无语义倾向的词或者交换位置后有相同语义合法性的结构例如被动句、关系从句、副词位置等。人工构造这些句对时要注意真正有效的是“语义等价但结构不同”的句子而不是意思完全不同的句子。构造句对时还有一个细节尽量避免让两个句子在词汇层面产生共现差异。如果模型在“汽车追自行车”上偏好主动语序在“自行车追汽车”上也偏好同样的结构位置而不是换一个更有语义合理性的顺序这才说明模型关注的是结构而不是世界知识。2.2 从困惑度到输出概率指标怎么选常见做法是计算模型对整句的困惑度困惑度越低代表模型认为这个句子越自然。或者直接取句子末尾 token 的累积概率。要注意的是词序改变通常会让句子的总 token 数发生变化所以不能只看 raw probability一般要看按 token 长度归一化之后的困惑度。另外不同模型家族的打分尺度不一致跨模型比较时不要直接对比绝对困惑度要对比两个句子之间的相对差异。这一点最容易踩坑同一个模型在不同 prompt 或不同温度下生成的偏好可能都不一样而打分任务最好固定 seed、固定 prompt 模板否则结果不稳定。我个人做这类评测时会把三类指标都记下来整句困惑度、按 token 数平均后的困惑度、以及目标结构中心词的预测概率。前两个用来判断整体自然度第三个用来判断模型是否在关键句法位置上有针对性偏好。2.3 与人类加工难度的对接真正让这类研究有价值的一步是把模型打分和人类行为数据放在一起。人类阅读时的注视时间、反应时、问卷可接受度都可以作为参照。如果模型对某个词序的打分越低人类阅读同结构句子的反应时也越长那么模型的偏好就初步具备“类人”特征。当然这种对应是相关性不是因果。模型可能因为训练数据里某种词序出现频率高而给高分人类也可能因为使用频率高而觉得更自然。两者可能殊途同归但不能因此断言模型“像人一样思考”。能在文章里把这个边界讲清楚比直接下结论要更有价值。还要注意取样偏差。人类可接受度数据通常来自几十个人的问卷样本量小、个体差异大。模型打分则是确定性的。两者对比时不要只看均值最好也看分布和排序一致性比如用 Spearman 相关而不是简单看哪一句分高。3. 想复现这类实验环境步骤怎么搭3.1 数据准备的几个关键点我建议先不要急着搭建大实验先从一个小规模句对集合开始。你需要准备一个句子集里面包含若干组结构对照同一语义的主动句和被动句主语在前的句子和宾语在前的句子关系从句修饰语靠近中心词和远离中心词的句子日语、韩语等语序自由语言中的可接受变体句对每组句对要控制长度、词汇频率、句法复杂度。如果句子长度差太多模型打分可能受长度影响而不是受词序影响。另外尽量避开歧义句和需要外部常识才能判断的句子否则你分不清模型是在用世界知识还是用语言结构。句子数量方面我一般先准备 50 到 100 对。太少看不出趋势太多又不容易检查数据质量。宁可第一批句对少一点也不要让错误数据污染整个实验。3.2 一个最小可运行的打分脚本下面给一个示例思路用常见的 Transformers 库加载一个自回归模型然后对单句计算困惑度。这里用的是一个演示写法实际模型名、设备和你想要的分词方式需要按自己的环境调整。import torch from transformers import AutoTokenizer, AutoModelForCausalLM model_name your-model-name-here tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) model.eval() def sentence_perplexity(text): inputs tokenizer(text, return_tensorspt) input_ids inputs[input_ids] with torch.no_grad(): outputs model(input_ids, labelsinput_ids) loss outputs.loss.item() return float(torch.exp(torch.tensor(loss))), loss然后对句对里的两个句子分别调用这个函数记录困惑度和 loss。pair [猫追了狗, 狗被猫追了] for sent in pair: ppl, loss sentence_perplexity(sent) print(sent, round(ppl, 2), round(loss, 4))运行环境方面自回归模型打分不需要很高的算力普通 CPU 也能跑但句子数量多、模型大时建议用 GPU。显存占用取决于模型体积和句子长度一般 7B 以下模型在单卡 16G 显存上就能处理绝大多数评测句。如果内存不够可以把句子分批处理。3.3 结果怎么判断如果模型对某个结构稳定地给出更低困惑度而且这个差异在多个句对上都一致才可以说模型存在一个可观察的词序偏好。注意几个判断标准差异要足够大。困惑度差 0.1 可能是噪声连续 20 个句对都差 0.5 以上才更可信。差异要一致。如果一半句对偏向 A另一半偏向 B那更可能是句子本身的问题而不是词序偏好。要做控制组。把句子里的实词随机替换成其他词重新跑一遍如果偏好消失了说明模型依赖的可能是词汇共现而不是抽象的语序规律。我一般会先用 10 个句对跑通流程确认脚本、数据处理和日志都没问题再扩展到几百个句对。不要一上来就开并发或者用大模型跑全部数据否则后面排查会非常痛苦。4. 模型能力边界词序偏好不等于语法理解4.1 语序自由语言更容易暴露问题英语、汉语这种语序相对固定的语言词序偏好在训练数据里信号很强模型学起来并不难。真正有挑战的是日语、韩语、土耳其语、德语这类语序自由度较高的语言同一个语义可以对应多种合法词序训练语料里各种变体都存在。这时候模型的偏好就变得不稳定。有些模型会偏向高频语序有些模型会把上下文边缘信息当成线索。如果你的评测对象是多语言模型建议不要只测英语最好把语序自由的低资源语言也加进来否则很容易高估模型的泛化能力。我实测过一些多语言模型发现在日语里模型对“主语-宾语-动词”和“宾语-主语-动词”的偏好差异经常小于英语里主动语序和被动语序的差异。这并不一定是模型能力差而是训练语料里两种语序都足够常见模型没必要建立强偏好。理解这一点能避免把“没有偏好”误判成“能力缺陷”。4.2 训练数据的统计偏差会伪装成“偏好”一个常见陷阱是模型对某些词序打高分可能只是因为这些词序在训练语料里占比高并不是形成了抽象规则。我见过不少实验把这种统计偏差直接写成“模型具有类人偏好”但实际上换一个领域、换一种句法结构结果就崩了。要区分这两种情况核心方法是看“迁移性”。把一个在新闻语料里学到的词序偏好迁移到风格差异很大的文本上如果偏好还能保持才更有说服力。如果换了语料就变了说明模型记住的只是数据分布不是语言规律。另一个做法是检查同义句对在不同领域子集上的表现。如果模型在维基百科、新闻、口语对话三种语料上对同一结构的偏好方向一致那说明这个偏好比较稳固如果方向相反基本可以确认是数据分布导致。4.3 提示词和生成参数会改变观测结果同一个模型你用零样本直接打分是一种结果你把它放进一个精心设计的提示词模板是另一种结果。温度、top-p、惩罚系数都会影响生成侧的词序分布。特别是在做生成任务评测时不要把“生成出的句子语序自然”直接等同于“模型偏好这个语序”因为解码算法本身就施加了额外约束。如果要做严格评测建议固定解码参数至少跑 3 次取稳定结果并汇报波动范围。不要只给一张成功样例要汇报失败案例和不确定案例。下表是我在实际评测时会关注的维度和对应观察点评测维度实验方法关键观察常见误判句法结构偏好最小差异句对打分困惑度差异是否一致把语义偏好当成句法偏好语序迁移跨领域、跨语言测试偏好是否保持把统计共现当成抽象规则人类相关性与反应时/可接受度对照排序是否一致把相关性当成因果生成侧表现固定参数多次生成语序分布是否稳定把解码噪声当成模型偏好5. 从静态打分到推理与行动ReAct 带来的新视角5.1 ReAct 是什么为什么要放在这里聊相关热词里出现了一组表述react: synergizing reasoning and acting in language models。简单说ReAct 是一类让语言模型在生成答案的同时执行行动、观察结果的思路核心是把“推理轨迹”和“实际行动”结合起来。它和词序偏好看起来不在一个层面但两者有一个交汇点当模型开始做多步推理和工具调用时中间步骤的语言组织会变得非常重要。如果模型在你给它构造的复杂推理链里对词序高度敏感那它对中间步骤的理解很容易出现偏差。词序偏好因此不再只是语料学问题而是会影响 agent 任务稳定性的一个工程变量。去年到今年很多团队从只评测“模型最后输出的答案对不对”转向评测“模型在推理和行动过程中的每一步是否稳定”。词序偏好恰恰是中间步骤稳定性的一个底层变量。5.2 推理轨迹会不会改变模型的词序敏感度我个人的观察是在 ReAct 风格的任务里模型的输出不是单独一句话而是一段包含理由、行动、观察的文本。这段文本越长模型对局部词序的敏感度越高因为任何一个小结构的怪异都会增加整个上下文的混乱程度。但也正因为如此评测词序偏好就需要更细的粒度——不能只给整段落打分还要对每个子句单独分析。目前没有足够多的公开数据支持“更长推理轨迹一定导致更依赖默认词序”这种绝对结论所以这更多是一个值得设计的实验方向而不是已经验证的事实。如果你在做 agent 相关项目建议把中间步骤的语序稳定性也纳入日志监控而不仅仅是看最终答案对不对。比如一个 agent 生成了“先读取文件内容然后根据文件内容判断结果”如果把“根据文件内容判断结果”改成“判断结果根据文件内容”前者显然更容易被后续步骤引用。这种差异在单句评测里可能只体现为困惑度差一点但在多步 agent 任务里可能影响输出解析和上下文记忆。5.3 结合点评测集设计和多维度指标把 ReAct 和词序偏好放在一起看真正有价值的是评测设计上的变化。以前我们只需要静态打分现在需要动态评估模型在推理、行动、观察的循环里是否保持了稳定的语言结构感知。换句话说评测维度要从“模型认为哪句更自然”扩展到“模型在生成时会主动选择哪种结构”。这类评测需要更复杂的数据标注也需要把格式化输出、工具调用协议等工程因素纳入控制变量。我在做这类实验时会多记录一层信息中间步骤中动词出现的位置、主语和宾语的距离、关系从句的嵌入深度。这些指标虽然看起来偏语言学但在调试 agent 时经常能提前暴露问题。如果你想设计一个比较完整的评测可以按这样的流程先做静态句对打分再做固定 prompt 的多次生成最后放入一个多步 agent 任务里观察失败率。三者结合才能把“模型偏好”“生成稳定性”“任务稳定性”三件事区分开。6. 实际落地时的排查顺序和避坑经验6.1 先看数据再调模型如果你跑出来的词序偏好结果和论文结论不一致先别怀疑模型能力先检查句子对本身。常见问题包括句对长度不一致、句子里有生僻词、结构差异过大、句子包含无法被分词器正确切分的字符。我一般会先把句子单独打印出来肉眼确认一遍再做标准化处理。不要一开始就调模型参数。大部分“实验结果不稳定”的问题根源在输入数据或者评测脚本而不是模型本身。换模型前先把同一批句子跑在不同 seed 下看看结果波动有多大。波动大就先处理波动再做结论。另外检查分词器是否把同一个结构的句子切分成了完全不同的 token 序列。有些语言一个词会被拆成多个子词这会让困惑度计算产生偏差。如果两个句子的 token 数量差太多优先排查是不是分词导致的。6.2 常见问题排查清单按下面的顺序排查通常不会漏看报错和日志。是模型加载失败、显存不足还是分词器警告。看输入格式。分词结果是否符合预期特殊符号有没有被错误合并。看资源占用。显存或内存是否溢出CPU 是否打满有没有别的任务抢占。看评测脚本。loss 是不是在正确的 token 上计算有没有把 padding token 也算进去。看结果波动。多次运行同一批数据差异是否在可接受范围。看对照组。把词汇随机替换后偏好是否仍然存在。注意遇到“模型对所有句子都打近似相同的分”通常不是模型没有偏好而是打分方式出了问题比如把所有 token 都算进了 loss或者句子太短导致差异被平均掉。6.3 我的建议先把单任务跑稳再谈批量。批量评测时要单独考虑句对命名、结果输出格式、失败重试和断点续跑。如果只是跑几十个句对用普通脚本就够了如果要跑上千句对或者跨语言测评建议把每个句对的结果单独存成一个 JSON字段包括句子原文、模型名、困惑度、loss、模型版本、seed 和运行时间。这样后续复现和排查都会省很多时间。模型选择上新手建议先用一个小模型跑通全流程比如 1B 或 3B 级别确认数据和脚本都没有问题后再切换到大模型。大模型打分未必更准只是更能体现当前主流模型的能力两者结论可能不同。评测报告里最好同时写出模型版本和加载时的精度设置比如是否用了半精度因为这会略微影响打分结果。最后说一句实在话词序偏好评测最大的坑不是工具不会用而是你把“模型觉得某个句子更像训练数据”误当成了“模型像人一样理解语言结构”。两者之间的差距正是我们需要用受控实验、迁移测试和多维指标去填平的。如果读完这篇你只记住一件事那就是别用一两个生成样例判断模型的词序偏好请选择最小差异句对加严格控制的评测流程。