Jyotisha/docs/tasks/TASK-rectification-minute-resolution-research-20260914.md

# 研究单 · 为什么候选分不开：打分尺度的分钟分辨率（2026-09-14）

- 基线：`origin/staging` @ `d97b9e9f`（含 BUG-685/686/687 的实现 `7f28bfec` 与风格题前置 `d97b9e9f`）。
- 分支：`codex/rectification-minute-resolution-research-20260914`，worktree `.worktrees/rectification-minute-resolution-research-20260914`。
- 性质：**离线测量，不改线上行为。** 除任务 0（修基准数据）外，任何尺度改动都必须先量出收益才另立实现单。
- 来源：2026-09-14 与上游 `/workspace/yinduzhanxing` 的能力对照（subagent 报告存档 `docs/research/upstream_rectification_gap_2026_09_14.md`，执行方开工时把 scratchpad 那份 195 行报告落盘到这个路径）。

## 1. 问题

真机连续多轮出现"带年月的题问完、候选仍然并列"：最近一次 6 轮后 posterior 是 16 / 16 / 15 / 14 / 13，交付卡给出 26% / 26% / 20%，用户只能蒙。

**这不是题问得不够，是打分对分钟不敏感。** `scripts/active_rectification_event_engine.py:216–246`，一个日精度事业事件的分数拆成两类：

| 类别 | 上限 | 在 20 分钟窗内是否变化 |
| --- | --- | --- |
| 本命宫位（整宫制）、宫主、功能吉凶、Narayana、Ashtakavarga、Shadbala、过运 | **11.5** | 基本不变（只在跨上升星座时变） |
| 分盘命中 `points += weight / (2 * len(varga_charts))` | **2.125** | 每分钟都在变 |

约 **5 : 1**。每答一题，九个候选拿到的分里约八成是"人人有份"的底座，真正区分分钟的只有一两分。BUG-570 记的"底座 11–15、事件差 4–5"是同一件事。**再加十道题，比例不变，仍然分不开。**

同时，用来判断"改动有没有收益"的封存基准本身欠力：`references/real_case_calibration/minute_rectification_holdout_v3.json` 每例**恰好 3 件事**、半径 ±10 分钟，自带 `source_audit_status: invalidated_after_replay`（两处日期错）。真实会话是 5–18 件事。**用它否决尺度改动是过严的**，BUG-560 当时记的「offset 覆盖 12/20」很可能是样本欠力而非改法无效。

上游对照结论（已核）：`b9a0ef8f..92d3a47a` 43 个提交里生时校正**零改动**，没有新技法可抄；上游自己 09-04 的复盘也承认接了 KP、18 件事 5 领域之后仍「整窗零淘汰」。**这条路得我们自己走。**

## 2. 决策记录

| 决策 | 内容 |
| --- | --- |
| D1 | **KP 宫头子主参与评分**（产品负责人 2026-09-14 拍板）。这**推翻 BUG-325 防复发条里的「不得把 KP 观察计分」**——该条写于 2026-08-20，当时的理由是 KP 快照刚做出来、未经标定。现在的理由是：KP 宫头子主是 20 分钟窗内唯一变化 3–5 次的整宫级判据，数据本仓已经每分钟在算（`scripts/rectification/kp_cusp_observation.py`），只被 `active_rectification_event_engine.py:71` 的 `OBSERVATION_ONLY_LAYERS` 挡在评分外。**方向已定，本研究单只负责标定权重与验证收益，不负责"要不要做"。** 执行方不得以 BUG-325 为由拒改；但也不得在没有测量结果的情况下直接改线上默认权重。 |
| D2 | **不得为了提高命中率放宽置信度或确认门控**（`AGENTS.md` §8）。所有改法只动打分尺度，不动 `confirmation_allowed` / `acceptance_allowed` / 并列判据。 |
| D3 | **不得硬编码对齐特定答案。** 上游 `scripts/ashtakavarga.py` 的 `PL9_BAV_CELL_OVERRIDES`（为对齐某份 PDF 覆写特定行星/星座的 bindu）是反面样板，本仓不采用这种做法。 |
| D4 | **口径前置**：本仓交点模式默认 `mean`、上游默认 `true`（最大差 1.7°，足以翻宫）。本单所有测量在**本仓口径**下进行，结果文档首行写明 ayanamsa 与 node mode，不得与上游数字直接对比。 |
| D5 | 任务 0（修基准）是唯一允许落盘改数据的部分，且只改 `references/real_case_calibration/**` 与研究脚本，不碰线上评分代码。 |

## 3. 任务 0 · 先把基准修好（前置，必做）

没有可信基准，后面全部测量都无法判读。

- 修 `minute_rectification_holdout_v3.json` 的两处日期错，重跑 `source_audit`，把 `source_audit_status` 恢复成有效或明确注明每例的来源与精度。
- 产出 **v4**：`references/real_case_calibration/minute_rectification_holdout_v4.json`
  - 每例 **≥ 7 件带年月事件**、**≥ 4 个领域**（对齐真实会话，而不是 3 件）；
  - 出生时间来源为公开 AA 级；**不得使用真实用户资料**（`AGENTS.md` §8）；
  - 三档搜索半径：**±10 / ±30 / ±60 分钟**，分别记录，用来看改法在宽窗和窄窗上的表现是否一致；
  - 每例标注真实分钟所在簇，供命中率统计。
