zlt
/
akg-factor-bridge
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
akg-factor-bridge/docs/G1实测与待办_2026-07-26.md

17 KiB
Raw Blame History

量化因子 · G1 实测结论与待办（2026-07-26）

第一批（桥侧口径修复 + 插槽视图 v2）已实机验证通过，代码已入库，不在此重复。 本文只记两件事：G1 实测读出的事实（后续决策的依据）、尚未完成的第二三批。 07-27 增补：改1 交付后做了阶段方案交叉评审，结论并入二三批与新增的第五节（待回传读数）。

一、G1 实测（2026-07-24 截面，实机）

覆盖池 2391 只——设计文档写的 1675 已过时，316 个池在持续涌现收录。

1. 门槛② 的损耗几乎全部来自"没有券商覆盖"，不是估值 U 2391 → 有 upside 795（33%）→ upside≥0 剩 755。 无券商覆盖挡掉 1596 只（67%）；θ_v=0 只挡掉 40 只（有覆盖股的 5%）。 ⇒ §9-3 的 q 必须显著上调，否则估值那一刀形同虚设。 ⇒ §9-4（无覆盖股怎么办）不是边角料，是三分之二的池。

2. 三项正交 corr(z_H, z_V) = −0.033；z_T 与另两项均 ≈ 0.01。 ⇒ 评审中"三项加权实为两项"的担心被证伪，三项各带独立信息。

3. 0.5/0.3/0.2 是严格的"传导优先"，不是加权混合 w_T=0.50 → top10 10/10、top20 20/20、top30 30/30、top50 39/39。 39 只传导票精确占满前 39 名，0.3/0.2 只在组内排序、跨组不起作用。 实测要真混合需 w_T ≈ 0.20（此时 top20 只有 6/20 是传导票）。

4. 传导票 39 只（P 的 5.2%），组合可行性没问题 top20 可以整篮子都是传导票，不存在"只剩 1~3 只"的塌缩。

5. 硬伤1 真实 binding 当日 12 个候选里 6 个 quiet 存满 12 条。

二、第二批 · 基座四处 + 桥侧一尾（施工中）

不触碰 claims/documents，不需 replay，不需重抽。

  1. ✅(07-27 已交付已提交) graph_store.topic_context 的 Cypher 加 ORDER BY，cap 30 → 200。 实际落法：q_members ORDER BY ts_code, name（升序 NULL 后置 → 上市成员优先入 cap）、 q_drives 同类补序。验证读数未回（见五-1）。 ⚠️ 传导数值口径自此有断点（成员抽样确定化），仪表盘回看时注意。
  2. ✅(07-27 已交付待实机验证) transmission.scan：去 quiet[:12] 全量落库 （核实：旁批只消费聚合 pricing 不吃明细行，"喂前12"之说不成立，无需保留）； mkt_trade_date 写值 + 新鲜度/完整度双告警（快照非扫描日、stock 行数 < MIN_MKT_STOCK_ROWS=1000，均只告警不中止）；已拍板并落地：调用点显式 cap=1000 + 大主题闸 MAX_TARGET_MEMBERS=600（超者跳过并 log）。 pricing 语义随之升级为全体未动成员统计（原为前 12 样本）。 核实：scan 内并无 members_total≥30 之类代码闸（读数清单那条是读数请求）。
  3. ✅(07-27 已交付待实机验证) hotspot._latest_mkt / _movers_set 加 trade_date 参数（None=原行为，hotspot 自身 18:00 扫描零变化）；transmission.scan 起点 解析一次 D → movers 钉死同一快照日（改2 的独立取日查询就地升级为解析点）。 参数化 ≠ 打开传导历史重扫，§2.2 铁律不动。 备忘：quiet 明细价位仍取最新（claim_store 层，不在四处清单；不影响 moved_ratio，只影响旁批展示价位）。
  4. ✅(07-27 已交付待实机验证) sync_consensus(lookback_days, asof=None)： 窗口 [asof−N, asof]，report_date <= ref 上界已补（live 同样生效，纯更点时 正确）；唯一键已核对 = PRIMARY KEY(ts_code, asof_date) ✓ 回填不覆盖 live； 历史回填不触发需求核销（asof=None 才核销）；返回值带 asof。 甲案回填驱动脚本（逐日 asof 循环）仍是另一项未做。
  5. ✅更正：视图 v3 不需要——第一批 apply-views 已一并落了表列 ALTER 与视图 曝列（sql 第 9 / 72 行：mkt_trade_date、n_quiet_stored），已实机验证过。 链条真缺口只剩桥侧采信规则（三批-5）。

已定：新鲜度不中止扫描，只告警 + 记 mkt_trade_date。

