测试时扩展与推理大模型评测：可复现性工程实践

最近在对比推理大模型（reasoning LLM）的不同评测方式时，被一个很现实的问题卡住：模型效果波动不小，同一个 prompt 跑两次，答案可能完全不同；换一个推理采样配置，分数能差好几个点。如果评测工具、推理参数、随机种子都没固定下来，最后很难说清楚模型能力提升究竟是模型变了，还是只是测试方式变了。

这篇文章围绕 Test-Time Scaling（测试时扩展）这一主题，结合 Reasoning LLMs 的推理行为、Inference Regimes（推理配置）、第三方评估工具接入，以及可复现性工程实践，梳理一套完整可落地的评测思路。内容偏实操，代码都是可以直接在本地跑的最小示例，适合正在做 LLM 效果评测、想接入第三方评估工具，或者研究采样策略对模型分数影响的读者。

1. 背景与核心概念

1.1 什么是 Test-Time Scaling

传统的大模型能力提升，主要靠训练阶段：更多数据、更大模型、更长时间的训练。但对于推理任务，比如数学题、逻辑判断、代码调试，模型在训练完成之后，仍然可以通过“多算一会儿、多想几步”来获得更高质量的回答。

这种在推理阶段增加计算量、改善生成质量的做法，就是 Test-Time Scaling。

一个最简单的例子是数学题：

问题：一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？

不做扩展时，模型可能直接输出：3 * 2 + 2 * 4 = 14。

如果做测试时扩展，模型可能会先自言自语：

鸡有 2 条腿，3 只鸡是 6 条腿。 狗有 4 条腿，2 只狗是 8 条腿。 总腿数是 6 + 8 = 14。

当推理过程变长、中间检查变多，错误概率会下降。更进一步的扩展，可以让模型生成多条候选答案，再用投票或验证器选出最可靠的结果。

这种现象在 OpenAI 的 o1 / o3 系列模型中比较典型，也让“测试时计算（Test-Time Compute）”这个概念成为研究热点。与之相似的还有 self-consistency（自洽性）、best-of-n 采样、多数投票、轻量级验证器筛选等方法。

1.2 为什么 Inference Regimes 会影响评测结果

Inference Regimes，可以理解为“模型推理阶段的运行配置组合”。它决定了模型在给定同一个 prompt 时，到底如何生成内容。

常见维度包括：

同一个模型，temperature=0 和 temperature=0.7，n=1 和 n=10，最终评测分数可能差异不小。

因此，如果你在论文或项目报告中写“本模型准确率达到 85%”，却不描述推理阶段参数，那这个结果就很难复现。Inference Regimes，本质上是评测报告里必须交代清楚的实验条件。

1.3 评测与可复现性的关系

评测（Evaluation）回答的是“模型效果到底怎么样”。可复现性（Reproducibility）回答的是“别人能不能按同样的设置得到相同结果”。

评测结果可信的前提，是可复现。但在真实项目中，数据集版本会在更新、评估脚本会被调整、模型服务可能做了量化或 batch 推理，这些都会影响最终指标。

常见的评测完整性问题包括：

• 只记录准确率，不记录 prompt 模板和模型版本。
• 为了效果对比，临时把 temperature 调低，却没写在报告里。
• 评测数据集做完清洗后，没有保存清洗脚本。
• 多个评测工具混用，指标口径不一致。
• 随机性没有固定，实验重复两次结果相差很大。

所以，评测工程中需要引入稳定的第三方评估工具，并且让工具能够调用自建的推理 API，使用自定义评估标准。这也是本文后半部分的实战重点。

2. 环境准备与第三方评估工具选型

2.1 基础环境

本文示例以 Python 3.10+ 为基准，需要准备：

• Python 3.10 或更高版本
• pip 包管理工具
• OpenAI SDK（用于调用兼容接口）
• FastAPI + uvicorn（用于模拟自建推理服务）
• promptfoo 或 DeepEval（第三方评估工具）

如果你已经有可用的推理 API，就不用搭 mock 服务，直接把 base_url 和 API Key 换成真实服务即可。

