企业官网建设流程全解析

最近在给一批模型做真实场景评估时，我发现一个很矛盾的现象：同一个数学题，题干原封不动时模型能答对，只是把“多少平方厘米”改成“面积是几平方厘米”，回答质量就明显下滑；再把 temperature 从 0.2 调到 0.8，连续问 5 次，竟然能出现 3 种不同的答案。去翻主流评测榜单，这些模型又都表现良好，仿佛完全不存在这种脆弱性。

如果你也遇到过类似情况，那我们要讨论的问题就很明确了：不是模型“不会”，而是我们对模型鲁棒性的评估方式存在盲区。很多模型在常见 benchmark 上高分通过，但换一种说法、换一组解码参数，推理能力就露馅。这种“评测看起来很强、实际用起来很不稳”的错位，可以称之为 LLM 鲁棒性幻觉——模型的鲁棒性并没有榜单分数展示的那么好，只是常规评测没有把压力场景覆盖到。

这篇文章会围绕 LLM 鲁棒性、解码策略和压力测试展开，先从概念上解释为什么普通评测会失真，再给出一套可以自己跑起来的“解码级压力测试”方案，包含可复制的 Python 代码、评测指标设计、常见踩坑和最佳实践。无论你是做模型选型、Prompt 调优，还是给业务接入大模型，都可以用这套思路提前发现模型的真实短板。

1. 背景：为什么常规大模型评测会掩盖鲁棒性问题

1.1 LLM 鲁棒性到底指什么

LLM 鲁棒性是一个范围很广的概念，简单理解就是：当输入发生变化、环境出现干扰时，模型是否仍然能给出稳定且正确的结果。它通常包含几个层面：

• 输入扰动鲁棒性：同义改写、词序调整、标点变化、错别字、多语言混用等，不应导致结论发生剧烈变化。
• 解码参数鲁棒性：temperature、top_p 等生成参数变化后，模型答案应当保持基本一致，尤其是客观题和推理题。
• 指令格式鲁棒性：用户把问题包装成“请解决以下问题”“你是数学助教”等不同指令格式时，模型要能识别真实任务。
• 上下文鲁棒性：前面加了无关对话、角色设定、少量干扰信息后，模型不应丢失原始问题。
• 对抗鲁棒性：面对刻意构造的诱导、攻击或边界输入时，模型不能被轻易带偏。

常规评测通常只给出一组固定的 prompt，跑一次或少数几次，然后计算准确率。这种方式能反映模型在“标准环境”下的上限，却无法回答一个非常实际的问题：用户不会每次都按标准模板提问，生产环境里同一个问题可能有几十种说法。

1.2 什么是“鲁棒性幻觉”

“鲁棒性幻觉”不是说模型真的产生了幻觉内容，而是指评价体系给人们制造了一种“这个模型很鲁棒”的虚假安全感。

一个典型的形成路径是：

1. 模型在主流 benchmark 上刷出高分；
2. 开发者据此认为模型“推理能力强”“很稳定”；
3. 实际接入业务后发现，用户换一种提问方式，模型就答错；
4. 回到测试集检查，又发现分数没变。

出现这种情况，往往不是有人在造假，而是 benchmark 本身存在局限。公开测试集的问题表述相对固定，模型可能在预训练和微调阶段见过相似样本；评测试只用贪婪解码或默认参数，采样随机性被忽略；评测指标只关心最终答案是否匹配，不关心中间推理是否靠谱；几乎没有评测会系统性地对同一道题做几十种语义等价改写。当这些局限叠加在一起，榜单分数和真实鲁棒性之间就会产生明显落差。

1.3 为什么强调“解码级”压力测试

大模型的推理结果不是一次性生成出来的，而是解码器根据概率分布逐 token 采样得到的。即使输入完全相同，只要解码策略不同，输出就可能不同。常规跑分通常只选一个温度参数，这相当于只拍了模型在理想状态下的一张照片，无法反映模型在真实采样空间中的稳定性。

