金融大模型评测与选型：从榜单分数到上线决策

金融圈这两年在选模型这件事上踩的坑，我见得比想象中多。很多人拿到一份开源大语言模型的榜单，看到某个 7B 或 32B 模型在综合评测里排得很靠前，就直接拉去做财报问答、合同审阅、客服话术生成，跑了两周发现输出里小数点错位、把"环比"当"同比"、被问到不确定的费率时张口就来。问题多半不在模型本身，而在于评测环节从一开始就问错了问题。这篇内容聊的就是怎么把"AI 在金融领域的能力"这件事真正测出来：怎么定义维度、怎么造题、怎么判分、怎么做横向比较、怎么把榜单分数翻译成上线决策。适合正在做模型选型的技术负责人、做金融场景落地的算法同学，以及需要向业务方解释"为什么这个模型不能用"的产品同学。哪怕你只跑过一次简单的准确率评测，下面这些拆解也能帮你把结论的可靠性往上提一个档。

1. 通用榜单在金融场景失灵的三个具体原因

先说一个反直觉的结论： 在通用榜单上分差 3 个百分点的两个开源模型，放到金融任务上，分差可能变成 30 个百分点，而且方向可能反过来。 这不是夸张，是任务结构差异导致的必然结果。通用榜单衡量的是"广泛知识与常识推理的覆盖广度"，而金融场景需要的是"在特定文档结构下的精确操作能力"。两者重叠的部分比大多数人以为的少得多。

1.1 知识记忆和操作执行是两种完全不同的能力

模型能准确解释"什么是久期""贴现现金流的基本假设是什么"，靠的是训练语料里的高频覆盖；而让它从一张二十行的债券持仓明细里算出加权平均久期，靠的是多步数值追踪、单位换算、公式选择这一整套执行链条。通用榜单里绝大多数题目是前者——四选一、判断题、简短问答，答对只需要一次知识检索。金融实务里绝大多数任务是后者。我见过一个模型在金融常识选择题上拿到 85 分以上，但让它从一份对账单里抽取六项费用并加总，十次里有四次把某项年化费率直接当成当期金额加上去。这种错误在榜单上完全看不出来，因为榜单根本不测这类操作。

这个落差有个很实用的判断方法：把任务按"需要几步内部状态维护"来分类。零步（直接回忆答案）、一步（单一公式代入）、多步（需要中间结果传递）、长链（需要跨段落引用并保持一致性）。通用榜单基本集中在零步和一步，金融场景的痛点集中在多步和长链。你选型时如果只看了前者，等于只验了发动机怠速，没上过路。

1.2 训练语料污染让分数失去了区分度

选择题形式的金融知识题在公开语料里流传太广，几乎可以肯定进入了主流开源模型的预训练数据。后果是头部模型在这个维度上分数挤成一团，70 分和 78 分之间可能只反映"见过原题的次数"，而不是能力差异。更麻烦的是这种污染很难自查——你在本地跑出高分，会误以为是模型强，其实是模型背过。

判断有没有污染，有个成本很低的办法：把题目里的数字、主体名称、时间全部替换成同构的假值，语义结构完全保留。如果替换后正确率断崖式下跌（比如从 78 掉到 52），说明模型靠的是对原题的记忆模式匹配；如果基本持平（78 掉到 74），说明它真的掌握了推理路径。这个对照实验我建议每个维度都做一遍，成本不过多跑一轮，但能帮你排除掉大部分虚假高分。

1.3 金融问答里"半对"往往等于"全错"

这条是判分设计的核心约束。你问"这个产品的年化综合费率是多少"，模型答"2.35%"，标准答案是"2.53%"——从文本相似度看差一个数量级的字符，从业务看是两个完全不同的结论，直接导致定价错误。同理，一段风险揭示话术里少了一句"历史业绩不代表未来表现"，整段在合规审核时就是不可用的，但在 BLEU 或者语义相似度打分下可能还有 0.8 分。

