MARKET RESEARCH
設計評議
2026-10-13 · 1 天前量的——網站量測會過期，改過之後要重跑
這一頁是什麼
執行與內容審查提案退回會保留原因；只有連線、截斷等執行故障才自動接續。處理進度見系統健康的自動修復區。
| 題目 | 執行狀態 | 通過 | 退回／錯誤 |
|---|---|---|---|
| 網站提案 | 執行完成 | 1 | 0 |
| 研究候選 | 執行完成 | 1 | 0 |
研究凍結中，規則分兩層（與 /methodology、/meeting 同一句）：live 管線與 live 帳維持凍結（2026-08-21 起）；離線研究已於 2026-08-31 依使用者決定解凍（reports/unfreeze-2026-08-31.md）。下方「提升準確率」那一段仍是候選清單，不是待辦——這支腳本不跑任何實驗、不碰模型、不消耗驗證折；要跑得先寫 prereg 並排驗證折預算。
座位就兩個題目提案：網站怎麼優化、有什麼方法能讓預測更準。 事實全部由腳本當場量（逐頁位元組與秒數、cProfile 佔比、既有成績）， agent 只做判斷——它不填任何數字。
提案要進這一頁，必須說得出代價與反例：
- 要花幾次驗證折 不寫代價的提案是免費的，而免費的提案會無限多
- 什麼結果會推翻它 講不出反例的提案不是假說，是願望
提案裡「對現況的宣稱」（為什麼是它）會過引用檢查，憑空的數字整則退回； 但「提議的目標值」不查——那些數字現在還不存在，查了等於禁止提具體門檻。
⚠️ 這一層驗數字，不驗推理。實測有一則提案說
「gzip 能降低 /record 的 6.95 秒」——數字全對，因果是錯的（那 7 秒是
計算不是傳輸）。另一次有兩則把驗證折成本填成 22，而 22 是那次評議
當時事實池裡的「驗證折已用」（reports/validation_use_log.md
第 22 筆記於 2026-08-26）——現在是 43 次，這是一次
過去的事故，不是現況。範圍檢查會標記這種，但只標記不丟掉：
成本估錯是判斷失準，不是誠信問題。
A. 量到的網站現況（量了 49 頁，下表列最慢的 8 頁）事實由腳本當場量，agent 只做判斷
⚠️ 這些秒數量的是本機直連，不是使用者實際走的公網通道——所以它們是下界，真實體感只會更慢。
| 頁 | 秒 | KB | 快取 | gzip |
|---|---|---|---|---|
| /record | 6.76 | 216 | — | ✅ |
| /performance | 2.10 | 296 | — | ✅ |
| /futures | 1.02 | 168 | — | ✅ |
| /theme-report | 0.89 | 120 | — | ✅ |
| /watched | 0.73 | 94 | — | ✅ |
| /backtest | 0.68 | 61 | — | ✅ |
| /us-scorecard | 0.56 | 55 | — | ✅ |
| /tx | 0.38 | 67 | — | ✅ |
上表是量到的 49 頁裡最慢的 8 頁（按秒數倒序），另有 41 頁未列——沒列不代表沒量到。全部 49 頁的原始量測在 data/live/design_council.json。
最慢那一頁（/record，共 17.01 秒）的時間花在哪裡——「這頁很慢」不是可以動手的事實，這張表才是。
| 函式 | 檔 | 呼叫次數 | 佔比 |
|---|---|---|---|
| ece_null_floor | metrics.py | 9 | 98.6% |
| expected_calibration_error | metrics.py | 4,509 | 97.3% |
| reliability_table | metrics.py | 4,509 | 86.9% |
| __getitem__ | series.py | 157,323 | 52.3% |
A. 網站優化提案
把 metrics.py 的 expected_calibration_error／reliability_table 改為向量化計算，並對 /record 的 9 次 ece_null_floor 結果做 memoize，避免 4,509 次重複呼叫。中工程
- 為什麼是它
- /record 總耗時 17.01 秒中，ece_null_floor 佔 98.6%（僅 9 次呼叫）、expected_calibration_error 佔 97.3%、reliability_table 佔 86.9%（各 4,509 次），__getitem__ 被打 157,323 次佔 52.3%，瓶頸明確在這條呼叫鏈。
- 改完怎麼量
- 重跑 cProfile 看 /record 總耗時是否從 17.01 秒降到 1 秒內、ece_null_floor 佔比是否大幅低於 98.6%、__getitem__ 呼叫數是否明顯低於 157,323 次；並實測 /record 回應時間（原 6.76 秒）。
B. 提升準確率（候選清單，一則都沒跑）每則都必須說出代價與反例，缺一就丟掉
不再找新 edge；離線研究結束前只做一件事：確認現有 0.0013 nats 的判別量級是否在任何成本假設下都不可能轉成正期望，並把結論寫進報告。驗證折 0 次
- 為什麼可能有用
- 方向命中率 0.3676 低於多數類基準 0.4317；平衡準確率雖 t=7.09 顯著，但判別量級接近沒有（0.0013 nats），每次進場成本 3.07bp——顯著但撐不過成本的格局已定。
- 什麼會推翻它
- 若重新用 next_open 口徑重測（含 117 欄）量到明顯大於 0.0013 nats 且換算後期望值超過 3.07bp 成本，則「放棄找 edge」的結論被推翻，重啟研究。
- 最可能怎麼失敗
- 最可能的失敗方式：這只是把「放棄」包裝成提案，未來重測 117 欄 +cross+night 路徑時發現 58 欄結論不能外推，白白錯過一條未驗證的路徑。
B. 提案能引用的事實提案裡對現況的宣稱只能引用這些數字，憑空的會被引用檢查整則退回
| 項目 | 值 | 來源 | 備註 |
|---|---|---|---|
| 方向命中率 | 0.3676 | walk-forward OOS 3,841 筆 | 多數類基準 0.4317——輸給「永遠猜多數類」 |
| 進場勝率 | 0.4803 | walk-forward OOS | 基準 50% |
| 進場比例 | 0.6683 | walk-forward OOS | |
| 每次進場成本 | 3.07bp | assumed-cost (參數未查證) | |
| 樣本數 | 4,100 | record.csv h=1 walk-forward（至末端） | |
| 平衡命中率 | 0.3848 | record.csv h=1 oos_walkforward_full | 無資訊基準 0.3333 |
| 區間涵蓋率 | 0.8217 | record.csv h=1 oos_walkforward_full | 目標帶 0.70–0.90 |
| 區間平均寬度 | 0.0262 | record.csv h=1 oos_walkforward_full | 只報涵蓋率不報寬度是禁止的——寬到夠寬一定涵蓋得到 |
| ECE | 0.0438 | record.csv h=1 oos_walkforward_full | |
| ECE 有限樣本下限 | 0.0112 | record.csv h=1 oos_walkforward_full | 完美校準也會量到這麼多 |
| 真實校準誤差 | 0.0326 | record.csv h=1 oos_walkforward_full | 上線門檻 0.05——excess 才是模型的誤差，ECE 不是 |
| 驗證折已用 | 42 次 | validation_use_log.md | 🔴 live 管線與 live 帳凍結中；離線研究 2026-08-31 已解凍，新實驗要先寫 prereg 並排驗證折預算 |
| 保留集動用 | 21 次 | holdout_touch_log.md | 🔴 live 管線與 live 帳凍結中；離線研究 2026-08-31 已解凍，新實驗要先寫 prereg 並排驗證折預算 |
| 事先判準 | 0 過 / 4 不過 | config/experiment.toml 判準檢定 | direction / calibration / interval / cost 全部未通過 |
| 特徵欄數 | 117 | tx_features.parquet | 全部欄數；⚠️ 0.0013 nats 那個結果量的是 58 欄核心路徑，不是這 117 欄——117 欄的 +cross+night 路徑從未在 next_open 口徑下重測過 |
| 特徵換到的資訊量 | 0.0013 nats | reports/c-grid-curve-2026-08-25.md（58 欄核心路徑） | 曲線最佳點幾乎正好落在「每天都說 1/3 / 1/3 / 1/3」那條線上。⚠️ 這是 58 欄路徑的數字，不要寫成 117 欄 |
| 折間 t 檢定 | t = 7.09 | 五折 walk-forward（df = 4） | 平衡準確率五折全部高於無資訊基準——判別能力存在，量級接近沒有 |
| 折數 | 5 折 | config/experiment.toml |
5f92ccf（第 163 次提交，2026-10-14） ｜ 資料建置於 2026-10-14 10:30 UTC ｜ 行情與研究結果供查看；會員可管理觀察清單並要求更新個股分析