为什么阶梯单轮/多轮的单题 API 成本全平台最高 —— 假设逐个排除 + 三方口径对账 · 2026-06-27
数据源:insight 分析库(直连实测) · 看板 insight.humanlaya.com/dashboard/settlement & project-report · 题目前端 talents-ai.com/admin/items · 所有数字均连库复现,关键项三方对拍。
口径只有一套:以专家/质检在题目前端页看到的为准,每个 checker 标【✅前端可见】或【🔒背后跑】。下面是单轮 131 实跑的全部 checker(确定数,非约等于):
| 前端看到的检测 | 库 check_type | 调用次数 | token占比 | 前端 |
|---|---|---|---|---|
| 反作弊检测 已修,现73/次 | cheating | 10,632 | 52.3% | 可见 |
| 单轮 AI 质检 gate | gate_quality | 986 | 14.1% | 可见 |
| 质量检测 | v3sp_mod_quality | 12,684 | 9.6% | 可见 |
| 批量评分规则 | rubrics_batch | 3,256 | 5.3% | 可见 |
| 场景标签检测 | v3sp_tag | 5,143 | 4.7% | 可见 |
| 指令拆分 | v3sp_mod_split | 2,264 | 2.7% | 可见 |
| 参考答案校验 | reference | 1,498 | 2.1% | 可见 |
| 完备性检测 | coverage | 1,773 | 1.4% | 可见 |
| 逐条评分 | rubric | 10,302 | 7.8% | 🔒背后跑 |
只有「逐条评分」前端看不到 —— 它在后台按"每条 rubric 一次"增量跑(改哪条查哪条),所以专家/质检页里不单列,但照样调模型、照样烧 token。其余 8 个前端流程里都看得到。
看板「PE节点质量」只显示其中有"通过/否"判定的那几个(更少),那是看板自己的过滤,不代表只有那几个在跑。多轮 133 同理,其逐条评分占 36.7%(见 §4)。
| 项目 | 每次 checker token | 每完成题调用次数 | API/完成题 | 废弃率 |
|---|---|---|---|---|
| 阶梯单轮 131 | 26k | 115 | ¥684 | 94% |
| 阶梯多轮 133 | 32k | 84 | ¥296 | 93% |
| Excel大师3期 97 | 20k | 41 | ¥87 | 85% |
| 小龙虾一期 128 | 6k | 207 | ¥60 | 92% |
| 小龙虾二期 139 | 2k | 45 | ¥6 | 92% |
口径:API/完成题 = 结算周期内项目全部 API ÷ 付费完成数(看板「完成口径/题」同源,已复现到分);token/次 = 该项目 checker 调用平均 total_tokens;调用次数/完成题 = 该状态题的 checker 调用 ÷ 题数。
| 档 | 题数 | 均调用 | 均返修打回 | 完成率 |
|---|---|---|---|---|
| 低 <50 次 | 562 | 15 | 0.1 | 2% |
| 中 50–149 | 193 | 85 | 0.8 | 15% |
| 高 150+ 次 | 100 | 240 | 1.6 | 19% |
两个项目的剩余成本结构不一样(所以不能并起来看):
token 占比 = 该项目 checker 累计 total_tokens 占比(历史口径;反作弊那块是 6/26 修复前的账)。"节点"= 看板有判定 / "子检查"= 无判定、UI 不单列。
| 检测(UI 中文名) | 类型 | 调用次数 | token 占比 |
|---|---|---|---|
| 反作弊检测 已修,现 73/次 | 节点 | 10,632 | 52.3% |
| 单轮 AI 质检 gate | 节点 | 986 | 14.1% |
| 质量检测 | 节点 | 12,684 | 9.6% |
| 逐条评分 | 子检查 | 10,302 | 7.8% |
| 批量评分规则 | 节点 | 3,256 | 5.3% |
| 场景标签检测 | 子检查 | 5,143 | 4.7% |
| 指令拆分 | 子检查 | 2,264 | 2.7% |
| 参考答案校验 | 节点 | 1,498 | 2.1% |
| 完备性检测 | 节点 | 1,773 | 1.4% |
去掉已修的反作弊后,往后大头:单轮 AI 质检 gate ~30% > 质量 ~20% > 逐条 ~16% > 批量 ~11%。
| 检测 | 类型 | 调用次数 | token 占比 |
|---|---|---|---|
| 逐条评分 | 子检查 | 10,839 | 36.7% |
| 反作弊检测 已修 | 节点 | 1,843 | 22.2% |
| 批量评分规则 | 节点 | 3,492 | 13.8% |
| 考点完备性 | 节点 | 1,930 | 7.3% |
| 参考答案校验 | 节点 | 1,481 | 6.4% |
| 清晰度检测 | 节点 | 1,862 | 5.8% |
| 指令拆分(多轮) | 子检查 | 910 | 3.4% |
| 多轮 AI 质检 gate | 节点 | 307 | 2.5% |
| 场景标签检测 | 子检查 | 1,274 | 1.7% |
去掉已修的反作弊后:逐条 ~47% 绝对大头 > 批量 ~18% > 完备性 ~9%。
| # | 问题 | 解法 | 难易 |
|---|---|---|---|
| 1 | 反作弊每次塞历史、烧几万 token,占单轮 52%,且对"难度/AI生成"没用 | 已修(6/26) → 每次 73 token | 已完成 |
| 2 | 单轮 AI 质检 gate 单次 ~25 万 token(全量塞 rubric + 历史) | 瘦身:只带相关 rubric 段 / 去掉冗余历史快照 | 中 · checker 侧可改 |
| 3 | 多轮逐条评分占 47%(增量、砍不掉),量大是因返修/自检多 | 治根:降难度门槛 + 早给"过不了"信号,减少反复磨 | 难 · 难度校准 |
| 4 | 废弃率 92–94%,API 摊到极少完成题 | 同上,废弃降→分母大→单题成本自然塌 | 难 · 根因 |
| 5 | 题本身复杂(17–19 rubric、多轮长上下文) | 砍不动,接受 —— 别在这浪费力气 | 不动 |
「单轮 AI 质检 gate」每次输入约 41 万 token(单次最贵)。解剖一条真实输入(59.97 万字符):
| 组成 | 占比 | 能不能砍 |
|---|---|---|
| 真正要判的考点正文(rubricDetail) | ~0.3% | 必留 |
整段题目 prompt 被重复嵌 48 次(每条 rubric 的 contentSnapshot 各带一份全文,每份 ~5.7k 字符) | ~大头 | 砍47份留1份 |
之前"逐条评分"的完整结果(每条 rubric 的 asyncCheckState:模型一/二 × 各项判定理由,共 197 段) | ~大头 | 删/只留结论 |
| 元数据(checkTime / requestTime / batchId / aiCheckPassed…) | 零散 | 删 |
给研发的提法:① contentSnapshot 的 prompt 全文只保留一份全局;② 去掉 asyncCheckState(旧逐条结果)或只留结论不留理由;③ 去掉无关元数据。需研发确认一点:gate 判断时是否真用到 asyncCheckState —— 不用 = 直接全删。
库 tbl_rubric_ai_check_log 记每一次模型调用流水(含跨天的反复自检、子检查);前端是清理/分页后的视图,且逐条评分不单列。例:76625 从 6/8 改到 6/18 共 3 天,质量检测 70 次、逐条 152 次 —— 都是不同分钟的独立调用,非重复;前端拉到底可对上节点类(反作弊/质量/批量等)。
全 131 反作弊 1.06 万次调用中:33% 是 0 token(该题没有历史可比对 = 无需检测,直接返回),67% 烧几万~69 万 token(注入历史比对)。所以它忽烧忽不烧是真实的,不是数据错;6/26 改动后整体降到 73 token/次。
依据 dwd_pe_gate_log_detail.display_status:产出 passed/failed 的 = 看板节点;只产 completed 的 = 子检查(逐条评分、场景标签、指令拆分)。check_type ↔ check_name(中文)一一对应,无归并。