所以金融评测的判分逻辑必须偏严： 数值题用容差判分而非相似度，字段抽取用精确匹配或严格 F1，生成类题目用"必含要素 + 禁含表述"的清单式打分。 这套逻辑会让整体分数看起来比通用榜单低不少，但它是可用的。我自己搭评测集时有个习惯，先写判分规则再写题目，如果一道题我想不出严格的判分方式，那这道题就不进题集——因为它的分数不可解释。

2. 把"金融能力"切成可测的六块：维度定义与配比

直接问"这个模型金融能力怎么样"是没法回答的，就像问"这个人数学好不好"——要看他做的是算术、证明还是建模。评测的第一步是把笼统的"金融能力"拆成互相独立、各自可判分的维度，然后给每个维度定权重。权重不能平均分，也不能按"难度"分，要按 业务频次 分。

2.1 六个维度的定义与各自的判分方式

下面这套切分是我目前用下来覆盖面比较完整、又不会互相重叠太多的方案。每一项都对应明确的任务形态和判分机制，避免出现"这道题算知识还是算推理"的扯皮。

维度	典型任务形态	判分方式	建议权重
概念与术语理解	名词解释、是非判断、概念辨析	精确匹配 + 要点清单	10%
结构化字段抽取	从报表、合同、流水中提取指定字段	字段级 F1（严格匹配）	25%
多步数值计算	比率、增长率、折现、加权平均、费用加总	容差判分（相对误差 ≤ 0.5%）	25%
文档比对与差异识别	两版合同条款差异、两期报表科目变动	差异项集合的召回与误报	15%
合规表述生成	风险揭示、产品说明、免责声明	必含要素清单 + 禁含表述	15%
边界识别与拒答	信息不足、超范围请求、诱导性提问	拒答准确率 + 编造率	10%

抽取和计算两项加起来占了 50%，理由很直接：这是实际业务里调用量最大的两类任务，也是错误代价最高的两类。合规生成占 15% 是因为它的失败模式不是"答错"而是"答得不完整"，属于另一类风险。概念理解只给 10%，是因为它最容易被污染、区分度最差，也是最少被真正依赖的能力——没有哪个业务流程会单独调用模型解释一个术语。

2.2 权重为什么不按难度分配

有人会说计算题最难，应该给 40%。这个思路在学术评测里成立，在工程选型里不成立。你选模型是为了跑业务，业务分布决定权重分布。如果你们的场景是信贷材料审核，那抽取和比对就该占到 60% 以上，计算反而次要；如果做的是投研辅助，数值计算和长文档比对才是核心。所以这张权重表应该按你们自己的调用日志重新算一遍——统计一下历史调用里各类任务的实际占比，直接拿占比当权重，比拍脑袋靠谱得多。

调整权重的时候有个细节要注意：维度之间不能有严重的能力相关性，否则加权等于重复计分。比如"概念理解"和"合规生成"在某些模型上高度相关（都靠语料覆盖），如果两个都给高权重，等于把语料覆盖度测了两遍。可以先跑一次维度间的相关性矩阵，相关系数超过 0.8 的两个维度考虑合并或者降权。

2.3 主观题的评分标尺必须细到可执行

生成类题目最容易变成"看感觉打分"。解决办法是写 rubric，而且要写到另一个没参与出题的人能照着打分。以一段产品说明生成为例，标尺可以拆成四层：

• 必含要素 ：风险等级、适用人群、费用构成、不确定性提示，缺一项扣 25%
• 数值一致性 ：文中出现的所有比例、金额必须与给定材料完全一致，出现一处不一致直接判 0
• 禁含表述 ：不得出现收益承诺、不得出现"保本""稳赚""无风险"类表述、不得给出具体买卖建议
• 结构完整性 ：需要有明确的免责段落，且不与正文混排

这四层里，第二层和第三层是硬门槛，触犯即零分；第一层和第四层是分级打分。这种"硬门槛 + 分级"的混合结构比单一总分更贴近业务判断——业务方看到的总分没意义，他们关心的是"有没有踩红线"。

3. 题集从哪来：自建、改造与防泄漏的实操做法

公开的金融评测集可以用，但只能当基线，不能当选型依据。原因前面说过：污染严重、任务形态偏知识题、评分粒度和你的业务不匹配。真正能拿来做决策的题集，必须自己建。