版本说明：不同工具的配置格式差异较大，本文以常见版本为主。实际使用时，请以官方文档和pip show输出的版本为准。

安装依赖的命令：

pip install openai fastapi uvicorn promptfoo deep-eval

如果你只需要其中某一个工具，可以分开安装。例如：

pip install deep-eval # npm 安装 promptfoo npm install -g promptfoo

2.2 主流第三方评估工具

目前社区常用评估方案大致分两类。

一类是离线评估框架，适合批量跑 benchmark，比如：

• lm-evaluation-harness（EleutherAI 出品，支持大量公开数据集）
• OpenCompass（上海人工智能实验室开源，支持中英文评估）

另一类是面向业务的自定义评估工具，适合对接自建 API、编写自定义指标，比如：

• promptfoo（类似单元测试的评测工具，用 YAML 配置测试用例）
• DeepEval（Pytest 风格的 LLM 评估框架，可以自定义 metrics）
• OpenAI Evals（OpenAI 开源的评估框架，可注册自定义 eval）

如果你需要“调用自己写的 API，根据自己定义的评价标准”来做评估，promptfoo 和 DeepEval 是更灵活的选择。

2.3 本文实战场景

我设计的示例场景如下：

1. 有一个自建推理服务，接口兼容 OpenAI API 格式。
2. 需要评测模型在高斯数学题上的准确率。
3. 每次生成不只跑 1 条答案，而是先采样 N 条候选，再用多数投票得出最终答案。
4. 评测脚本需要记录温度、种子、模型版本、prompt 版本，保证实验可复现。

在代码实现上，我会先用 FastAPI 写一个 mock 推理服务，再分别演示 promptfoo 和 DeepEval 的接入方式。这样你不需要真实模型也能跑通流程。

3. 核心概念拆解

3.1 Test-Time Scaling 的常见策略

Test-Time Scaling 并不单指“让模型生成更多内容”，而是包含多个层面的扩展手段。

3.1.1 多数投票 / Self-Consistency

对同一个问题生成 N 个答案，然后统计答案中出现次数最多的那个作为最终输出。

这是最直观的扩展方式，效果稳定，实现简单。

import collections answers = ["14", "14", "14", "15", "14", "13"] final_answer = collections.Counter(answers).most_common(1)[0][0] print(final_answer)

输出：

14

对于有唯一正确答案的数学题，多数投票能显著提升准确率，但代价是多次调用模型，推理成本变为原来的 N 倍。

3.1.2 Best-of-N 采样 + 验证器

生成 N 个候选答案，再使用一个验证器（reward model / verifier）对候选答案排序，选出得分最高的。

这种方式适合“答案没有单一标准，但可以判断好坏”的任务，比如代码、开放式问答。

3.1.3 长思维链 / 隐式搜索

像 o1 这类模型，会在内部生成较长的推理轨迹，再输出最终答案。这种方式不需要显式采样多轮，而是把更多计算放在单次生成内。

3.2 Inference Regimes 的关键参数

需要注意的是，temperature=0在技术上并不是完全确定性，不同框架、不同硬件下仍有微弱差异。要保证严格可复现，最好固定 seed，并保留完整参数快照。

3.3 评估流程的组成

一次完整的评测流程，通常包含：

1. 数据准备：测试用例的加载与清洗。
2. 推理调用：调用自建 API，设置 Inference Regimes。
3. 答案解析：从模型输出中提取最终答案。
4. 指标计算：根据自定义标准评分。
5. 结果记录：保存原始输出、参数和指标到本地文件。

在这套流程里，数据、参数、代码、运行环境四者耦合在一起，哪一环没记录，复现都会出问题。

4. 实战：用第三方评估工具评测自定义 API

下面进入代码实战部分。我会给出一个可以直接复制的完整流程。

4.1 准备一个兼容 OpenAI 的自建推理服务

先写一个 FastAPI 服务。为了演示方便，这个服务不会真的加载大模型，而是返回一个模拟推理结果：从几个预置答案中随机抽一个。

