Jyotisha/docs/tasks/TASK-rectification-jev-intent-classifier-research-fix2-20260919.md

TASK · Jev 意图分类研究修复单 2：把已跑未报的数字补进报告（2026-09-19）

• 基线：origin/staging @ eb8f5147（含 c2ecbc74 修复轮）
• 原单：TASK-rectification-jev-intent-classifier-research-20260919.md；修复单 1：TASK-rectification-jev-intent-classifier-research-fix-20260919.md
• 分支：codex/rectification-jev-intent-research-fix2-20260919（从 origin/staging 新建）
• 性质：报告补漏；不重造语料、不重跑 Jev、不改线上代码、不立 BUG。除 F1 第 3 条外全部可离线从 .cache/jev_intent/ 出，不消耗 token。

1. 修复轮验收结论（对照修复单 1 逐条）

项	结论	证据（验收方在 origin/staging @ eb8f5147 独立重算）
红线 1 · 不改线上	通过	git diff --stat d6fc4fb8..c2ecbc74 只有 scripts/research/**、tests/test_jev_intent_research.py、docs/**、BLOCKED.md
红线 2 · key 不进仓库	通过	全仓 grep 无 token；脚本只读环境变量
红线 3 · 真实消息不提交	通过	报告 JSON 里 "source": "B" 0 行，只有聚合数；.cache/jev_intent/ 不在仓库
红线 4 · sha256 固化	通过	三份 sha256 与提交文件实算一致；报告 meta.sha256 同值；id_check_ok = true，rows 的 C 类 id 集合与 simulated.jsonl 完全相等
红线 5 · 快速门	通过（Python 定向）/ 环境缺口	python3 -m unittest tests.test_jev_intent_research：11 passed；本机无 .venv，run_quality_gate.py --profile quick 未跑
红线 6 · 真实模型生成与复核	通过	complete_chat 走 DeepSeek Chat Completions；GENERATOR_NAME / REVIEWER_NAME = deepseek-flash；README 有生成 / 复核提示原文；review_sample 无正则；源码无 bank = {
红线 7 · 语料三项统计	通过	去重 825 / 900、单条最多重复 5、八种人设最少 48（点选+采集）、惜字如金+方言 = 20.0%（≤ 20% 的边界值）、长度 P25 / 中位 / P75 = 16 / 20 / 24（P25 落在 8–16 的上沿）
红线 8 · 现行对照全量	通过	来源 C 现行 400 / 400 / 100 全量一次，第二次 133 / 133 / 33
F1 语料重造	通过	争议率 2.85%（36 / 1261），三层 400 / 400 / 100，配额偏差 ≤ 4.5%
F2 重跑 T2	通过	Jev×2、现行×1 + 1/3；unavailable = 0；报告表内每个数字与我从 rows 重算一致
F3 报告	部分未通过	结论「缺数据」成立；但 §2 列出的已跑未报数字缺席
F4 来源 B	部分未通过	157 条人工标注、Jev×2、现行×1 都跑了；现行在来源 B 上的准确率没有出现在任何文件里；T3 要求「写明差在哪一类标签」只写到层，没到标签
F5 记录	通过	PROGRESS 修复轮段、BLOCKED 三条划掉、README 状态行、token 分列齐全

结论「缺数据」采纳，产品不据此上线。 未通过项只影响「下一步该补什么」的判断，不影响本轮结论。

2. 事故实证

2.1 现行模型在来源 B 上跑了、没报（P1）

• scripts/research/jev_intent_probe.py main()：if source_b: run_batch(source_b, …, run_id="current_1", call_fn=call_current_retry) —— 现行模型确实在 157 条真人样本上跑了一次；PROGRESS token 表也计了「B 一次」。
• 报告 JSON metrics 只有 source_b / source_b_by_layer 两项，且全是 jev_1 的数；没有 current 在来源 B 上的任何聚合。MD、PROGRESS 同样没有。
• 后果：无焦点层 Jev 78.8%（26 / 33）是「Jev 不行」还是「这 33 条本身难 / 标注有争议」，现在无法判断；而这是真人 + 人工标注 + 线上模型三者齐备的唯一一组数，也是产品下一步决策最需要的数。

2.2 来源 B 上 Jev 的高置信错误没进报告（P1）

报告 JSON 里已有、MD 没写的数：

来源 B（Jev）	全集 n=157	点选 n=17	采集 n=107	无焦点 n=33
intent 准确率	91.1%	94.1%	94.4%	78.8%
三题全对	81.5%	82.4%	89.7%	54.5%
高置信错误率（≥0.8 且错）	6.4%	0.0%	5.6%	12.1%
低置信召回	24.1%	66.7%	18.2%	20.0%
dated 准确率	91.7%	88.2%	97.2%	75.8%

高置信错误的绝对门槛是 ≤ 3%；真人样本上全集 6.4%、无焦点 12.1%，比来源 C 的 0–2.8% 差得多。这是比「层差 17.2pp」更直接的不可接证据，报告必须写。

2.3 无焦点层差在哪一类标签没写（P2，原单 T3 明文要求）

原单 T3：「报告必须写明差在哪一类标签」。现报告只到层。来源 B 无焦点层 7 条错，gold 与 Jev 各是什么、是否集中在 provide_new_evidence ↔ unclear，要按标签给混淆表（只给计数，不给原文）。

2.4 复核模型 = 对照模型 + 复核提示 ≈ 生产提示（P2，方法学限制，写进报告即可）

• REVIEW_RUBRIC（jev_intent_corpus_build.py）与生产 COLLECT_INSTRUCTIONS 逐句对应：「没有/没发生/这方面没什么 → no」「记不清/…/以后再说 → unsure」「不要把「没有」或「记不清」标成 yes」「不要按 A/B/C/D 位置猜」「既明确否定又补充新经历 → answer_current_focus + no」。
• 复核与对照都是 deepseek-flash。于是进入 simulated.jsonl 的 900 条，是「Flash 用近生产提示能答对目标标签」的那 900 条；被剔的 36 条恰是 Flash 不同意的。
• 后果：现行模型在来源 C 上的 97.5% / 98.8% / 94.0% 是构造出来的上界，「采集层 Jev 92.2% 未过相对门槛 94.5%」不能当作 Jev 输给现行的证据。修复单 1 允许同一模型生成 + 复核，但没预见复核提示与对照提示同源；本单不要求换模型重复核（产品未拍板再花 token），只要求报告写明这条限制并把相对门槛那一行标「不可判」。

2.5 Jev 采集层 31 条 intent 错例里有标签争议（P2，写进错例画像即可）

验收方逐条看了 Jev 在采集层的 intent 错例（gold → Jev）：provide_new_evidence → answer_current_focus 17 条、unclear → answer_current_focus 9 条、stop → unclear 4 条、ask → unclear 1 条。

• 17 条 pne 错例几乎全是「另外 2019 年我换工作搬了家」句式；其中若干条尾句直接落在当前题域（例：题问感情，答「…感情那会儿真没细想」；题问工作，答「工作那摊子反而没顾上细想」），按生产提示读是 answer_current_focus + unsure，Jev 的判法有依据。
• 9 条 unclear 错例的句子是「一时半会儿真捋不明白」「这事我一时真说不上来」，按生产提示「记不清/想不起来 → unsure」读也是 answer_current_focus + unsure；现行模型自己也在其中 3 条上判了 answer_current_focus。
• 这两类合计 ≥ 20 条，占 Jev 采集层 intent 错例的 2/3。它们的 gold 由「生成目标 + Flash 复核同意」得来，不等于人工真值。

2.6 语料像真人的程度（观察项，不判失败）

修复单 1 只把长度和人设写成硬红线，三项都过；原单 T0 还要求按来源 B 的标点 / 语气词比例约束生成，没进红线，实测差距如下：

指标	来源 B（真人）	来源 C（模拟）
含标点	13%	98.9%
含语气词	4%	25.6%
含年份或月份	81%	47.8%
带年份句里写「2019」	—	236 / 429 = 55%
provide_new_evidence 里是搬家/换工作	—	152 / 157

根因在 ALT_EVENT_HINTS：七个领域的「另一件事」提示全是「搬家 / 换工作」两种，年份没约束，模型就收敛到「另外 2019 年搬过家」。这解释了「模拟语料不代表真人」的一部分，也解释了 2.5 的错例为何长得一样。不在本单修，写进报告「限制」一节，留给产品决定是否再造一轮。

3. 决策记录

1. 本轮结论「缺数据」采纳。不上线、不影子双跑，直到 2.1 的数字出来后产品再拍板下一步（补真机样本 / 再造语料 / 关单）。
2. 本单不新增任何模型调用（F1 第 3 条例外见下），全部从 .cache/jev_intent/ 已有结果聚合；执行方若发现 cache 里没有来源 B 的 current_1 结果，按让步 1 处理。
3. 不换复核模型、不重造语料；2.4 / 2.6 只写限制。

4. 硬红线

原单 §4 与修复单 1 §5 全部继续生效。另加：

9. 来源 B 仍只写聚合与混淆计数，不得出现任何一条真人原文、id、时间戳。
10. 不得为让来源 B 的数字好看而改 gold；标注争议只能写成「争议 n 条」并列出争议类型。

5. 任务分解

F1 · 报告补齐来源 B 三组数（P1）

1. jev_intent_probe.py 的指标段增加 current_source_b / current_source_b_by_layer（口径与 source_b 相同；现行无置信度，置信度三列记 null），MD「代表性检验」一节改成一张表：行 = 三层 + 全集，列 = n / Jev intent / 现行 intent / Jev 高置信错误 / Jev 低置信召回 / Jev 自洽（jev_1 vs jev_2 在来源 B 上）。
2. 无焦点层按标签给 gold × Jev 与 gold × 现行两张混淆计数表（4 × 4，只有计数）。
3. 若 cache 里没有来源 B 的现行结果，允许只为这 157 条跑一次现行（约 16 万 input token），PROGRESS 记明。
4. 验收：MD 表里每个数能从报告 JSON 重算；tests/test_jev_intent_research.py 新增一条断言：报告 JSON 的 metrics 含 current_source_b 且 n == meta.source_b_n。

F2 · 报告增加「限制」一节（P2）

写三条：复核 ≈ 生产提示且同模型（2.4）、采集层错例的标签争议（2.5，给计数与 3 条改写示例）、语料风格差距表（2.6）。「现行模型对照」一节的采集层「未过」改成「不可判（复核与对照同源）」。

F3 · 记录

• PROGRESS 追加「修复轮 2」段。
• docs/tasks/README.md 状态行改为本单结论。
• 不立 BUG。

6. 让步顺序

1. cache 里没有来源 B 现行结果且产品不再给 key：F1 第 1 条只填 Jev 列，现行列标 unavailable，PROGRESS 写明；F1 第 2 条照做。
2. 无焦点层 7 条错例里有执行方自己都拿不准的标注：写「标注争议 n 条」，不改 gold。

7. 开工前置命令

git fetch origin --prune
git worktree add -b codex/rectification-jev-intent-research-fix2-20260919 .worktrees/rectification-jev-intent-research-fix2-20260919 origin/staging
cd .worktrees/rectification-jev-intent-research-fix2-20260919
ls .cache/jev_intent/            # 确认 source_b.jsonl 与 runs cache 在
python3 -m unittest tests.test_jev_intent_research

8. BUG 编号

不立 BUG。docs/BUG_HISTORY.md 当前最大号 BUG-970。