3.1 从脱敏业务文档反推题目，而不是凭空出题

最有效的建集方式是从真实文档结构出发。拿一批脱敏后的年报片段、产品说明书、对账单、合同文本，先人工标注出若干个"锚点"——就是那些必须准确读出来才能做后续计算的数字和条款。然后围绕锚点出题，保证每道题的答案都能追溯到文档里的具体位置。

这个做法有个明显好处： 可验证性。 模型答错时，你能立刻定位是没找到锚点、找到了但读错、读对了但算错，还是算对了但表述错。这四种失败模式的修复方向完全不同，而如果用公开题集，你只能看到"错了"，没法往下拆。

具体操作上，我一般按这个流程走：先选 15 到 20 份结构差异较大的文档（不同行业、不同报表格式、不同条款风格），每份手工出 10 到 15 道题，形成 200 题左右的种子集。这批题全部人工核对答案，作为"金标准"。然后用模板化改写把种子集扩到 600 到 1000 题，扩展出来的题目抽 10% 回检。种子集永远不进自动扩增流程，避免错误在扩增中被放大。

3.2 扰动改写的六种手法，各自测的是不同能力

单纯换数字只能测"会不会算"，测不出鲁棒性。我常用的扰动有以下几类，每一类对应一个明确的考察点：

扰动类型	具体做法	考察点	预期影响
数值替换	换掉锚点数字，保持结构	是否真在计算而非匹配模板	正确率应基本持平
单位变换	万元改元、年化改月度	单位识别与换算	正确率会明显下降
表格重排	调换列顺序、插入干扰列	表头对齐能力	中等下降
语义反转	同比改环比、含税改不含税	细粒度语义区分	大幅下降
噪声注入	插入无关段落、页眉页脚	抗干扰能力	小幅下降
信息缺失	删掉关键字段，看是否拒答	边界识别	应触发拒答

这里的判断标准很关键： 数值替换后分数应该基本不变，语义反转后分数应该明显下降。 如果数值替换就让分数崩了，说明模型在背题；如果语义反转后分数纹丝不动，说明它根本没读到那个词，可能在靠上下文猜测。两种异常都值得单独排查。

3.3 防泄漏的几条硬规则

题集一旦泄漏到公开渠道，基本就废了。几条我一直在用的规则：

题集不进任何公开代码仓库，哪怕是私有仓库也要单独加密存放；题目的哈希值可以做登记，但题干和答案不落公开文档。

每季度轮换 20% 的题目，优先替换掉那些所有被测模型都答对的题——这些题已经没有区分度，留着只占篇幅。

更有效的一招是用"未来题"：拿评测时点之后才发布的文档出题。模型的训练截止时间早于文档发布时间，客观上不可能见过。这类题目的分数最能反映真实的泛化能力。缺点是出题有滞后性，需要提前布局——我通常会在每个季度初就把当季新发的文档存一份，等到下个季度出题时正好可用。

4. 判分环节才是真正的误差来源

大部分人把精力全花在出题上，判分环节随手写个字符串匹配就完事。实际上， 在你已经把题出好的前提下，评测结果的可信度上限由判分器决定。 我见过不止一次，同一批模型、同一批题，换一套判分规则，排名直接对调。

4.1 三类判分器的分工不能混

判分器要按题目类型分工，混用会出大问题：

• 规则判分 ：适用于所有有唯一答案的题——数值、字段、是非判断。优点是零方差、完全可复现，缺点是对格式敏感，需要做好归一化。
• 模型判分 ：适用于开放式生成——合规话术、分析结论、说明文字。优点是能处理语义等价，缺点是有系统性偏差，必须校准。
• 人工抽检 ：适用于所有类型的抽样复核，比例建议 10%，重点抽两类：模型判分和规则判分结论不一致的题、以及所有被判为零分的题。

关键在于规则判分和模型判分的边界要划死。数值题绝不能用模型判分——模型裁判很容易被"看起来对"的答案骗过去，尤其是当错误答案的推理过程很长很详细的时候。反过来，合规话术题也不该用关键词匹配，因为同一个意思有太多种表达方式，硬匹配会大量误判。