# 文件路径：server.py import random import uvicorn from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class ChatRequest(BaseModel): model: str = "mock-reasoner" messages: list temperature: float = 0.7 max_tokens: int = 128 seed: int | None = None class Choice(BaseModel): index: int message: dict finish_reason: str = "stop" class ChatResponse(BaseModel): id: str object: str = "chat.completion" choices: list[Choice] usage: dict ANSWERS = [ "The answer is 14.", "Final answer: 14.", "14", "Let me think carefully. 3 chickens have 6 legs. 2 dogs have 8 legs. Total is 14.", ] @app.post("/v1/chat/completions", response_model=ChatResponse) def chat_completion(req: ChatRequest): if req.seed is not None: random.seed(req.seed) content = random.choice(ANSWERS) return ChatResponse( id="chatcmpl-mock", choices=[ Choice( index=0, message={"role": "assistant", "content": content}, finish_reason="stop", ) ], usage={"prompt_tokens": 20, "completion_tokens": len(content), "total_tokens": 20 + len(content)}, ) if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

启动服务：

python server.py

注意：这只是一个 mock 服务，用来验证评估流程。真实项目中，你需要把/v1/chat/completions转发到自己的推理引擎，比如 vLLM、TGI，或者你内网部署的模型服务。

4.2 使用 promptfoo 进行评测

promptfoo 是一个命令行评测工具，可以用 YAML 定义 prompt 和测试用例，也支持自定义 API 地址。

4.2.1 初始化配置文件

在项目目录下创建一个promptfooconfig.yaml：

# 文件路径：promptfooconfig.yaml prompts: - | 请回答下面的数学题，只输出最终答案数字。 题目：一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？ providers: - id: openai:chat:mock-reasoner config: apiBaseUrl: http://localhost:8000/v1 apiKey: dummy-key temperature: 0.7 max_tokens: 128 tests: - vars: question: "一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？" assert: - type: contains value: "14"

这里apiBaseUrl指向自建服务，apiKey填任意非空字符串即可，openai:chat:mock-reasoner表示调用 OpenAI 兼容接口。

4.2.2 运行评测

promptfoo eval

如果希望输出完整报告：

promptfoo eval -o report.html

promptfoo 的断言机制非常灵活，包括：

• contains：输出包含某个文本。
• equals：输出完全等于某个文本。
• javascript：执行自定义 JS 判断。
• python：调用自定义 Python 脚本。
• model-graded：用另一个 LLM 打分。

这种方式非常适合“自己定义评价标准”。

4.3 使用 DeepEval 进行评测

DeepEval 是 Python 生态的评估库，风格接近 pytest，适合在代码里精细控制评估流程。

4.3.1 编写自定义评估用例

# 文件路径：test_eval.py import os from deepeval import assert_test from deepeval.test_case import LLMTestCase from deepeval.metrics import AnswerRelevancyMetric def call_my_api(question: str, seed: int = 42) -> str: # 这里直接调用自建 API from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy-key") response = client.chat.completions.create( model="mock-reasoner", messages=[ {"role": "user", "content": question} ], temperature=0.7, max_tokens=128, seed=seed, ) return response.choices[0].message.content def test_math_answer(): question = "一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？" output = call_my_api(question) # 自定义判断：答案里必须包含 14 assert "14" in output, f"模型输出不包含 14，实际输出：{output}" test_case = LLMTestCase( input=question, actual_output=output, expected_output="14", ) metric = AnswerRelevancyMetric( threshold=0.5, model="gpt-4o-mini" ) assert_test(test_case, [metric])

这里有一个关键点：AnswerRelevancyMetric本身通常需要调用 OpenAI 模型来判断相关性。如果不想引入另一个模型，可以只用简单的assert做规则判断，或者自定义一个 Metric 类。

DeepEval 的自定义 Metric 示例：

# 文件路径：custom_metric.py from deepeval.metrics import BaseMetric from deepeval.scorer import Scorer class ContainsAnswerMetric(BaseMetric): def __init__(self, expected: str): self.expected = expected self.threshold = 1.0 def measure(self, test_case) -> float: if self.expected in test_case.actual_output: self.success = True return 1.0 self.success = False return 0.0 def is_successful(self) -> bool: return self.success @property def __name__(self): return "ContainsAnswerMetric"