解码级压力测试的思路是：在保持语义等价的条件下，主动改变输入表述和解码参数，再观察输出变化。它能回答几类关键问题：

• 同一个问题换 5 种问法，模型还能不能稳定答对？
• temperature 从低到高变化时，模型是“微调变通”还是“彻底跑偏”？
• 某些模型是否只是记住了例题的“模板”，一旦题干措辞偏离训练分布就失灵？
• 模型输出在多次采样中一致率有多高？

这些信息，比单一 benchmark 分数更能反映模型在真实产品中的可用性。

2. 核心概念与评测设计思路

2.1 鲁棒性、准确率与泛化性的区别

开始写代码之前，先把概念边界理清。

• 准确率（Accuracy）衡量模型在给定测试集上答对的占比，是结果性指标。
• 泛化性（Generalization）衡量模型面对训练时未见过的新样本、新分布时的表现。
• 鲁棒性（Robustness）更强调模型在输入扰动、环境变化、参数变化下维持性能的能力。

准确率高不代表鲁棒性好。一个模型可能在固定问题集上拿到 90 分，但这些问题只要换一种同义说法，分数就掉到 60 分，这种情况就是典型的“高准确率 + 低鲁棒性”。泛化性关注的是“没见过的东西能不能处理”，鲁棒性关注的是“见过的东西换个马甲还能不能认出来”。

2.2 解码参数如何影响推理稳定性

LLM 生成答案时，会对词表中的每个 token 计算一个概率，再根据解码策略决定选哪个 token。几个常见参数的影响如下：

temperature 控制概率分布的平滑程度。temperature 越低，高概率 token 被选中的可能性越大，输出越接近贪心解码；temperature 越高，低概率 token 也有机会被选中，输出更多样，但也更容易偏离正确答案。

top_p（核采样）控制候选 token 的累计概率范围。top_p=1.0 表示保留全部候选，top_p 越小，候选范围越窄。它和 temperature 同时使用时，会共同影响最终采样分布。

max_tokens 控制最大生成长度。对于推理题，如果长度限制太短，模型可能来不及输出完整推导过程；如果太长，部分模型在长文本生成后段可能出现重复或逻辑漂移。

repetition_penalty（重复惩罚）会降低已经出现过的 token 的概率。这个参数对生成长文本比较重要，但过高的惩罚值有时会破坏正常表达。

在“解码级压力测试”里，我们对这些参数做扫描，就是为了观察模型输出对解码配置的敏感度。一个足够稳定的模型，在 temperature 从 0 升到 1 的过程中，客观题答案虽然可能存在表述差异，但核心结论不应该反复横跳。

2.3 压力测试与常规评测的关系

常规评测回答“这个模型能得多少分”，压力测试回答“这个模型在多大范围内能保持住分数”。两者的关系不是互相替代，而是层级递进。

常规评测先划定标准能力基线，压力测试再对基线做压力对抗。更完整的评测流程应该是：

1. 设计一组有标准答案的评测样本；
2. 在标准场景下跑出基准确率；
3. 对样本施加语义保持扰动；
4. 对同一问题做多次采样和参数扫描；
5. 对比扰动前后、参数变化前后的结果差异；
6. 计算鲁棒性衰减度、一致性等指标；
7. 对失败样本做 case 分析。

3. 解码级压力测试要覆盖哪些维度

3.1 输入表达扰动

这是最基础的扰动方式，核心要求是“语义不变，表达改变”。举几个可以落地的方向：

• 同义改写：把“计算面积”改成“求解面积”“它的面积是几”；把“如果……那么……”改成“假设……由此可得……”。
• 细节调整：把“8厘米”写成“8 cm”，题目含义不变，但 token 分布变化很大。
• 添加冗余引导语：比如“这是一道小学数学题，请用小学方法求解”与“请用严谨推理作答”，对模型的答题策略会产生影响。
• 选项顺序变换：选择题中调换 ABCD 的顺序，正确答案在选项中的位置随之变化。