4.2 数值题判分的七个细节陷阱

数值判分看起来简单，实际上坑非常多。下面这些是我在实操中一条条踩出来的：

1. 单位归一 ：答案里可能写"12.5 万元"也可能写"125000"，判分前必须先做单位解析和统一换算。
2. 百分比与小数 ：0.125 和 12.5% 是同一个值，但字符串完全不同。判分器要能把两者归一。
3. 千分位分隔符 ："1,234,567" 和 "1234567" 必须等价。
4. 负数表示 ：括号表示负数（会计惯例）、前置负号、后缀"负"，三种写法都要覆盖。
5. 精度容差 ：建议用相对误差而非绝对误差，阈值 0.5%。绝对误差在数值量级差异大的题目上会失效——100 块的题允许误差 1 块和 100 万的题允许误差 1 块，严格程度天差地别。
6. 四舍五入边界 ：模型算出 2.3449 报 2.34，标准答案 2.35，相对误差 0.4% 在容差内，算对。但如果容差设成 0.1%，就会被误判。容差阈值的设定要和题目的有效数字位数匹配。
7. 多值答案 ：有些题要求同时给出几个数，判分要区分"全对""部分对""全错"，不能简单用"是否包含"来判断。

这七条里，第五条和第六条最容易出错。我的经验是： 容差阈值应该由出题人逐题标注，而不是全局统一。 一道只需要保留两位小数的费用题，容差就该是 0.01 的绝对量级；一道涉及多年折现的估值题，容差可以放宽到 1%。全局统一阈值必然在某些题上过松、某些题上过严。

4.3 模型裁判的四种偏差和校准方法

用模型给模型打分，听起来省事，实际上引入了一堆系统性偏差。常见的四种：

• 位置偏差 ：两个答案对比时，裁判倾向给排在前面的打高分。解决方法是交换顺序各评一次，取平均。
• 长度偏好 ：更长的答案普遍得分更高，哪怕内容更啰嗦。解决方法是在提示词里明确"长度不影响评分"，并在校准集上验证这个偏差是否被压住。
• 同族偏好 ：裁判对自己的同系列模型打分偏高。解决方法是裁判模型必须与被测模型不同族，且版本固定。
• 宽松漂移 ：不加约束时，裁判倾向于给中等偏上的分数，导致分布集中在 3 到 4 分之间，区分度消失。解决方法是在提示词里给出明确的分数锚点示例，每个档位配一个典型样本。

校准的具体做法：准备 150 到 200 条人工已标注的样本，让裁判跑一遍，算它和人工的一致性。如果用 Cohen's kappa，低于 0.6 就别用了，说明它和人的判断逻辑差太远；0.6 到 0.75 可以用但要抽检加密；0.75 以上才算基本可信。这个校准集要长期保留，每次换裁判模型或改提示词都要重跑一遍。

有个容易忽略的点：裁判模型的版本必须锁死。同一个模型的不同版本，判分倾向可能差异很大，而且这种差异不会体现在模型名称上。建议记录完整的版本标识和调用参数，方便复现。

5. 横向对比怎么做才站得住：统计、成本与结果解读

题出好了、判分器校准了，接下来是横向比较。这一步最容易出现的问题是： 把几个百分点的差异当成能力差异。 实际上在几百题的规模下，大部分差异都在噪声范围内。

5.1 样本量和置信区间的关系，先算清楚再比

准确率是一个比例估计，天然带置信区间。样本量 300 题、准确率 70% 时，95% 置信区间的半宽大约是 5 个百分点。也就是说，71% 和 74% 这两个数字，在 300 题的规模下 没有任何统计意义上的区别 。如果只凭这 3 个百分点就选了模型，等于在掷骰子。

样本量	观测准确率 70% 时的 95% 区间半宽	能区分的最小差距
100	约 ±9 个百分点	18 个百分点以上
300	约 ±5 个百分点	10 个百分点以上
800	约 ±3 个百分点	6 个百分点以上
2000	约 ±2 个百分点	4 个百分点以上

