大模型编程能力评测与幻觉核查实操教程

一、教程目标

本教程要解决的问题是：当某款大模型以亮眼跑分发布后，你如何在自有环境中，用一套可复现、可对账的流程，独立判断它在编程能力、工具调用真实性、幻觉水平、单位成本与额度稳定性四个维度上的真实表现。

完成本教程后，你将得到：

1. 一套隔离的评测执行环境，保证同一用例在多次、多版本下可比；
2. 一份自建任务集（含验收标准与预算约束），而非依赖单一公开基准；
3. 一份“工具调用溯源报告”，用于判断某个惊艳效果来自模型自身还是外部服务；
4. 一套幻觉率核查方法，能区分“裸测”与“挂核查闭环”两种口径；
5. 一份单位任务成本对账表，以及一套额度与调度治理方案。

需要说明的是：教程不评价任何具体厂商优劣，只提供方法。真实选型结论应由你自己跑出来的数据支撑。

二、适用场景与读者

• 开发者：要给项目选编码助手或代码生成模型，担心宣传指标与手感不一致；
• 测试/评测工程师：需要把“模型好不好”变成可执行、可归档的用例；
• 技术负责人：需要在成本、时延、稳定性之间做取舍，并向团队给出依据；
• 平台运维/FinOps 人员：需要管控长任务带来的额度耗尽与费用失控。

典型业务场景包括：代码补全与生成选型、终端自动化任务（构建、迁移、脚本修复）、多模态还原类任务（参考图生成可交互界面）、知识问答类场景的事实性风险评估。

三、为什么必须做“官方口径 + 独立实测”双轨评测

模型发布期的宣传指标与真实体感出现偏差，通常集中在四类结构性原因上，评测流程必须分别覆盖：

偏差类型	常见表现	评测应对
效果归因偏差	演示效果惊艳，但复现不出来；追查发现能力来自内置技能调用的外部服务	工具调用溯源 + 禁用外部工具复跑
任务难度口径偏差	公开基准分数很高，自建的多轮还原任务三版都不收敛	自建任务集 + 多轮收敛率统计
事实性口径偏差	带检索核查后幻觉率很低，裸测幻觉率高出数倍	裸测/挂核查双组对照
成本与配额偏差	单次任务墙钟时长数倍于同类，长任务中途被额度切断	成本对账 + 预算与额度治理

把这四类偏差纳入评测设计，是整篇教程的主线。

四、前置准备

4.1 账号、权限与额度

• 至少一个可调用模型服务的主账号，以及可独立计量、独立限流的项目子账号（用于隔离评测流量）；
• 明确的额度类型：按 token 计量额度、按时段/滚动窗口的并发额度、按时长的会话额度。这三类要分开确认，否则“任务失败”的原因无法归因；
• 若同时评测多个模型，确保各模型使用独立的凭据与独立的日志通道。

4.2 隔离执行沙箱

模型生成代码后必须在受控环境中执行，建议具备：

• 容器化运行，单任务独立生命周期，结束后销毁；
• 网络出口策略可切换：allow_all（真实使用）与 deny_external（能力纯净性测试）两种模式；
• 资源与时长硬限制：CPU/内存上限、单次任务墙钟超时、进程数上限；
• 只读基础镜像 + 可写工作目录，避免测试代码污染宿主。

4.3 数据与任务集

准备四类用例（示例数量：每类 10～30 条）：

1. 复现型：给参考图或参考描述，要求还原可交互组件；
2. 终端自动化型：给定仓库与报错，要求定位并修复，产出可执行命令序列；
3. 真实业务抽样型：从你自己的历史工单/缺陷中脱敏抽取，最贴近真实收益；
4. 事实问答型：需要外部信息才能回答的问题，用于测幻觉。

4.4 日志与计量埋点

至少记录以下字段，否则后续所有分析都不可信：

trace_id, case_id, model_id, model_version,
request: {prompt_hash, input_assets, tools_allowed, temperature, max_tokens},
response: {usage.input_tokens, usage.output_tokens, usage.reasoning_tokens,
           latency.first_token_ms, latency.total_ms, finish_reason},