然后用这个自定义指标跑测试：

# 文件路径：test_with_custom_metric.py from deepeval.test_case import LLMTestCase from custom_metric import ContainsAnswerMetric test_case = LLMTestCase( input="一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？", actual_output="The answer is 14.", ) metric = ContainsAnswerMetric(expected="14") score = metric.measure(test_case) print(f"Score: {score}, Success: {metric.is_successful()}")

这种方式的好处是：评估标准完全由你定义，不依赖其他模型判断。

4.4 实现多数投票评估

要评估 Test-Time Scaling 的效果，需要对比不同采样数量 n 下的准确率。

下面是一个完整的 Python 脚本。它会调用自建 API N 次，提取答案并投票。

# 文件路径：majority_vote_eval.py import collections import random from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy-key") QUESTIONS = [ "一个农场里有 3 只鸡和 2 只狗，总共有多少条腿？", "小明有 5 个苹果，给了小红 2 个，还剩几个？", "12 + 7 等于多少？", ] CORRECT_ANSWERS = ["14", "3", "19"] def extract_answer(text: str) -> str: # 简单提取数字，真实项目需要更严谨的解析 import re numbers = re.findall(r"\d+", text) if not numbers: return "" return numbers[-1] def generate_with_api(question: str, temperature: float, seed: int) -> str: response = client.chat.completions.create( model="mock-reasoner", messages=[{"role": "user", "content": question}], temperature=temperature, max_tokens=128, seed=seed, ) return response.choices[0].message.content def majority_vote(question: str, n: int, temperature: float, seed: int) -> str: answers = [] for i in range(n): raw = generate_with_api(question, temperature, seed + i) answer = extract_answer(raw) answers.append(answer) counter = collections.Counter(answers) final_answer, _ = counter.most_common(1)[0] return final_answer, answers def evaluate(temperature: float = 0.7, n: int = 5): correct = 0 for i, question in enumerate(QUESTIONS): final_answer, all_answers = majority_vote(question, n=n, temperature=temperature, seed=42 + i) is_correct = final_answer == CORRECT_ANSWERS[i] correct += int(is_correct) print(f"Question {i + 1}: final={final_answer}, expected={CORRECT_ANSWERS[i]}, correct={is_correct}") print(f" candidates: {all_answers}") accuracy = correct / len(QUESTIONS) print(f"Accuracy: {accuracy:.2%}") if __name__ == "__main__": evaluate(temperature=0.7, n=5)

运行效果：

Question 1: final=14, expected=14, correct=True candidates: ['14', '14', '14', '14', '14'] Question 2: final=3, expected=3, correct=True candidates: ['3', '3', '3', '3', '3'] Question 3: final=19, expected=19, correct=True candidates: ['19', '19', '19', '19', '19'] Accuracy: 100.00%

当前 mock 服务只返回固定答案，所以准确率为 100%。真实场景中，候选答案会有波动，投票机制才会发挥明显作用。

5. 可复现性实践

5.1 固定随机种子与参数

大多数推理框架都支持 seed 参数。评测脚本里，建议对每次请求传入不同的 seed 组合，比如：

seed = 1000 + question_index * 10 + sample_index

这样即使多轮运行，同一位置的采样结果不会变化。

同时，把所有推理参数记录到 JSON 文件中：

# 文件路径：save_config.py import json config = { "model": "mock-reasoner", "temperature": 0.7, "top_p": 1.0, "max_tokens": 128, "seed": 42, "n_answers": 5, "voting": "majority", "prompt_version": "v1.0", } with open("inference_config.json", "w", encoding="utf-8") as f: json.dump(config, f, ensure_ascii=False, indent=2)

5.2 保存完整实验记录

推荐每个实验一个目录：

experiments/ run_20250101_1200/ inference_config.json dataset.csv raw_outputs.jsonl metrics.json prompt_template.txt eval_script.py