做这张表的目的是让选型讨论有个共同基准。当有人说"这个模型比那个高 4 分"，你可以直接问"你的题集多大"。如果答案是 200 题，那这个 4 分基本可以忽略。真要区分小差距，要么把题集做到 1500 题以上，要么改用配对比较。

5.2 配对比较比独立比较灵敏得多

同一批题跑多个模型，属于配对设计，可以用更灵敏的方法。核心思路是只看"两个模型答案不同的那些题"，然后检验分歧的方向是否有系统性。比如 300 道题里，两个模型答案一致的有 240 道，剩下的 60 道里 A 对 B 错 42 道、A 错 B 对 18 道——这个差距就比总分差 8 个百分点更有说服力，因为它排除了题目难度差异的干扰。

配对方法还有个附带好处：能直接告诉你 模型的能力是互补还是重叠。 如果两个模型的分歧题目大量集中在同一个维度上，说明它们在该维度上有系统性差异，可以考虑按维度分工；如果分歧随机散布在各维度，说明它们能力相近，选便宜的那个就行。

5.3 成本-性能的二维视角，比单看分数有用十倍

只按得分排序是最粗糙的选型方式。实际决策中，成本约束往往比分数更重要。我一般会做一张二维表，横轴是单位千次调用的成本，纵轴是加权得分，然后把所有候选模型点上去，找帕累托前沿——也就是那些"没有其他模型在同等成本下得分更高、也没有其他模型在同等得分下成本更低"的模型。

一个典型的分布是这样的：7B 级别的模型成本极低但得分在 60 分左右；30B 级别成本是前者的 4 到 6 倍，得分在 75 分左右；70B 级别成本再翻几倍，得分 82 分左右。这条曲线在 70 分附近有一个明显的拐点。如果你们的业务对准确率的要求是"80 分以上才可上线"，那 7B 和 30B 都不用考虑；但如果要求是"70 分以上，配合人工复核"，30B 级别往往是性价比最优的选择，把剩下的预算花在人工审核上，整体效果比直接上最大模型更好。

5.4 结果表要分段读，别只扫总分

一张好的评测结果表应该按维度分列，而不是只给一个加权总分。读的时候重点关注三个模式：

• 抽取高、计算低的模型 ：说明它能读懂文档但执行链条不稳。这类模型适合做信息提取类的前置处理，不适合直接用在一锤定音的计算任务上。
• 计算高、合规低的模型 ：能算但不会说话，风险在于生成内容踩线。这类模型可以放在内部工具链里，不直接对客。
• 整体中等但拒答维度极好的模型 ：这类模型在客服、咨询类场景里价值很高，因为它的失败模式是"我不知道，请转人工"，而不是"编一个看起来合理的答案"。

我见过不少团队在选型时把拒答率当成"能力不足"的标志，实际上在金融场景里恰恰相反。一个敢说"根据提供的材料无法确定"的模型，比一个凡事都能给出答案的模型安全得多。

6. 从榜单分数到上线决策：部署侧还必须测什么

评测分数是在理想条件下测出来的：FP16 精度、单条请求、充分上下文、无并发。真实部署环境跟这四条全都不一样。这一节讲的是那些"上了线才发现"的差距。

6.1 量化带来的掉分，不同任务敏感度差异极大

为了省显存，几乎所有人都会上量化。INT8 通常掉分很少，INT4 就要看任务了。关键在于： 不同维度对量化的敏感度完全不同。

根据我自己的测试经验，概念理解类任务在 INT4 下的掉分通常很小（1 到 3 个百分点），因为这类任务对数值精度不敏感；字段抽取类掉分中等（3 到 6 个百分点）；但多步数值计算类任务的掉分可能是最大的，有些模型在 INT4 下会从 70 分掉到 55 分以下。原因是量化误差会在多步计算中累积放大，而且模型对数字的敏感度下降后，容易出现"把 3.24 读成 3.42"这类错误。

所以量化之后必须重跑一遍评测，而且重点看计算维度的掉分。如果计算维度掉超过 8 个百分点，宁可上更大的显存或者换更小的模型，也别硬用量化版本。