tool_calls: [{name, args_hash, external_endpoint_kind, http_status, latency_ms}],
result: {accepted, score, rounds_used, error_code}

finish_reason 与 error_code 尤其重要：额度耗尽、超时、内容过滤导致的失败，与“模型能力不足”必须区分开。

4.5 对照基线

固定 1～2 个基线模型（含一个小参数模型作成本对照），在同一套用例、同一套配置、同一沙箱下跑，否则横向量化没有意义。

五、实施步骤

步骤 1：定义指标口径（先定口径，再跑数据）

这一步的作用是避免“跑完再挑指标”导致的结论漂移。建议口径如下：

• 一次通过率：首轮输出即通过验收的用例占比；
• 多轮收敛率：允许 N 轮修复（建议 N=3）后的通过率；
• 平均收敛轮数：衡量“修复效率”，比通过率更能反映工程可用性；
• 幻觉率：被判定为“与证据矛盾”的断言数 / 全部可判定断言数；
• 单位任务有效成本：实际扣费金额 / 通过验收的用例数（不是 / 总调用次数）；
• 单任务墙钟时长 P50/P95：直接影响人机协作体验；
• 中断率：因额度、超时、限流中断的任务占比。

注意：分母口径要写死。用“调用次数”作分母会显著低估失败重试带来的真实花费。

步骤 2：搭建隔离沙箱并做基线校验

先跑一个已知答案的“探针用例”（如生成一个打印指定字符串的最小程序），确认三件事：容器内网络策略生效、超时能被正确触发并写入 error_code、用量字段能正常回收。

只有探针用例通过，后续数据才有可比性。很多评测事故的根源就是用量统计没打通，导致成本估算偏低数倍。

步骤 3：构建设计任务集，写死验收标准

每个用例必须自带验收标准，禁止“看起来差不多”。示例（结构化示意）：

{
  "case_id": "REPRO-003",
  "type": "ui_reproduction",
  "prompt": "根据提供的 5 张参考图，用通用前端三维渲染方案还原一个可交互的控制器模型",
  "inputs": ["ref_01.png", "ref_02.png", "..."],
  "acceptance": [
    {"kind": "static_check", "rule": "无占位文本、无 TODO、构建无报错"},
    {"kind": "structural_check", "rule": "按键、摇杆、握把的空间位置关系与参考图一致"},
    {"kind": "human_review", "criteria": ["标识与图文元素可辨识", "交互可响应", "无肉眼可见穿模"]}
  ],
  "budget": {"max_rounds": 3, "max_wall_clock_sec": 900, "max_cost_usd": 0.5},
  "determinism": {"temperature": 0, "seed": 42, "network": "configurable"}
}

终端类用例额外要求：产出物能被 CI 直接执行，修复不能通过删除测试用例“通过”。

步骤 4：锁定确定性配置

同一用例在不同轮次之间要尽量可比，建议固定：采样温度、随机种子（若服务支持）、最大输出长度、系统提示词版本、检索/联网开关、工具白名单。

同时保留两组配置做对照：

• 纯净组：禁用外部工具与检索，测模型自身能力；
• 完整组：允许工具与检索，测端到端交付效果。

两组差值就是“工程配套带来的增益”，这个数字比绝对分数更有决策价值。

步骤 5：跑基线并做工具调用溯源（关键步骤）

这一步直接回应“演示效果复现不出来”这类争议。做法是：在完整组运行中，把每一次工具调用记录成可审计的结构化日志，并统计：

1. 外部调用占比：依赖外部服务完成的子任务数 / 总子任务数；
2. 外部端点识别：记录被访问服务的类别（如三维资产生成、检索、图像识别），不记录具体品牌；
3. 失败注入实验：把外部端点替换为返回空结果的桩服务，重跑同一用例；
4. 纯净组对照：完全禁用外部调用后重跑。

判定规则可以写得很干脆：

