大模型宣传指标复核实操：从基准到成本

教程目标

本教程帮助读者搭建一套可重复执行的模型能力复核流程。厂商宣传中的数据通常只给出结论，不给出测试条件。本教程把这些结论转换成读者可以执行、记录和复查的测试项。完成后，你应当能够：

• 把宣传口径拆成可测试的用例；
• 控制变量，保证不同模型或不同版本在相同条件下对比；
• 记录耗时、Token用量和费用，计算单任务的实际成本；
• 对生成结果做可重放检查，并通过事实核查统计幻觉比例；
• 输出一份团队能复用、能追溯的评测报告。

适用场景

• 技术选型：接入某个模型服务前，判断其能力是否满足业务需求。
• 成本评估：比较不同推理档位的标价与实际消耗，避免只看单价。
• 版本回归：模型或服务升级后，用同一套测试集检查是否出现退化。
• 资料核查：面对二手传播的评测结论，判断其测试条件和来源是否可靠。

前置准备

1. 账号与权限：准备可调用模型接口的访问凭证，并确认额度、速率限制和可用模型列表。
2. 运行环境：一台能访问外网的开发机或测试服务器，安装常用脚本语言运行时和 HTTP 客户端库。建议使用虚拟环境隔离依赖，避免版本冲突影响结果。
3. 测试数据：准备 30 到 100 条样本，覆盖目标场景的常见情况和边界情况。样本应来自真实业务，尽量避免直接使用公开题库，因为公开题目可能已进入模型训练数据，导致结果偏高。
4. 结果存储：准备一张表格或一个数据库表，用于保存原始请求、原始响应、耗时、用量、测试参数和人工评分。
5. 基础知识：理解 Token 计费、上下文窗口、采样温度、最大输出长度等概念。这些参数直接影响结果和成本。

实施步骤

步骤一：把宣传口径拆成可测条目

厂商宣传通常使用“大幅提升”“显著降低”之类的表述，这类表述无法直接验证。第一步要把每一条宣传转换成四个要素：测试对象、测试任务、判定标准和对比基线。

例如，“幻觉率从某个数值降到另一个数值”可以拆成：测试对象是某个模型版本；测试任务是回答一组带参考答案的事实性问题；判定标准是回答中出现与参考答案不一致或无依据的断言即计为幻觉；对比基线是上一代版本，在相同题目上的结果。

这一步的目的是在测试开始前明确“什么算通过”。如果先跑数据再定标准，容易不自觉地偏向想要的结论。

步骤二：固定测试条件

模型输出具有随机性，同一提示词多次运行结果可能不同。测试前应固定以下条件，并把它们写入报告：

• 采样温度，复核时通常取较低值以减少随机波动；
• 最大输出长度，避免因截断导致结果失真；
• 系统提示词和任务提示词的完整文本；
• 是否启用工具调用，以及可用工具的清单；
• 调用时间和模型标识。

每条样本建议运行 3 次以上，记录分布而不是只取一次结果。如果同一样本的几次结果差异很大，说明该任务本身不稳定，单次成功率不能代表模型能力。

步骤三：编写统一的调用脚本

所有被测模型必须使用同一份脚本、同一组参数和同一批样本。脚本负责发送请求、计时、记录响应和用量。下面是通用伪代码：

for case in test_cases:
    for run in range(RUNS_PER_CASE):
        start = now()
        resp = call_model(
            model=TARGET_MODEL,
            prompt=case.prompt,
            temperature=FIXED_TEMPERATURE,
            max_output_tokens=MAX_OUT,
            tools=TOOL_CONFIG
        )
        latency = now() - start
        save_record(
            case_id=case.id,
            run=run,
            output=resp.text,
            usage=resp.usage,
            latency=latency,
            tool_config=TOOL_CONFIG,
            timestamp=start
        )

脚本中的密钥应从环境变量或密钥管理服务读取，不要写入代码或日志。

步骤四：记录成本与耗时

单价下降不等于单任务成本下降。推理档位较高时，模型可能产生更多推理相关的输出Token，耗时也会变长。因此需要从用量明细中读取实际数据，并按下面的方式计算：

单任务成本 = 输入Token数 × 输入单价
           + 输出Token数 × 输出单价
           + 工具调用费用（如有）

耗时建议拆成两部分统计：首字延迟（从发送请求到收到第一个字节）和生成耗时（从首字到结束）。两者分开记录，才能判断慢的原因是排队还是生成过程本身。

计算结果应取中位数和分位数，而不是只看平均值。平均值容易被少数极端样本拉偏。

步骤五：检查生成类任务的输出

生成类任务包括代码、页面、三维模型、图像描述等。这类输出无法用简单的字符串匹配判断对错，建议分三层检查：

