1. 为什么评测结果总在“微妙波动”：非确定性输出的真实来源做模型评测的人，大概都经历过这种状况：今天跑同一份测试集，综合分数比昨天高了0.3分，你以为是Prompt改动起了效果，复盘时发现昨天的分支根本没动模型，只是重新跑了两次推理。最后真相大白，问题不在模型版本，而在输出本身——同样输入、同样参数，模型每次吐出来的内容就是不完全一样。这不是偶发故障，而是生成式模型的固有属性。理解这件事之前，得先把“非确定性”的来源拆开看。1.1 采样参数：temperature、top_p 与随机数种子自回归语言模型在生成下一个Token时，本质上是输出一个概率分布，再从这个分布里“抽签”决定实际Token。只要你没有把采样参数设置成完全贪心（greedy decoding），温度、top_p、top_k这些参数就会引入随机性。temperature控制概率分布的锐化程度，温度越高，低概率Token被抽中的机会越大；top_p是核采样，只从累计概率达到阈值的Token里抽；即便你都固定下来，随机数种子变了，抽样路径也会变。我见过不少团队以为“temperature=0就绝对确定”，实际并非如此。部分推理后端在temperature=0时会走贪心路径，但遇到并行计算、浮点累加顺序变化时，仍可能产生微小差异。这里有个容易被忽略的点：并行Token采样和beam search在极端情况下也有非确定性，因为CUDA算子层面存在非原子操作的重排可能。1.2 推理后端、硬件与浮点累加：被忽略的隐性噪声文本层面的随机性大家还有感知，硬件层面的差异就很少有人排查了。同一个float运算在GPU上的累加顺序不同，结果就可能差一个尾数，这个尾数在连续几层网络中被放大后，就可能影响最终采样概率的排序——尤其在logits差距很小的情况下。另一个隐性来源是并发请求。评测时通常用多线程或异步方式同时打多个推理请求，请求到达后端的批次不同，模型内部执行的矩阵运算顺序也不同。有些推理服务还会动态合并请求，把batch size从1变成8，这本身就会改变浮点累加路径，输出自然跟着变。这些非确定性对“分数线上涨0.1还是下跌0.1”的影响是实实在在的。如果你的评测流程里没有一层东西来处理这个问题，你做的所有对比实验都可能建立在一堆随机噪声之上。1.3 用户视角的问题：评测分数没变，答案是变了有一种更隐蔽的情况比分数波动更难受：分数看起来完全一致，但抽看具体回答，同一个问题前后两次跑的答案措辞完全不同，甚至结论角度都换了方向。指标没暴露差异，因为你的评分器只对最终答案做了关键字匹配，或者只看格式对不对。可一旦下游任务需要“把答案再喂给下一个Agent”，或者需要把多条生成结果合并成一份报告，这种逐条差异就会被放大成流程层面的不一致。于是归一化就不再是“加分项”，而是评测工程里必须做的一道工序。这也是Harness层需要承担这项工作的原因——它不是模型推理的一部分，却是评测链路里承上启下的关键位置。2. Harness层该做什么：归一化放在这里的边界逻辑很多人听到“Harness层”会觉得陌生，其实它在评测框架里的定位很朴素：负责把一条测试请求从“原始输入”变成“可评分的标准化输出”。模型本身只管生成内容，测试集只管提供问题和标准答案，中间那层组织逻辑就是Harness。2.1 Harness层的职责边界我理解Harness层至少要做四件事：接收测试用例，渲染Prompt模板，把可变参数灌进去；调用模型推理接口，按设定好的并发数、重试策略去取输出；拿到原始输出后，做清理、提取、格式化，产出一个稳定结构；把稳定结构交给评分器，由评分器与标准答案比对。大多数评测框架的Harness层已经覆盖了前两项，第三项常常被省略，或者被挪到了评分器里“临时凑合”。但归一化后处理恰恰应该稳定落在Harness层，因为它要同时满足“可见原始输出”和“不关心具体评分逻辑”两个条件。2.2 为什么不放在评分器或模型层先说为什么不适合放在更下层。模型层是推理服务，它干的是生成活，你总不能指望每个推理服务都内置一套“评测输出规范化模块”。不同模型的输出风格差异极大，把归一化逻辑下沉到模型层，意味着每次换模型都要重新实现一遍，而且会污染推理服务的职责边界。再说为什么不适合放评分器。评分器应该只做一件事：判断“最终答案”和“标准答案”是否一致，或者打分。如果让它顺带承担“从原始输出里提取答案”的工作，一旦提取规则变化，所有历史评分都会失去可对比性。更麻烦的是，同一个测试集可能会有多个评分维度，比如一个查正确性，一个查格式规范，你把归一化放在评分器里，两个评分器就要各写一遍清洗逻辑，迟早出现规则漂移。Harness层是离模型输出最近、又能统一收口的位置。在这一层完成归一化后，所有下游评分器拿到的都是同一份“干净数据”，评分器之间不会因为清洗方式不一致产生分歧。2.3 不同任务类型的归一化粒度Harness层做归一化，粒度必须跟着任务类型走，不能一套规则打天下。抽取式问答：只需要提取答案文本，做大小写和标点归一；数学计算题：需要统一数字格式，比如“0.5”和“.5”要归一成同一种写法；结构化输出任务：要求模型返回JSON或表格，则需要做字段对齐、键排序、值类型校验；开放式写作：几乎不能归一化，顶多做末尾换行清理，过多处理反而伤内容。这意味着Harness层的归一化模块必须有“策略模式”，按Task Type注册不同的处理链，而不是写一个全局正则处理函数一把梭。我见过太多项目前期图省事，全局统一清理，后来遇到结构化输出任务时发现JSON被清得支离破碎，只能推倒重来。3. 完整后处理管线拆解：从原始文本到稳定答案归一化不是简单replace几个字符，它是一条有先后顺序的管线。顺序错了，效果会打折扣，甚至把有效信息处理坏。我通常在Harness层维护一个后处理链，每一环都做成可插拔函数。这里给出我实际使用的一套管线顺序，给想做归一化的读者一个参考。3.1 输出提取：剥离过程文本，定位最终结果第一步是从模型的原始输出里找出“真正要评分的那段内容”。大模型在回答问题时经常带多余信息，比如先分析一段，再给结论；或者把思考过程也吐出来；又或者干脆用“根据以上分析，答案是XXX”这种句式。评分器如果直接对着整段输出做匹配，很容易被过程文本干扰。Harness层的提取策略通常是这几种：正则定位“最终答案”“答案是”“Therefore”等标记，截取标记后的内容；结构化输出任务里，用花括号或方括号边界做提取，拿到完整JSON块；思维链任务里，按约定好的分隔符（比如“最终输出:”）截取后半部分。这一步的原则是“宁可多截一点，不要少截”。因为后续还有格式清理环节，多出来的尾巴可以被正则修掉；截短了，正确答案可能直接被切掉，评分器想救都救不回来。3.2 格式层规范化：代码块、引号、空白与Unicode提取出目标片段后，进入格式清理。这块最琐碎，却也最见功力，我列一下实际项目里最常用的一组规则：去除Markdown标记，比如```、**、##，但要在“提取答案代码”类任务里保留代码块内容，这个需要做策略判断；统一引号，把英文双引号、中文引号全转成一种形式；归一化空白字符，多个连续空格变一个，全角空格变半角，行尾空格删除；Unicode归一化（NFKC），把全角字母数字、特殊符号转成标准形式。不要小看引号和空白的处理。很多评测标准答案是人工标注的，标注人顺手打了个中文引号，模型输出的是英文引号，精确匹配直接判错，可实际上语义完全一样。这类问题在中文评测集里出现频率非常高。格式层还需要处理一个特殊场景：换行符。有些模型会用\n来表示换行，有些会输出真实换行。如果你的归一化规则把“\n”作为字面量替换掉，而真实输出里的换行符又没有同步处理，就会导致提取出来的答案中间夹着大量断行，评分器的字符串匹配直接崩掉。正确做法是先统一成真实换行，再做最后的空白清理。3.3 结构数据归一化：JSON排序与schema对齐近期很多评测任务要求模型输出JSON格式。相比纯文本，JSON的归一化更复杂，因为键值顺序、缩进、字段缺失都会影响下游解析。我的做法是三层处理：提取JSON块：从输出文本里用边界匹配找到最外层花括号；解析与类型强转：把字符串里的“True/False/null”转成JSON标准值，数字从字符串转成数字类型；键排序与字段补齐：用sort_keys=True输出稳定结构，并对照schema给缺失字段补默认值。这里有个关键点：排序要在序列化阶段做，不是排序字符串。如果拿原始字符串做字符排序，JSON直接改坏。正确流程是用解析库（比如Python的json模块）解析成dict，再设置sort_keys=True重新序列化。还有一个小技巧，如果任务允许，schema约束比后处理归一化更省事。在Prompt里写清楚“必须返回JSON key为以下顺序”，模型输出结构通常会更稳定。但你不能指望所有模型都严格遵守指令，所以Harness层还是要保留schema对齐能力，做双重保险。3.4 语义级兜底：同义改写与数字格式统一格式归一化解决不了语义层面的等价问题，所以管线里还要加一层语义兜底。这一层不用做得太深，但要把最常碰到的几个坑填平。数字格式是最典型的例子：0.5和.5要统一；10000和10,000要分清是千分位还是小数点；1e3和1000要看任务约定；中文“百分之五十”和“50%”在需要时归一到同一种表达。这几条直接用正则就能处理，但要注意作用域，别把普通句子里的人名、专有名词误伤。此外，同义改写是可选层。比如“北京市”和“北京”是否等价，“中华人民共和国”和“中国”是否算同一答案，这些要按评测集的标准答案约定来配置。我的建议是Harness层不要主动做语义级强替换，容易把正确答案改成错误答案。更稳妥的做法是把它做成一个“候选答案别名表”，由测试集维护，Harness层只做匹配时展开。所以这层的核心原则是：能做格式归一的不要做语义归一，能做别名表的不要做模型改写。4. 结果聚合与缓存：让非确定性进一步“收敛”无论归一化多强，它处理的只是“已生成输出”的格式与结构，改变不了模型每次生成的随机性。要让最终的评测指标更稳定，Harness层还需要在归一化之后再补两道工序：多次运行的结果聚合，以及输出缓存。4.1 多次运行的确定性聚合策略多数评测框架允许同一测试用例重复运行多次，再把分数合并成一条指标。问题在于怎么合并最合理。最大值策略（Max）：偏乐观，适合代码生成、SQL编写这类“只要一次成功就算成功”的任务；多数投票（Majority Vote）：主体上是让多个采样结果投票，选出现次数最多的答案，适合闭卷问答、选择题场景；中位数或均值：对需要看边缘分布的任务更稳，但要求答案本身可量化。我实际项目里最常用的是“答案级多数投票 + 分数级均值”的组合。先在Harness层对几十次采样的输出做归一化，然后按归一化后的文本做等价归类，拿出现频率最高的答案作为这条测试用例的“代表输出”，再把代表输出交给评分器。这样能有效压制单次采样的随机波动，同时又不掩盖模型本身的真实能力差异。这里有个坑：别把多数投票放在评分之后、分数之前。如果先对每次采样分别打分，再对分数求平均，模型输出里偶尔出现的“正确但不规范”答案会被直接判错，然后被投掉，最后分数偏低。先归一化、再投票、再评分，流程顺序错了结果差别很大。4.2 输出缓存与幂等校验Harness层做归一化还有个额外好处：天然适合做输出缓存。缓存的粒度是“请求键 + 归一化规则版本”。请求键通常包括：模型名称和版本；采样参数（temperature、top_p、max_tokens）；Prompt哈希；归一化规则版本号。只要这些都没变，同样的输入就不必反复请求模型，直接复用上一次归一化后的输出。评测回归时，这一手能省掉大量推理费用和时间，尤其在测试集规模上万条的时候，缓存命中率往往能到六成以上。缓存有一个容易忽略的注意事项：缓存键里一定要带上采样参数。我见过有人只缓存了Prompt哈希，没带temperature，结果同一道题在不同温度参数下复用了同一条输出，评测结果失真，排查了很久才发现是缓存逻辑把“该有的随机性”给吞掉了。4.3 回归测试中的误差边界归一化做完之后，评测分数不会完全零波动，但应该收敛在一个合理区间里。我一般会在评测跑完后额外输出一个“波动率指标”，也就是同一用例在多次运行下分数的标准差或变异系数。如果波动仍然很大，首先要检查的是Harness层归一化规则有没有真的覆盖到这个任务类型，而不是直接怀疑模型。比较实用的做法是设一个阈值，比如变异系数超过0.05就要告警，并在评测报告里高亮标注“当前指标受非确定性影响较大”。这样模型优化的同学就能意识到，某个改动导致的分数上涨0.2可能还在噪声区间里，不能当成有效结论。没有这个边界控制，评测结果很容易被误读成模型能力变化。5. 踩坑清单：归一化过程中最容易翻车的细节最后整理一下我在Harness层做归一化时踩过的一些实际坑，每一个都是花了不少排查时间才搞明白的，提前写出来帮读者少走弯路。5.1 规则叠加顺序：先提取，再格式化，不要反过来我最早做归一化时，为了追求“一次性全部处理干净”，写了一个大正则同时做提取、去标记、替换引号。结果出现了很离谱的情况：模型输出被转义成字面意义的“\n\n”，我的正则先替换了引号，把转义符结构打乱，后面的信息提取直接失效。矫正后的铁律是：严格按“提取主体 -> 结构定位 -> 格式清理 -> 语义统一”的顺序执行。提取是最先的步骤，尽可能在原始输出最“原生态”时做；格式清理放在提取之后，才不会把主体内容裁坏。一旦顺序颠倒，后面所有步骤都可能被前面一步的副作用带偏。5.2 场景误伤：需要原样输出的任务被“修坏”归一化规则不管多完善，都可能有副作用。最典型的是代码生成任务：你辛辛苦苦清理Markdown标记，结果把模型输出里的缩进空格给吞了；你统一了全角符号，结果把代码字符串里的中文引号也替换成了英文引号，程序直接编译不过。这就是为什么我在前面强调“策略模式”而不是全局清理。每个任务类型的归一化链要独立注册，代码生成任务就跳过标点归一化，只做代码块提取和尾部空白清理；数学题任务只做数字格式统一，不做同义替换。宁可让某些任务少归一化，也不要让规则跨场景误伤。实战经验：每加一条归一化规则，一定要跑一遍现有全部任务类型的样本集，抽查那些“不需要被这条规则处理”的任务有没有被动过。这条规则我称之为“反向回归验证”，它的价值比正向用例回归还高。5.3 怎么判断归一化是否生效：方差量化与样本审查很多团队做了归一化，但说不清它到底有没有用，因为缺少量化判断方案。我建议从两个维度看。第一个维度是指标方差。选一批波动明显的评测用例，在不改动模型的前提下，分别跑“无归一化”和“有归一化”两条流程，对比分数的变异系数。如果归一化后指标方差明显下降，说明处理有效性；如果方差几乎没变，说明规则没打中要害，需要审查用例样本的实际输出差异。第二个维度是“等价样本抽查”。每次跑完评测后，随机抽几十条“被归一化规则修改过输出”的样本，打印出原始输出和归一化后输出，人工对着看。这一步能很快发现误伤问题。我见过最典型的一个问题是：归一化规则把模型输出的核心结论句末尾的句号去掉了，而标准答案恰好以句号结尾，导致大批用例判错。这种问题不做样本抽查看不出来，只看方差指标完全无感。5.4 缓存命中率的维护：规则版本号是命根子前面提到缓存要靠“归一化规则版本号”作为请求键的一部分，这里单独强调一下：版本号一定要跟代码里的规则配置强绑定，不能靠人肉更新。我踩过的坑是规则改了一版，但配置中心里忘了同步版本号，导致Harness层继续用旧版本的缓存结果，新规则完全没有生效，测评报告数据集体失真。最稳妥的做法是把规则配置本身计算哈希值，用这个哈希当作版本号。规则只要有变动，版本号自动变化，缓存自动失效，不需要任何人工记忆。最后说点实在的我在实际项目中体会最深的一点是：归一化不是“锦上添花”，而是评测链路里最容易产生“隐性收益”的部分。它不会提升模型本身的能力，但它能把真实能力从噪声里剥离出来，让每一条指标变化都可解释。如果你发现评测分数在多个分支间摇摆不定，又找不出模型差异，先不要急着调模型，回头看看Harness层有没有做完整的后处理。把非确定性输出归一化这一步补齐，很多莫名其妙的“波动”会立刻安静下来。尤其是当你的评测结果需要被用来发布横向对比报告、或者做版本发布依据时，这一层的价值会体现得更明显。最后再分享一个小建议：别把归一化规则设计得太“聪明”，尽量用可读、可审查的白名单式规则，比复杂的智能转换更容易长期维护。你只需要盯着香草色的“初始输出”和“最终评分输入”两头，中间每一步都能被日志回放，这套评测体系就算立住了。
1. 为什么评测结果总在“微妙波动”：非确定性输出的真实来源做模型评测的人，大概都经历过这种状况：今天跑同一份测试集，综合分数比昨天高了0.3分，你以为是Prompt改动起了效果，复盘时发现昨天的分支根本没动模型，只是重新跑了两次推理。最后真相大白，问题不在模型版本，而在输出本身——同样输入、同样参数，模型每次吐出来的内容就是不完全一样。这不是偶发故障，而是生成式模型的固有属性。理解这件事之前，得先把“非确定性”的来源拆开看。1.1 采样参数：temperature、top_p 与随机数种子自回归语言模型在生成下一个Token时，本质上是输出一个概率分布，再从这个分布里“抽签”决定实际Token。只要你没有把采样参数设置成完全贪心（greedy decoding），温度、top_p、top_k这些参数就会引入随机性。temperature控制概率分布的锐化程度，温度越高，低概率Token被抽中的机会越大；top_p是核采样，只从累计概率达到阈值的Token里抽；即便你都固定下来，随机数种子变了，抽样路径也会变。我见过不少团队以为“temperature=0就绝对确定”，实际并非如此。部分推理后端在temperature=0时会走贪心路径，但遇到并行计算、浮点累加顺序变化时，仍可能产生微小差异。这里有个容易被忽略的点：并行Token采样和beam search在极端情况下也有非确定性，因为CUDA算子层面存在非原子操作的重排可能。1.2 推理后端、硬件与浮点累加：被忽略的隐性噪声文本层面的随机性大家还有感知，硬件层面的差异就很少有人排查了。同一个float运算在GPU上的累加顺序不同，结果就可能差一个尾数，这个尾数在连续几层网络中被放大后，就可能影响最终采样概率的排序——尤其在logits差距很小的情况下。另一个隐性来源是并发请求。评测时通常用多线程或异步方式同时打多个推理请求，请求到达后端的批次不同，模型内部执行的矩阵运算顺序也不同。有些推理服务还会动态合并请求，把batch size从1变成8，这本身就会改变浮点累加路径，输出自然跟着变。这些非确定性对“分数线上涨0.1还是下跌0.1”的影响是实实在在的。如果你的评测流程里没有一层东西来处理这个问题，你做的所有对比实验都可能建立在一堆随机噪声之上。1.3 用户视角的问题：评测分数没变，答案是变了有一种更隐蔽的情况比分数波动更难受：分数看起来完全一致，但抽看具体回答，同一个问题前后两次跑的答案措辞完全不同，甚至结论角度都换了方向。指标没暴露差异，因为你的评分器只对最终答案做了关键字匹配，或者只看格式对不对。可一旦下游任务需要“把答案再喂给下一个Agent”，或者需要把多条生成结果合并成一份报告，这种逐条差异就会被放大成流程层面的不一致。于是归一化就不再是“加分项”，而是评测工程里必须做的一道工序。这也是Harness层需要承担这项工作的原因——它不是模型推理的一部分，却是评测链路里承上启下的关键位置。2. Harness层该做什么：归一化放在这里的边界逻辑很多人听到“Harness层”会觉得陌生，其实它在评测框架里的定位很朴素：负责把一条测试请求从“原始输入”变成“可评分的标准化输出”。模型本身只管生成内容，测试集只管提供问题和标准答案，中间那层组织逻辑就是Harness。2.1 Harness层的职责边界我理解Harness层至少要做四件事：接收测试用例，渲染Prompt模板，把可变参数灌进去；调用模型推理接口，按设定好的并发数、重试策略去取输出；拿到原始输出后，做清理、提取、格式化，产出一个稳定结构；把稳定结构交给评分器，由评分器与标准答案比对。大多数评测框架的Harness层已经覆盖了前两项，第三项常常被省略，或者被挪到了评分器里“临时凑合”。但归一化后处理恰恰应该稳定落在Harness层，因为它要同时满足“可见原始输出”和“不关心具体评分逻辑”两个条件。2.2 为什么不放在评分器或模型层先说为什么不适合放在更下层。模型层是推理服务，它干的是生成活，你总不能指望每个推理服务都内置一套“评测输出规范化模块”。不同模型的输出风格差异极大，把归一化逻辑下沉到模型层，意味着每次换模型都要重新实现一遍，而且会污染推理服务的职责边界。再说为什么不适合放评分器。评分器应该只做一件事：判断“最终答案”和“标准答案”是否一致，或者打分。如果让它顺带承担“从原始输出里提取答案”的工作，一旦提取规则变化，所有历史评分都会失去可对比性。更麻烦的是，同一个测试集可能会有多个评分维度，比如一个查正确性，一个查格式规范，你把归一化放在评分器里，两个评分器就要各写一遍清洗逻辑，迟早出现规则漂移。Harness层是离模型输出最近、又能统一收口的位置。在这一层完成归一化后，所有下游评分器拿到的都是同一份“干净数据”，评分器之间不会因为清洗方式不一致产生分歧。2.3 不同任务类型的归一化粒度Harness层做归一化，粒度必须跟着任务类型走，不能一套规则打天下。抽取式问答：只需要提取答案文本，做大小写和标点归一；数学计算题：需要统一数字格式，比如“0.5”和“.5”要归一成同一种写法；结构化输出任务：要求模型返回JSON或表格，则需要做字段对齐、键排序、值类型校验；开放式写作：几乎不能归一化，顶多做末尾换行清理，过多处理反而伤内容。这意味着Harness层的归一化模块必须有“策略模式”，按Task Type注册不同的处理链，而不是写一个全局正则处理函数一把梭。我见过太多项目前期图省事，全局统一清理，后来遇到结构化输出任务时发现JSON被清得支离破碎，只能推倒重来。3. 完整后处理管线拆解：从原始文本到稳定答案归一化不是简单replace几个字符，它是一条有先后顺序的管线。顺序错了，效果会打折扣，甚至把有效信息处理坏。我通常在Harness层维护一个后处理链，每一环都做成可插拔函数。这里给出我实际使用的一套管线顺序，给想做归一化的读者一个参考。3.1 输出提取：剥离过程文本，定位最终结果第一步是从模型的原始输出里找出“真正要评分的那段内容”。大模型在回答问题时经常带多余信息，比如先分析一段，再给结论；或者把思考过程也吐出来；又或者干脆用“根据以上分析，答案是XXX”这种句式。评分器如果直接对着整段输出做匹配，很容易被过程文本干扰。Harness层的提取策略通常是这几种：正则定位“最终答案”“答案是”“Therefore”等标记，截取标记后的内容；结构化输出任务里，用花括号或方括号边界做提取，拿到完整JSON块；思维链任务里，按约定好的分隔符（比如“最终输出:”）截取后半部分。这一步的原则是“宁可多截一点，不要少截”。因为后续还有格式清理环节，多出来的尾巴可以被正则修掉；截短了，正确答案可能直接被切掉，评分器想救都救不回来。3.2 格式层规范化：代码块、引号、空白与Unicode提取出目标片段后，进入格式清理。这块最琐碎，却也最见功力，我列一下实际项目里最常用的一组规则：去除Markdown标记，比如```、**、##，但要在“提取答案代码”类任务里保留代码块内容，这个需要做策略判断；统一引号，把英文双引号、中文引号全转成一种形式；归一化空白字符，多个连续空格变一个，全角空格变半角，行尾空格删除；Unicode归一化（NFKC），把全角字母数字、特殊符号转成标准形式。不要小看引号和空白的处理。很多评测标准答案是人工标注的，标注人顺手打了个中文引号，模型输出的是英文引号，精确匹配直接判错，可实际上语义完全一样。这类问题在中文评测集里出现频率非常高。格式层还需要处理一个特殊场景：换行符。有些模型会用\n来表示换行，有些会输出真实换行。如果你的归一化规则把“\n”作为字面量替换掉，而真实输出里的换行符又没有同步处理，就会导致提取出来的答案中间夹着大量断行，评分器的字符串匹配直接崩掉。正确做法是先统一成真实换行，再做最后的空白清理。3.3 结构数据归一化：JSON排序与schema对齐近期很多评测任务要求模型输出JSON格式。相比纯文本，JSON的归一化更复杂，因为键值顺序、缩进、字段缺失都会影响下游解析。我的做法是三层处理：提取JSON块：从输出文本里用边界匹配找到最外层花括号；解析与类型强转：把字符串里的“True/False/null”转成JSON标准值，数字从字符串转成数字类型；键排序与字段补齐：用sort_keys=True输出稳定结构，并对照schema给缺失字段补默认值。这里有个关键点：排序要在序列化阶段做，不是排序字符串。如果拿原始字符串做字符排序，JSON直接改坏。正确流程是用解析库（比如Python的json模块）解析成dict，再设置sort_keys=True重新序列化。还有一个小技巧，如果任务允许，schema约束比后处理归一化更省事。在Prompt里写清楚“必须返回JSON key为以下顺序”，模型输出结构通常会更稳定。但你不能指望所有模型都严格遵守指令，所以Harness层还是要保留schema对齐能力，做双重保险。3.4 语义级兜底：同义改写与数字格式统一格式归一化解决不了语义层面的等价问题，所以管线里还要加一层语义兜底。这一层不用做得太深，但要把最常碰到的几个坑填平。数字格式是最典型的例子：0.5和.5要统一；10000和10,000要分清是千分位还是小数点；1e3和1000要看任务约定；中文“百分之五十”和“50%”在需要时归一到同一种表达。这几条直接用正则就能处理，但要注意作用域，别把普通句子里的人名、专有名词误伤。此外，同义改写是可选层。比如“北京市”和“北京”是否等价，“中华人民共和国”和“中国”是否算同一答案，这些要按评测集的标准答案约定来配置。我的建议是Harness层不要主动做语义级强替换，容易把正确答案改成错误答案。更稳妥的做法是把它做成一个“候选答案别名表”，由测试集维护，Harness层只做匹配时展开。所以这层的核心原则是：能做格式归一的不要做语义归一，能做别名表的不要做模型改写。4. 结果聚合与缓存：让非确定性进一步“收敛”无论归一化多强，它处理的只是“已生成输出”的格式与结构，改变不了模型每次生成的随机性。要让最终的评测指标更稳定，Harness层还需要在归一化之后再补两道工序：多次运行的结果聚合，以及输出缓存。4.1 多次运行的确定性聚合策略多数评测框架允许同一测试用例重复运行多次，再把分数合并成一条指标。问题在于怎么合并最合理。最大值策略（Max）：偏乐观，适合代码生成、SQL编写这类“只要一次成功就算成功”的任务；多数投票（Majority Vote）：主体上是让多个采样结果投票，选出现次数最多的答案，适合闭卷问答、选择题场景；中位数或均值：对需要看边缘分布的任务更稳，但要求答案本身可量化。我实际项目里最常用的是“答案级多数投票 + 分数级均值”的组合。先在Harness层对几十次采样的输出做归一化，然后按归一化后的文本做等价归类，拿出现频率最高的答案作为这条测试用例的“代表输出”，再把代表输出交给评分器。这样能有效压制单次采样的随机波动，同时又不掩盖模型本身的真实能力差异。这里有个坑：别把多数投票放在评分之后、分数之前。如果先对每次采样分别打分，再对分数求平均，模型输出里偶尔出现的“正确但不规范”答案会被直接判错，然后被投掉，最后分数偏低。先归一化、再投票、再评分，流程顺序错了结果差别很大。4.2 输出缓存与幂等校验Harness层做归一化还有个额外好处：天然适合做输出缓存。缓存的粒度是“请求键 + 归一化规则版本”。请求键通常包括：模型名称和版本；采样参数（temperature、top_p、max_tokens）；Prompt哈希；归一化规则版本号。只要这些都没变，同样的输入就不必反复请求模型，直接复用上一次归一化后的输出。评测回归时，这一手能省掉大量推理费用和时间，尤其在测试集规模上万条的时候，缓存命中率往往能到六成以上。缓存有一个容易忽略的注意事项：缓存键里一定要带上采样参数。我见过有人只缓存了Prompt哈希，没带temperature，结果同一道题在不同温度参数下复用了同一条输出，评测结果失真，排查了很久才发现是缓存逻辑把“该有的随机性”给吞掉了。4.3 回归测试中的误差边界归一化做完之后，评测分数不会完全零波动，但应该收敛在一个合理区间里。我一般会在评测跑完后额外输出一个“波动率指标”，也就是同一用例在多次运行下分数的标准差或变异系数。如果波动仍然很大，首先要检查的是Harness层归一化规则有没有真的覆盖到这个任务类型，而不是直接怀疑模型。比较实用的做法是设一个阈值，比如变异系数超过0.05就要告警，并在评测报告里高亮标注“当前指标受非确定性影响较大”。这样模型优化的同学就能意识到，某个改动导致的分数上涨0.2可能还在噪声区间里，不能当成有效结论。没有这个边界控制，评测结果很容易被误读成模型能力变化。5. 踩坑清单：归一化过程中最容易翻车的细节最后整理一下我在Harness层做归一化时踩过的一些实际坑，每一个都是花了不少排查时间才搞明白的，提前写出来帮读者少走弯路。5.1 规则叠加顺序：先提取，再格式化，不要反过来我最早做归一化时，为了追求“一次性全部处理干净”，写了一个大正则同时做提取、去标记、替换引号。结果出现了很离谱的情况：模型输出被转义成字面意义的“\n\n”，我的正则先替换了引号，把转义符结构打乱，后面的信息提取直接失效。矫正后的铁律是：严格按“提取主体 -> 结构定位 -> 格式清理 -> 语义统一”的顺序执行。提取是最先的步骤，尽可能在原始输出最“原生态”时做；格式清理放在提取之后，才不会把主体内容裁坏。一旦顺序颠倒，后面所有步骤都可能被前面一步的副作用带偏。5.2 场景误伤：需要原样输出的任务被“修坏”归一化规则不管多完善，都可能有副作用。最典型的是代码生成任务：你辛辛苦苦清理Markdown标记，结果把模型输出里的缩进空格给吞了；你统一了全角符号，结果把代码字符串里的中文引号也替换成了英文引号，程序直接编译不过。这就是为什么我在前面强调“策略模式”而不是全局清理。每个任务类型的归一化链要独立注册，代码生成任务就跳过标点归一化，只做代码块提取和尾部空白清理；数学题任务只做数字格式统一，不做同义替换。宁可让某些任务少归一化，也不要让规则跨场景误伤。实战经验：每加一条归一化规则，一定要跑一遍现有全部任务类型的样本集，抽查那些“不需要被这条规则处理”的任务有没有被动过。这条规则我称之为“反向回归验证”，它的价值比正向用例回归还高。5.3 怎么判断归一化是否生效：方差量化与样本审查很多团队做了归一化，但说不清它到底有没有用，因为缺少量化判断方案。我建议从两个维度看。第一个维度是指标方差。选一批波动明显的评测用例，在不改动模型的前提下，分别跑“无归一化”和“有归一化”两条流程，对比分数的变异系数。如果归一化后指标方差明显下降，说明处理有效性；如果方差几乎没变，说明规则没打中要害，需要审查用例样本的实际输出差异。第二个维度是“等价样本抽查”。每次跑完评测后，随机抽几十条“被归一化规则修改过输出”的样本，打印出原始输出和归一化后输出，人工对着看。这一步能很快发现误伤问题。我见过最典型的一个问题是：归一化规则把模型输出的核心结论句末尾的句号去掉了，而标准答案恰好以句号结尾，导致大批用例判错。这种问题不做样本抽查看不出来，只看方差指标完全无感。5.4 缓存命中率的维护：规则版本号是命根子前面提到缓存要靠“归一化规则版本号”作为请求键的一部分，这里单独强调一下：版本号一定要跟代码里的规则配置强绑定，不能靠人肉更新。我踩过的坑是规则改了一版，但配置中心里忘了同步版本号，导致Harness层继续用旧版本的缓存结果，新规则完全没有生效，测评报告数据集体失真。最稳妥的做法是把规则配置本身计算哈希值，用这个哈希当作版本号。规则只要有变动，版本号自动变化，缓存自动失效，不需要任何人工记忆。最后说点实在的我在实际项目中体会最深的一点是：归一化不是“锦上添花”，而是评测链路里最容易产生“隐性收益”的部分。它不会提升模型本身的能力，但它能把真实能力从噪声里剥离出来，让每一条指标变化都可解释。如果你发现评测分数在多个分支间摇摆不定，又找不出模型差异，先不要急着调模型，回头看看Harness层有没有做完整的后处理。把非确定性输出归一化这一步补齐，很多莫名其妙的“波动”会立刻安静下来。尤其是当你的评测结果需要被用来发布横向对比报告、或者做版本发布依据时，这一层的价值会体现得更明显。最后再分享一个小建议：别把归一化规则设计得太“聪明”，尽量用可读、可审查的白名单式规则，比复杂的智能转换更容易长期维护。你只需要盯着香草色的“初始输出”和“最终评分输入”两头，中间每一步都能被日志回放，这套评测体系就算立住了。