这些扰动不需要依赖外部大模型，用轻量规则脚本就可以完成。关键是扰动后必须人工确认标准答案没有被改变。

3.2 指令格式扰动

同一个问题，在真实使用中可能以不同形式出现。比如“直接回答”“计算一下”“请以‘答案是：’结尾”“你是数学助教，请见谅，但必须作答”等。对格式敏感并不是致命伤，但如果格式一变，模型就从答对变成答错，说明它并没有真正掌握题目背后的推理规律，只是靠着训练时见过的文本模式在“猜”。

3.3 解码参数扫描

解码参数扫描是“解码级”这个名称的核心来源。实际执行时，可以按如下列表组合：

• temperature：0.0、0.2、0.5、0.8、1.0
• top_p：0.8、0.9、1.0
• max_tokens：128、512
• 每组参数下重复采样 3 到 10 次

扫描会产生大量请求，需要控制成本。建议先用小样本集跑通流程，再逐步扩展。

3.4 思维链与推理过程压力测试

推理题的答案只是表象，推理过程更能说明问题。压力测试中可以要求模型“先输出思考过程，再给出答案”，也可以直接问“请逐步解释”。这样做有两个目的：

• 观察中间推理是否存在错误但答案偶然正确的“假阳性”；
• 观察模型在必须解释步骤时是否会暴露概念理解漏洞。

对于数学题，还可以故意在上下文中加入一个无关条件，比如“长方形的长是 8 厘米，宽是 5 厘米，操场上有 3 个小朋友在跑步，请问面积是多少？”如果模型把无关信息也算进去，说明它对关键信息筛选能力不足。

3.5 多次采样一致性测试

同一个问题在 temperature=0.7 下采样 10 次，统计答案分布。如果 10 次中出现了 3 种以上不同结论，说明模型在这个问题上的置信度分布很分散，这在需要稳定输出的业务场景中是高风险信号。

4. 从零搭建轻量级压力测试框架

下面进入实操环节。我会用 Python 搭建一个最小可用的 LLM 解码压力测试框架。这里的代码侧重演示评测思路，你可以直接复用，也可以按自己的模型 API 调整。

4.1 环境准备与项目结构

本文示例环境如下：

• 操作系统：Windows 10/11、macOS、Linux 均可
• Python：3.9 或更高版本
• 依赖库：openai>=1.0、pandas、numpy
• 模型接入：任意兼容 OpenAI Chat Completions 格式的服务，例如 vLLM、Ollama 的 OpenAI 兼容端点、各类云厂商模型服务

安装依赖：

pip install "openai>=1.0" pandas numpy

项目目录结构：

pressure_test/ ├── dataset.py # 评测样本与标准答案 ├── llm_client.py # 统一模型调用客户端 ├── perturb.py # 扰动生成器 ├── runner.py # 评测执行入口 ├── analysis.py # 结果汇总与指标计算 └── output/ # 运行结果目录

4.2 准备评测样本集

样例数据需要覆盖数学计算和逻辑推理两类客观题。每个样本都有唯一的标准答案，并提供若干手写问法变体。

# 文件路径：pressure_test/dataset.py # -*- coding: utf-8 -*- SAMPLE_QUESTIONS = [ { "id": "math_01", "type": "math", "question": "一个长方形的长是8厘米，宽是5厘米，它的面积是多少平方厘米？", "answer": "40", "variants": [ "一个长方形的长是8厘米，宽是5厘米，请计算它的面积，并给出数值。", "长方形的长为8cm，宽为5cm，问它的面积是几平方厘米？", "已知一个长方形的长是8厘米，宽是5厘米，求面积。", ], }, { "id": "math_02", "type": "math", "question": "商店里有12个苹果，卖出了5个，又进来了3个，现在商店里有多少个苹果？", "answer": "10", "variants": [ "商店原有12个苹果，卖出5个后再进货3个，问现在有几个苹果？", "12个苹果卖掉5个，又运来3个，剩余多少个？", ], }, { "id": "logic_01", "type": "logic", "question": "如果所有的 A 都是 B，且小明是 A，那么下列说法一定正确的是？", "answer_choice": "A", "choices": [ "小明是 B", "小明不是 B", "无法判断小明与 B 的关系", "小明可能是 A 也可能不是 A", ], "variants": [ "已知所有 A 都属于 B，小明属于 A，由此可以推出什么？", "假设每一个 A 都是 B，同时小明是 A，哪个结论必然成立？", ], }, { "id": "logic_02", "type": "logic", "question": "甲比乙高，乙比丙高，三人中谁最高？", "answer": "甲", "variants": [ "甲的个子比乙高，乙又比丙高，请问三个人里面最高的是谁？", "已知甲高于乙，乙高于丙，谁的身高最高？", ], }, ] def get_dataset(): return SAMPLE_QUESTIONS

