root/Jyotisha
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
e776cf9d8397138ca6d6effaa4ec5d747155ed11
Jyotisha/docs/tasks/TASK-rectification-minute-resolution-research-20260914.md
T
Jesse_ChenandClaude Fable 5 9943a05a01 docs(research): brief for minute-resolution scoring, plus the upstream gap report 
上游 b9a0ef8f..92d3a47a 的 43 个提交里生时校正零改动，没有新技法可取。候选
分不开的根因在本仓自己的打分结构：一个日精度事件里窗口内恒定的项上限 11.5
分，随分钟变化的项上限 2.125 分，约 5:1。研究单先修封存基准（v3 每例仅 3 件
事、被标 invalidated）出 v4，再离线量五个改法：分盘除数、去底座、KP 宫头子主
计分（产品 2026-09-14 拍板，推翻 BUG-325 的「不得计分」一条）、年精度事件改
边际似然、聚类签名层与计分层对齐。有收益才另立实现单。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0155nFCgCHtoA7jhSDGmZmMu
2026-09-14 11:17:33 +00:00

9.2 KiB
Raw Blame History

研究单 · 为什么候选分不开：打分尺度的分钟分辨率（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. 开工前置命令

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 当时的最大号顺延。
Reference in New Issue View Git Blame Copy Permalink