- 交付：数据文件 + `docs/research/holdout_v4_build_2026_09_14.md`（来源、标注协议、与 v3 的差异、为什么 v3 不足以做判据）。
- 验收：v4 上重跑当前线上算法，给出**基线成绩单**（下面五个指标），这份成绩单是后续所有改法的对照。

## 4. 任务 1 · 要量的五个改法

在 v4 上逐项单独测量、再测两两组合。**统一指标（五个）**：

1. **真实分钟命中率**：真实分钟落在头名簇的比例；
2. **真实分钟落在交付区间内的比例**（不得为了收窄把真值挤出去）；
3. **交付区间宽度**（分钟）中位数；
4. **并列率**：前两名 posterior 分差 = 0 的案例占比（当前痛点的直接度量）；
5. **每轮熵下降**：答完第 N 题后的候选熵，看收敛速度。

| 编号 | 改法 | 改哪里 |
| --- | --- | --- |
| **R1** | 分盘项除数调整：`weight / (2 * len(varga_charts))` 的除数取 `2 * len` / `len` / `sqrt(len)` / 固定 2 四档 | `active_rectification_event_engine.py:231` |
| **R2** | **去底座**：每个事件的分数减去该事件在**当前窗口所有候选上的最小值**，只保留差异部分 | 同文件，事件分汇总处 |
| **R3** | **KP 宫头子主计分**（D1 已拍板）：把 `KP_cusps` 移出 `OBSERVATION_ONLY_LAYERS`，按 kp1/4/7/10 与事件领域的对应关系给权重，权重取 0.5 / 1.0 / 2.0 三档 | `active_rectification_event_engine.py:71`、`scripts/rectification/kp_cusp_observation.py` |
| **R4** | **年精度事件改边际似然**：现在对 12 个月取算术平均，把"某一个月正好踩中换运"摊薄成 1/12；改为对月取 max 或对数边际似然 | `scripts/rectification/scoring_service.py:250` 一带 |
| **R5** | **聚类签名层与计分层对齐**：`candidate_contrast.py:25` 的 `SIGNATURE_LAYERS` 只有 d1/d9/d10/d24/d4/d12/md，实际计分还用 D5/D7/D3/D2/D11/D30 → 分数不同的分钟被并进同一簇丢掉；`md`（月宿）在同日窗口内恒定，占空位。改为按本次有证据的领域动态取签名层 | `candidate_contrast.py:25` |

补充要求：

- 每个改法都要报告**副作用**：真值被挤出区间的案例数、区间过窄的案例数、某一档半径上退化的案例数。
- R3 额外要报告：KP 在各例 20 分钟窗内实际变化几次；若某例窗内不变，该例不计入 R3 的收益统计（避免用无关样本稀释）。
- R2 要注意与 `decision_policy.py:341` 的按簇分摊交互（那里已用簇内最高分代表，不存在 BUG-570 的同型偏置，改动不得把它破坏）。

## 5. 交付

- `scripts/research/minute_resolution_sweep.py`（新，只读线上模块，不改默认行为；参数化跑五个改法与组合）。
- `docs/research/minute_resolution_2026_09_14.md` + 同名 `.json`：基线成绩单 + 每个改法在三档半径上的五个指标 + 副作用统计 + 口径声明（D4）。
- 结论只允许三种：**有收益**（命中率与区间覆盖率不降、并列率下降、区间宽度中位数下降）→ 立实现单并给推荐参数；**无收益** → 关闭并写明；**不确定** → 说明还缺什么数据或样本量。
- 不得把研究脚本接进生产路径；不得改 `active_rectification_event_engine.py` / `scoring_service.py` / `candidate_contrast.py` 的线上默认值。

## 6. 硬红线

1. Python 改动跑 `.venv/bin/python scripts/run_quality_gate.py --profile quick`；改到哪个模块就跑对应 `tests/test_*.py`。
2. 不得使用真实用户出生资料、姓名、邮箱；样本只用公开名人或明确虚构数据。
3. 不得放宽置信度、确认门控或并列判据（D2）。
4. 不得为对齐某个期望答案硬编码覆盖（D3）。
5. 研究结论不得写成"感觉更好"；每条都要落到五个指标上的数字。

## 7. 开工前置命令

```bash
git fetch origin --prune
git worktree add -b codex/rectification-minute-resolution-research-20260914 \
  .worktrees/rectification-minute-resolution-research-20260914 origin/staging
cd .worktrees/rectification-minute-resolution-research-20260914
python3 scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45
```

开工前读：`docs/research/upstream_rectification_gap_2026_09_14.md`（对照报告）、`docs/BUG_HISTORY.md` 的 BUG-325（KP 红线，本单 D1 推翻其中一条）、BUG-560（holdout 否决记录）、BUG-570（底座与事件差）。

## 8. BUG 编号

- 本单是研究单，**不新增 BUG 编号**。测量后若立实现单，届时按 `docs/BUG_HISTORY.md` 当时的最大号顺延。