阶梯计划 · AI Checker 成本归因

为什么阶梯单轮/多轮的单题 API 成本全平台最高 —— 假设逐个排除 + 三方口径对账 · 2026-06-27

数据源:insight 分析库(直连实测) · 看板 insight.humanlaya.com/dashboard/settlement & project-report · 题目前端 talents-ai.com/admin/items · 所有数字均连库复现,关键项三方对拍。

0 · 全部 checker 清单(以前端为准 · 确定数)

口径只有一套:以专家/质检在题目前端页看到的为准,每个 checker 标【✅前端可见】或【🔒背后跑】。

每题成本拆解(周期口径 = 看板「完成口径/题」)

项目API/题其中 checker其中 模型反作弊(单块)去反作弊后
阶梯单轮 131¥684¥559 (82%)¥125 (18%)¥291¥393
阶梯多轮 133¥296¥268 (90%)¥28 (10%)¥56¥240
单轮比多轮贵 ¥388/题(¥684−¥296),拆成两块:
反作弊占 ¥235(单轮 ¥291 vs 多轮 ¥56)—— 差距的大头,已 6/26 修;
② 修完后还差 ¥153(单轮跑模型多花 ¥97 + 其他 checker 多花 ¥56)。
反作弊是"单轮贵"的最大原因;修完后差距从 ¥388 缩到 ¥153,单轮仍略贵但不悬殊。不存在"多轮更费"。两边都是 ~82–90% 是 checker、跑模型只 10–18%。

每题的钱花在哪个 checker(单轮 / 多轮各一张)

下面是单轮 131 实跑的全部 checker(确定数,非约等于):

前端看到的检测库 check_type调用次数题目数平均/题token占比前端
反作弊检测 已修cheating10,63285512.452.3%可见
质量检测v3sp_mod_quality12,68485514.89.6%可见
场景标签检测v3sp_tag5,1437207.14.7%可见
单轮 AI 质检 gategate_quality9872633.814.1%可见
批量评分规则rubrics_batch3,2634357.55.3%可见
参考答案校验reference1,5003364.52.1%可见
完备性检测coverage1,7764064.41.4%可见
指令拆分v3sp_mod_split2,2645604.02.7%可见
逐条评分rubric10,31430234.27.8%🔒背后跑

蓝底两行(反作弊 + 质量)是成对触发——同一次"题目质量检测"里连着跑(差几十秒、都正好 855 题)。场景标签是独立触发(720 题、7 次/题,比那两个少),不在这对里。

下面是多轮 133 实跑的全部 checker(确定数):

前端看到的检测库 check_type调用次数题目数平均/题token占比前端
逐条评分rubric10,88428837.836.7%🔒背后跑
反作弊检测 已修cheating1,8444424.222.2%可见
清晰度检测clarity1,8644424.25.8%可见
批量评分规则rubrics_batch3,4953529.913.8%可见
考点完备性multichatv2_coverage1,9333295.97.3%可见
参考答案校验reference1,4843084.86.4%可见
指令拆分multichatv2_mod_split9104042.33.4%可见
多轮 AI 质检 gatelabeling_gate_quality307545.72.5%可见
场景标签检测v3sp_tag1,2754083.11.7%可见

多轮里成对触发的是反作弊 + 清晰度(都正好 442 题)—— 多轮用"清晰度"代替单轮的"质量"。

只有「逐条评分」前端看不到 —— 它在后台按"每条 rubric 一次"增量跑(改哪条查哪条),所以专家/质检页里不单列,但照样调模型、照样烧 token。其余前端流程里都看得到。多轮里逐条占 36.7%(单轮 7.8%):因为多轮判一条 rubric 也要把整段对话当上下文,每次 2.67 万 token(单轮 8.9k)—— 这是 §6 配置表里"逐条注入 prompt+模型回复"的体现,但它只说明多轮自己内部逐条最重,不代表多轮总成本高于单轮(见顶部:单轮始终更贵)。

看板「PE节点质量」只显示其中有"通过/否"判定的那几个(更少),那是看板自己的过滤,不代表只有那几个在跑。多轮 133 同理,其逐条评分占 36.7%(见 §4)。

三方对拍(已验):题 76755 反作弊 = 库 11 = 前端 ~11 ✅;质量检测 = 库 12 = 前端 ~12 ✅。题 76625:6/18 = 25 反作弊 + 25 质量(前端拉到底可数到)。看板单题 API ¥684.38 = 库复现 ¥684.38、付费完成 45 = 库 45 ✅。

1 · 现象:阶梯单题 API 全平台最高

