Files
Jyotisha/docs/tasks/TASK-rectification-holdout-expansion-20260929.md
T

84 lines
7.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# TASK · 生时校正:把开放评价集从 20 例扩到 ≥60 例(v5,2026-09-29)
## 基线
- `origin/staging` @ `b9133154`(写作时 head;开工时以最新 `origin/staging` 为准)。
- 分支 `codex/rectification-holdout-expansion-20260929`,工作树 `.worktrees/rectification-holdout-expansion-20260929`。
- **串行关系**:本单是 `TASK-rectification-scoring-research-20260929.md` 的前置。研究单的脚手架可以在 v4 上并行开发,但它的任何"过门 / 不过门"判定必须在本单交付的 v5 上做。
- 本单**不改任何生产代码**,不动 `scripts/research/sealed_holdout_rerun.py::PRODUCTION_FILES` 的 10 个冻结文件与 `frozen_scoring.files`(ERR-110)。
## 事故实证
生时校正打分方法的每一次"过门 / 不过门"都是在 20 例上判的(`references/real_case_calibration/minute_rectification_holdout_v4.json`,20 例公开 Rodden-AA,84 件年精度 + 59 件日精度事件)。20 例上 1 例 = 5 个百分点:
| 判定 | 数字 | 实际差几例 |
| --- | --- | --- |
| KP 宫头子主计分(R3,09-14)判 no_benefit | ±10 头名 0.35 → 0.20 | 3 例 |
| 精度分档闸门(09-15)判 no_benefit | ±10 头名 0.80 → 0.75 | 1 例 |
| V1n 分盘配权(09-26)判 no_benefit | ±10 头名 0.80 → 0.85,±60 宽度 56 → 73 | 1 例 / 若干例 |
| W3 分位区间(09-14)按红线不放行 | ±30 一例真值被挤出 | 1 例 |
这些判定都可能是对的,但都在噪声线上。定论页 `docs/research/rectification_minute_resolution_closure_2026_09_14.md` 的"已证伪"结论,其证据强度同样只有 20 例。
## 根因
v4 继承 v3 的 20 例名单(`docs/research/holdout_v4_build_2026_09_14.md`),只补了事件数与领域数,没有扩例数。没有一份 ≥60 例、事件与出处经人工核对、口径与本仓一致(ayanamsa `raman`、node mode `mean`)的公开评价集。
## 决策记录(产品 2026-09-29)
- **批准**扩建到 **≥60 例**(目标 80 例),新建 v5,v4 原文件不动(旧研究复跑仍要逐字节一致)。
- v5 是**开放评价集**(`truth_hidden_from_ranker=false`),用来量尺度、做留一法校准;不是封存盲测。封存盲测(`sealed_holdout_rerun.py`)与 reported-offset 记录不因本单改变。
- **只用公开名人**:Astro-Databank Rodden **AA** 级(出生证 / 医院记录)。不得选入本仓任何真实用户、库主、协作者或其亲友;不得用 A/B/C/DD 级。
- 事件抽取允许用模型起草,但**每条事件必须人工核对**来源页并记录 URL;模型草稿不得直接进数据集。
- 本单不改打分、不改闸门、不改任何常数;不得因 v5 上的基线成绩单而顺手调参。
## 硬红线
1. 隐私:只用公开名人;`tests/test_repo_privacy_markers.py` 全绿;数据集不得含任何真实用户资料。
2. 出生资料:出生时间、地点、时区逐例回到 Astro-Databank 页核对,记录 AA 等级与页面 URL;时区/夏令时按当地历史规则换算,写明依据(v3 曾有两处日期错,见 `holdout_v4_build_2026_09_14.md`)。
3. 事件:每例 ≥7 件带年月事件、≥4 个领域,字段与 v4 schema 一致(`domain` / `precision` / `date` / `source_url` / `independent_of_birth_source=true`);事件出处必须独立于出生资料来源。
4. 分层:名单要覆盖 —— 出生年代 ≥3 个年代段;纬度带 ≥3 档(|φ| <25° / 25–45° / >45°);南半球 ≥8 例;出生时间落在 22:00–02:00 的 ≥6 例(跨午夜路径,BUG-981~985);北京时区(UTC+8)≥6 例(本产品主要用户)。不满足分层要求写进 PROGRESS,不得静默。
5. 基线成绩单必须能复现旧数字:v5 的 v4 子集在 `minute_resolution_sweep.py` / `cluster_width_probe.py` 上跑出的三档头名、覆盖、宽度、并列率必须与 09-14 / 09-26 已发布的数字逐格一致;不一致先查口径,不得改旧文档。
6. 生产代码零改动;`run_quality_gate.py --profile quick` 与开工基线逐条一致。
7. `PYTHONHASHSEED=0`(ERR-111)。
## 任务分解
- **T1 选例协议与名单(BUG-1090)**
- 写 `docs/research/holdout_v5_protocol_2026_09_29.md`:入选标准、分层配额、排除规则(同一家族多人只取一人;出生时间"rectified"或"from memory"一律排除)、来源记录格式。
- 名单 ≥60(含 v4 的 20 例),每例:姓名、Astro-Databank URL、AA 等级、出生日期/时间/地点/时区依据。
- 验收:名单文件 `references/real_case_calibration/holdout_v5_roster.json`;分层统计表进 PROGRESS;隐私守卫全绿。
- **T2 事件抽取与核对**
- 每例 ≥7 件、≥4 领域;领域用 `scripts/active_rectification_event_engine.py::DOMAIN_CONFIG` 的键;精度诚实标注(year / month / day),不得把"某年"写成"某年 1 月"。
- 每条事件记录 `source_url` 与核对人;模型草稿另存 `_draft`,不进数据集。
- 验收:schema 校验测试 `tests/test_holdout_v5_schema.py`(字段、精度、领域、每例计数、URL 非空、`independent_of_birth_source` 全真);抽样 10% 由 Claude 验收时二次核对来源页。
- **T3 构建脚本**
- `scripts/research/holdout_v5_build.py`:从 roster + 事件文件生成 `references/real_case_calibration/minute_rectification_holdout_v5.json`,三档半径写在数据集上,口径字段(ayanamsa / node mode / 步长)显式写入。
- 验收:两次构建逐字节一致;v4 的 20 例在 v5 中的出生资料与事件与 v4 逐字段一致(新增事件除外)。
- **T4 基线成绩单**
- 线上算法在 v5 上跑 `minute_resolution_sweep.py`(五指标)与 `cluster_width_probe.py`(含淘汰的六题回放:头名、真值在区间、宽度中位、并列率、熵降),三档半径。
- 另按 `futile_collect_stop_replay.py` 口径跑 truth / opposite 六格。
- 验收:JSON 进 `docs/research/holdout_v5_baseline_2026_09_29.json`;v4 子集数字与已发布数字逐格一致(硬红线 5);全集数字进 PROGRESS 表。
- **T5 文档**
- `docs/research/holdout_v5_build_2026_09_29.md`(协议、分层统计、与 v4 差异、基线成绩单、复跑命令);`docs/research/ACTIVE_FRONTS.md` 加索引;定论页 §7 之后追加"§8 v5 已建,后续判定以 v5 为准"。
- 验收:文档齐;`docs/tasks/README.md` 状态板更新。
## 让步顺序
T1 > T2 > T3 > T4 > T5。**例数 < 40 不算完成**,40–59 例可先交付一版并在 PROGRESS 写明缺口与下一批计划;研究单的判定等到 ≥60 例。
## 开工前置命令
```bash
git fetch origin --prune
git worktree add -b codex/rectification-holdout-expansion-20260929 .worktrees/rectification-holdout-expansion-20260929 origin/staging
cd .worktrees/rectification-holdout-expansion-20260929
export PYTHONHASHSEED=0
.venv/bin/python -m pytest tests/test_repo_privacy_markers.py tests/test_minute_resolution_research.py tests/test_cluster_width_research.py -q # 基线
.venv/bin/python scripts/research/minute_resolution_sweep.py --help
```
## BUG 编号
开工时核对 `docs/BUG_HISTORY.md` 最大号(写作时 `BUG-1089`)。本单:**BUG-1090**(评价集 20 例欠力,所有打分判定在噪声线上)。由执行方以 `investigating` 登记,v5 交付后改 `resolved`,证据是 T4 成绩单与 T2 schema 测试。关联 BUG-560、BUG-1089。