• 若纯净组通过率显著低于完整组（例如从多数通过跌到几乎不通过），说明效果主要由外部能力承载，模型贡献的是编排与集成；
• 若替换桩服务后产出仍可用，说明能力在模型侧；
• 若模型在纯净模式下产出的质量“差一大截”，应在报告中明确标注能力边界，而不是笼统记为“模型强/弱”。

这一步必须如实留痕：评测结论的价值来自前提透明，而不是结论漂亮。

步骤 6：幻觉核查闭环（裸测 vs 挂核查）

幻觉率之所以出现数倍差异，多数源于是否挂了检索核查。因此必须跑两组：

伪代码：

claims = extract_claims(model_answer)          # 拆成可独立判定的事实断言
for c in claims:
    if not c.is_verifiable: c.verdict = "unverifiable"; continue
    evidence = retrieve(c.query)               # 裸测组：evidence = 空
    c.verdict = classify(c, evidence)          # supported / refuted / unverifiable
hallucination_rate = count(refuted) / count(supported + refuted + unverifiable)

要点：

• 分子只算“与权威来源矛盾”，不要把“无法验证”计入，否则指标失真；
• 断言拆分粒度要统一（建议以“可单独核对的最小事实单元”为准），否则跨模型不可比；
• 裸测组必须真的关闭检索与联网，并核验 tool_calls 中没有检索类调用；
• 报告中同时给出裸测值与挂核查值，并注明差值来自工程配套。

步骤 7：成本核算与对账

模型侧用量与你实际被扣的费用常常不一致，需要三层对账：

计费口径核对：input / output / 推理(reasoning) token 是否分别计价
重试放大系数：总调用次数 / 成功任务数        （>1 说明存在无效重试）
子任务冗余系数：子任务调用次数 / 逻辑子任务数 （过高说明调度或规划冗余）
单位有效成本：实际扣费金额 / 通过验收用例数

建议把“墙钟时长”和“扣费金额”画在同一张对比表里。实践中常见的一种情况是：某模型单次任务耗时数分钟而同类仅数十秒，但扣费金额接近甚至更高——此时时间成本成了隐藏成本，需要在决策中与费用一起计入。

步骤 8：额度与调度治理

长任务被滚动窗口额度切断，是评测和生产的共同痛点。治理要点：

1. 预算三级化：单任务预算、日预算、项目预算，任一级触发即降级或排队；
2. 软告警先行：达到预算 70% 时预警，达到 90% 时禁止开启新任务（允许当前任务收敛），避免“改到一半被切断”导致产出不可用；
3. 任务分片与断点续作：把大任务拆成可独立验收的子任务，每片保存中间产物，中断后从最近检查点恢复；
4. 失败分类重试：仅对限流、超时、网络类错误重试；对“验收不通过”不做自动重试，而是进入人工评审队列，避免费用被无效重试放大；
5. 并发与排队：评测任务用低优先级队列，与线上流量隔离。

步骤 9：生成可复现报告

报告至少包含：模型标识与版本、用例集版本、配置快照（温度/提示词版本/工具开关）、每组指标、失败样本清单（含 trace_id 与失败原因分类）、成本对账表、能力边界说明、复现步骤。

一份合格报告的标准是：他人按报告操作，能得到偏差在可接受范围内的同样结论。

六、配置说明（通用配置项含义与风险）

配置项	含义	建议与风险
采样温度	输出随机性	评测固定为低值；线上按场景调整
最大输出长度	单次生成上限	过小导致多轮截断，放大轮数与成本
上下文窗口	可容纳输入规模	超长上下文会提升单位成本，需配合摘要/裁剪
最大工具调用轮次	单次任务内工具调用上限	过大易失控烧额度，过小无法完成复杂任务
单任务超时	墙钟上限	必须小于额度滚动窗口，避免中途被切
网络出口策略	是否允许访问外部服务	纯净组必须关闭；生产组需配白名单
重试策略	错误类型与次数	区分错误类型，禁止对“结果不达标”自动重试
日志脱敏开关	输入内容是否落盘	默认开启脱敏，评测数据需最小必要采集