¥684
单轮 131 · API/完成题
¥296
多轮 133 · API/完成题
¥6–87
小龙虾 / Excel 对比
82–90%
API 里是 checker(非跑模型)
项目每次 checker token每完成题调用次数API/完成题废弃率
阶梯单轮 13126k115¥68494%
阶梯多轮 13332k84¥29693%
Excel大师3期 9720k41¥8785%
小龙虾一期 1286k207¥6092%
小龙虾二期 1392k45¥692%

口径:API/完成题 = 结算周期内项目全部 API ÷ 付费完成数(看板「完成口径/题」同源,已复现到分);token/次 = 该项目 checker 调用平均 total_tokens;调用次数/完成题 = 该状态题的 checker 调用 ÷ 题数。

单轮始终比多轮贵(¥684 vs ¥296,去反作弊 ¥393 vs ¥240,见顶部拆解)。这里的"每次 token / 调用次数"是横向对比 —— 阶梯每次 token 重(26–32k)是主因。

2 · 逐个排除假设

H1 · 是 AI checker 数量太多吗?
不是
阶梯有效 checker(≥100 次)9 个,但小龙虾一期也 9 个、Excel3 期 7 个。数量不是阶梯独有的问题。
H2 · 是专家每题跑的次数特别多吗?
不是
每完成题调用次数:阶梯 84–115,而小龙虾一期 207 反而更高,Excel 仅 22–41。阶梯在"次数"上并不突出。
H3 · 是每次调用的 token 太重吗?
是 · 主因
每次 checker:阶梯 26–32k、Excel 20k、小龙虾 2–6k(差 4–13 倍)。根源:阶梯每题平均 17–19 条 rubric(最多 100+),多轮还带 22 轮对话,每次检查都把整段 prompt + 全部 rubric / 历史塞进去。这是任务复杂度决定的,砍不掉;能砍的是"每次别全量塞"。
H4 · 是废弃率高、分母小把单题口径抬高了吗?
是 · 次因
单题成本 = 总 API ÷ 完成题。阶梯 71%(单轮)/69%(多轮)的 checker token 烧在最终废弃的题上,而完成的题极少(完成率仅 2–22%)→ 分母小、口径被抬高。
H5 · 是某几个题 / 某几个专家大量刷出来的吗?
不是
调用不集中:最烧的 10 道题只占全部调用 9%;按账号看没有人超 3%;摊在 121 个出题人身上。不是少数坏人/恶意刷。
H6 · 重跑多 = 返修来回的死亡螺旋吗?
不是(数据推翻)
按调用量分档(单轮 131):
题数均调用均返修打回完成率
低 <50 次562150.12%
中 50–149193850.815%
高 150+ 次1002401.619%
高调用题(240 次)平均只被打回 1.6 次(多轮 2.2),根本不是返修螺旋。那些调用主要是标注阶段反复自检(改一版点一次检测)。而且调用越多、完成率反而越高(19% vs 2%)—— 是认真磨,不是被来回打回。
H7 · 反作弊(查重)是头号烧钱项吗?
曾是 · 已修复
历史上反作弊占单轮 checker token 52%(累计 6 亿 token,每次塞历史 prompt)。6/26 PE 改动后,每次 token 从 2 万–20 万骤降到 73(连库按天证实)→ 这刀已经砍完,往后基本不烧。

3 · 结论

阶梯 API 贵 = 题本身复杂(每次 token 大)× 废弃率高(分母小)。
不是 checker 数量多、不是专家跑太多轮、不是有人恶意刷、不是返修死亡螺旋。
查重(反作弊)曾是最大单项,但已于 6/26 修复

为什么贵,单轮 / 多轮分开看(原因不一样):

4 · 去掉反作弊后,往后大头是谁

反作弊已修,看"剩下"的成本结构(各 checker 明细表见顶部 §0):

5 · 改进方案(按 ROI 排序)

#问题解法难易
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、多轮长上下文)砍不动,接受 —— 别在这浪费力气不动

6 · gate_quality 瘦身方案(实锤,可直接提研发)

「单轮 AI 质检 gate」每次输入约 41 万 token(单次最贵)。解剖一条真实输入(59.97 万字符):

组成占比能不能砍
真正要判的考点正文(rubricDetail)~0.3%必留
整段题目 prompt 被重复嵌 48 次(每条 rubric 的 contentSnapshot 各带一份全文,每份 ~5.7k 字符)~大头砍47份留1份
之前"逐条评分"的完整结果(每条 rubric 的 asyncCheckState:模型一/二 × 各项判定理由,共 197 段)~大头删/只留结论
元数据(checkTime / requestTime / batchId / aiCheckPassed…)零散
结论:砍掉重复 prompt + 旧检查结果两坨,保守省 70–80%+ token(41 万 → 几万),考点正文一字不动、判断质量不受影响。