6.2 长上下文和表格输入的真实表现，跟宣称的数字差很远

几乎所有模型都宣称支持 32K 甚至更长的上下文，但"支持"和"能用"是两件事。金融场景经常要把十几页的报表一次性喂进去，然后问其中某个字段。这时候会出现典型的 中间位置衰减 ：放在开头的字段召回率高，放在结尾的次之，放在中间的明显下降。

测这个不需要复杂的工具，自己造一个测试就好：取一份 20 页的文档，把同一个关键数字分别放在第 2 页、第 10 页、第 18 页，各问一次，重复 20 组。如果第 10 页的召回率显著低于第 2 页，说明模型存在位置衰减，那么在实际使用中就要配合分块检索，而不是无脑全量塞入。

表格输入的坑更隐蔽。很多模型对 Markdown 表格处理得不错，但对带合并单元格、多级表头、缩进层级的表格就会出错——它会把父级表头丢掉，导致"营业收入"和"营业成本"两个子项被当成同一层。如果你要处理这类表格，建议先做结构扁平化，把合并单元格展开成完整表头的二维表，再喂给模型。这一步预处理能挽回不少准确率。

6.3 吞吐、延迟和单位成本，必须自己摊算

榜单不会告诉你单位成本，这个必须自己算。公式很简单：

单次调用成本 = 输入tokens × 输入单价 + 输出tokens × 输出单价
单题成本 = 平均调用次数 × 单次调用成本

难点在于"平均调用次数"这一项——实际业务里往往不是一问一答，而是带重试、带检索增强、带多轮澄清的流程。一个需要平均 2.3 次调用才能得到可用结果的模型，即使单次成本低，整体成本也可能比一次就过的模型更高。

除了成本，还要测两个延迟指标：首 token 延迟和总生成时长。金融场景里的交互式查询对首 token 延迟很敏感，超过 2 秒用户就开始怀疑卡住了；而批处理任务更关心总吞吐。这两个指标在并发下的表现差异很大——单条测试都很快，一旦并发上到 20，小模型可能更稳，大模型可能直接排队。

测试项	测试方法	关注阈值
单条首 token 延迟	串行请求 50 次取 P95	交互场景建议 < 2s
并发吞吐	并发 20 持续 5 分钟，统计 tokens/s	看是否线性下降
单位成本	按真实调用链统计平均 tokens	与预算对比
长上下文耗时	32K 输入下的首 token 延迟	注意随长度非线性增长

最后一项特别容易忽略。上下文从 4K 涨到 32K，首 token 延迟可能翻三到五倍，这个增长不是线性的。如果业务里有大量长文档处理，这个延迟会成为瓶颈。

7. 我在几次评测里踩过的坑与排查链路

前面讲的是方法论，这一节讲具体翻车现场。这些坑的共同特点是：出问题时分数看起来正常，只有往下挖才能发现整个评测结论是错的。

7.1 题面提示词泄底，把推理题变成了填空题

有一批数值计算题，题面里为了"友好"写了"请逐步计算"这样的引导语。结果所有模型在这批题上的得分都异常地高，一度让我以为选型有了结论。后来做提示词对照实验才发现，问题出在这句引导语上——它把原本需要模型自己规划的计算路径直接点明了，而且某些题型里"逐步计算"的顺序本身就在暗示公式。

排查方法很简单：同一批题准备两个版本的题面，一个带引导语，一个纯客观陈述，各跑一遍。如果带引导语的版本分数明显更高（我遇到的情况是高了 11 个百分点），说明题面在帮模型，这批题的分数不能代表真实能力。修复方式是全部改成中性题面，或者在报告里明确标注"此分数为引导条件下的上限值"。

7.2 判分器把"我不知道"判成了正确答案

这个问题出现在边界识别维度上。有一类题的标准答案是"根据提供材料无法确定"，本意是考察模型会不会拒答。但判分器当时用的是关键词匹配，只要答案里出现"无法确定""信息不足"就判对。结果模型给出的答案是"根据材料无法确定具体费率，但通常行业平均水平在 2% 到 3% 之间"——前半句正确拒答，后半句直接编造了一个数字。判分器只看到了前半句，判对。

