1.1 复杂指令遵循能力的定义、边界与核心要素
我自己在做模型评测的时候，最头疼的一件事就是跟别人解释“到底什么叫复杂指令”。很多人会觉得，指令长一点、条件多一点就叫复杂了。我的理解不是这样。复杂指令遵循能力，说的是模型在面对一条包含多重约束、多个步骤、甚至带条件分支和格式要求的指令时，能不能稳定地把该做的事情全做对，而不是只做对一部分、或者挑简单的部分做。这个能力跟单纯的“理解能力”不是一回事，跟“知识储备”也不是一回事。它更接近一种执行层面的精确度问题。
边界方面，我会把“复杂”和“冗长”区分开。一段话写了两千字但里头就一个要求，那不算复杂，那叫啰嗦。真正的复杂指令往往有几个特征叠在一起：约束之间可能存在优先级、步骤之间有依赖关系、输出格式有硬性规定、还可能藏着否定性要求（比如“不要出现某个词”）。我通常拿这四个维度来判断一条指令的复杂程度：约束数量、步骤深度、格式严格度、冲突处理需求。这四个维度里同时占两个以上，我就认为它进入复杂指令的范畴了。
核心要素我归纳成三块。一块是约束解析，模型得把散落在指令各处的条件都拎出来，不能漏。一块是执行规划，多步骤任务得有个合理的顺序，不能跳步也不能乱序。还有一块是输出校验，模型得在生成过程中自己检查有没有踩到否定约束、格式对不对。这三块里头任何一块掉链子，整条指令的遵循质量就会打折扣。我见过不少模型约束解析没问题，但执行到一半就把前面的格式要求忘了，这种就属于核心要素没串起来。
1.2 对比评测的目标、原则与适用场景
我做对比评测的目标很直接，就是想搞清楚不同模型在复杂指令场景下到底差在哪、差多少。不是为了排个名次就完事，我更看重的是能不能定位到具体的失败环节。比如同样是约束满足率低，有的模型是漏约束，有的模型是约束冲突时选错了优先级，这两种问题的优化方向完全不一样。评测目标里我会特别强调“可归因”这一点，分数背后的原因比分数本身有用得多。
原则方面，我坚持三条。一条是任务要贴近真实使用场景，不能为了难而难，故意构造一些现实中没人会写的指令。另一条是可复现，同一套任务集换个人跑、换个时间跑，结果得基本一致，不然对比就没有意义。还有一条是分层报告，不能只给一个总分，得按指令类型、约束类型拆开看，否则高分模型在某个细分场景下翻车了都看不出来。这三条原则我在设计任务集的时候会反复对照，有时候为了可复现性会牺牲一点任务的花哨程度，我觉得这个取舍是值得的。
适用场景我一般会分三类来说。一类是模型选型，团队要挑一个模型落地到具体产品里，这时候对比评测的重点是目标场景下的表现，不是通用能力。一类是能力诊断，模型已经上线了，想定位它在哪类指令上容易出问题，那就得用细粒度拆分的任务集。还有一类是研究性质的横向对比，关注的是趋势和差异，任务覆盖面要广一些。这三类场景对评测框架的要求不太一样，我在设计的时候会先问清楚用途，再决定任务集和指标的权重怎么分配。
1.3 评测对象、任务集与指标体系总览
评测对象这块，我通常会覆盖几类模型：通用大模型、推理增强模型、开源模型、闭源模型。每一类里头再挑几个有代表性的版本。选模型的时候我会注意版本对齐，尽量用同一时期的模型做对比，不然进步速度差异会干扰结论。有些模型有多个尺寸版本，我会优先选实际部署中常用的那个尺寸，而不是一味挑最大的。评测对象的数量我不追求多，一般控制在八到十二个之间，太多了跑起来成本高，分析起来也容易散。
任务集我是按“指令类型 × 复杂度等级”来组织的。指令类型涵盖多约束型、多步骤型、条件分支型、格式约束型、否定约束型这几类。复杂度等级分三级，从两三个约束的轻度复杂，到五六个约束加步骤依赖的中度复杂，再到带冲突条件和跨轮一致性的重度复杂。每个格子里的样本数量我一般不少于二十条，保证统计上有基本的稳定性。任务来源上，一部分是我自己构造的，一部分是从真实业务日志里脱敏改写来的，后者的价值在于它能暴露一些人工构造时想不到的坑。
指标体系我分了三层。最上面是结果层，就是约束满足率、步骤完整率、格式合规率这几个硬指标。中间是过程层，看的是模型在中间步骤上的表现，比如有没有提前终止、有没有重复执行、错误恢复用了多少轮。最下面是成本层，包括延迟、token消耗这些。三层指标我一般不会加权成一个总分，而是分开呈现。原因很简单，不同场景对这三层的重视程度不一样，合成一个分数反而把信息压扁了。我自己看报告的时候也是先看结果层，再看过程层定位问题，成本层作为参考。
1.4 大模型复杂指令遵循能力对比评测的流程设计
流程设计这块，我的做法是从任务定义开始，到报告输出结束，中间大概七八个环节。任务定义环节要把指令模板、参考答案、评分规则一起定下来，这三样东西得同步设计，不能先写任务再想怎么评。任务定完之后会做一轮预测试，拿两三个模型跑一下，看看任务难度分布是不是合理，有没有出现所有模型都满分或者都零分的情况。预测试这一步很多人会跳过，我觉得挺可惜的，它能省掉后面大量的返工。
正式评测阶段我会把人工评审和自动评分结合起来跑。自动评分负责大批量跑约束满足率和格式合规率，人工评审负责抽查那些自动评分拿不准的样本，尤其是涉及语义正确性和指令意图理解的部分。两边的结果会做一致性校验，如果差异超过一个阈值，就回去检查评分规则是不是有歧义。这个校验环节我吃过亏，早期有一次自动评分把“格式正确但内容跑偏”的样本判成了满分，后来加了人工抽查才发现问题。
收尾阶段是结果分析和报告输出。我会把结果按模型、按指令类型、按复杂度等级三个维度交叉拆开，找出那些“整体分数不错但某个细分格子明显偏低”的情况。这类模型往往是优化优先级最高的，因为它的短板很具体，改起来有方向。报告里我还会附上典型失败样本的原文和模型输出，方便读者自己判断。整个流程跑一轮，如果任务集规模在五百条左右，大概需要三到五天，其中人工评审占的时间最多。
2.1 人工标注评测与专家评审方法
我始终觉得人工评测是这类对比的压舱石。自动打分跑得再快，碰到"模型到底有没有理解指令意图"这种问题，还是得靠人来看。我一般把人工评测拆成两层：标注员层负责大批量的基础判断，比如约束有没有满足、步骤有没有漏、格式对不对；专家层负责抽查和仲裁，尤其是那些边界模糊的样本。两层不是简单的上下级关系，标注员发现规则说不清楚的地方会往上报，专家评审时也会反过来校验标注结果的一致性。
标注员的培训我花的时间比很多人想象的多。光给一份评分手册不够，我会让他们先跑一轮试标，把分歧样本拿出来集体讨论，讨论完再修订手册。这个循环走两到三轮，标注一致性才能稳定下来。我用的是一致性系数做量化，低于阈值的批次会打回重标。有人觉得这样太费时间，我的经验是前期多花两天，后面能省掉一周的返工。
专家评审这块我更看重的是"能解释失败"。专家不光要判对错，还得写清楚模型错在哪一步、是约束漏解还是优先级判断出了偏差。这些评语对后续优化特别有价值，比单纯一个通过率数字有用得多。专家评审的样本量我一般控制在总样本的百分之十到十五，覆盖所有指令类型和复杂度等级，确保每个格子里都有专家意见。
2.2 程序化规则验证与自动评分方法
程序化验证是我用来跑量的主力手段。凡是能写成规则的约束，我都会尽量把它规则化，比如"输出必须包含三个指定字段""回答长度不超过两百字""不能出现某个敏感词"这类，用正则或者结构化解析就能判，又快又稳。格式约束、否定约束、字段完整性这几类特别适合程序化处理，准确率接近百分之百，还不用花钱。
麻烦的是那些没法完全规则化的约束。像"解释要清晰易懂""论证要有逻辑"这种，程序化评分只能做近似，比如统计句子长度分布、检查连接词使用，但这些指标跟真实质量的相关性有限。我的做法是给这类约束设计一个代理指标集，同时明确标注"这是代理指标，不替代人工判断"。代理指标我一般会做一轮相关性验证，拿人工评分做参照，相关性太低的指标直接砍掉，不硬凑。
自动评分的工程实现上，我倾向于把评分逻辑和任务定义解耦。每条任务带一份独立的评分配置文件，里头写清楚用哪些规则、权重怎么分、哪些情况算部分通过。这样换任务集的时候不用改评分代码，只改配置就行。部分通过的判定我设了三档：完全满足、部分满足、未满足。部分满足这一档特别重要，它能暴露出"做了一半"这种中间状态，比简单的通过/不通过信息量大得多。
2.3 LLM-as-a-Judge 与混合评估方法
用大模型当裁判这件事，我的态度是"能用但要小心"。它在语义层面的判断力确实比规则引擎强，尤其是判断"回答有没有偏离指令意图"这种软性约束时，表现比关键词匹配好太多。我一般会让裁判模型输出结构化的判断结果，包括每个约束的满足情况、整体评分、以及简短的判理由，这样方便回溯。
裁判模型的选择上有几个坑我踩过。一个是裁判和被评模型同源的问题，同一个家族出来的模型容易有偏好，判自己家的输出会宽松一些。我的应对是交叉裁判，用不同家族的模型互相评，取一致性高的结果作为最终判定。另一个是位置偏见，把两个模型的输出放一起对比时，裁判容易偏向排在前面的那个。解决办法很简单，正反两个顺序各跑一遍，结果取平均。
混合评估是我目前最常用的方案。程序化规则跑全量，负责硬约束和格式类的判定；裁判模型跑全量里规则覆盖不到的部分；人工评审抽查前两者的分歧样本和高风险样本。三层结果做交叉验证，一致性低于阈值的地方全部进入人工复核队列。这套流程跑下来，成本比纯人工低一个数量级，准确率比纯自动高不少。我觉得关键在于每层各司其职，不要让某一层承担它不擅长的判断。
2.4 对抗测试、消融测试与鲁棒性测试
对抗测试是我用来找模型短板的手段。我会刻意构造一些"陷阱指令"，比如前后矛盾的约束、藏在长句中间的否定条件、看起来很相似但优先级不同的要求。这些指令在真实场景里不一定常见，但它们能快速暴露模型在约束处理上的薄弱环节。我一般会准备一批对抗样本单独跑，不混进主任务集，免得拉低整体分数的可读性。
消融测试的思路是拆开来看。同一条复杂指令，我会生成几个变体：去掉一个约束、把多步骤改成单步骤、把否定约束改成肯定表述。然后对比模型在这些变体上的表现差异。如果去掉某个约束之后模型分数大幅上升，说明它原本就卡在这个约束上。这种归因方式比看总分直观得多，我经常用它来定位具体是哪种约束类型在拖后腿。
鲁棒性测试关注的是稳定性。同一个任务换个表述方式、调换一下约束的出现顺序、加一点无关的干扰信息，模型的表现会不会大幅波动。我见过一些模型在原版指令上表现很好，稍微改个措辞就崩了，这种就属于鲁棒性不足。测试的时候我会记录每个任务在多个变体上的分数方差，方差大的任务标记出来单独分析。鲁棒性差往往意味着模型对指令模式的依赖过强，泛化能力有限。
2.5 测试数据构造、样本分层与统计显著性分析
数据构造这块我有两条路走。一条是人工构造，从指令模板出发，系统化地组合约束类型和复杂度等级，保证覆盖面。另一条是从真实业务日志里脱敏改写，这类样本的价值在于它带着真实场景的"脏"，很多人工构造时想不到的坑都在里头。两条路的样本我一般按七三开混合，人工构造的占七成保证可控性，真实改写的占三成保证接地气。
样本分层是按指令类型和复杂度等级做的二维分层。每个格子里我要求样本量不低于二十条，重度复杂那几档会加到三十条以上。分层的意义在于后续分析时可以按格子拆开看，不至于被总量掩盖了局部问题。分配样本的时候我会刻意让各格子的难度梯度拉开，避免出现大量样本集中在中间难度、两头没样本的情况。
统计显著性分析我一般会做置信区间和配对检验。两个模型的分数差异，如果不做显著性检验，很容易把随机波动当成真实差距。尤其是样本量不大、任务难度偏高的时候，波动会更明显。我通常会跑多轮评测取平均，每轮之间更换部分样本，然后看分数分布的稳定性。差异不显著的时候我会在报告里直接写明"未观察到显著差异"，而不是硬给个排名。这种做法看起来不够"有结论"，但对读者更负责。
3.1 多约束、多步骤与条件分支指令对比
我习惯把复杂指令拆成三个维度来看：约束的数量、步骤的链长、条件分支的嵌套深度。这三个维度单独拉出来都不算难，叠在一起就有的看了。我拿一组“写一份活动方案，预算不超过五千，必须包含三个子活动，每个子活动写明负责人，如果遇到雨天就改到室内”这样的指令去测，不同模型的差异会立刻显现出来。有的模型能把预算守住，却漏掉了雨天分支；有的大步骤都写全了，子活动的负责人却只填了两个。
多约束场景里我特别关注“约束优先级”的处理。指令里通常不会明说哪个约束更重要，但模型得自己判断。预算和活动数量冲突时保哪个？格式要求和内容完整性打架时听谁的？我见过不少模型在约束冲突时选择悄悄放弃一个，还不告诉你它放弃了。这种做法在评测里很要命，因为表面上看起来完成了，实际上漏了关键项。我一般会在评分时把约束满足情况按条列出，逐条核对，而不是只看整体有没有完成。
条件分支是我觉得最能拉开差距的一类。简单的if-else还好，碰到嵌套条件——“如果用户是会员且订单金额超过三百，走A流程；如果是会员但金额不足，走B；非会员一律走C”——模型就开始犯迷糊了。常见错误是把条件组合搞混，或者只处理了主分支漏了例外分支。我测的时候会专门设计一些“每个分支都只有一条样本”的组合，逼模型把每条路径都想清楚。
多步骤指令的难点在于步骤之间的依赖关系。前后步骤有先后顺序的，模型得按序来；后面步骤依赖前面步骤输出的，模型得把中间结果记住。我做过一个测试，让模型先算出某个数值，再把这个数值用到下一步的格式化输出里。结果有的模型第一步算对了，第二步输出时却用了一个完全不相干的数字。这不是理解能力的问题，更像是执行链路上“记不住”或“懒得记”。
3.2 格式约束、否定约束与冲突指令处理对比
格式约束看起来是最容易的，实际上翻车率不低。我要求输出必须是JSON、必须包含指定的三个字段、某个字段必须是数组类型，这些规则写得很清楚，可总有模型在细节上栽跟头——字段名拼错、类型写错、多塞了一个无关字段。更隐蔽的问题是“格式正确但内容错位”，比如把本该放在description里的内容放进了title里。我一般会用结构化的解析器去验证，解析不过的直接判失败，免得人眼看不出来。
否定约束是另一类我重点盯的。指令里说“不要出现任何品牌名称”“不要使用感叹号”“不要提到竞品”，这类要求模型得在生成过程中主动规避。我观察到的情况是，短输出里否定约束守得比较好，输出一长就开始松懈。尤其是那种“不要提及某个概念但又要围绕相关话题展开”的指令，模型往往会绕来绕去最后还是踩线。我测的时候会在提示词里把否定约束放前面和放后面各试一遍，看看位置对遵循率有没有影响。
冲突指令是我用来“压力测试”的保留节目。故意给两条互相矛盾的约束，比如“回答要尽可能详细”和“回答不超过一百字”，看模型怎么处理。好的做法是识别出冲突、主动说明、给出一个折中方案或者请用户澄清。差的做法是闷头写，写到一半违反其中一条，还不吭声。我见过有的模型直接忽略字数限制洋洋洒洒写一大篇，也见过有的模型为了守住字数把内容砍得只剩骨架。这两种都不算好的处理方式。
处理冲突指令的能力其实反映了模型对“指令意图”的理解深度。指令表面矛盾的时候，能不能推断出用户真正想要什么，是个挺高的要求。我印象比较深的是一个模型在遇到冲突时回了一句“这两个要求存在冲突，我优先保证内容详实，如需控制字数请告知”，这种主动沟通的处理方式我给了高分。评测不只是看它做没做到，还要看它在做不到的时候怎么应对。
3.3 长上下文、多轮对话与跨轮一致性对比
长上下文场景下我关注的是“中间遗忘”现象。把一条关键约束放在很长的背景材料中间，前后各塞一堆无关信息，模型还能不能把它捞出来遵守。我的测试结果不太乐观，不少模型对开头和结尾的约束记得牢，对中段的内容就容易忽略。长度超过一定阈值之后，遵循率下降得很明显，而且不同模型下降的曲线形状还不一样，有的缓降有的断崖。
多轮对话里的复杂指令遵循是另一个战场。第一轮定下的约束，到第五轮还在不在？我设计过这样的测试：第一轮要求“之后所有回答都用表格呈现”，然后连续问五个不相关的问题，看模型从第几轮开始忘了这个要求。结果挺有意思，有的模型能撑到第四轮，有的第二轮就恢复成纯文本了。这种跨轮一致性在实际产品里特别重要，用户的设定被忘掉是很糟糕的体验。
跨轮一致性还有个更难的变体：约束在中途被修改。第三轮用户说“刚才那个表格改成只保留两列”，模型得同时记住“继续用表格”和“只保留两列”这两条，还得知道后者是对前者的修正而不是替换。我见过模型把“只保留两列”理解成“不用表格了”，也见过模型继续用原来的列数。这种指令演化的追踪能力，目前各家模型的表现参差不齐。
长上下文和多轮对话叠加的时候问题会放大。上下文长了，模型本来就更难抓住重点；轮次多了，早期设定的约束更容易被稀释。我一般会把这类测试单独拎出来跑，不和短指令混在一起，因为它们的失败模式完全不同。短指令失败多是“没理解”，长上下文失败多是“没记住”，归因方向不一样，优化手段也不一样。
3.4 工具调用、代码生成与数据分析任务对比
工具调用这类任务的指令遵循有个特点：约束不只在文字里，还在工具的接口定义里。模型得同时遵守“用户说了什么”和“工具要求什么”。我测的时候会故意设置一些情况，比如用户要求查天气但没给城市名，或者要求调用一个不存在的工具，看模型是硬着头皮瞎调，还是能识别出缺参数、主动追问或者说明情况。瞎调的模型我扣分扣得很重，因为这在真实系统里会直接导致故障。
代码生成任务我主要看几个点：功能对不对、边界条件处没处理、代码风格符不符合要求。指令里我通常会加一些具体约束，比如“用Python写”“不要用第三方库”“函数名必须是xxx”“要处理空输入”。这些约束单独看都不难，组合起来就有模型顾此失彼了。功能写对了但用了禁止的库，或者函数名对了但没处理空输入，这类“部分满足”的情况特别多。
数据分析任务的指令往往带着“算出来再解释”的两段式要求。模型得先执行计算，再基于结果给出解读。我见过的问题是计算和解读脱节——算出来的数字是一个样，解读里引用的数字是另一个样。还有一种情况是模型跳过了计算直接给结论，看起来像模像样，仔细一查数据对不上。我一般会在评分时把“计算准确性”和“解读一致性”分开打分，避免一个高分掩盖另一个短板。
这三类任务放在一起对比很有意思。工具调用考验的是“对外部世界的敬畏”，模型得知道自己不能乱来；代码生成考验的是“精确执行”，差一个字符都不行；数据分析考验的是“前后一致”，自己算的东西自己得认。我在实际评测里发现，一个模型在这三类任务上的表现相关性并不高，工具调用强的代码未必写得好，代码写得好的数据分析未必靠谱。所以选型的时候不能只看一个总分，得按自己的业务场景对号入座。
3.5 多语言、安全合规与领域知识场景对比
多语言场景下我关注的不只是翻译质量，而是“约束在不同语言里还成不成立”。指令用中文写，要求输出英文，同时要求“不要使用被动语态”，这个约束在英文里的判断标准和中文不一样，模型能不能正确迁移过去是个问题。我测过一些中英混合的指令，模型有时候会把语言约束搞混，该用英文的地方冒出了中文，或者反过来。
小语种的表现差距就更明显了。我用泰语、阿拉伯语这类语种测过一些基础约束，比如格式要求和否定约束，遵循率比中英文低一大截。有些模型在小语种上连基本的指令理解都成问题，更别说复杂约束了。这个现象在做全球化产品的时候必须考虑，不能拿中文的评测结果去推断其他语言的表现。
安全合规场景的指令遵循有它的特殊性。很多约束是“隐性”的，用户不会明说“不要输出违法内容”，但模型得自己守住底线。我测的时候会构造一些边界样本，比如请求本身合规但表述方式容易引发风险的，或者多轮对话里逐步试探的。好的模型能在不误伤正常请求的前提下守住边界，差的模型要么一刀切拒绝所有相关请求，要么该拦的没拦住。
领域知识场景我主要看“专业约束”的遵循。比如医疗场景要求“不能给出具体用药剂量”，法律场景要求“必须注明仅供参考不构成法律意见”，金融场景要求“涉及收益必须提示风险”。这些约束对领域外的人来说可能不明显，但模型得知道。我测下来发现，通用模型在这些专业约束上的表现跟领域微调过的模型差距不小，尤其是在约束的完整性和表述的准确性上。
这几个场景放在一起，我想说的是复杂指令遵循不是一个单一能力。多语言考验的是约束的跨语言迁移，安全合规考验的是边界判断，领域知识考验的是专业常识的内化。一个模型在通用指令上表现好，不代表在这些专项场景上也靠得住。做选型的时候我一般会按场景分别评测，把每个场景的短板摸清楚，再决定用哪个模型、要不要做额外的约束兜底。
4.1 通用大模型与推理增强模型对比
我一开始以为推理增强模型在复杂指令遵循上会全面碾压通用模型，毕竟多了“思维链”这个外挂。实测下来发现不是这么回事，两者的差距比我想的要窄，而且各有各的瘸腿场景。拿那个经典的“多约束方案生成”任务来说，推理增强模型确实在步骤完整率上占优，它会老老实实把每一步的约束条件列出来再逐一满足。通用模型则喜欢跳步，脑子一热直接给结果，回头检查才发现漏了约束。可一到格式约束场景，局面就反过来了。通用模型对JSON字段名、类型这些细节记得更牢，推理增强模型有时候为了“把逻辑讲清楚”会在输出里加一堆解释性文字，把原本干净的格式撑破了。
这个现象让我重新理解了两类模型的差异。推理增强模型的长处在于“拆解”，它能把一条复杂指令拆成子任务来处理，适合那种步骤之间有依赖关系、需要做中间计算的场景。我测过一个多跳推理结合格式约束的任务：先根据给定数据算出一个值，再把这个值填进指定模板的指定位置。推理增强模型的表现明显更稳，它不会在跳步的时候丢失上下文。通用模型在这个任务上翻车率就高一些，主要是算对了但填错了地方，或者算到一半开始自由发挥。
我也注意到推理增强模型有个成本问题在里面。它输出的token数普遍更多，因为它会把推理过程写出来。这在评测时不影响正确率，但在实际产品里意味着更高的延迟和更贵的账单。我测过一个中等复杂度的指令，推理增强模型的响应时间差不多是通用模型的两到三倍。所以选型的时候不能只看谁更准，得把“多花的钱和多等的时间”折算进去。我目前的判断是：对正确率极度敏感、对延迟不敏感的场景，推理增强模型值这个价；日常对话、简单指令场景，通用模型性价比更高。
4.2 开源模型与闭源模型对比
开源模型和闭源模型的差距，在简单指令上已经很小了。我拿一组基础约束去测，比如“输出三行”“每行以数字开头”“不要出现某个词”，开源模型的表现跟闭源旗舰打得有来有回。这个结果我其实有点意外，因为前两年开源模型在这种细节遵循上还经常掉链子。现在的情况是，中量级的开源模型在常规约束上已经及格了，偶尔还能超常发挥。
差距体现在“脏活累活”上。我所谓的脏活，指的是那种约束多、条件绕、还夹杂着相互矛盾要求的指令。闭源模型在冲突指令面前更倾向于主动说明、给出折中方案，开源模型则更容易闷头硬写，写到哪算哪。有一次我测一个“必须包含至少五个要点但总字数不超过一百五十字”的冲突指令，闭源模型回了我一句“这两个要求较难同时满足，我尽量压缩”，然后给出了一个勉强能看的版本。开源模型的反应是直接无视字数限制，洋洋洒洒写了三百多字，五个要点倒是都包含了。
开源模型还有一个问题在稳定性上。同一个指令跑五遍，闭源模型的输出质量波动不大，开源模型有时候能给你来个“抽奖”式表现，好的时候接近闭源，差的时候连基本格式都守不住。这个波动对评测来说挺折磨人的，我一般会跑多次取平均，但单次结果的不确定性意味着实际部署时得加更多的兜底逻辑。
部署灵活性是开源模型的绝对优势。我可以自己控制版本、自己微调、自己决定什么时候升级。闭源模型的API一更新，行为可能就变了，评测结果的可复现性会打折扣。我遇到过某次闭源模型小版本升级后，之前在特定格式约束上的表现突然变差，这种事在开源方案里是可以避免的。所以我的结论是：如果业务场景对稳定性要求高、又不想被供应商牵着走，开源模型值得认真考虑，前提是你得接受它在复杂冲突场景下的处理能力还有差距，并且愿意投入精力做兜底。
4.3 约束满足率与步骤完整率表现对比
约束满足率和步骤完整率这两个指标，我一般分开看，因为它们反映的是不同层面的能力。约束满足率看的是“说到的有没有做到”，步骤完整率看的是“该做的有没有做完”。我测下来发现一个挺普遍的现象：模型在约束满足率上普遍高于步骤完整率。换句话说，它们更擅长“守规矩”，不太擅长“走全程”。
我拿一个差旅报销流程的指令去测：要求分四步走——核对发票信息、计算可报销金额、填写报销单、给出审批建议，每一步都有具体的格式要求。结果好几个模型在第一步和第二步做得很好，发票信息核对得仔细，金额也算对了，到第三步填单子的时候开始偷工减料，该填的字段只填了一半，第四步的审批建议直接一句话带过。整条链路能走完的模型不多，走完还能保证每一步都符合格式要求的更少。
约束满足率这边也有意思。我把约束分成“显性”和“隐性”两类。显性约束是那种明确写出来的，比如“不超过两百字”“用JSON格式”“包含三个字段”。隐性约束是隐含在指令意图里的，比如用户说“用表格对比三款产品”，那至少要保证三款产品都在表格里、对比维度得清晰。显性约束的满足率整体不错，大部分模型能守住八成以上。隐性约束的满足率就参差不齐了，有的模型会漏掉一款产品，有的模型表格画了但维度混乱。
步骤完整率和约束满足率之间还有一个交叉效应我特别关注：步骤越多，约束满足率下降得越厉害。三步以内的指令，约束满足率还能维持；超过五步，很多模型就开始顾此失彼了，前面的步骤守住了格式，后面的步骤就放松了，或者反过来。我在评分表格里会按步骤逐条记录约束满足情况，这样能看出模型是在哪一步开始“放弃治疗”的。这个数据对实际使用很有参考价值，如果你的业务流程有七八个步骤，就得知道模型大概从第几步开始不靠谱，提前做好人工复核的安排。
4.4 格式合规性、鲁棒性与错误恢复能力对比
格式合规性这一块我测得很细。JSON输出是最常见的测试项，我不仅看能不能解析，还看字段名拼写、字段类型、嵌套结构对不对。有些模型输出的JSON能解析，但字段名的大小写跟要求不一致，或者本该是数组的字段给了一个字符串。这类错误人眼扫一遍不一定看得出来，但程序一跑就崩。我一般用严格的schema校验，差一个字符都判失败，不给“差不多”留余地。
鲁棒性测试我喜欢用“扰动法”。同一个指令，我换几种说法去问，看模型的表现稳不稳。比如把约束条件放在句首和放在句尾各试一遍，把长指令拆成两段发和一次性发各试一遍。我观察到的情况是，约束放在句首时遵循率普遍更高，放在大段文字中间时容易被忽略。有些模型对指令的表述方式特别敏感，换个说法就守不住约束了，这种在实际产品里很危险，因为用户不会每次都按你测试时的句式来提问。
错误恢复能力是我最近才开始重点关注的维度。具体做法是：故意在指令里埋一个“坑”，比如要求调用一个不存在的工具，或者给出一个自相矛盾的约束，看模型是硬着头皮往下走，还是能识别出问题并主动沟通。表现好的模型会回一句“你提到的这个工具不在可用列表里，请确认”，表现差的模型会编一个假的调用结果糊弄过去。我印象很深的一次测试，我要求模型“用Python的pandas库读取一个CSV文件”，同时又在约束里写了“不要使用任何第三方库”。一个模型的处理方式是先指出冲突，然后给出两个方案让我选：要么放弃pandas，要么放宽第三方库限制。另一个模型直接忽略了“不要使用第三方库”这条，闷头用pandas写完了代码。前者的处理方式我给了高分，因为它把决策权交还给了用户，而不是替用户做选择还瞒着不说。
格式合规性、鲁棒性、错误恢复这三个维度放在一起看，我发现一个规律：格式合规性强的模型，鲁棒性不一定好；鲁棒性好的模型，错误恢复能力往往也不错。这背后的逻辑我想了想，可能是这样的——鲁棒性好的模型对指令的理解更“泛化”，它抓住的是约束的语义而不是字面表达，所以换种说法它也能认出同一条约束。这种泛化能力也让它在遇到矛盾指令时更容易察觉到“不对劲”，从而触发主动沟通的行为。格式合规性更偏“机械执行”，跟语义理解的关系没那么直接，所以跟另外两个维度的相关性不强。
4.5 成本、延迟与部署可用性对比
成本这块我算得比较细。不只看每百万token的单价，还看“完成同一个任务实际花多少钱”。有的模型单价低，但完成一个复杂指令要输出一大堆冗余内容，算下来总成本反而更高。我测过一个多约束的格式化输出任务，模型A单价是模型B的一半，但模型A平均输出长度是模型B的两倍多，实际任务成本模型A反而贵了。这个账不算不知道，一算吓一跳。我现在的做法是按任务类型分别统计“单任务平均成本”，而不是只看标价。
延迟的差异在实际产品里比评测分数更影响体验。我测下来，同样的复杂指令，不同模型的响应时间能差出三到五倍。推理增强模型普遍慢，这个前面提过了。闭源大模型里也有快慢之分，有些模型做了推理加速，首token延迟能压到很低，但完整输出的总时长不一定短。我一般会分两个指标看：首token延迟和完整响应时长。前者影响用户“感觉快不快”，后者影响用户“等多久才能用”。流式输出能缓解首token的问题，但总时长摆在那里，复杂指令就是需要更多时间生成。
部署可用性是个容易被评测忽略的维度。我遇到过模型在评测集上表现很好，但API的限流策略很严格，高峰期经常返回超时错误。这种在实际业务里就是不可用。开源模型这边，部署可用性取决于你自己的运维能力，你得考虑GPU资源够不够、推理框架调优做没做、扩容方不方便。我自己的经验是，开源模型在流量稳定、可以提前规划容量的场景下很划算，突发流量场景下闭源API的弹性更好，但得接受它的限流和排队。
我还想提一个“隐性成本”的概念。闭源模型换版本、改行为、调价格，这些变动对业务方来说是隐性成本。我有个项目因为上游模型升级导致输出格式变了，下游的解析逻辑全得跟着改，这个工作量在选型时根本没人算进去。开源模型没有这个问题，版本锁死就行，但反过来你得自己承担安全补丁、性能优化的活。这两条路的隐性成本方向不一样，得根据自己的团队情况来权衡。我目前的倾向是：核心业务用开源模型打底、闭源模型做增强，既锁住基本盘，又能享受前沿能力，代价是架构复杂度会上去一些。
5.1 典型失败模式与错误归因分析
我把近半年的评测记录翻出来做了个归类，发现失败模式翻来覆去就那么几类，但每一类的成因差别挺大。最常见的是“约束遗忘”，模型在长指令进行到后半段时，把前面明明说过的限制条件给丢了。我拿一个八步骤的流程指令反复测，前四步的约束遵守率能到九成，到第七步突然掉到六成以下，感觉像是模型的“工作记忆”被前面的内容塞满了，后面的约束挤不进去。这种失败跟模型本身的上下文管理能力有关，换一种指令结构有时能缓解，但根治不了。
另一类高频错误是“过度发挥”。模型在完成指令要求的基础上自作主张加了料，比如要求输出三条建议它给五条，要求用陈述句它给你加感叹号。我一开始以为这是个别现象，后来发现这跟训练数据的分布有关，很多模型被训练成“尽量 helpful”，结果 helpful 过了头，把用户没要的东西也塞进来了。这种失败在开放域任务里不算大问题，但在格式敏感的流水线里就是灾难，下游解析器直接报错。
还有一种失败模式我觉得最隐蔽，就是“假性完成”。模型输出了一个看起来结构完整、格式规范的结果，但里面的内容是编的。我测过一个数据提取任务，要求从一段文本里抽出特定字段填进表格，有个模型表格画得很漂亮，字段名全对，但有两处数值跟原文对不上。它没有报错，没有说“我没找到”，而是用看起来合理的数字把空填了。这类错误人眼不仔细核对根本发现不了，但如果这个结果进了数据库，后面就是一连串的脏数据。
归因的话，我现在的判断是三分天注定、七分靠 prompt。模型本身的指令遵循能力有天花板，这个得认，但很多失败案例追根溯源是指令写得不够“防呆”。约束条件藏在长句子里、关键要求没有显式标号、格式规范只给了一个模糊的示例，这些都会把模型往错误的方向推。我做过一个对照实验，同一批任务，把指令里的约束全部提出来单列成清单，失败率直接降了将近三成。这个发现让我在后续的评测里养成了一个习惯：每次看到失败案例，先回头检查指令本身有没有歧义，再去怪模型。
5.2 Prompt设计、指令拆解与约束显式化策略
Prompt 设计这块我踩过的坑比吃过的饭还多。最开始我习惯把要求都揉在一段话里，写得跟小作文似的，结果模型经常顾此失彼。后来我改了策略，把约束按类型拆开：格式约束放一块、内容约束放一块、禁止性约束单独列一块。拆开之后我发现模型对“不要做什么”的敏感度明显低于“要做什么”，所以否定约束我会用更醒目的方式写，比如单独成行、前面加个感叹号标记。
指令拆解是个技术活。我的经验是，步骤之间如果有数据依赖，就一定要把依赖关系写清楚，不能默认模型能自己推出来。比如“根据第一步算出的结果填写第二步的表格”，这句话不能省，省了之后模型有概率在第二步用原始数据重新算一遍，算出来的数跟第一步对不上。我一般会在拆解后的每一步前面标上序号，并且用“使用上一步的结果”这种显式引用把步骤串起来。测试下来，加了显式引用的版本在步骤完整率上能高出十几个百分点。
约束显式化说起来简单做起来容易漏。我现在写 prompt 会过一遍检查清单：字数限制写了吗、格式要求给示例了吗、禁止项列全了吗、边界条件说明白了吗。这个清单我每次都在用，每次都能查出漏掉的东西。举个具体的例子，我要求模型输出一个表格对比三款产品，一开始只写了“用表格对比”，结果模型给的表格列数跟我想的不一样。后来我改成“输出一个四列的表格，列名依次是产品名称、价格、核心功能、适用场景，三款产品各占一行”，输出一下子就规整了。约束写得越具体，模型的发挥空间越小，但结果的可控性越高。在需要稳定输出的场景里，我宁愿牺牲一点灵活性换确定性。
还有一个策略我觉得挺管用，就是给“正例”和“反例”各一个。光说“用 JSON 格式输出”不够，我还会附上一小段正确输出的样例，再写一句“不要像下面这样在 JSON 外面包一层解释文字”。反例的作用比我想的大，模型看到反例之后明显更清楚边界在哪。这个技巧在格式约束特别多的任务里效果拔群，我测过加了反例之后格式合规率从七成出头直接拉到九成以上。
5.3 模型选型、路由与组合使用建议
选型这件事我现在的态度很明确：没有全能冠军，只有组合拳。我的基本配置是一个便宜大碗的通用模型打底，负责处理日常的、约束不复杂的指令，再加一个推理增强模型处理高难度的多步任务，最后挂一个格式合规性特别强的模型专门做结构化输出。这个组合听起来有点折腾，但算下来总成本比全用旗舰模型低不少，效果还更稳。
路由策略我试过两种。一种是按任务类型硬路由，规则写死：带 JSON 输出的走 A 模型、带多步计算的走 B 模型、普通问答走 C 模型。这种方式的优点是可控，缺点是规则维护起来烦，新任务类型一出来就得加规则。另一种是让一个小模型先做意图分类，判断指令的复杂度和约束类型，再决定路由到哪个模型。后者灵活但多了一层不确定性，分类错了后面全错。我现在偏向混合方案：高频任务用硬路由，长尾任务用分类器兜底，分类置信度低的时候直接路由到最强的模型，宁可多花点钱也别在长尾场景上翻车。
组合使用还有一个玩法是“串联”。让一个模型先出草稿，另一个模型做检查。我试过用通用模型生成格式化内容，再用一个专门做校验的轻量模型对照约束清单逐条检查，发现有漏就回退重写。这个方案在约束特别多的任务里效果很好，相当于给输出加了一道质检工序。代价是延迟翻倍，所以我只在离线批处理的任务里用这个模式，在线交互场景还是单模型直出。
模型选型不能只看评测分数，这个我吃过亏。有个模型在我的评测集上约束满足率排前三，但一上生产环境就发现它的输出长度极不稳定，同样的指令有时候给三行有时候给三十行，导致下游的 token 成本完全没法预估。后来我在选型表里加了一列“输出长度方差”，专门记录这个指标。现在我的选型逻辑是：先看硬指标（约束满足率、格式合规率）筛掉不达标的，再看软指标（输出稳定性、延迟分布、成本方差）在剩下的里面挑。软指标不过关的模型，硬指标再好看也不敢用。
5.4 评测基准维护、复现与持续监测
评测基准这东西有保质期，我一开始没意识到。半年前精心构造的一套测试集，现在跑出来的分数已经没有区分度了，好几个模型都能拿满分。原因很简单，模型在迭代，测试集没变，被刷爆是迟早的事。我现在每季度会做一次基准的“新鲜度检查”，把那些所有模型都做对的题剔掉，换成新的挑战样本。保持一定比例的“难题”在里面，基准才有生命力。
复现性是我踩过的另一个坑。同一个模型、同一套题，我隔两周跑一次，分数能差出五个百分点。排查下来发现两个原因：一是模型提供方的后台在悄悄更新，版本号没变但行为变了；二是评测脚本里的随机种子没固定，采样温度的影响被放大了。现在我每次评测都会记录完整的元信息：模型版本号、API 调用时间戳、温度参数、随机种子、评测脚本的 commit hash。这些信息缺一个，结果就没法复现。开源模型这边好一些，版本锁死就行，闭源模型只能靠勤记录来对冲不确定性。
持续监测我建议做成自动化的。我的做法是搭了一个轻量的监控流水线，每周从生产日志里采样一批真实用户指令，脱敏后自动跑一遍评测，重点盯三个指标：约束满足率有没有掉、格式合规率有没有波动、平均输出长度有没有异常漂移。这三个指标任何一个出现显著变化，就触发人工排查。这套机制帮我抓到过一次上游模型静默升级导致格式约束失效的问题，发现的时候影响面还很小，及时做了回退。
基准维护还有一个容易被忽略的点：测试集的多样性。我早期构造测试集的时候偷懒，同一个模板换了几个词就当成新样本，结果模型在模板题上分数很高，一遇到真实用户的花式提问就拉胯。后来我强制要求测试集里至少三成的样本来自真实用户日志，并且人工改写过的比例不能超过一半。真实样本里的那些别扭表达、省略、错别字，恰恰是检验模型鲁棒性的好东西。我现在宁测试集看起来“脏”一点，也不想它太干净以至于失去检验能力。
5.5 复杂指令遵循能力对比评测的趋势展望
我觉得下一个阶段最大的变量是多模态指令的加入。现在的评测基本还是纯文本的天下，但实际产品里用户已经开始甩截图、传表格、丢语音转文字了。混合模态的约束遵循比纯文本难得多，比如“根据这张图表生成一段描述，字数不超过一百字，且必须包含图表里的三个关键数据点”，模型得先把图看懂，再把约束记住，最后在输出里同时满足内容和格式要求。我试过几个支持视觉输入的主流模型，在这类任务上的表现参差不齐，有的连图表里的数字都读错，更别提遵循字数约束了。这块的评测方法论现在基本是空白，谁先建立起标准谁就有话语权。
动态评测可能会取代静态测试集。我现在的评测方式本质上是“出一张卷子考所有人”，但模型迭代太快，卷子很快就过时了。我设想中的下一代评测是“出题机”模式：用一个大模型根据当前模型的薄弱环节自动生成新的测试用例，难度动态调整，永远让评测集比模型能力领先半步。这个想法在技术上已经可行了，我做过小规模实验，用模型生成对抗样本去测另一个模型，能挖出不少静态测试集漏掉的问题。难点在于自动生成的质量控制，生成的题不能太偏也不能太简单，这个校准目前还得靠人工介入。
个性化评测也会是一个方向。通用 benchmark 测的是“平均能力”，但实际业务场景千差万别，一个做法律文书生成的团队和一个做客服机器人的团队，需要的指令遵循能力完全不是一个维度。我预测未来会出现更多面向垂直场景的评测套件，比如“合同条款提取指令遵循评测”“多轮售后对话约束遵循评测”这种。这类评测的构造成本高，但针对性极强，对实际选型的指导价值比通用榜单单高出一个量级。我自己已经在尝试给几个高频业务场景建小型专用评测集，样本量不大但贴近真实分布，用起来比通用集顺手。
最后一个趋势我猜是评测和优化的边界会越来越模糊。现在的流程是先评测、再根据结果改 prompt 或换模型，未来可能会变成评测结果直接驱动 prompt 自动优化。我见过一些早期的尝试，用评测反馈做信号去搜索更好的指令表述，效果初现但还不稳定。这条路如果走通，评测就不只是“打分”了，而是变成优化闭环里的一个传感器。到那时候，做评测的人和做产品的人可能就坐在同一张桌子上了。