保留原始输出到 JSONL 文件，可以随时复盘：

# 文件路径：save_raw_outputs.py import json with open("raw_outputs.jsonl", "a", encoding="utf-8") as f: record = { "question": question, "candidates": all_answers, "final_answer": final_answer, "expected": CORRECT_ANSWERS[i], "config": config, } f.write(json.dumps(record, ensure_ascii=False) + "\n")

5.3 版本锁定

不管是用 lm-evaluation-harness、promptfoo 还是 DeepEval，都要锁定工具版本。

pip freeze > requirements.txt

如果使用 npm 安装的 promptfoo，则提交package-lock.json到仓库。

模型版本也很关键。如果你的模型服务支持多个版本，评测时要显式指定，避免默认版本悄悄变化。

5.4 随机性与不确定性的处理

即使固定 seed，在不同硬件或不同 batch 大小下，结果也可能有差异。可复现性实践并不是追求“绝对相同”，而是追求“在合理误差范围内一致”。

更严谨的做法是：多次运行评测，报告平均值和标准差，而不是单次结果。

6. 常见问题与排查思路

7. 最佳实践与工程建议

7.1 评测数据集与 prompt 分离

不要用临时写在脚本里的字符串作为测试集。把测试数据和 prompt 模板分开管理，推荐使用文件组织：

• data/questions.jsonl：只存题目和标准答案。
• prompts/math_cot.txt：存 prompt 模板，包含变量占位符。

这样修改 prompt 时不需要改动代码，也方便对比不同 prompt 版本。

7.2 评估 Metrics 尽量可解释

在 Test-Time Scaling 实验中，单纯看准确率有时会掩盖问题。建议同时观察：

• 平均生成 token 数。
• 单次推理耗时。
• 候选答案多样性。
• 投票后正确率 vs 单次正确率。

这些指标能帮你判断扩展策略是否真的有效。

7.3 区分模型能力与采样策略收益

如果你发现 n=10 的多数投票比 n=1 准确率高，这不代表模型更强，而是采样策略带来增益。报告里最好分开描述：

• 基础准确率：n=1 时的表现。
• 扩展后准确率：n=10 时的表现。
• 增益量：扩展带来的提升幅度。

这样能避免“刷分式评测”带来的误导。

7.4 安全与授权提醒

如果你要评估的是线上模型，注意：

• 评测请求量不要超过服务配额。
• 不要在评测脚本里明文存储生产环境 API Key，建议使用环境变量。
• 如果要跑大量 Prompt，先在小范围测试，避免触发服务端限流或安全策略。

7.5 自动化与 CI 集成

对业务关键指标，可以把评测流程接入 CI。比如每次模型版本更新后，自动运行 100 条冒烟测试用例，失败则阻止发布。

promptfoo 支持直接作为命令行工具集成到 CI：

promptfoo eval --max-concurrency 4 promptfoo share

DeepEval 也支持与 pytest 配合，直接作为测试套件运行。

8. 总结与下一步学习路线

本文从 Test-Time Scaling 的背景出发，梳理了推理阶段扩展的核心思路，重点解决了三个工程问题：

• 如何用第三方评估工具接入自建推理 API。
• 如何自定义评估标准，比如多数投票和答案包含判断。
• 如何提升评测结果的可复现性。

如果你正在做推理大模型的效果评测，下一步可以优先做这几件事：

1. 把现有的评测脚本改成“数据集 + Prompt 模板 + 推理配置 + 评估脚本”分离的结构。
2. 引入 promptfoo 或 DeepEval 中的任意一个，先把自建 API 的冒烟评测跑通。
3. 在固定 seed 和参数记录的前提下，对比 n=1 和 n=5 的多数投票效果差异。
4. 尝试用更复杂的数据集，比如 GSM8K 或 MATH 的子集，观察 Test-Time Scaling 在不同难度上的表现差异。

评测这件事，投入产出比很高。把评估流程标准化之后，后面每一次模型迭代、参数调整，都能得到清晰可信的结论。希望这篇内容对你正在做的推理模型评测项目有帮助。