并行建议（07-27，唯一逐日流失项）：二三批都可以晚做，快照每晚一天永久少一天—— ① freeze.py 确认进每日调度；② 基座 industry_pools_history（池成员日快照）尽早开积累 （覆盖池 1675→2391 的膨胀速度加重此项）；③ 全量 quiet 的 live 传导史从改2上线日才开始， §10 GRU 的"≥1 年"计时器实质从那天起算 ⇒ 改2 宜紧不宜慢。

三、第三批 · 待决策

★ 前置（07-27 评审加）：三批一律用二批落地后的重跑读数拍板，07-24 读数作废。 去 quiet[:12] + cap200 会改变 z_T 的生成分布：传导覆盖从 83 行/日上一个量级、 "池内 95% 为 0"的稀疏前提（§3.4 例外处理的依据）、39 票、16/20 重合全部要重测 ——重跑 probe 的 corr / 权重 / 票数三张读数即可。

  1. 无券商覆盖的 1596 只（§9-4）——升为主决策：门槛②实测语义 ≈ "有覆盖 ∧ upside≥0"， 覆盖挡 67%、估值只挡有覆盖股的 5%，q 只作用于剩下三分之一。 9-4 不定，门槛②的价值主张站不住。
  2. θ_v 的 q（§9-3）——9-4 定了之后按重跑读数定，次级旋钮。
  3. 传导组内部怎么排——当前按连续 z_T，两段式按"冷+便宜"（档位 + tiebreak； §9-8/9-9 实质并入此题，成一道结构选择题）。07-24 读数 top20 重合 16/20 仅供方向感， 按前置重测后再拍。
  4. 赛道门槛 C 的数据源——industry_pools 成员级无 segment/layer，图谱在 Neo4j。 建议：claims 口径先用于覆盖体检，基座投影视图（第五/六插槽）作 S1 正解。
  5. mkt_trade_date 采信规则（07-27 评审加）——stale 时剔除 / 打折 / 只标记？ 与 §9-7 A 案有一处会打架：若桥把 stale 日传导整体剔掉 → 当日 z_T std=0 → 按 §3.4 整列置 0 → 恰违反 §10"不得静默置零"判收。⇒ A 案"有数据才出行"的判据升级为 "有采信规则放行的数据才出行"，随本条一并拍。

§9 对账（07-27）：9-1 热度翻转从未正式关掉（零成本，建议即关）；9-6 已定甲案（关）； 9-7 建议现在拍 A（其形态由上面第 5 条决定）；9-2 赛道清单仍是 G2 阻塞项；9-5 延后 S2 不变。

四、下一步建议

akg_gate（0/1，全池出行）与 akg_score 一起注册——否则平台的 IC/分层只看得到 池内排序，完全看不到两道门槛的价值，而门槛才是这套逻辑的主体。

07-27 补：gate 先注册可兼当"覆盖溢价"仪表（帮 9-4 拍板），但 factor_metadata 描述必须 写明当前语义 = 覆盖 ∧ upside≥0 ∧ C，并预期 9-4 决策后重定义——否则平台 IC 史读到的 主要是"有无券商覆盖"。G3 开工前置确认从 §9-8 一项扩为 §9-3 / 9-4 / 9-8 三项。

