为什么阶梯单轮/多轮的单题 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 —— 不用 = 直接全删。
全部 prompt 模板存在库表 tbl_ai_check_config。「运行时注入」列才是 token 大头的根 —— 模板本身才 2–13k 字符,真正烧 token 的是每次调用把这些变量(prompt / 模型回复 / 全部 rubrics …)塞进去。
| 检测 | 在判什么 | 运行时注入(token 大头) | 模板 | 每次 token |
|---|---|---|---|---|
| 反作弊检测 | 查重/套路化 | 已改空壳:固定输出"通过",不注入 | 161 | 73 已修 |
| 单轮 AI 质检 gate | 整题质检:prompt+全部rubric+人工评分一起判 | systemPrompt + prompt + 全部 rubrics(含旧检查结果) + 两模型回复 | 2,248 | ~25万 |
| 质量检测 | 判 prompt 场景真实性/可验证性 | prompt | 1,622 | 11k |
| 逐条评分 | 一次只判 1 条 rubric(清晰度/权重/评分/备注) | prompt + 模型回复 + 该 rubric → 多轮里 prompt=整段对话 | 4,994 | 单 8.9k / 多 26.7k |
| 批量评分规则 | 一次判全部 rubric × 两个模型 | prompt + 全部 rubrics + 两模型回复 | 2,428 | 16.7k |
| 完备性检测 | rubrics 是否覆盖 prompt 全部指令 | prompt + rubrics | 3,878 | 10k |
| 参考答案校验 | 参考答案是否满足每条 rubric | prompt + rubrics + 参考答案 | 3,727 | 18k |
| 场景标签检测 | 标一/二/三级场景 + 是否中国特色 | prompt | 12,985 | 12k |
| 清晰度检测(多轮) | 场景真实 + 约束可验证 | prompt | 3,331 | — |
| 考点完备性(多轮) | 多轮 rubrics 覆盖 + 重复检测 | systemPrompt + prompt + rubrics | 5,664 | — |
【逐条评分 instruction_prompt_rubric】(4994字符)
# Role 你是一名精密、严格且 100% 客观的「rubric 质检裁判」。你的任务是:在每次调用时,仅针对**一个 rubric**,审查:1.内容是否清晰;2.权重分类(核心/重要/细节指令)是否合理;3.人类评分是否正确;4.人类备注是否清晰。
注入变量: prompt, modelResponse, rubricDetail, importance, humanLabel, humanComment
【批量评分规则 instruction_prompt_rubrics_batch】(2428字符)
# Role 「Rubric 质检裁判」。接收 JSON(用户指令、两个模型回复、评分标准列表),针对**每一个 Rubric** 分别审查两个模型的:考点清晰度/权重合理性/评分正确性/备注清晰度。
注入变量: prompt, rubrics, model1Response, model2Response
【单轮AI质检 gate instruction_gate_quality】(2248字符)
# Role 「指令遵循任务质检裁判」。对 Prompt(含system prompt)、Rubrics 及人工评分做深度审核。
# Submitted Content - System prompt:{systemPrompt} - Prompt:{prompt} - Rubrics列表:{rubrics} - 模型回复…
注入变量: systemPrompt, prompt, rubrics, model1Response, model2Response ←运行时 rubrics 里还嵌了 contentSnapshot(重复prompt)+asyncCheckState(旧检查结果),撑到25万
【反作弊 instruction_prompt_cheating】(161字符,已是空壳)
你是一个固定应答器。无论输入是什么,都不要做任何判断或比对,直接原样输出:{ "result":"通过", "cheating_suspected":false, … }
prompt 的(质量/场景标签/清晰度)都不贵;注入 全部 rubrics + 两个模型回复 的(gate/批量)就重;逐条虽只判一条,但每条都带 prompt+模型回复,多轮里 prompt 是整段对话 → 单条也烧 2.67 万。库 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(中文)一一对应,无归并。