这里强调一点：手写变体是保证“语义等价”最稳妥的方式。自动改写很容易引入歧义或意外改变题目约束。如果你有更多人力和预算，可以请人把评测集扩展到几百条；如果只是个人验证，十几条精选样本也能暴露趋势。

4.3 编写模型调用客户端

为了让脚本适配不同模型服务，采用 OpenAI SDK，通过 base_url 切换不同后端。

# 文件路径：pressure_test/llm_client.py # -*- coding: utf-8 -*- import os from openai import OpenAI class LLMClient: def __init__(self, model: str, base_url: str = None, api_key: str = None): self.model = model # 如果 api_key 为空，SDK 会读取环境变量 OPENAI_API_KEY self.client = OpenAI( base_url=base_url or "https://api.openai.com/v1", api_key=api_key or os.environ.get("OPENAI_API_KEY"), ) def chat( self, user_content: str, system_prompt: str = None, temperature: float = 0.2, top_p: float = 1.0, max_tokens: int = 512, seed: int = None, ) -> str: if system_prompt is None: system_prompt = ( "你是一个严谨的评测助手。回答问题时请先理解题意。" "如果题目是数学题，请在最后输出“答案：数值”；" "如果题目是选择题，请以“答案：字母”结尾。" "不要输出多余的空行和解释。" ) kwargs = { "model": self.model, "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_content}, ], "temperature": temperature, "top_p": top_p, "max_tokens": max_tokens, } # 部分兼容服务不支持 seed，这里做一次异常降级 if seed is not None: kwargs["seed"] = seed try: resp = self.client.chat.completions.create(**kwargs) return (resp.choices[0].message.content or "").strip() except Exception: # 如果带 seed 失败，去掉 seed 后重试 if "seed" in kwargs: kwargs.pop("seed") resp = self.client.chat.completions.create(**kwargs) return (resp.choices[0].message.content or "").strip() raise

注意：不同模型服务商对 seed 参数的支持程度不一样。有些服务即使传了 seed，也只能影响部分随机性，无法做到完全可复现。评测时应该把是否支持 seed 作为一个独立变量记录下来，而不是默认所有请求都支持完全复现。

4.4 实现扰动生成器

扰动生成按四个维度进行：问题变体、题干包装、选项乱序、无关干扰信息。