五、待回传读数清单（07-27 汇总）

  1. ✅(07-27 判收通过) 改1 验证：源码在容器生效（cap200 + ORDER BY×3）+ topic_context 8 大环节双跑逐位一致（正是改1 所修之层；movers 集合为确定性 SQL）。 更正：第三层 scan 双跑实为空转比较——07-27 无 hotspot 台账 → 空扫描落库 0 行， list_candidates() 回落到最新日(07-24)静态行，比较必然一致； 07-24 台账未被触碰（84 行为周五 beat 原始产出，旁批完好）。 真端到端双跑并入改2 验证。
  2. ✅(07-27 已回) mkt_daily 分 kind 深度：concept/industry 均 07-10~07-23 共 7 天， stock 07-10~07-24 共 9 天。 结论①：快照史与 live 传导史（07-11 起）同龄，§7"近似区间前推"没有空间， 该讨论正式关闭——传导只 live 定案；改3 的价值回归纯 live 正确性。 结论②（新异常）：07-24 有 stock 快照而 concept/industry 止于 07-23，kind 间 新鲜度错位实锤（17:30 快照任务疑似部分失败，查当日 sync 日志）；改3 的 mkt_trade_date 告警须覆盖"非 stock kind 落后"情形。
  3. ✅(07-27 已回) 环节成员数：Segment 9663 组 max 217、>200 仅 1 组（整机制造， 实测已被 cap 截到 200）；Concept 31993 组 max 4010、>200 有 10 组——巨组多为 资质类垃圾标签（高新技术企业 4010 / 小型微利企业 843 / 联营企业 298），但真实 热门题材也超（人工智能 449 / 新能源 380）。⇒ 改2 拍板：moved_ratio / quiet 改 不截断聚合口径（推荐）或再提 cap；顺带把资质类概念挡在传导主题源之外。
  4. ✅(07-27 已迁) cron 曾装错机器（基座机 tlai4090），已清零并改装到 factor@factorevaluation（40 18 * * 1-5，build all daily 自动带 freeze）。 data/frozen/ 尚无 = freeze 从未跑过 ⇒ 今晚 18:40 首跑，明早验 data/frozen/2026-07-27/ + data/cron_build.log（若报 service not running， exec 换 run --rm）。
  5. ✅(07-27 已回) 两项判收读数： ①probe 全输出已回：universe 316 主题 / 2391；热度覆盖 100%（2389/2391）； 事件 13~15%；传导近窗并集 6%。新发现：probe 的 upside 分节走基座内部 mkt_daily 现价路径，算出"可算 0/2391"且"有现价仅 727/2391"——是 probe 侧 连接伪象或 mkt_daily stock 快照本身只存部分股票（待五-7 定位）；与桥的 upside （gp_day_data 现价，795 行正常落库）不同源，不影响因子。 赛道覆盖初判：核聚变系（可控核聚变16/核聚变15/聚变10/托卡马克装置29，有重叠）、 商业航天 69、低空经济 95、脑机接口 20、6G 21、氢能 53 全部非空，"空赛道" 担忧初步解除；但主题名碎片化严重（核聚变 4 种写法、AI算力 2 种、"无"41 / "报告分部"3 等垃圾主题）= G2 映射 yml 的实际工作面。 ②gp_day_data 按年：1997~2006 稀疏（34~119 天/年），2007 起完整（≈250 天/年） ⇒ 可信起点定为 2007-01-01；§6.2 ⚠️ 关闭，§7"理论可回填到 2006"修正为 2007。
  6. 二批全落地后：重跑 probe 的 corr / 权重 / 票数三张读数（三批的拍板依据） ——等 2~3 个新制度交易日，建议 07-30 前后

六、二批完整测试清单（今晚 19:30 定时提醒已设）

前提：四处改动 + 桥 cron 已部署（17:30 前 pull + force-recreate backend/worker/worker-interactive/beat；赶不上则明天跑同一清单）。

  1. 17:35 基座·快照健康：mkt_daily 当日分 kind 行数——三 kind 齐 + stock≈2391（≈1675=池源滞后新问题；缺 kind=又挂，查日志）
  2. 18:20 基座·台账判收：按 scan_date 汇总 candidates / quiet_rows 总数 / mkt_trade_date / max(members_total)，期望 quiet_rows 远超旧 144 帽、 mkt_trade_date=当日、max_members≤600；逐行不变量 (members_total − moved) = jsonb_array_length(quiet)
  3. worker 日志 grep：行情快照|异常少|大主题闸（快照健康时前两者不应出现）
  4. 改3 只读验证：容器内 _latest_mkt("stock", date(2026,7,23)) 应返回 (2026-07-23, 1675 行)；_movers_set(date(2026,7,23)) 与不传参数的最新日结果可不同
  5. 改4 单日试跑：sync_consensus(asof=date(2026,7,18)) → 该 asof 行数 >0 且 live 行不受影响（上界由代码保证，gp_report_rc 侧可抽查）
  6. 桥机 18:45+：ls data/frozen/（应有 2026-07-27/）+ tail data/cron_build.log （service not running 则 exec→run --rm）
  7. 顺手：07-24 的 17:30 sync 日志（受污染日根因）

六节判收结果（07-27 晚实测）：0✅新码三真｜2✅quiet_rows 410（旧制 93/102， 约 4.4×），不变量 12/12 全 t，mkt_trade_date=07-24 如实打标，max_m=99 未触闸 （整机制造 217 图成员中上市仅 99，改1 的上市优先排序本就保住了它）｜4✅钉死 07-23=(07-23,1675 行)，movers 按日分明（479 vs 75）｜5✅asof=07-17 写 1388 行、 live 无扰、核销=0（闸生效；1388≫邻近 live 行=当前池口径回填的预期形态） ⇒ 改1~4 机制层全部判收通过，二批关账。

