最近在给一批模型做真实场景评估时我发现一个很矛盾的现象同一个数学题题干原封不动时模型能答对只是把“多少平方厘米”改成“面积是几平方厘米”回答质量就明显下滑再把 temperature 从 0.2 调到 0.8连续问 5 次竟然能出现 3 种不同的答案。去翻主流评测榜单这些模型又都表现良好仿佛完全不存在这种脆弱性。如果你也遇到过类似情况那我们要讨论的问题就很明确了不是模型“不会”而是我们对模型鲁棒性的评估方式存在盲区。很多模型在常见 benchmark 上高分通过但换一种说法、换一组解码参数推理能力就露馅。这种“评测看起来很强、实际用起来很不稳”的错位可以称之为 LLM 鲁棒性幻觉——模型的鲁棒性并没有榜单分数展示的那么好只是常规评测没有把压力场景覆盖到。这篇文章会围绕 LLM 鲁棒性、解码策略和压力测试展开先从概念上解释为什么普通评测会失真再给出一套可以自己跑起来的“解码级压力测试”方案包含可复制的 Python 代码、评测指标设计、常见踩坑和最佳实践。无论你是做模型选型、Prompt 调优还是给业务接入大模型都可以用这套思路提前发现模型的真实短板。1. 背景为什么常规大模型评测会掩盖鲁棒性问题1.1 LLM 鲁棒性到底指什么LLM 鲁棒性是一个范围很广的概念简单理解就是当输入发生变化、环境出现干扰时模型是否仍然能给出稳定且正确的结果。它通常包含几个层面输入扰动鲁棒性同义改写、词序调整、标点变化、错别字、多语言混用等不应导致结论发生剧烈变化。解码参数鲁棒性temperature、top_p 等生成参数变化后模型答案应当保持基本一致尤其是客观题和推理题。指令格式鲁棒性用户把问题包装成“请解决以下问题”“你是数学助教”等不同指令格式时模型要能识别真实任务。上下文鲁棒性前面加了无关对话、角色设定、少量干扰信息后模型不应丢失原始问题。对抗鲁棒性面对刻意构造的诱导、攻击或边界输入时模型不能被轻易带偏。常规评测通常只给出一组固定的 prompt跑一次或少数几次然后计算准确率。这种方式能反映模型在“标准环境”下的上限却无法回答一个非常实际的问题用户不会每次都按标准模板提问生产环境里同一个问题可能有几十种说法。1.2 什么是“鲁棒性幻觉”“鲁棒性幻觉”不是说模型真的产生了幻觉内容而是指评价体系给人们制造了一种“这个模型很鲁棒”的虚假安全感。一个典型的形成路径是模型在主流 benchmark 上刷出高分开发者据此认为模型“推理能力强”“很稳定”实际接入业务后发现用户换一种提问方式模型就答错回到测试集检查又发现分数没变。出现这种情况往往不是有人在造假而是 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_p1.0 表示保留全部候选top_p 越小候选范围越窄。它和 temperature 同时使用时会共同影响最终采样分布。max_tokens 控制最大生成长度。对于推理题如果长度限制太短模型可能来不及输出完整推导过程如果太长部分模型在长文本生成后段可能出现重复或逻辑漂移。repetition_penalty重复惩罚会降低已经出现过的 token 的概率。这个参数对生成长文本比较重要但过高的惩罚值有时会破坏正常表达。在“解码级压力测试”里我们对这些参数做扫描就是为了观察模型输出对解码配置的敏感度。一个足够稳定的模型在 temperature 从 0 升到 1 的过程中客观题答案虽然可能存在表述差异但核心结论不应该反复横跳。2.3 压力测试与常规评测的关系常规评测回答“这个模型能得多少分”压力测试回答“这个模型在多大范围内能保持住分数”。两者的关系不是互相替代而是层级递进。常规评测先划定标准能力基线压力测试再对基线做压力对抗。更完整的评测流程应该是设计一组有标准答案的评测样本在标准场景下跑出基准确率对样本施加语义保持扰动对同一问题做多次采样和参数扫描对比扰动前后、参数变化前后的结果差异计算鲁棒性衰减度、一致性等指标对失败样本做 case 分析。3. 解码级压力测试要覆盖哪些维度3.1 输入表达扰动这是最基础的扰动方式核心要求是“语义不变表达改变”。举几个可以落地的方向同义改写把“计算面积”改成“求解面积”“它的面积是几”把“如果……那么……”改成“假设……由此可得……”。细节调整把“8厘米”写成“8 cm”题目含义不变但 token 分布变化很大。添加冗余引导语比如“这是一道小学数学题请用小学方法求解”与“请用严谨推理作答”对模型的答题策略会产生影响。选项顺序变换选择题中调换 ABCD 的顺序正确答案在选项中的位置随之变化。这些扰动不需要依赖外部大模型用轻量规则脚本就可以完成。关键是扰动后必须人工确认标准答案没有被改变。3.2 指令格式扰动同一个问题在真实使用中可能以不同形式出现。比如“直接回答”“计算一下”“请以‘答案是’结尾”“你是数学助教请见谅但必须作答”等。对格式敏感并不是致命伤但如果格式一变模型就从答对变成答错说明它并没有真正掌握题目背后的推理规律只是靠着训练时见过的文本模式在“猜”。3.3 解码参数扫描解码参数扫描是“解码级”这个名称的核心来源。实际执行时可以按如下列表组合temperature0.0、0.2、0.5、0.8、1.0top_p0.8、0.9、1.0max_tokens128、512每组参数下重复采样 3 到 10 次扫描会产生大量请求需要控制成本。建议先用小样本集跑通流程再逐步扩展。3.4 思维链与推理过程压力测试推理题的答案只是表象推理过程更能说明问题。压力测试中可以要求模型“先输出思考过程再给出答案”也可以直接问“请逐步解释”。这样做有两个目的观察中间推理是否存在错误但答案偶然正确的“假阳性”观察模型在必须解释步骤时是否会暴露概念理解漏洞。对于数学题还可以故意在上下文中加入一个无关条件比如“长方形的长是 8 厘米宽是 5 厘米操场上有 3 个小朋友在跑步请问面积是多少”如果模型把无关信息也算进去说明它对关键信息筛选能力不足。3.5 多次采样一致性测试同一个问题在 temperature0.7 下采样 10 次统计答案分布。如果 10 次中出现了 3 种以上不同结论说明模型在这个问题上的置信度分布很分散这在需要稳定输出的业务场景中是高风险信号。4. 从零搭建轻量级压力测试框架下面进入实操环节。我会用 Python 搭建一个最小可用的 LLM 解码压力测试框架。这里的代码侧重演示评测思路你可以直接复用也可以按自己的模型 API 调整。4.1 环境准备与项目结构本文示例环境如下操作系统Windows 10/11、macOS、Linux 均可Python3.9 或更高版本依赖库openai1.0、pandas、numpy模型接入任意兼容 OpenAI Chat Completions 格式的服务例如 vLLM、Ollama 的 OpenAI 兼容端点、各类云厂商模型服务安装依赖pip install openai1.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_urlbase_url or https://api.openai.com/v1, api_keyapi_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(questionquestion) 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 需要完成四件事标准场景原题 默认参数。变体场景同一题的不同问法。格式与噪声压力加入指令包装或无关干扰句。采样一致性高温下反复采样多次。# 文件路径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_okTrue) 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, questionNone): 根据样本生成用户消息 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_promptSYSTEM_PROMPT, temperaturetemperature, top_ptop_p, max_tokensmax_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, requiredTrue, help模型名称) parser.add_argument(--base-url, defaulthttps://api.openai.com/v1, helpOpenAI兼容服务地址) parser.add_argument(--api-key, defaultNone, helpAPI Key默认读取环境变量) parser.add_argument(--repeat-times, typeint, default5, help高温采样次数) args parser.parse_args() client LLMClient(modelargs.model, base_urlargs.base_url, api_keyargs.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], temperature0.2, top_p1.0, max_tokens256, scenariobase, repeat_idx0, )) # 2. 同义问法变体 for i, variant in enumerate(get_question_variants(item)): if i 0: continue rows.append(run_case( client, item, variant, temperature0.2, top_p1.0, max_tokens256, scenariofvariant_{i}, repeat_idx0, )) # 3. 指令包装压力 for wrap_idx in [1, 2, 4]: wrapped_q wrap_question(item[question], wrap_idx) rows.append(run_case( client, item, wrapped_q, temperature0.2, top_p1.0, max_tokens256, scenariofwrap_{wrap_idx}, repeat_idx0, )) # 4. 无关干扰信息 rng random.Random(42) noise_q add_irrelevant_noise(item[question]) rows.append(run_case( client, item, noise_q, temperature0.2, top_p1.0, max_tokens256, scenarionoise, repeat_idx0, )) # 5. 选择题选项乱序压力 if item.get(choices): shuffled_item shuffle_choices(item, rng) rows.append(run_case( client, shuffled_item, shuffled_item[question], temperature0.2, top_p1.0, max_tokens256, scenarioshuffle_choices, repeat_idx0, )) # 6. 高温多次采样一致性 for rep in range(args.repeat_times): rows.append(run_case( client, item, item[question], temperature0.8, top_p1.0, max_tokens256, scenariosampling_high_temp, repeat_idxrep, )) with open(csv_path, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnameslist(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[高温采样一致性] temperature0.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_groupsFalse) .dropna() ) if len(consistency_df): print(f 首次结果保持率粗糙一致率{consistency_df.mean():.2%}) if __name__ __main__: main()python analysis.py4.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. 常见问题与排查思路下面整理压力测试脚本运行过程中可能遇到的问题以及对应的排查方式。问题现象常见原因解决思路请求报错 AuthenticationErrorAPI Key 缺失或无效检查环境变量是否设置确认 key 与 base_url 是否属于同一服务服务端返回 404 Not Foundbase_url 路径不对OpenAI 兼容服务通常以/v1结尾检查服务文档确认完整地址请求 429 限流并发请求过多或配额不足降低请求频率必要时在每次请求之间加 sleep或提高账号配额部分服务不支持 seed 参数兼容服务未实现该功能在客户端去掉 seed 再重试记录“本次运行不可完全复现”解析答案大量失败模型没遵循“答案X”格式先查看 raw_output如果格式问题普遍考虑升级 system prompt 或改用解析后 LLM judge同一次采样结果每次都不一样服务端采样本身存在随机性对需要稳定输出的任务提高采样一致率要求使用更低 temperature高温采样下长输出截断max_tokens 不够调大 max_tokens或要求模型先给结论再给解释评测结果波动大样本数量太少扩样本或减少场景组合先保证每个场景有足够统计量同一 API 不同时间结果不稳定服务端模型版本可能滚动更新记录每次评测的模型名、服务地址、时间戳便于回溯排错流程可以统一为先看原始输出再查请求参数最后核对环境。不要一上来就怀疑模型能力很多时候是解析脚本和后端服务的问题。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 模型自身也需要抽样校准不能盲目信任。第二尝试把鲁棒性测试结果与模型决策结合起来。比如在温度较高时某题多次采样结果不稳定说明该题对模型来说处于“低置信区域”。这类题目在业务中应被设计成需要二次确认、转人工或默认不采用高风险自动决策而不是把单次输出直接当最终结果。第三关注测试集本身的生命周期。随着模型能力提升旧的扰动方式可能不再有区分度。你需要持续维护一份“失败案例库”把每次线上真正出错的样本沉淀下来扩充为下一轮测试集。这样才能让评测跟上模型迭代的速度而不是永远在评测旧问题。大模型评测不是跑一次分就结束的工作。榜单分数只是起点真正决定一个模型能不能上线的是它在各种“意外输入”下还能不能保持稳定的表现。希望这篇解码级压力测试的拆解能帮你建立一套更接近真实场景的模型评估习惯。