# 文件路径：pressure_test/perturb.py # -*- coding: utf-8 -*- import copy import random # 常见指令包装，用来模拟真实用户的不同表达习惯 STYLE_WRAPS = [ "{question}", # 原样 "请解决如下问题：\n{question}\n请只输出最终答案。", "题目：{question}\n要求：认真作答，并在最后用“答案：”标出你的结论。", "你现在是一名严谨的老师。请完成以下题目：\n{question}", "看看这道题：{question} 请给出你的答案。", ] def get_question_variants(item): """返回题目自身的多个语义等价问法""" variants = [item["question"]] for v in item.get("variants", []): variants.append(v) return variants def wrap_question(question: str, wrap_index: int) -> str: """用不同指令格式包装题目""" wrap_index = wrap_index % len(STYLE_WRAPS) return STYLE_WRAPS[wrap_index].format(question=question) def add_irrelevant_noise(question: str) -> str: """在题目前后加入无关信息，干扰模型对关键信息的提取""" noise_sentences = [ "顺便说一下，今天的天气不错。", "这只是日常练习的一部分，请不要紧张。", "请注意，做题前先仔细阅读题目。", ] noise = random.choice(noise_sentences) return f"{noise}\n{question}" def shuffle_choices(item, rng: random.Random): """打乱选择题选项顺序，并同步更新正确答案字母""" if not item.get("choices"): return item original_choices = item["choices"] original_answer = item["answer_choice"] original_idx = ord(original_answer) - ord("A") idx = list(range(len(original_choices))) rng.shuffle(idx) new_choices = [original_choices[i] for i in idx] new_answer_idx = idx.index(original_idx) new_answer = chr(ord("A") + new_answer_idx) new_item = copy.deepcopy(item) new_item["choices"] = new_choices new_item["answer_choice"] = new_answer return new_item def build_choice_text(choices): """把选项列表拼成用户可见文本""" return "\n".join([f"{chr(ord('A') + i)}. {c}" for i, c in enumerate(choices)])

4.5 评测执行入口

runner 需要完成四件事：

1. 标准场景：原题 + 默认参数。
2. 变体场景：同一题的不同问法。
3. 格式与噪声压力：加入指令包装或无关干扰句。
4. 采样一致性：高温下反复采样多次。

# 文件路径：pressure_test/runner.py # -*- coding: utf-8 -*- import argparse import csv import os import random from dataset import get_dataset from llm_client import LLMClient from perturb import ( build_choice_text, get_question_variants, wrap_question, add_irrelevant_noise, shuffle_choices, ) OUTPUT_DIR = "output" os.makedirs(OUTPUT_DIR, exist_ok=True) SYSTEM_PROMPT = ( "你是一个严谨的评测助手。回答问题时请先理解题意。" "如果题目是选择题，请输出“答案：X”（X为选项字母）；" "如果题目是数学题或判断题，请输出“答案：结论”。" "不要输出多余解释。" ) def parse_answer(text: str, q_type: str): """从模型输出中提取答案，简单规则解析""" if not text: return None, text # 优先找“答案：”后面的内容 for marker in ["答案：", "答案是", "结论：", "答案:"]: if marker in text: tail = text.split(marker, 1)[-1].strip() if q_type == "math": import re m = re.search(r"-?\d+(?:\.\d+)?", tail) return m.group(0) if m else None, text else: tail_clean = tail.replace("。", "").replace(" ", "") if tail_clean: return tail_clean[:20], text break # 没有“答案”标记时，直接按类型提取 if q_type == "math": import re nums = re.findall(r"-?\d+(?:\.\d+)?", text) if nums: return nums[-1], text # 选择题：找孤立字母 for ch in text: if ch.upper() in "ABCD": return ch.upper(), text return None, text def build_user_content(item, question=None): """根据样本生成用户消息""" question = question or item["question"] if item.get("choices"): content = question + "\n" + build_choice_text(item["choices"]) else: content = question return content def run_case(client: LLMClient, item, question, temperature, top_p, max_tokens, scenario, repeat_idx): user_content = build_user_content(item, question) raw = client.chat( user_content, system_prompt=SYSTEM_PROMPT, temperature=temperature, top_p=top_p, max_tokens=max_tokens, ) if item["type"] == "math": expected = str(item["answer"]) else: expected = item.get("answer_choice", item.get("answer", "")) predicted, _ = parse_answer(raw, item["type"]) if predicted is not None: if item["type"] == "math": accepted = predicted == expected else: accepted = predicted.upper() == str(expected).upper() else: accepted = False return { "sample_id": item["id"], "scenario": scenario, "repeat_idx": repeat_idx, "question": question, "expected": expected, "predicted": predicted, "raw_output": raw, "accepted": accepted, "temperature": temperature, "top_p": top_p, } def main(): parser = argparse.ArgumentParser() parser.add_argument("--model", required=True, help="模型名称") parser.add_argument("--base-url", default="https://api.openai.com/v1", help="OpenAI兼容服务地址") parser.add_argument("--api-key", default=None, help="API Key，默认读取环境变量") parser.add_argument("--repeat-times", type=int, default=5, help="高温采样次数") args = parser.parse_args() client = LLMClient(model=args.model, base_url=args.base_url, api_key=args.api_key) dataset = get_dataset() csv_path = os.path.join(OUTPUT_DIR, "eval_results.csv") rows = [] for item in dataset: # 1. 标准场景 rows.append(run_case( client, item, item["question"], temperature=0.2, top_p=1.0, max_tokens=256, scenario="base", repeat_idx=0, )) # 2. 同义问法变体 for i, variant in enumerate(get_question_variants(item)): if i == 0: continue rows.append(run_case( client, item, variant, temperature=0.2, top_p=1.0, max_tokens=256, scenario=f"variant_{i}", repeat_idx=0, )) # 3. 指令包装压力 for wrap_idx in [1, 2, 4]: wrapped_q = wrap_question(item["question"], wrap_idx) rows.append(run_case( client, item, wrapped_q, temperature=0.2, top_p=1.0, max_tokens=256, scenario=f"wrap_{wrap_idx}", repeat_idx=0, )) # 4. 无关干扰信息 rng = random.Random(42) noise_q = add_irrelevant_noise(item["question"]) rows.append(run_case( client, item, noise_q, temperature=0.2, top_p=1.0, max_tokens=256, scenario="noise", repeat_idx=0, )) # 5. 选择题选项乱序压力 if item.get("choices"): shuffled_item = shuffle_choices(item, rng) rows.append(run_case( client, shuffled_item, shuffled_item["question"], temperature=0.2, top_p=1.0, max_tokens=256, scenario="shuffle_choices", repeat_idx=0, )) # 6. 高温多次采样一致性 for rep in range(args.repeat_times): rows.append(run_case( client, item, item["question"], temperature=0.8, top_p=1.0, max_tokens=256, scenario="sampling_high_temp", repeat_idx=rep, )) with open(csv_path, "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=list(rows[0].keys())) writer.writeheader() writer.writerows(rows) print(f"评测完成，结果已写入：{csv_path}") print(f"共发起请求数：{len(rows)}") if __name__ == "__main__": main()