七、示例说明

主评测循环（通用伪代码）：

for case in case_set:
    for group in [pure, full]:                 # 纯净组 / 完整组
        trace = run_agent(model, case, config[group])
        assert_network_policy(case, trace)     # 校验外部调用是否按预期被允许/拒绝
        score = evaluate(case.acceptance, trace.artifacts)
        cost  = reconcile(trace.usage, billing_record)
        write_record(case, group, score, cost, trace)

关键一致性校验（可直接落地为 CI 断言）：

1. 用例编号与验收标准不得为空
2. 纯净组 trace 中检索/外部生成类调用次数必须为 0
3. finish_reason 为额度/限流类时，不计入“能力不足”统计
4. 单位有效成本 = 实际扣费 / 通过用例数（分母不得用调用次数）
5. 每个失败样本必须能按 trace_id 重放

八、结果验证

按以下清单验收评测是否成立：

• 探针用例通过，网络策略与超时机制按预期生效；
• 用量字段回收率接近 100%，与账单抽样对账误差在可接受范围内；
• 纯净组与完整组分别出数，差值有解释；
• 幻觉率在裸测与挂核查两种口径下都有数值，且断言拆分规则一致；
• 失败样本全部完成原因分类（能力不足 / 上下文不足 / 预算耗尽 / 限流 / 验收标准歧义）；
• 报告可由第三方按步骤复现，指标偏差在声明范围内。

九、常见问题与排查

现象	可能原因	排查动作
复现不出演示效果	演示环境含外部能力或特殊提示词	抓 tool_calls，做桩替换与纯净组对照
首轮质量差、后续版本改善明显	提示词、上下文组织或输入资产未对齐	对齐提示词版本与输入分辨率，固定配置重跑
任务改到一半失败	撞上滚动窗口额度或单任务超时	查 error_code/finish_reason，拆任务分片并前移预算告警
幻觉率两组差异巨大	是否启用检索核查、判定口径不同	核对 tool_calls 中检索调用数与分子定义
单任务耗时远高于同类	长推理链、串行子任务、无效重试	看推理 token 占比与子任务调用序列，评估并行化与路由
费用远超预估	重试放大、子任务冗余、超长上下文	计算重试放大系数与冗余系数，收敛重试策略
同一用例多次结果差异大	温度过高、后端版本漂移	固定温度与种子，记录版本号，纳入回归基线

十、优化建议

• 成本：对简单任务做模型路由，用较小参数模型承接；开启结果缓存与检索结果复用；对长上下文做结构化摘要而非全量拼接。
• 稳定性：任务分片 + 检查点续作；预算三级告警；失败分类重试；评测与线上流量物理隔离。
• 可维护性：用例集纳入版本管理，指标口径写成配置文件；每次模型或提示词变更都跑回归基线，形成趋势曲线而非单点快照。
• 安全与合规：评测数据最小化采集并脱敏；产物归档到对象存储并设生命周期；关键指标接入监控告警。若使用百度智能云的对象存储归档评测产物、用日志服务与监控告警跟踪调用量与费用曲线，可显著降低自建流水线的运维成本。
• 结论表达：所有对外或对内输出的评测内容，若存在商业合作性质，应按相应平台规则如实披露；报告中对未核实的信息应明确标注“待核实”，避免把推测当结论。

十一、总结

本教程的核心思路是：把“模型好不好”拆成四类可独立测量的偏差——效果归因、任务难度口径、事实性口径、成本与配额，再用隔离沙箱、双组对照、工具调用溯源、幻觉核查闭环和三层成本对账把它们分别量化。

关键动作回顾：先定指标口径，再搭沙箱，再用自带验收标准的任务集跑纯净组与完整组，最后做成本对账与额度治理，产出可复现报告。

后续可以继续深化的方向包括：把评测流水线接入 CI 做模型版本回归门禁、用真实工单持续扩充业务抽样集、以及把单位有效成本纳入技术选型的常态看板。