修复方式是改成分步判分：先判断是否拒答，再判断拒答的理由是否成立，最后检查拒答之后有没有追加无依据的补充。第三步是关键，因为在实际业务里，这种"先拒答再补充"的模式是最危险的——用户会记住后面那个编造的数字，而忘记前面那句"无法确定"。

这类问题的通用排查思路是： 把所有被判为正确的答案，人工抽读 50 条。 如果发现有"部分正确但整体不可用"的情况，说明判分器的粒度太粗，需要拆成多步。

7.3 生成参数没对齐，导致结果不可复现

这个坑最冤枉。两个模型对比时，一个用了默认的 temperature 0.7，另一个在测试脚本里被设成了 0。结果第一轮跑完，低温度那个在数值题上明显占优；换了个脚本重跑，结论反过来了。

数值类任务对采样参数极其敏感。temperature 0.7 意味着同一个问题问十次可能得到三四种不同的计算路径，其中任何一步算错就全错；而 greedy 解码至少保证路径稳定。我现在的做法是： 所有评测统一用 greedy 解码（temperature 设为 0 或极小的值），固定随机种子，记录完整的调用参数，并且把参数写进结果文件名。 生成类任务如果想测稳定性，单独做一轮多采样测试，报告里分开展示，不要和确定性任务的分数混在一起。

还有一点：模型版本必须锁死。同一个模型在不同时间调用，backend 可能已经更新了，同名不同版的情况非常常见。我的做法是在评测脚本里记录完整的版本标识字符串，并且在报告里附上抓取日期。

7.4 疑似污染的验证：同义改写和数字替换的组合拳

当你怀疑某个模型的高分来自记忆，可以用组合验证。准备三组题：原题、只改数字的同构题、完全同义改写但结构不同的题。三组的正确率关系能说明很多问题：

• 原题高、改数字后暴跌： 强污染信号 ，模型在匹配题目模式。
• 原题高、改数字略降、改写后大降：说明模型对表述形式敏感，泛化能力弱。
• 三组基本持平：说明模型确实掌握了方法，分数可信。
• 三组都不高：说明这个维度就是它的弱项，分数如实反映。

我遇到过最极端的情况是一个模型在原题上 88 分，改数字后掉到 41 分。这个落差基本可以断定它记住了一批题目的答案模式——因为如果真会算，换个数字不该有这么大影响。这批题的分数后来被我从报告里剔除了，改用重新生成的题目。

顺带说一句，验证污染这件事要定期做，不能只做一次。模型在持续更新，新版本可能在更大的语料上训练，污染情况会变。我一般每换一次被测模型版本，就重跑一次污染验证，成本不高，但能避免拿着错误的分数做决策。

7.5 一个容易被忽略的细节：测试集顺序的影响

最后说个听起来很玄但确实存在的影响——题目顺序。有些模型在处理连续同类型题目时，会出现"上下文惯性"，前面几道题都是同类计算，后面即使换了类型，它也会沿用前面的格式和思路。这在批量评测里会造成同一道题在不同位置得到不同结果。

验证方法：把同一批题打乱顺序跑三遍，看单题结果的波动率。如果某道题在三次里结果不一致，说明它对上下文位置敏感。处理方式有两个：一是每道题独立请求、清空上下文（成本高但最干净），二是接受这个波动，在报告里给出多次运行的平均值和波动范围。我倾向于后者，因为真实使用中用户也不会每次都在空白上下文里提问。

写到这里，基本上把一个完整评测流程里能踩的坑过了一遍。最后分享一个我自己一直在用的判断标准： 如果一份评测报告不能告诉你"模型在什么情况下会失败"，那它的价值就只剩排序。 排序在选型初期有点用，但真正决定能不能上线的，永远是那些失败案例的具体形态——是算错、是编造、是漏读，还是拒答不当。把这些失败案例整理成一份清单，比任何一个总分都更能说服业务方，也更能指导后续的提示词优化和流程设计。