运行命令示例：

cd pressure_test # 如果你的服务地址是本地 vLLM / Ollama python runner.py \ --model your-model-name \ --base-url http://localhost:8000/v1 \ --repeat-times 5 # 如果使用环境变量中的 OPENAI_API_KEY python runner.py --model gpt-4o-mini --repeat-times 3

注意：脚本默认每次请求都会真实调用远程模型，会产生费用或消耗配额。第一次跑通建议把上面脚本复制一份，先只保留前两道题，或者给 dataset 函数临时加一个切片限制。

4.6 结果汇总与指标计算

分析脚本读取 CSV，然后计算四类指标：

• 标准场景准确率；
• 各扰动场景准确率；
• 鲁棒性衰减度；
• 高温采样一致率。

# 文件路径：pressure_test/analysis.py # -*- coding: utf-8 -*- import pandas as pd CSV_PATH = "output/eval_results.csv" def normalize_answer(x): if x is None: return None return str(x).strip().lower() def main(): df = pd.read_csv(CSV_PATH) # 标准场景 base_df = df[df["scenario"] == "base"] base_acc = base_df["accepted"].mean() if len(base_df) else 0 print(f"[标准场景] 样本数={len(base_df)} 准确率={base_acc:.2%}") # 扰动场景 print("\n[扰动场景]") perturb_scenarios = [ s for s in df["scenario"].unique() if s not in ("base", "sampling_high_temp") ] for s in sorted(perturb_scenarios): sub = df[df["scenario"] == s] acc = sub["accepted"].mean() drop = base_acc - acc print(f" {s:<20} 样本数={len(sub):<4} 准确率={acc:.2%} 相对基线衰减={drop:+.2%}") # 高温采样一致性 sample_df = df[df["scenario"] == "sampling_high_temp"] print("\n[高温采样一致性] temperature=0.8") if len(sample_df): for sample_id, group in sample_df.groupby("sample_id"): unique_answers = group["predicted"].apply(normalize_answer).nunique() agree_ratio = group["accepted"].mean() print( f" {sample_id:<12} 采样{len(group)}次 " f"不同答案数={unique_answers} 正确率={agree_ratio:.2%}" ) # 整体一致率：连续两次结果相同的概率近似用“与首次结果相同”的比例表示 def first_consistency(g): first = normalize_answer(g.iloc[0]["predicted"]) if first is None: return None return (g["predicted"].apply(normalize_answer) == first).mean() consistency_df = ( sample_df.groupby("sample_id") .apply(first_consistency, include_groups=False) .dropna() ) if len(consistency_df): print(f" 首次结果保持率（粗糙一致率）={consistency_df.mean():.2%}") if __name__ == "__main__": main()