1. 可运行性检查：代码能否通过编译或运行，页面能否正常加载，生成文件的格式是否正确。
2. 自动化结构检查：对照预设的检查项，例如组件数量、关键元素是否存在、接口是否符合约定。
3. 人工评分：由两名以上评审人员独立打分，给出评分标准说明。评分前不要互相讨论，以减少相互影响。

对于声称“不依赖外部服务”的生成能力，应设计对照组：在禁用外部工具的条件下重复同一任务，比较两组结果。同时，检查调用日志，确认请求中是否包含未声明的工具或外部接口调用。如果日志显示了额外调用，应如实记录，但在证据充分前不要直接下结论。

步骤六：核查幻觉率

幻觉率的核查依赖一套带参考答案的事实题库。建议按以下流程执行：

1. 为每道题准备可追溯的参考答案，并注明来源；
2. 让被测模型回答，保存完整回答；
3. 由两名评审人员独立标注每个断言是否有依据，标注完成后计算一致率，分歧部分由第三人裁决；
4. 幻觉率 = 含有无依据断言的回答数 ÷ 回答总数。

样本量较小时，比例的波动会很大。例如 50 道题中错 4 道与错 6 道，比例相差 4 个百分点，但这种差异很可能只是随机波动。报告中应同时写出样本量和判定规则。

步骤七：汇总为评测报告

报告应包含以下内容，便于他人复现：

项目	内容
测试对象	模型名称、版本标识、调用时间
测试条件	温度、最大输出长度、工具配置、运行次数
样本信息	样本数量、覆盖场景、来源说明
结果指标	通过率、幻觉率、耗时中位数、单任务成本
与宣传口径对比	测试条件是否一致，差异在哪里
局限性	样本偏差、判定争议、未覆盖的场景

配置说明

配置项	含义	取值逻辑	风险
采样温度	控制输出随机程度	复核时取较低值，创作类任务可适当提高	温度过高导致结果不可复现
最大输出长度	限制单次输出的Token上限	按任务实际需要设定，并留出余量	设置过小会截断输出，导致误判
单次超时	等待响应的最长时间	按任务复杂度设定，并记录超时次数	超时过短会把慢响应误判为失败
重试次数	失败后重新请求的次数	建议 1 到 2 次，并记录每次重试	重试会增加成本，还可能掩盖真实失败率
并发数	同时发送的请求数	不超过服务方允许的速率限制	并发过高会触发限流，影响耗时数据

结果验证

完成测试后，按以下四层检查结果是否可信：

1. 数据完整性：每条样本的每次运行都有记录。缺失或重复的记录要单独标注。
2. 抽样核对：随机抽取约 10% 的记录，与原始响应、用量明细逐条比对，确认没有写入错误。
3. 统计显著性：两组结果的差异必须超过样本波动范围，才能说明模型之间存在差异。样本量少时，应明确写出“差异不显著”。
4. 口径一致性：确认测试条件与宣传口径一致，包括版本、推理档位和是否启用工具。条件不一致时，结果不能直接对比。

常见问题与排查

• 同一样本结果波动大：多数原因是采样温度偏高或样本本身模糊。先降低温度，再检查题目是否有多种合理答案。若任务本身有多种正确答案，应改用可自动判定的评分标准。
• 实际成本高于预期：通常是只按标价估算，漏掉了推理相关输出或工具调用费用。对照用量明细逐项核对。
• 同一模型不同时间结果不同：服务方可能更新了模型版本或后端调度策略。记录每次调用的版本标识和时间，按时间段分组分析。
• 额度提前耗尽：长任务没有设置上限。为每个任务设置最大迭代次数和超时，并在脚本中监控剩余额度。
• 生成的代码无法运行：提示词没有说明运行环境、依赖版本和接口约束。在提示词中明确这些信息，并把运行环境纳入测试条件。
• 幻觉判定产生争议：判定规则写得太宽泛。提前定义什么算“有依据”，并用双人标注的一致率检验规则是否清楚。

优化建议

• 性能：根据速率限制调整并发数，对重复请求做本地缓存，避免为相同输入重复付费。
• 安全：访问凭证使用环境变量或密钥管理服务保存。测试样本中若含业务数据，先做脱敏处理，并限制存储范围。
• 稳定性：对超时和限流错误使用指数退避重试，失败样本单独归档，便于事后分析。
• 可维护性：测试集做版本化管理，脚本参数化，每次测试的配置文件与结果一同归档。
• 成本控制：先用小样本估算总成本，再设定预算上限。按任务难度分级选择推理档位，简单任务不必使用最高档位。
• 证据管理：报告中区分“已验证结论”和“未经核实的传闻”。二手爆料