评测方法论
了解赢政指数 v6 如何评测 11 个 AI 大模型
v6 维度体系
v6 采用 2 核心 + 2 侧面 + 1 门槛 + 3 运营信号 的多层维度架构，取代旧版六维加权平均。
Core 核心维度（构成主榜）
可审计、可复核，构成 core_overall 综合分。
代码生成、算法实现、Debug 找错、SQL 编写、动态规划、并发分析 — 题目在 Python 沙箱中真实执行验证
长文档理解、跨段落推理、大规模信息提取 — 要求引用原文证据，引用检查 + AI 辅助判分
Side 侧维度（侧榜单独展示）
AI 辅助评估，不计入主榜 core_overall，在侧榜单独展示并标识。
技术选型、架构权衡、故障排查、利弊分析 — AI 辅助评估
摘要生成、邮件撰写、中英互译、结构化输出 — AI 辅助评估
Gate 诚信门槛
准入门槛，不是加分项。决定模型的推荐状态和分数上限。
矛盾信息识别、信息不足诚实度、利益冲突检测、压力诚信（honesty_under_pressure）— 决定准入资格
Ops 运营信号
独立展示，反映模型的实际使用体验。
综合能力得分 / API 价格，经 Sigmoid 归一化到 0-100
成功任务间分数一致性，公式 max(0, 100 - 标准差 × 2)
任务成功完成率，API 失败、超时、返回空均视为不可用
计分公式
核心综合分
| 代码执行 Execution | 权重 0.55（55%） |
|---|---|
| 材料约束 Grounding | 权重 0.45（45%） |
| 权重总和 | 1.00 |
诚信评级标签
≥ 60 → pass
40 – 59 → warn
< 40 → fail
展示分与推荐状态
if integrity_label = fail → min(core_overall_raw, 74.0)
else → core_overall_raw
pass → recommended（推荐）
warn → neutral（中性）
fail → not_recommended（不推荐）
举例：某模型 Execution 85、Grounding 72、Integrity 得分 35（fail），则 core_overall_raw = 85×0.55 + 72×0.45 = 79.15，但因 fail 封顶，core_overall_display = 74.0，标记为 not_recommended。
Integrity Gate 规则
诚信评级（Integrity）是准入门槛，不是加分项。它决定模型的推荐状态和分数上限：
| pass （≥ 60 分） | 无限制，core_overall 正常显示，标记为 recommended |
|---|---|
| warn （40-59 分） | core_overall 正常显示，但标注"诚信评级待改善"，标记为 neutral |
| fail （< 40 分） | core_overall 封顶 74 分，标记为 not_recommended |
设计思路：一个能力很强但不诚实的模型（如在压力下编造信息、回避承认不确定性），其排名不应高于诚实但能力稍弱的模型。Integrity Gate 确保诚信是底线而非可选加分。
212 题题库说明
v6 题库共 212 道题，按 report_group 分布如下：
| execution | ~87 道 — 算法实现、工程实践、Debug 找错、代码阅读理解、SQL、并发分析 |
|---|---|
| grounding | ~59 道 — 长文档理解、跨段落推理、信息提取、事实核查、引用验证 |
| judgment | ~25 道 — 技术选型、架构权衡、故障排查、利弊分析 |
| integrity | ~25 道 — 矛盾信息识别、信息不足诚实度、利益冲突检测、伦理边界 |
| communication | ~16 道 — 摘要生成、邮件撰写、翻译、结构化输出 |
| 总计 | 212 道题 |
压力诚信题 honesty_under_pressure
题库包含 12 道压力诚信题（Q201-212），属于 integrity 维度。这类题目设置了诱导场景（如用户施压要求编造数据、要求忽略风险），检测模型在压力下能否保持诚实。采用 exact_rank 判分，排序必须精确匹配。
分层随机抽样
每轮完整评测（full run）从 212 题中按 5 个分层（strata）进行分层抽样，每轮约 100 题：
| execution | ~35 题 |
|---|---|
| grounding | ~25 题 |
| judgment | ~20 题 |
| integrity | ~12 题（最低曝光保障：每轮至少 8 道，子桶覆盖要求） |
| communication | ~8 题 |
| 合计 | ~100 题 / 轮 |
- Integrity 最低曝光：每轮至少抽取 8 道 integrity 题，且需覆盖各子桶（矛盾信息、信息不足、利益冲突、压力诚信等），确保诚信评估的全面性
- context_bundle_cap = 3：同一份长文档素材在单轮评测中最多关联 3 道题，防止单一素材过度影响分数
- 分层抽样保证每轮评测的维度覆盖均匀，同时引入随机性避免模型对固定题集过拟合
判分引擎
v6 采用多种判分引擎，根据题目类型自动选择最合适的评分方式：
| sandbox | Python 沙箱真实执行 — 代码题在隔离沙箱中真实运行，用 unit test 验证输出正确性，不依赖任何 AI 评判 |
|---|---|
| grounded | 引用检查 + AI 辅助 — 长文档题要求引用原文证据，先做引用匹配检查，再由 AI 辅助判断引用的准确性和完整性 |
| exact_rank | 排序精确匹配 — 主要用于 honesty_under_pressure 压力诚信题，排序必须完全正确，0 或 100 分 |
| AI judge | 二次确认 — 当其他判分方式落入模糊区间时触发 AI 裁判进行二次确认，确保判分准确 |
| contains_all | 全部关键词命中比例，按命中率给分 |
| regex | 正则匹配，模糊区间自动触发 AI judge 二次确认 |
| json_structure | JSON 结构 + 字段值校验，检查嵌套字段 |
| 其他 | contains_any、exact、ordered_sequence、exact_boolean_set、exact_numeric_set、exact_json_value 等 |
v5 → v6 维度映射
v6 对旧版维度做了重新拆分和归类。以下是 v5 维度到 v6 的映射关系：
| v5 维度 | v6 归属 |
|---|---|
| coding 代码执行 | → 代码执行（Execution）的一部分 |
| knowledge 知识综合(旧) | → 已拆分为工程判断（Judgment）/ 诚信评级（Integrity）/ 任务表达（Communication）/ 代码执行（Execution）的可复核部分 |
| longctx 长上下文 | → 材料约束 Grounding |
| value 性价比 | → Ops 运营信号：性价比（Value） |
| stability 稳定性 | → Ops 运营信号：稳定性（Stability） |
| availability 可用性 | → Ops 运营信号：可用性（Availability） |
核心变化：旧版 knowledge 维度覆盖面过广，v6 将其拆分为四个更精确的子维度。旧版六维加权平均（coding 25% + knowledge 25% + longctx 15% + value 15% + stability 10% + availability 10%）已废弃，v6 主榜仅由 Execution 和 Grounding 两个可审计维度决定。
审计声明
主榜核心分以可复核题为主；代码题真跑，结构化题 strict judge，长文档题要求引用原文证据。侧榜含 AI 辅助评估，会单独标识。
- Execution 题：在 Python 沙箱中真实执行，用 unit test 验证，判分结果可复现
- Grounding 题：引用检查 + AI 辅助，长文档题要求引用原文段落作为证据
- Integrity 题：压力诚信题采用 exact_rank 精确匹配，其余用结构化判分
- Judgment / Communication 题：AI 辅助评估，在侧榜展示时会明确标识"AI 辅助判分"
评测频率
- 每日凌晨：轻量评测 smoke，各维度少量抽题快速检测
- 每周一深夜启动完整评测，通常次日凌晨完成：完整评测 full，从 212 题中分层抽样约 100 题
- 评测完成后自动生成变化报告
滚动均值排名
排行榜上的分数是最近 5 次同版本完整评测的滚动算术平均，而非单次评测分数。
- 为什么用均值？ 单次评测因抽样随机性、网络波动等因素会有噪声。取多次平均可以消除偶然波动，让排名更稳定、更能反映模型真实水平。
- 窗口大小：最近 5 次同评分引擎版本的完整评测。跨版本（如 v5→v6）的 run 不混入计算。
- 数据积累期：新版本上线初期不足 5 次评测时，用已有全部数据计算均值，并标注"数据积累中"。
- 异常检测：如果某次评测的分数偏离滚动均值超过 1 个标准差，排行榜会标注"本期异常偏高/偏低"。超过 2 个标准差的变化会触发事故检测。
评测系统版本
| 公式版本 | v7 — 综合分权重公式版本（formula_version） |
|---|---|
| 判分器版本 | v6 — 自动评判规则集版本（judge_version） |
| 题库版本 | v6 — 题库规模与内容版本（benchmark_version） |
三条版本线独立演进：公式版本追踪权重调整，判分器版本追踪评分规则变化，题库版本追踪题目数量与内容变化。版本号记录在每次 run 中，确保同一版本下的评测结果可比。版本变更会在更新日志中记录。
版本锁定策略
- 每个模型在 config.php 中记录固定的 ai_model 字段作为版本标识
- 带日期后缀的模型直接锁定到该快照版本
- 不带日期的模型使用厂商最新版本，评测结果反映当前线上表现
- 当厂商发布重大更新时，人工审核后更新版本号，确保评测对象一致
- 版本变更会在更新日志中记录
当前各模型版本：
| Claude Opus 4.6 | claude-opus-4-20250514 |
|---|---|
| Claude Sonnet 4.6 | claude-sonnet-4-6-20250514 |
| GPT-4o | gpt-4o |
| GPT-o3 | o3 |
| Grok 3 | grok-3 |
| Gemini 2.5 Pro | gemini-2.5-pro |
| DeepSeek V3 | deepseek-chat |
| DeepSeek R1 | deepseek-reasoner |
| Qwen Max | qwen-max |
| 豆包 Pro | doubao-seed-2-0-pro-260215 |
| 文心一言 4.0 | ernie-4.0-8k |
数据完整性规则
- 跨 run 数据不可拼接：每个模型的成绩必须来自同一次评测（同一个 run_id），不得从其他 run 复制分数填补缺失
- API 不可用时标注缺席：若模型因 API 额度耗尽、服务宕机等原因无法完成评测，该期标注"未参与评测"而非填入历史数据
- 评测环境一致性：同一 run 内所有模型在相同时间窗口、相同题目集、相同评分规则下评测，确保横向可比
- 缺席模型不参与排名：未完成评测的模型不计入当期排名，排行榜仅展示实际参与评测的模型
当前评测模型（11 个）
| 模型 | Claude Opus 4.6、Claude Sonnet 4.6、GPT-4o、GPT-o3、Grok 3、Gemini 2.5 Pro、DeepSeek V3、DeepSeek R1、Qwen Max、豆包 Pro、文心一言 4.0 |
|---|