给研发的提法:contentSnapshot 的 prompt 全文只保留一份全局;② 去掉 asyncCheckState(旧逐条结果)或只留结论不留理由;③ 去掉无关元数据。需研发确认一点:gate 判断时是否真用到 asyncCheckState —— 不用 = 直接全删。

范围:单轮 gate 和多轮 gate 都有这个重复(单轮 538 次 × ~31 份重复;多轮 51 次 × ~17 份,每次更大但跑得少)。batch / 逐条 / 完备性都干净(0 重复)。瘦身对单轮收益更大(gate 单轮占 14% token、多轮只 2.5%)。
实例 · 单轮题 76407:一次 gate 输入 65 万字符,题目「某项能力验证…"霉菌和酵母计数"结果汇总…」在同一次输入里出现 62 次(本应 1 次)—— 这题 ~15 条 rubric,每条都附了一份完整题目快照。
根因(已查代码,可证):contentSnapshot 本是"内容没改就别重复检测"的去重快照(存每条 rubric 上);gate 拼 prompt 时把整条 rubric(含快照 + 旧结果 asyncCheckState)整个序列化进去了,所以题目被复制几十遍。修法:拼 gate prompt 时剥掉这两个字段,只留 rubricDetail,rubric 正文不动。代码:v3_sp_mod/(单轮)、multichatv2_mod/(多轮)。

7 · 每个 checker 怎么配置的(prompt 模板)

全部 prompt 模板存在库表 tbl_ai_check_config「运行时注入」列才是 token 大头的根 —— 模板本身才 2–13k 字符,真正烧 token 的是每次调用把这些变量(prompt / 模型回复 / 全部 rubrics …)塞进去。

检测在判什么运行时注入(token 大头)模板每次 token
反作弊检测查重/套路化已改空壳:固定输出"通过",不注入16173 已修
单轮 AI 质检 gate整题质检:prompt+全部rubric+人工评分一起判systemPrompt + prompt + 全部 rubrics(含旧检查结果) + 两模型回复2,248~25万
质量检测判 prompt 场景真实性/可验证性prompt1,62211k
逐条评分一次只判 1 条 rubric(清晰度/权重/评分/备注)prompt + 模型回复 + 该 rubric → 多轮里 prompt=整段对话4,994单 8.9k / 多 26.7k
批量评分规则一次判全部 rubric × 两个模型prompt + 全部 rubrics + 两模型回复2,42816.7k
完备性检测rubrics 是否覆盖 prompt 全部指令prompt + rubrics3,87810k
参考答案校验参考答案是否满足每条 rubricprompt + rubrics + 参考答案3,72718k
场景标签检测标一/二/三级场景 + 是否中国特色prompt12,98512k
清晰度检测(多轮)场景真实 + 约束可验证prompt3,331
考点完备性(多轮)多轮 rubrics 覆盖 + 重复检测systemPrompt + prompt + rubrics5,664
展开 · 4 个关键模板原文(开头)
【逐条评分 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, … }
读这张表的方法:token 贵不贵看「运行时注入」——只注入 prompt 的(质量/场景标签/清晰度)都不贵;注入 全部 rubrics + 两个模型回复 的(gate/批量)就重;逐条虽只判一条,但每条都带 prompt+模型回复,多轮里 prompt 是整段对话 → 单条也烧 2.67 万。

8 · 待办(To-Do)+ 预期压到多少

动作状态省什么
① 查重(反作弊)从模板下掉6/26 已改空壳,下周从模板移除反作弊不再跑;它和"质量"绑在同一检测动作,下掉后这块也解耦
② 单轮 AI 质检(gate)不重复 prompt 快照待研发(改拼 prompt 的序列化,rubric 不动)gate 单次从 ~25 万 token 降一大截

预期(反作弊 + 质检 两项调整后,每完成题 API):

附录 · 口径对账细节

A. 库 vs 前端为什么数字不同

tbl_rubric_ai_check_log每一次模型调用流水(含跨天的反复自检、子检查);前端是清理/分页后的视图,且逐条评分不单列。例:76625 从 6/8 改到 6/18 共 3 天,质量检测 70 次、逐条 152 次 —— 都是不同分钟的独立调用,非重复;前端拉到底可对上节点类(反作弊/质量/批量等)。

B. 反作弊"0 token"是什么

全 131 反作弊 1.06 万次调用中:33% 是 0 token(该题没有历史可比对 = 无需检测,直接返回),67% 烧几万~69 万 token(注入历史比对)。所以它忽烧忽不烧是真实的,不是数据错;6/26 改动后整体降到 73 token/次。

C. 节点 vs 子检查判定

依据 dwd_pe_gate_log_detail.display_status:产出 passed/failed 的 = 看板节点;只产 completed 的 = 子检查(逐条评分、场景标签、指令拆分)。check_type ↔ check_name(中文)一一对应,无归并。