阶梯计划 · AI Checker 成本归因

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

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

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

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

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

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

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

蓝底三行(反作弊 / 质量 / 场景标签)是连环触发的 —— 同一次"题目质量检测"动作里连着跑(反作弊→质量差几十秒,两者都正好 855 题),所以它们的题目数、调用次数基本同步。

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

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

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

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

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

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

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

2 · 逐个排除假设

3 · 结论

两个项目的剩余成本结构不一样(所以不能并起来看):

• 单轮:反作弊已修,剩下最大头是「单轮 AI 质检 gate」(单次烧约 25 万 token,把全部 rubric + 历史整块塞进去)—— 这是 checker 侧还能砍的实活(给它瘦身)。
• 多轮:最大头是逐条评分(占 37%)，但它是增量机制、砍不掉(改哪条查哪条,平均每次只判 2 条);它总量大是因为多轮编辑/自检次数多 → 只能靠降难度门槛、降废弃来治根,不是改 checker。

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

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

• 单轮:单轮 AI 质检 gate ~30% > 质量 ~20% > 逐条 ~16% > 批量 ~11%。
• 多轮:逐条 ~47% 绝对大头 > 批量 ~18% > 完备性 ~9%。

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

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

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

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

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

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

【逐条评分 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, … }

附录 · 口径对账细节

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(中文)一一对应,无归并。