python analysis.py

4.7 结果如何解读

假设你跑完一批数据，输出可能类似下面这样：

[标准场景] 样本数=4 准确率=100.00% [扰动场景] noise 样本数=4 准确率=75.00% 相对基线衰减=-25.00% sampling_high_temp 样本数=20 准确率=65.00% 相对基线衰减=-35.00% variant_1 样本数=4 准确率=100.00% 相对基线衰减=+0.00% variant_2 样本数=4 准确率=75.00% 相对基线衰减=-25.00% wrap_1 样本数=4 准确率=75.00% 相对基线衰减=-25.00%

如果某个模型标准题全对，但某一类扰动掉 25 个百分点以上，说明它的能力边界非常窄。这里尤其要关注的是：不是“某道题做错了”，而是“哪一类语义变化触发了错误”。把失败样本的原始输出打印出来逐条看，往往能发现模型只是在匹配关键词，而不是真的在推理。

上面示例数据只是演示格式，不要当作任何真实模型的结论。真实评测中你需要用足够大的样本量和多轮扰动才能得到稳定结论。

5. 评测指标设计的常见误区

5.1 只看最终答案是否正确

最典型的评测误区是：只比较模型输出和标准答案字符串是否一致，不管推理步骤。

一个模型可能“过程全错、答案碰巧正确”，尤其在多步数学题中。比如计算 12 + 5 × 3，模型先算成 17 × 3 = 51，答案错误；但如果题目改成 12 + 3 × 5，模型先算 15 + 12 = 27，答案又碰巧对了。这种情况只看答案无法发现模型运算顺序混乱。

更好的做法是对可选答案的任务同时记录完整输出，并定期抽人审读推理链条。条件允许时，可以让另一个强模型作为 judge 评估推理步骤质量，但 judge 模型自身也可能存在偏好，需要抽样对照。

5.2 忽略输出格式解析失败

很多模型在压力测试下会突然不遵守输出格式。比如要求输出“答案：A”，它输出一大段解释后说“因此选 A”。这本身就是一个鲁棒性问题，但如果在解析答案时直接判错，可能会低估模型真实能力，也可能高估——如果解析逻辑写得太宽松，把解释里出现的任意字母 A 当成答案，又会造成误判。

建议把解析失败的样本单独统计为parse_error，不要简单并入“回答错误”。这样能区分两类问题：模型不会做，和模型会做但格式崩了。这两类问题在落地时的处理方式不同：前者需要换模型或改造任务，后者往往可以通过输出解析层和后处理兜底解决。

5.3 小样本下的指标方差

压力测试一次会跑很多组合，如果原始题目太少，单个场景下的准确率可能因为一两道题的变化出现剧烈波动。比如只有 4 道题，错 1 道准确率就掉 25 个百分点。不要因为一次小样本测试的波动就下结论。建议先做小样本定性观察，再对最可能的模型候选扩大样本量做统计评测。