新仪表首夜逮住的两起事故（待办）： A. 07-27 当日 mkt 无数据 → 定性=源侧迟到（07-27 晚二读）：源 MAX(timestamp) 19:50 时已=2026-07-27，而 17:30 sync 只见到 07-24（顺手把它 727→2389 修复、 三 kind 补齐——sync 本身没坏，取"源侧最新"照章办事）。当晚修复链已给 （sync 手动重拍→hotspot→transmission 同日重扫→桥补建，命令在对话）。 结构性建议待拍板：beat 加"第二拍"sync-market（如 09:55 UTC=17:55 CST， 幂等删后插，首拍已有当日则等效空操作），基座 workers/tasks.py 一行。 佐证：akg.sync_market_snapshot 路由 interactive 队列（tasks.py:43） ⇒ 快照/传导的运行日志在 worker-interactive 容器，不在 worker—— 六-3 的 grep 落空即此因。 B. 桥 cron 首夜失败（两层）：①data/ 为容器 root 属主，宿主重定向 Permission denied——日志已改 $HOME 路径；②cron 时刻的宿主时区未定： 若桥机宿主是 UTC，40 18 实为凌晨 02:40 CST（我给错，已认领）—— 跑 date 判定后改 40 10（UTC）或保持 40 18（CST）。 ③桥容器 date.today()=2026-07-28（run.py daily 裸取 today → 空跑出 2026-07-28 垃圾目录、四路 0 行）——容器时钟/TZ 待测；治本=cron 行加显式 --date $(date +\%F)（宿主取日，两种宿主时区下均正确），已并入修复命令。 遗留小项：consensus 历史 07-16/07-22 空日（低优先）。 probe 三张读数提醒已钉 07-30 周四 19:00。 工作规约（07-27 用户令）：所有命令必须标注运行机器—— 【基座机 tlai4090·astock-kg】/【桥机 factorevaluation·akg-factor-bridge】。

07-28 晨复盘（事故收口）：

  • A 关闭：修复链完成——07-27 mkt 三 kind 补齐（2389/386/90）；根因=源迟到实锤 （次晨重拍即得完整当日）。第二拍已落码（beat 表 sync-market-2nd，17:55 CST， beat 配置本就是 Asia/Shanghai 时区，直接写 17:55）——部署=基座 pull 后 force-recreate beat。拍板记录：07-27 传导台账不重扫，保持 mkt_trade_date=07-24 的降级标记（重扫=今日图谱套昨日，成员性前视；降级标记正是采信规则的输入）。
  • B 关闭：桥宿主=UTC 实锤 → cron 已改 40 10（=18:40 CST）+ 显式 --date $(date +\%F)；"容器 07-28 之谜"消解——那批命令实际在次晨 UTC 零点后执行， 容器 UTC 无时钟病。frozen=07-24+07-27（垃圾 07-28 已清）。桥代码为卷挂载 （compose .:/app），pull 即生效无需 rebuild。
  • C（新，已修）：桥自检两条旧制度判据假阳性（">=30 撞 cap30" 6 条误报、 "quiet 存满 12" 7 条误报）——已重写：mkt_trade_date 检查保留（07-27 实测有效， 桥打出"该日传导项不可信"=链路端到端贯通的实证）；members_total>600（大主题闸值） 才告警=制度回退 tripwire；新增不变量检查 n_quiet_stored=members_total−moved。 config.UPSTREAM_MEMBER_CAP 默认 30→600，UPSTREAM_QUIET_CAP 废弃。
  • 07-27 补建因子读数：transmission 302 行（旧制 83）/ heat 2387 / upside 992 / event 531；segment_members/edges 0 行=投影表未建，预期内（三批-4）。
  • 07-28 晨间占位台账（hotspot 32 候选 / transmission 12 候选 quiet 218，09:25 建） 今晚 18:00/18:15 beat 删后插自然覆盖，无需处理。
  • 今晚（07-28）=首个全自动夜，明晨验：①mkt_daily 07-28 三 kind（第二拍是否兜住） ②传导台账 mkt_trade_date=07-28 ③桥 cron 10:40 UTC 首次正点（frozen/2026-07-28 重新出现 + 因子行数非 0 + 新自检无假阳性）。
  1. ✅(07-27 已回) mkt_daily stock 按日行数：52/52/131/81/1674/1674/1675/1675/727 （07-10~07-24，缺 07-16、07-21）。四个结论： ① stock 快照 = 池内快照非全市场（1674≈当时池规模）——probe"有现价 727" 即 07-24 部分写入所致，五-5① 伪象定位完毕； ② 07-24 的 17:30 sync 中途挂（stock 只写 727/2391，concept/industry 0 行） ⇒ 当日传导在残缺行情上算出，07-24 记为受污染日； ③ 快照史 flaky：07-16、07-21 整日缺，07-10~15 仅 52~131 行 ⇒ 传导 live 完好起点 = 07-17（完好日仅 17/20/22/23 四天）； 快照完整性建议纳入周检/巡检（非二批）。 ④ 今晚 17:30 盯行数：≈2391=健康且池源同步；≈1675=sync 用滞后池源（新问题）； 再挂=马上查日志。07-24 缺口的 sync 日志仍待查。