建立可信的模型与 Agent 评测

理解这条链路

先拆测试类型

mock 验证采集、计时和评分代码；确定性故障注入验证控制规则；真实模型推理验证特定输入下的模型；真人电话才验证实际交互。每条 raw 记录带 data_kind、模型版本和运行配置，不把这些样本混在同一排行榜里。

比总分更重要的两张表

一张是失败类型表：事实错误、漏调工具、越权动作、超时、空结果；另一张是配对变化表：同一题旧版失败新版成功、旧版成功新版失败。LLM Judge 要对照人工金标并盲化候选名称；按用户或通话聚类估计不确定性，避免把重复轮次当独立样本。

按这个顺序操作

1. 定义业务成功、不可接受错误与时间限制，再冻结测试集和归一化规则。
2. 用空输出、多余调用、错误参数、越权操作等反例先测试评分器。
3. 在相同输入、版本与预算下运行候选，保留所有失败和原始事件。
4. 复核新增退化案例，只有关键门禁通过才做有限发布。

可直接复用的记录模板

run_id / task_id / source_group / data_kind：
model_snapshot / prompt_hash / tool_schema_hash：
expected_final_state / observed_final_state：
critical_error / timeout / empty_output：
judge_version / human_label / paired_baseline：
禁止将 mock、合成音频和真人电话混成一个准确率。

做到什么程度才算通过

• 评分器反例会被正确判失败。
• 所有请求都进入明确分母。
• 真实与模拟数据可单独筛选。
• 结论包含关键错误、配对差异及样本限制。

本轮确认的事实与来源

以下为公开资料支持的具体结论；操作流程和验收建议属于工程推导。仓库说明或厂商效果表述不等于独立实测。

这次更新了什么

合并可信评测和千问实战；旧版综合分、模拟模型名偏差和小样本榜单不再用于选型。

接着解决下一个问题