6. 常见问题与排查思路

下面整理压力测试脚本运行过程中可能遇到的问题，以及对应的排查方式。

排错流程可以统一为：先看原始输出，再查请求参数，最后核对环境。不要一上来就怀疑模型能力，很多时候是解析脚本和后端服务的问题。

7. 最佳实践与工程建议

7.1 评测集要避免污染与过度拟合

如果把公开 benchmark 的题目直接拿来测试，很难判断模型是新学会推理，还是背下了答案。自建评测集时，优先写不与公开数据集重复的原创题目，并且保证评测集的题目在训模型和选型阶段没有被用于 prompt 调试。评测集需要像代码一样纳入版本管理，任何改动都要记录。

7.2 每个扰动都必须保证语义等价

自动扰动最容易踩的坑是“扰动完题目意思变了”。例如把“多少”替换成“价格”，就可能改变题型。建议对每个扰动样本做人工抽检，或者用规则校验题目中关键数字、逻辑连接词没有变化。对选择题做选项乱序时，一定要同步更新标准答案字母，否则整批结果都会出错。

7.3 记录每一次请求的完整上下文

评测结果不能只记 correct/wrong，还要保存模型名、模型版本、base_url、temperature、top_p、max_tokens、原始输出、时间戳。缺少这些信息，几周后回看 CSV 时会完全无法复现。输出文件建议采用 CSV 或 JSONL 格式，至少保留原始输出列，方便失败 case 分析。

7.4 先区分“格式问题”和“能力问题”

压力测试时，模型经常出现“会但不说人话”的情况，比如结论正确但格式不符，解析器判错。建议在统计时区分：

• answer_correct：模型内部结论是否与标准答案一致；
• format_ok：输出是否满足约定的格式。

产品落地时，如果格式问题占比高，可以加一层输出结构化解析；如果 answer_correct 本身很低，就需要更换或微调模型。两类问题的成本完全不同。

7.5 安全与隐私边界

测试数据如果来自真实业务，要注意脱敏。不要直接把用户聊天记录、手机号、身份证号、企业未公开代码或文档传到第三方模型服务。调用云端 API 前，先确认服务协议允许你用这些数据做评测。评测请求也不要高频打满对方配额，避免影响线上业务。

7.6 把鲁棒性评测做成常态化回归

模型上游可能随时更新版本，同一个模型名背后的实际权重也可能发生变化。建议把压力测试脚本接入定时任务，每周或每次模型版本升级后跑一遍，并把结果推送给团队。这比在榜单页看到分数变化要早很多，能有效避免线上模型悄悄“变笨”而不自知。

8. 下一步的学习与工程路线

到这里，你已经掌握了一套从数据准备、扰动生成、解码参数扫描到指标计算的完整评测方法。接下来可以沿着三个方向继续深入。

第一，把当前这套“规则扰动脚本 + 字符串判分”升级为更专业的评测流水线。你可以在样本库中增加对抗性题目、多语言题目、长上下文干扰题，并接入一个强 judge 模型来评价开放式回答的推理质量。注意 judge 模型自身也需要抽样校准，不能盲目信任。

第二，尝试把鲁棒性测试结果与模型决策结合起来。比如在温度较高时某题多次采样结果不稳定，说明该题对模型来说处于“低置信区域”。这类题目在业务中应被设计成需要二次确认、转人工或默认不采用高风险自动决策，而不是把单次输出直接当最终结果。

第三，关注测试集本身的生命周期。随着模型能力提升，旧的扰动方式可能不再有区分度。你需要持续维护一份“失败案例库”，把每次线上真正出错的样本沉淀下来，扩充为下一轮测试集。这样才能让评测跟上模型迭代的速度，而不是永远在评测旧问题。

大模型评测不是跑一次分就结束的工作。榜单分数只是起点，真正决定一个模型能不能上线的是它在各种“意外输入”下还能不能保持稳定的表现。希望这篇解码级压力测试的拆解，能帮你建立一套更接近真实场景的模型评估习惯。