修复:TTM 股息率两处残余缺陷 + 公司行为三处静默错误;新增回测级排除行业清单
说明:本提交是工作区中此前的未提交工作(在 cf6d4d2 之后产生),**非本次会话所写**,
按用户要求**不跑测试、直接记录变更并推送**。
已完成推送前的基础安全检查:无明文凭据、无大文件、`.env`/`logs/`/`output/` 仍被忽略。
测试状态:**本次未执行测试套件**。
## 一、TTM 股息率的两处残余缺陷 + 卖出复核
起因:用户报告 `600690.SH` 在 2026-07-30 触发清仓、07-31 开盘卖出,实际不该卖。
### 缺陷一:同一除权日的多条「实施」记录被逐行累加
- 成因:`hd_dividend` 写入侧刻意保留全量公告记录,去重键含 `ann_date`,
同一笔分红会有多条「实施」记录落在**同一除权日**;查询侧逐行累加即重复计入。
- 规模:5724 只有现金分红的股票中 **953 只**存在同除权日重复(多出 1313 行)。
- 效果:`600690.SH` 的 `ttm_dps` 长期虚高约一倍(2.46848 vs 真实 1.23424),
窗口到期时又必然回落,把假象放大成一次 −78% 的塌陷。
- 修法:新增 `factor.dividend_yield.dedupe_dividend_events()`,按 `(symbol, ex_date)`
聚合成**一笔经济事件**(金额/股数逐字段取最大 → 收敛「分项 + 合计」;
日期取最晚 → PIT 保守)。三处入口统一调用:`ttm_dps_series`、
`Repo.dividend_events`、`universe/filters/dividend.py`。
### 缺陷二:只看相邻间隔,漏掉「年度 → 中期 → 下一年度」的跳法
- 成因:7.6 的「按后继接管」只看相邻两次除权的间隔。实测 `600690.SH`:
FY2024 年度 2025-07-25、FY2025 中期 2025-11-07、FY2025 年度 2026-08-21。
105 天的间隔使前两笔被判为「年内多次分红」而互不取代,392 天又超过 `365+45`
→ **2026-07-25~08-21 出现 28 天空窗**,可见现金只剩 0.26920。
- 修法:`ttm_dps_series` 的覆盖窗口由「按相邻间隔」升级为「**按财年 `end_date`**」:
① 后继接管(保留 7.6 行为,阈值 `ttm_days - grace_days` = 320 天);
② **跨财年补位**:每个财年最后一笔 → 下一财年最后一笔入场,上限 `365 + grace`;
③ **末笔宽限兜底**:无后继时覆盖 `365 + grace`(真停发仍如实归零)。
- 验收(作者实测):600690 在 2026-07-27 的 `ttm_dps` 由 0.53840 变为 **1.23424**,
股息率 5.30%、历史分位 92.98%,**不再触发 P25 清仓**。
### 缺陷三(设计缺口):卖出只认「已除权的现金」,不认「已公告的分红」
- 成因:FY2025 年度分红 0.89151 的**实施公告日是 2026-06-25**,除权日 2026-08-21。
TTM 现金口径看不到它 → 「股息率处于历史低位」在字面上为真,
实际描述的是**现金流时点**而非分红能力恶化。
- 修法:新增 `entry/exit.confirm`(`enabled` / `min_ratio` / `announce_lookback_days`):
若「已公告未除权」的分红说明股息率本应更高,且
`TTM ÷ (TTM + 已公告未除权) < min_ratio`,则判定**未确认**:
保持仓位并记录 `EXIT_UNCONFIRMED`(不进成交流水)。真降息不会命中。
## 二、公司行为的三处静默错误(分红/送转/配股口径)
### 问题一:纯送转被整行丢弃(凭空亏损)
- `_apply_dividends` 在算送股**之前**就按 `cash_div_tax <= 0` 整行 `continue`,
于是「10 送 10」这类**无现金分红**的送转完全不调股数 ——
而价格是不复权价、除权日照常腰斩 → 记出一笔不存在的亏损。
- 规模:全库「实施且 `stk_div > 0`」13,038 行,其中**纯送转 3,268 行**;
高股息池成员在 2015-2026 区间内 **824 笔**(如 `000793.SZ` 每 10 股转增 12 股,
单笔约 −54% 的该持仓市值)。
- 修法:现金与送转**各自独立判断**,只有「既无现金也无送转」才跳过;
并把 `stk_bo_rate`/`stk_co_rate` 写入分红台账留痕。
### 问题二:同一除权日的重复记录被重复入账
- 全库 **1401 组**同 `(symbol, ex_date)` 的多条实施记录(1240 组字段相同;
96 组报告期不同、122 组金额不同)。实测 `002352.SZ 2024-11-07` 同时有
0.4 / 1.0 / 1.4 三条,而 1.4 = 0.4 + 1.0 是合计口径 → 逐行累加会放大两三倍。
- 修法:复用 `dedupe_dividend_events`(与缺陷一同一个函数)。
### 问题三:分红再投资的声明与行为不一致
- 引擎实际行为一直是「分红现金回到与初始资金同一个 `cash` 变量,
下次调仓按目标权重再配置」= `reinvest` + `portfolio_rebalance`;
但 `backtest.yml` 写的是 `same_stock_next_open`,于是每次 run 都声明
「未实现分红再投资规则,分红留存为现金」,让人误以为分红不可再投资。
- 修法:配置改为已实现组合 `cash_mode: reinvest` + `reinvest_rule: portfolio_rebalance`;
声明逻辑抽成 `dividend_handling_notes()`,**逐档取值都有单测**对应
(`hold`/`cash_out`/`same_stock_next_open`/`handle_stock_dividend=false`/配股
才声明未实现)。顺带接线一直是**死字段**的 `dividend.apply_dividend_tax`。
## 三、新增:回测层面的排除行业清单(黑名单)
- 位置与语义:`config/backtest.yml: universe_exclusions.industries` ——
「**这次回测**特意不要哪些行业」(研究口径),
与 `config/universe.yml`(策略选股定义)**叠加取并集**,只做减法。
三种回测模式(single / walkforward / daily)一律生效。
- 最大的坑:数据库 `stock.industry` 里**没有「房地产业」**,它被拆成四个名字,
写「房地产」或「房地产业」**一只都排除不掉**:
`全国地产` 26 只 + `区域地产` 43 只 + `房产服务` 13 只 + `园区开发` 14 只 = **96 只**(1.6%)。
因此 `MarketFilter` 首次求值时拿名单与表内实际取值核对,
**写错名字直接抛 `ConfigError`**(并按字符重合度提示最接近的真实取值)。
- 接线:三个入口都走生效后的配置;并修掉一处缓存陷阱(配置变更后缓存未失效)。
- 新增测试锁定它。
## 四、其它
- `src/hdiv/core/config.py`:新增配置模型(排除行业、卖出复核等,+102 行)
- `src/hdiv/data/repo.py`(+45)、`src/hdiv/backtest/engine.py`(+121)、
`backtest/daily.py`、`backtest/walk_forward.py`、`web/service.py`、
`report/universe_report.py` 相应接线
- 测试:新增 `tests/test_dividend_fiscal_year.py`;扩充
`test_backtest.py` / `test_config.py` / `test_daily.py` /
`test_dividend_smoothing.py` / `test_universe.py`
- `tools/diag_dividend_artifact.py`:诊断脚本与上述修复对齐
- 文档:`docs/implementation-status.md` 新增 §7.6b / §7.7 / §11;
`docs/user-guide.md` 新增排除行业清单说明
## 待验证
本次按要求**未执行测试**。上述「实测/验收」数字均引自文档中作者自己的记录,
非本次会话验证结果。建议合入后跑一次全量测试(注意:daily 的 DB 标记测试
因 `hd_cashflow` 无界扫描仍然很慢)。
This commit is contained in:
@@ -14,6 +14,31 @@ period:
|
||||
start: 2015-01-01
|
||||
end: latest
|
||||
|
||||
# ------------------------------------------------------------
|
||||
# 排除行业清单(股票池黑名单)
|
||||
#
|
||||
# 语义:按 stock.industry **精确匹配**(区分字面,不做前缀/模糊匹配),
|
||||
# 命中的股票在股票池阶段就被淘汰,三种回测模式
|
||||
# (single / walkforward / daily)一律生效。
|
||||
#
|
||||
# 与 config/universe.yml 的关系是**叠加**,不是覆盖:
|
||||
# universe.yml —— 「什么样的公司够格」(市值/分红/质量 + 行业豁免)
|
||||
# 本清单 —— 「这次研究特意不要哪些行业」
|
||||
# 因此本清单只会让股票池变小,不会放宽任何既有条件。
|
||||
# 若 universe.yml 自己也声明了 industry_exclusions,两者取并集。
|
||||
#
|
||||
# 行业名必须与数据库 stock.industry 逐字一致。查当前取值:
|
||||
# SELECT industry, COUNT(*) FROM stock GROUP BY industry ORDER BY 2 DESC;
|
||||
# 留空 [] = 不排除任何行业。
|
||||
# ------------------------------------------------------------
|
||||
universe_exclusions:
|
||||
# 房地产业。注意:数据库里**没有**「房地产业」这个标签,它被拆成四个行业名,
|
||||
# 所以这里要写全四条,只写「房地产」不会有任何匹配:
|
||||
# 全国地产 / 区域地产 —— 房地产开发(万科A、保利发展、金地集团…)
|
||||
# 房产服务 —— 物业/中介/房产服务(招商积余、我爱我家…)
|
||||
# 园区开发 —— 开发区与园区运营商(陆家嘴、张江高科…)
|
||||
industries: [全国地产, 区域地产, 房产服务, 园区开发]
|
||||
|
||||
# ------------------------------------------------------------
|
||||
# 调度:多久评估一次信号、多久重建一次股票池
|
||||
# ------------------------------------------------------------
|
||||
|
||||
@@ -91,6 +91,27 @@ exit:
|
||||
stop_loss_pct: null
|
||||
max_holding_days: null
|
||||
|
||||
# ----------------------------------------------------------
|
||||
# 清仓前复核:防止「现金流时点」被当成「分红能力恶化」
|
||||
#
|
||||
# TTM 股息率只统计**已除权**的现金,因此在窗口边界上必然有台阶:
|
||||
# 上一年度分红满 365 天退出,而本年度分红可能还没除权。实测
|
||||
# 600690.SH 2026-07-30:FY2025 年度分红 0.89151 早在 2026-06-25
|
||||
# 就已实施公告(除权日 2026-08-21),当时可见现金只剩中期 0.26920,
|
||||
# 分位 0.1% ≤ P25 触发清仓 —— 实际不该卖。
|
||||
#
|
||||
# 规则:若「已公告未除权」的分红说明股息率本应更高,且
|
||||
# TTM ÷ (TTM + 已公告未除权) < min_ratio,则判定未确认:
|
||||
# 保持仓位并记录 EXIT_UNCONFIRMED(不进成交流水)。
|
||||
# 真降息(公告金额本身就低或无公告)不会命中。
|
||||
# ----------------------------------------------------------
|
||||
confirm:
|
||||
enabled: true
|
||||
# 比值下限:0.8 表示「已公告分红足以把股息率抬高 25% 以上」才拦截
|
||||
min_ratio: 0.8
|
||||
# 只回溯这段时间内公告的分红(自然日)
|
||||
announce_lookback_days: 400
|
||||
|
||||
# ------------------------------------------------------------
|
||||
# 仓位控制(plan.md §20)
|
||||
# ------------------------------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user