真实项目体检 · WLE 三期(proj 150)
小龙虾三期的 Checker，判得对不对?
拿这个项目的真实数据跑一遍上一版原型 —— 结论:3 个 checker 天天判，但判定几乎不对齐人工。
● 真实数据 · 截至 2026-07-09 · 项目仍在跑
1 · 这个项目有哪些 checker
2 个判定 gate + 1 个打标签工具
wle_ref_process_checkgate
参考流程检查
1,009 次 · 218 题
判打回 66%通过 34%
判定:check_reason.passed(真/假)
wle3_all_ai_checkgate
第三期整体质检
712 次 · 183 题
返修 45%
可改后过 14%
通过 34%
5%
判定:overallConclusion(通过/需返修/…)
wle3_sp_tags_check工具 · 剔除
题目打标签
941 次 · 246 题
输出领域/用途标签 · 非判定
给题打领域标签,不算准确率
2 · 核心发现 · AI 判定 vs 人工结果
判定几乎不预测人工会不会打回
底色 = 全项目 79% 的题至少被打回一次。checker 说"通过"的题,打回率应该明显更低才对 —— 但没有。
wle3_all_ai_check · 整体质检
≈ 零信息量
AI 判通过 vs 判返修,人工打回率只差 4.6pt —— 判定基本没带信息。120 道 AI 判通过的题,93 道照样被人工打回。
wle_ref_process_check · 参考流程
倒挂 · 需排查
方向反了:AI 判「通过」的题反而被人工打回更多。要么口径反、要么在测另一个维度 —— 先排查再用。
3 · 漏放证据 · 人工打回但 checker 放过
人工在打回时点的这些问题,checker 基本没拦
从真实人工评语归类(原文含隐私,此处只出类型):
FN 类型
主任务没用够 5 个非公开工作文件
平台硬规则,人工高频打回
FN 类型
有 AI 生成 / AI 改写痕迹
文件疑似 AI 造,非真实工作流
FN 类型
参考做法 / 流程不完整、覆盖面不够
与 ref_process 该管的维度重叠,却漏了
FN 类型
真实文件未做隐私脱敏
人名 / 学校 / 学号未处理
FN 类型
模型主要错误分析不严谨 / 不完整
错误点写成格式问题,不到位
4 · 这个项目测不了的
✕ 误杀率(FP) · 生产数据拿不到
小龙虾三期的强制通过备注 expert_remarks = 0 —— 专家没有"我没错、申请通过"的留言记录,所以误杀(好题被冤枉打回)这一侧,生产信号是空的。要量这个项目的误杀率,只能走 L2 抽样标注。
⚠ 口径诚实说明:上面的"打回率"是上限口径 —— 多轮 gate 下 79% 的题本来就至少被打回一次;而且人工打回的维度未必正好是这个 checker 检查的维度。所以这是方向性诊断(判定不对齐),不是精确的漏放率。精确值要按「维度对齐 + 终态口径」算 —— 那正是 L1 记分卡要做的事。
5 · 这个项目怎么补
三步就能把小龙虾三期接进记分卡
01解析 check_reason JSON 拿判定 —— 这两个 checker 的 pass/fail 藏在 JSON(passed / overallConclusion)里,is_hit 是空的,ETL 要按 JSON 解析。
02漏放按维度对齐算 —— 拿人工打回评语的问题类型 vs 各 checker 该管的维度,对得上才算它漏放,别用"曾被打回"笼统算。
03误杀走 L2 抽样 —— 这项目没有备注信号,抽一批被 checker 判返修的题人工复核,补误杀率。
一句话
2,673 次调用、判定 ≈ 零信息量,却一直没人知道 —— 这就是"没准确率体系 = 放养"最实的一个例子。接进 记分卡,这个项目第一版就能看出来。