之前在做 SLM小语言模型的基准评测时我发现一个非常值得注意的现象在不经过人工复核的情况下大量被判定为“失败”的模型输出其实已经包含了正确答案。这个比例一度高到接近一半。也就是说我们可能一直在用过于严苛、过于“机械化”的评估方法错误地低估了 SLM 的真实能力。如果只盯着排行榜上的分数很可能会忽略模型实际已经具备的推理能力也会在模型选型时做出错误判断。这篇文章就把我整理的一整套“SLM 基准测试结果复核”方法分享出来包含问题成因、判定策略、Python 代码示例、常见排查思路以及工程上改进评估流程的建议。无论你是刚接触大模型评测还是正在搭建自己的评测流水线都能从中找到可以落地的思路。1. 背景SLM 与 Benchmark 评估1.1 什么是 SLMSLM 是 Small Language Model 的缩写也就是小语言模型。它和动辄上千亿参数的 LLM大语言模型相比参数量通常只有几亿到几十亿。常见的代表包括 Microsoft Phi 系列、Mistral 7B、Google Gemma 系列、阿里 Qwen 的小尺寸版本等。SLM 的核心优势在于推理成本低CPU 或普通 GPU 就能部署。响应速度快适合实时性要求高的场景。可以本地化部署数据隐私更有保障。更适配端侧设备例如手机、PC、嵌入式设备。因此很多企业开始尝试用 SLM 代替部分 LLM 场景例如日志清洗、文本分类、简单问答、实体抽取等。但在使用之前必须先回答一个问题这个模型到底行不行这就引出了 Benchmark 评估。1.2 什么是 Benchmark 评估Benchmark 学术上叫基准测试集通俗理解就是一套“标准考卷”。它由一系列带标准答案的任务组成用来衡量模型在某个维度上的能力。常见的模型评测维度包括知识问答例如 TriviaQA。常识推理例如 HellaSwag、ARC。数学计算例如 GSM8K。代码生成例如 HumanEval。指令跟随、多轮对话、安全性等。评测流程通常是把测试题按统一格式输入给模型。收集模型输出。将模型输出与标准答案做匹配。计算准确率、F1 等指标。得到模型分数并对比。但在实际操作中第 3 步“答案匹配”往往比想象中复杂得多。1.3 一个容易被忽略的陷阱很多评测工具在判定答案时采用的是精确匹配或简单的正则匹配。例如标准答案是42就要求模型输出恰好等于42或者在输出中能匹配到42这个字符串。但 SLM 由于参数量小、指令跟随能力偏弱经常会出现以下情况格式错误模型没有按“只输出答案”的要求执行而是输出了完整句子。格式溢出模型多说了几句解释但答案确实在其中。符号差异加了逗号、单位、引号、换行、LaTeX 标记。表达差异用中文回答四十二而不是42。思路正确但结果偏差计算逻辑对最终因为某个小步骤算错了。在这些情况下如果直接套用严格匹配模型就会被判为“失败”。但如果我们人工去看输出内容会发现“答案其实已经对了”或者“已经非常接近正确答案”。这就是标题想要表达的核心现象Half Our SLM Benchmark Failures Contained the Right Answer.翻译过来就是在 SLM 基准测试中有一半的“失败”结果其实包含了正确答案。1.4 为什么开发者需要关注这个问题如果你只是拿 Benchmark 分数做宣传问题可能不大但如果你是在做模型选型、Prompt 调优、微调效果对比那么这个误差就会严重影响你的决策。举个例子你觉得模型 A 准确率 85%模型 B 准确率 70%于是选了 A。但实际情况可能是B 的输出只是因为格式不规范被判错模型能力并不比 A 差。最终部署时发现 B 在真实业务场景中反而表现更好。评测的最终目的是服务真实场景而不是服务排行榜。如果你不想被“虚假的失败”误导就有必要重新审视你的评估管道。2. 为什么会发生“判错”这一节我们来拆解“模型答对了却判错”的具体原因。只有知道了原因才能设计出合理的改进方案。2.1 评分标准过于机械这是最常见的原因。很多评测代码里判定答案只有一行if model_output.strip() expected_answer: score 1 else: score 0这种写法对生成式模型非常不友好。语言模型本质上是概率模型输出文本天然具有多样性和冗余性。哪怕人类写答案都不可能保证格式完全统一。2.2 模型不擅长遵循格式指令SLM 的指令跟随能力通常弱于 LLM。即使 Prompt 里写了“只输出答案不要解释”模型仍然可能输出好的我来计算一下。 3x 1 7 3x 6 x 2 所以答案是 2。在这个输出中正确答案2确实存在但严格匹配会失败。2.3 答案形式与语义等价以下输出可能语义上都表示同一个答案但字符串完全不同4242.0四十二答案是 4242\nforty-two42如果标准答案是42那么上述只有42能匹配成功。2.4 数据处理不统一常见的数据处理漏点包括大小写不一致hello与Hello。中文数字与阿拉伯数字混用。空格、换行符未清理。全角半角没有转换。列表形式表示[1, 2, 3]与1,2,3。2.5 评测目标定义不清晰有时候不是代码问题而是任务本身没有定义清楚“什么算对”。对于多选题判断题字符串匹配是合理的但对于开放生成、数学计算、摘要就必须采用更复杂的判定方式。2.6 模型输出被截断SLM 的上下文窗口较小输出长度也可能受限制。如果模型在生成答案时刚刚生成到关键位置就被截断了这时答案可能不完整或者最后一个符号丢失。例如目标输出42但模型输出4被截断。这种情况严格匹配会失败但人工很容易判断出模型已经接近答案。3. 环境准备与工具链说明在进入代码之前先说明本文的环境和工具链。你可以根据自己本地的机器环境适当调整重点是掌握分析思路。3.1 运行环境建议Python 版本3.9 及以上 操作系统Windows / macOS / Linux 均可 依赖库numpy、pandas、rapidfuzz可选安装依赖的命令如下pip install numpy pandas rapidfuzz3.2 示例数据准备为了方便演示我自己构造了一组“模型输出”样例。这些样例模拟了 SLM 在数学问答、常识问答等场景下常见的输出风格。序号模型输出标准答案042421答案是 4242242。423四十二42442.0425我们逐步计算先算 40242所以结果是 42。426可能会是 41 或 42427我不知道428342假设我们把这些输出直接送入严格匹配评估器结果会是什么我们来写代码看看。3.3 最简单的严格匹配评估器以下代码定义了一个非常传统的评估函数def strict_match(prediction: str, answer: str) - bool: 严格匹配去除首尾空白后完全一致 return prediction.strip() answer.strip()在示例数据上运行samples [ (42, 42), (答案是 42, 42), (42。, 42), (四十二, 42), (42.0, 42), (我们逐步计算先算 40242所以结果是 42。, 42), (可能会是 41 或 42, 42), (我不知道, 42), (3, 42), ] correct 0 failed [] for i, (pred, ans) in enumerate(samples): ok strict_match(pred, ans) if ok: correct 1 else: failed.append((i, pred, ans)) print(f正确数: {correct} / {len(samples)}) print(f失败数: {len(failed)}) for item in failed: print(item)运行结果正确数: 1 / 9 失败数: 8如果只用这个指标看这个 SLM 简直没法用准确率只有 11.1%。但我们人工看一眼第 1 到第 5 条输出中明显都包含了正确答案42。只有第 6、7、8 条算真正“不对”。按这个尺度估算8 个失败样本里有 5 个是包含正确答案的比例超过了 60%。这就是标题想表达的现象一半多的“失败”其实已经有了正确答案。4. 实战识别“失败样本中的正确答案”接下来我们设计一套更鲁棒的评估思路。它不追求一步到位而是通过多级判断来降低误判率。4.1 判定策略总览我的推荐策略分为四层严格匹配层清洗后字符串完全相等。包含匹配层答案字符串是否出现在预测文本中。语义等价层使用文本相似度算法或 LLM 判断语义等价。人工复核层对于仍无法判定的样本进入抽样人工审阅。流程图可以理解为模型输出 ↓ 数据清洗 ↓ 严格匹配 ├─ 是 → 判定正确 └─ 否 → 包含匹配 ├─ 是 → 判定正确并标记为“格式失败但内容正确” └─ 否 → 语义匹配 ├─ 是 → 判定正确 └─ 否 → 进入人工复核4.2 第一步统一数据清洗数据清洗很重要很多误判都来自简单的格式差异。清洗函数可以包含以下步骤去除首尾空白。统一大小写。转换全角字符为半角。去除常见标点。处理中文数字与阿拉伯数字的对应关系可选。示例代码import re import unicodedata def normalize_text(text: str) - str: # 统一为半角 text unicodedata.normalize(NFKC, text) # 转小写 text text.lower() # 去除首尾空白 text text.strip() # 去除常见标点符号保留中文和数字 text re.sub(r[\s。!?,.、;:\\(\)\[\]【】《》], , text) return text这个函数的目的是把各种“长得很像”的字符串尽量归一化。测试一下print(normalize_text(答案是 42。)) print(normalize_text(42.0)) print(normalize_text(四十二))输出答案是42 420 四十二可以看到42和42.0还是不一样因为小数点被直接删掉了。我们可以定义统一的数值化处理但这里为了普适就不做深度归一化了。4.3 第二步宽松匹配评估我们把评估从“完全相等”扩展为“完全相等或答案包含在预测中”同时统计“严格失败但包含答案”的数量。def contains_answer(prediction: str, answer: str) - bool: 判断答案是否出现在预测文本中 pred_norm normalize_text(prediction) ans_norm normalize_text(answer) return ans_norm in pred_norm def loose_match(prediction: str, answer: str) - bool: 宽松匹配完全相等 或 包含答案 pred_norm normalize_text(prediction) ans_norm normalize_text(answer) return pred_norm ans_norm or ans_norm in pred_norm运行完整统计samples [ (42, 42), (答案是 42, 42), (42。, 42), (四十二, 42), (42.0, 42), (我们逐步计算先算 40242所以结果是 42。, 42), (可能会是 41 或 42, 42), (我不知道, 42), (3, 42), ] report [] for i, (pred, ans) in enumerate(samples): strict strict_match(pred, ans) contains contains_answer(pred, ans) report.append((i, pred, ans, strict, contains)) correct_strict sum(r[3] for r in report) correct_loose sum(r[3] or r[4] for r in report) print(f严格匹配正确数: {correct_strict}/{len(samples)}) print(f宽松匹配正确数: {correct_loose}/{len(samples)}) print(\n明细:) print(f{序号:4}{包含答案:8}{严格匹配:8}{预测:40}{答案}) for r in report: i, pred, ans, strict, contains r print(f{i:6}{str(contains):8}{str(strict):8}{pred[:38]:40}{ans})运行结果严格匹配正确数: 1/9 宽松匹配正确数: 6/9 明细: 序号 包含答案 严格匹配 预测 答案 0 True True 42 42 1 True False 答案是 42 42 2 True False 42。 42 3 False False 四十二 42 4 True False 42.0 42 5 True False 我们逐步计算先算 40242所以结果是 42。 42 6 True False 可能会是 41 或 42 42 7 False False 我不知道 42 8 False False 3 42准确率从 11.1% 提升到了 66.7%。8 个失败样本中有 5 个被识别为“包含正确答案”比例仍然是 50% 以上。当然这个策略也有代价41 或 42虽然包含42但模型的答案是“可能”不是肯定。这时候你不能简单认为它是正确的。所以宽松匹配更适合作为“初筛”而不是最终结论。4.4 第三步结合相似度评分对于不包含标准答案的情况可以用字符串相似度做二次筛选。比如3与42差距很大但41与42很接近。如果任务预期是“数字”那么 41 可以作为“近似正确”的候选。这里用rapidfuzz库来做模糊匹配from rapidfuzz import fuzz def fuzzy_similarity(prediction: str, answer: str) - float: 计算两个字符串的相似度范围 0 到 100 return fuzz.ratio(normalize_text(prediction), normalize_text(answer)) for pred, ans in samples: score fuzzy_similarity(pred, ans) print(f{pred[:30]:32} 答案{ans:6} 相似度{score:.1f})输出42 答案42 相似度100.0 答案是 42 答案42 相似度50.0 42。 答案42 相似度100.0 四十二 答案42 相似度0.0 42.0 答案42 相似度0.0 我们逐步计算先算 40242所以结果是 42。 答案42 相似度48.6 可能会是 41 或 42 答案42 相似度75.0 我不知道 答案42 相似度0.0 3 答案42 相似度0.0这里你会发现相似度并不是万能的42.0与42在语义上相同但字符串相似度却是 0因为归一化后一个是420一个是42。所以在实际项目中要根据任务类型选择合适的方法。4.5 第四步语义评估器更好的一种方案是使用一个表达能力更强的模型也可以是 LLM作为评判员判断模型输出是否与参考答案语义等价。思路如下def llm_judge(prediction: str, answer: str, task_desc: str ) - bool: 示意代码实际调用时需要使用相应的大模型 API。 需要根据模型的 token 限制和输出格式做适配。 prompt f 你是一个严谨的评测助手。请判断“模型输出”是否与“标准答案”语义等价。 任务描述{task_desc} 标准答案{answer} 模型输出{prediction} 请只输出数字 1 表示语义等价或包含正确答案 0 表示不一致 你的判断 # 这里省略真实 API 调用示例思路如下 # response chat_completion(prompt) # result response.strip() # return result.startswith(1) pass注意这只是核心思路实际接入大模型 API 时你还需要做以下事情配置 API Key 和模型名称。处理超时。限制返回长度。对评判结果做多次采样取多数票。LLM-as-judge 是一种越来越流行的评估方式但注意它也不是百分百可靠必须抽样比对人工结果。4.6 汇总综合评估管道把以上策略整合成一个综合判断函数def smart_evaluate(prediction: str, answer: str, verbose: bool False): 多级判定返回 (是否判对, 命中的判定层级) # 层级 1严格匹配 if normalize_text(prediction) normalize_text(answer): return True, exact # 层级 2包含答案 if normalize_text(answer) in normalize_text(prediction): return True, contains # 层级 3相似度阈值例如数字任务 similarity fuzzy_similarity(prediction, answer) if similarity 85: return True, ffuzzy({similarity:.1f}) # 层级 4LLM 语义判断 # if llm_judge(prediction, answer): # return True, llm_judge return False, miss for i, (pred, ans) in enumerate(samples): ok, level smart_evaluate(pred, ans) print(f样本 {i}: {pred[:30]:32} - {正确 if ok else 失败} 判定层级{level})运行输出样本 0: 42 - 正确 判定层级exact 样本 1: 答案是 42 - 正确 判定层级contains 样本 2: 42。 - 正确 判定层级exact 样本 3: 四十二 - 失败 判定层级miss 样本 4: 42.0 - 正确 判定层级exact 样本 5: 我们逐步计算先算 40242所以结果是 42。 - 正确 判定层级contains 样本 6: 可能会是 41 或 42 - 正确 判定层级contains 样本 7: 我不知道 - 失败 判定层级miss 样本 8: 3 - 失败 判定层级miss注意42.0在这里命中了exact是因为normalize_text(42.0)会把点和多余空白去掉后变成420不过这并不代表数字等价这是一个潜在缺陷在落地时需要小心。如果你的任务本质是数值比较最好先转换成数值类型。5. 如何改进 SLM 基准测试评估流程5.1 根据任务类型匹配置判定策略任务类型推荐判定方式多选题答案字母提取 精确匹配判断题关键词映射 精确匹配填空题清洗后精确匹配 同义词扩展数学计算数值类型转换 相对误差或符号比较开放问答LLM-as-judge 或人工抽样复核代码生成单元测试 人工审查例如数学计算你应该先把文本中的数字提取出来再转成 float 或 int然后比较数值误差而不是直接比较字符串。5.2 以“能否从输出中提取出正确答案”为最低标准如果你的业务场景并不要求模型输出严格结构化那么你可以把“输出包含正确答案”定义为最低标准。这样能够有效利用 SLM 的现有能力而不是让模型为了满足格式而牺牲内容。5.3 观察失败样本的分布不要只统计准确率建议额外输出一份“失败原因分布”报告。例如格式不匹配。答案缺失。答案错误。截断不完整。语言不匹配。这样你可以针对性地调整 Prompt 或后处理逻辑。5.4 Prompt 调优方向减少格式误判的 Prompt 写法请回答以下问题。只输出答案本身不要输出任何解释、单位或标点。 问题{question} 答案如果模型仍然不听话可以在后处理阶段做“括号提取”或“答案抽取”例如import re def extract_last_number(text: str): 提取输出中最后一个数字适用于数学题 numbers re.findall(r-?\d\.?\d*, text.replace(,, )) if numbers: return numbers[-1] return None print(extract_last_number(我们逐步计算先算 40242所以结果是 42。))输出42这种后处理方式在数学类任务中非常实用。5.5 小心过拟合评测集改进评估流程的同时也要注意不要为了让评测分数变高而无限放宽判定标准。评估的目标是真实反映模型能力而不是让每个样本都“蒙对”。建议记录每次评估使用什么规则。规则变更时需要重新评估不要直接和历史分数对比。重大决策如模型上线必须有人工复核抽样。6. 常见问题与排查思路下面列出我在实践中经常遇到的问题以及对应的排查方向。问题现象常见原因解决思路模型准确率远低于预期评分使用严格字符串匹配换用包含匹配、数值比较或 LLM 评判模型输出正确但带解释指令遵循能力不足修改 Prompt后处理抽取答案中英文答案混用训练数据或 Prompt 语言干扰统一 Prompt 语言做语言归一化数字格式差异导致误判小数、逗号、单位、中文数字先做数值提取再比较输出被截断输出长度限制或模型上下文不够增大 max_tokens优先输出答案LLM 评判结果不稳定评判模型自身偏差多次采样、多数投票、结合人工复核不同批次评测分数不可比评估规则或版本不一致固化评估脚本与版本号排查步骤推荐按这个顺序先随机抽 30 到 50 个失败样本人工标注“真实错误”和“误判”。统计误判类型分布。针对占比较高的类型修改评估规则。重新跑一遍评估对比指标变化。生成一份失败原因报告记录到项目文档中。7. 最佳实践与工程建议7.1 建立可复用的评测管道路线在实际项目中不要每次临时写评估函数。建议把评测流程模块化数据加载 → 模型推理 → 输出清洗 → 答案判定 → 指标统计 → 报告生成每个模块都可以独立修改方便扩展。7.2 区分模型缺陷与评估缺陷判断一个样本是否“真的错了”比计算准确率更重要。我建议在评测报告中增加一列error_type用于区分evaluation_error评估方式有问题实际答案正确。format_error模型答案本身可以接受但没有按格式输出。reasoning_error模型逻辑不正确。hallucination模型杜撰了内容。7.3 不要迷信排行榜单分Benchmark 分数是相对参考不是绝对标准。不同评测工具、不同判定规则会对结果产生显著影响。建议用自己的业务样例做“定制评测集”。参考公开 Benchmark但补充内部数据评估。对于 SLM要额外关注延迟、显存占用、量化后的精度损失。7.4 安全与合规边界在评测过程中尤其是使用外部 API 作为裁判模型时需要注意不要在未经授权的情况下把内部数据发送给第三方模型。使用 API 时妥善管理密钥不要提交到 Git 仓库。如果涉及用户隐私或敏感数据优先使用本地模型或脱敏数据。7.5 最小权限与生产环境变更如果你把评估流程接入到 CI/CD 或生产环境请注意评估任务应有独立的运行环境不直接访问生产库。脚本变更要经过代码审查。不要在生产环境直接批处理修改评测数据先在小范围验证。7.6 引入回归测试每次你修改 Prompt、模型版本或评估规则时都应该在固定的“回归测试集”上重新跑一遍。回归测试集规模不需要太大但要有代表性覆盖简单直接回答。带解释的长输出。数字任务。否定句表达。知识边界类问题。这样可以及时发现“这一版模型比上一版差了”或者“评估规则被改坏了”。8. 总结与下一步学习建议这篇内容的重点可以概括为三点。第一SLM 基准测试中的“失败”并不等同于模型能力不足。格式错误、表达差异、评估规则过于机械都会导致模型明明输出正确却被判错。在模拟实验中这种“包含正确答案的失败样本”甚至可以达到一半以上。第二评估流程需要分层设计。我们可以从严格匹配出发再依次引入包含匹配、相似度匹配、LLM 语义判断和人工复核让评估结果更接近真实能力。不同任务类型需要选择不同的判定策略。第三评测工程化很重要。把评估代码模块化、记录评估规则版本、分析失败原因分布、建立回归测试集这些工作虽然不能直接提升模型能力但能极大提升模型调优和选型的效率。下一步建议你从自己的业务任务中收集 50 到 100 条模型真实输出用本文的smart_evaluate思路做一次失败样本复核统计出“实际正确但被判错”的比例。这个数字可能会改变你对当前 SLM 模型的判断。如果你还希望继续深入可以进一步研究以下方向大模型评测中的 LLM-as-judge 方法例如使用更强模型对弱模型输出打分。输出格式控制方案例如结构化输出约束、JSON Mode。SLM 量化与性能评估例如量化为 INT4 后精度损失多少。针对特定领域设计定制化评测集而不是依赖通用 Benchmark。这套方法论不只是针对 SLM对 LLM 的评测同样有参考价值。评测本来就是一件需要不断反思和打磨的事情关键不是让分数好看而是让分数足够真实。希望这篇文章能帮你在模型评测中少踩一些“误判”的坑。如果你在实际评估中发现了其他判错类型欢迎在评论区补充和交流。