基金量化定投选基系统

# 《基金量化定投选基系统》项目章程

**项目名称：** 基金量化定投选基系统

**项目编号：** 2026-04-11-01

**项目经理：** Henry Lin

**日期：** 2026-04-11

**文档状态：v1.0.0

---

## 一、项目背景与立项理由

传统基金挑选依赖历史绝对收益排名或主观定性判断，严重忽略投资者在"周定投"场景下的真实盈利体验（浮盈回撤、止盈周期过长）。本系统旨在通过纯数据驱动与严密的时序逻辑，量化评估基金在"等额周定投"模式下的表现潜力。

立项核心理由：构建一套基于 LightGBM 的机器学习排序模型，精准识别能在 **150 周内以 DCA（简单平均成本法）实现 20% 止盈**的基金。解决"基金赚钱、基民不赚钱"的痛点，为业务端提供硬核的量化选基支撑，提升资产配置的科学性与客户持有体验。

## 二、项目目标

| 编号 | 目标项 | 具体描述 | 衡量标准 |

|------|--------|---------|---------|

| G-1 | 工程交付 | **8 个自然周**内完成端到端流水线 | 6 个 Step 全部通过验收 CheckList |

| G-2 | 技术底线 | 100% 遵守《最终设计规约 (v1.0)》铁律 | CI 强阻断触发率 = 0 |

| G-3 | 模型指标 | Top 20 推荐分桶显著跑赢等权基准 | 年化收益率、Sharpe、止盈成功率三指标均优于基准 |

| G-4 | 质量卡控 | 标签生成器 7 场景单测全过 | pytest 通过率 100% |

## 三、成功标准

项目达到"Done"状态的绝对验收条件：

- **规约符合度**：所有代码实现与 `/docs` 技术文档无任何偏离规约核心参数（150周、20%止盈、年化2.0%无风险利率、MAD边界3.0、共线性阈值 |r|>0.90 等）。

- **资源安全度**：在 64GB/36核 实体机上，端到端全量刷盘重训峰值内存 ≤ 50GB，CPU 峰值使用率 ≤ 80%，不触发 OOM。

- **产物完整性**：产出按年分区 Parquet 数据、SHA-256 数据血缘校验文件、标准化参数持久化文件、MLflow 实验记录、SHAP 归因图、四桶回测净值曲线。

- **流水线闭环**：在 Ubuntu 24 Docker 环境下，通过一条主指令完成"全量刷盘重训 → 自动评估 → 自动归档模型"全流程无人工干预运行。

## 四、关键干系人

| 角色 | 职责 | 核心关注点 |

|------|------|-----------|

| 项目经理（PM） | 规约守护者、交付卡控 | 红线不被违反，里程碑按期达成 |

| 算法/研发工程师 | 6 个 Step 模块实施 | 受限算力下实现高性能、合规代码 |

| 数据资产管理员 | 提供原始数据源 | 数据规模、质量与可用性 |

| 基础架构/运维 | Ubuntu 24 实体机与工具链 | Docker 部署、Gitea/Redmine/MLflow 可用性 |

## 五、项目范围与边界

### 包含在内（In Scope）

- 周频数据基础清洗（去重、异常值处理、长缺失截断、建仓期硬删、类型白名单过滤）

- 5 大类 40+ 维特征工程化计算、T-1 截面标准化、共线性剔除

- DCA 标签生成（20%止盈、150周窗口、样本平衡）

- LightGBM 模型训练（TimeSeriesSplit 5折、Optuna 超参搜索）

- 单基金查询与批量推荐推理服务（含 SHAP 归因与决策文本）

- Redmine 管理视图 + Gitea `/docs` 技术真相源双轨制文档建设

### 坚决不做（Out of Scope）

| 编号 | 边界项 | 理由 |

|------|--------|------|

| OB-1 | 日频/分钟频数据 | 仅处理周频，规约已锁定 |

| OB-2 | 增量更新机制 | 每周全量刷盘重训，规约 D-5 已锁定 |

| OB-3 | 真实交易闭环 | 不涉及资金自动扣款与报盘 |

| OB-4 | 费用扣除模拟 | `deduct_fee: false` 保持关闭 |

| OB-5 | UI 可视化前端 | 交付物为 API/脚本级推理能力 |

| OB-6 | DuckDB 滚动窗口计算 | FW-2 铁律严禁 |

| OB-7 | Pandas 依赖 | 全局禁止（LightGBM 内部除外） |

---

## 六、数据资源基线（已确认）

基于您提供的实际数据样例，已完成数据规模与内存安全评估：

### 6.1 净值表 `fund_net_info`

| 指标 | 数值 | 说明 |

|------|------|------|

| 单文件物理大小 | **920.1 MB** (CSV) | 全量原始数据 |

| 估算总行数 | **~2,300 万行** | 920.1MB ÷ 100行/4KB ≈ 23M |

| 单行字段 | `id`, `fund_id`, `cumulative_net_value`, `net_value_date` | `id` 为主键，清洗阶段丢弃 |

| 净值数据范围 | 2015-12-07 起 | 样例最早日期，覆盖约 10 年周频 |

| Parquet 预估大小 | **200-300 MB** | 列式压缩，通常为 CSV 的 1/3~1/4 |

| Arrow 内存预估 | **800 MB - 1.2 GB** | 3 有效列 × 23M 行 |

### 6.2 基金信息表 `fund_basic_info`

| 指标 | 数值 | 说明 |

|------|------|------|

| 总记录数 | **~26,000 条** | 全量基金信息 |

| 单文件物理大小 | **~4.2 MB** (CSV) | 10行/1.6KB × 2600 = ~4.16MB |

| 规约使用字段 | `fund_id`, `fund_name`, `fund_type`, `create_date` | 仅这 4 列 |

| **需丢弃字段** | `insert_datetime`, `update_datetime`, `insert_operator`, `update_operator` | **⚠️ 实际表比规约多 4 列，data_loader 必须显式丢弃** |

### 6.3 类型白名单覆盖率（基于样例推断）

| 样例中的 fund_type | 是否在白名单中 |

|-------------------|--------------|

| 混合型-灵活 | ✅ 保留 |

| 混合型-偏股 | ✅ 保留 |

| 债券型-混合二级 | ❌ 过滤 |

| 债券型-混合一级 | ❌ 过滤 |

| 指数型-股票 | ❌ 过滤 |

| 货币型-普通货币 | ❌ 过滤 |

> **推断**：26,000 只基金中，白名单 6 类（股票型、混合型-偏股、混合型-灵活、QDII-普通股票、QDII-混合偏股、QDII-混合灵活）预估保留 **5,000-10,000 只**。Step 2 数据基建完成后，数据质量审计日志需输出精确的白名单保留率，作为 Redmine M2 验收依据之一。

### 6.4 内存安全结论

| 处理阶段 | 预估内存占用 | 安全等级 |

|---------|-------------|---------|

| DuckDB 读取原始 CSV → 按年分区 Parquet | 5-10 GB | 🟢 安全 |

| DuckDB JOIN fund_basic_info（26K 行） | 增量 < 1 GB | 🟢 安全 |

| Polars 单年份 Arrow 转换（≤300万行 × 3列） | 1-2 GB | 🟢 安全 |

| Polars 单年份特征计算（≤300万行 × 40+特征） | 15-25 GB | 🟡 需串行 |

| **总计峰值（严格 FW-3 按年串行）** | **≤ 40 GB** | 🟢 低于 50GB 软限 |

> **核心防线**：严格执行 FW-3（按年份串行提取）+ DuckDB `memory_limit='40GB'` 硬限 + CI 环境 cgroup 50GB 压测。

---

## 七、高层级里程碑计划（8 周微步迭代）

```

Week 1          Week 2-3        Week 4-5         Week 6-7        Week 8

   │               │               │                 │               │

   ▼               ▼               ▼                 ▼               ▼

┌────────┐    ┌──────────┐   ┌────────────┐    ┌────────────┐   ┌──────────┐

│ Step 1 │───>│  Step 2  │──>│Step 3 & 4  │───>│   Step 5   │──>│  Step 6  │

│ 脚手架 │    │ 数据基建 │   │ 并行攻坚    │    │ 模型训练   │   │ 推理收口 │

└────────┘    └──────────┘   └────────────┘    └────────────┘   └──────────┘

   │               │            ┌──┴──┐              │               │

   ▼               ▼            ▼     ▼              ▼               ▼

 CI空跑       Parquet产出   特征引擎  标签器      MLflow记录     Production

 成功         审计日志通过   标准化   7场景单测     四桶回测       模型打标

              白名单覆盖率   参数输出  全绿         跑赢基准       文档闭合

              内存≤40GB                                         全部同步

```

### 各 Milestone 详细交付与 Done 标准

| MS | 周次 | 交付物 | Done 标准（硬卡点，缺一不可） |

|----|------|--------|------------------------------|

| **M1** | W1 | `pyproject.toml`、目录树、`config.yaml`、`config.py`、`logging.py`、`hash.py` | ① CI 空跑流水线在 Gitea 触发成功，无 Error；② `config.yaml` 参数与规约第七节完全一致 |

| **M2** | W2-W3 | `data_loader.py` + 按年分区 Parquet + DuckDB VIEW + 数据质量审计日志 | ① Parquet 文件产出，Schema 仅含 `fund_id`/`net_value_date`/`cumulative_net_value`；② 实体机压测峰值内存 ≤ 40GB；③ 审计日志包含：白名单保留率、缺失率、异常率、建仓期剔除数、存活期过滤数；④ `fund_basic_info` 多余 4 列已显式丢弃 |

| **M3a** | W4-W5 | `feature_engineering.py` + `features.parquet` + `standardization_params.parquet` + `final_feature_list.json` | ① 特征数 ≥ 40 维且全部为**长表形态**（严禁 Pivot 宽表）；② 首日（数据集第一天）所有标准化特征输出 NULL（T-1 Shift 验证）；③ `standardization_params.parquet` Schema 与规约 4.3 节一致；④ CI 强阻断通过 |

| **M3b** | W4-W5 | `label_generator.py` + `labels.parquet` + `test_label_generator.py` | ① 7 个必覆盖场景单测 100% 全绿；② label 值域严格为 [0, 149]；③ 正样本单基金上限 50 条、负样本上限 15 条；④ 等距抽样使用 `np.linspace` |

| **M4** | W6-W7 | `trainer.py` + 模型文件 + 回测报告 + SHAP 图 + MLflow 记录 | ① AUC、NDCG 指标记录完整；② Top 20 桶年化收益率、Sharpe、止盈成功率均优于全标的池等权基准；③ MLflow Production 标签打标成功；④ SHAP summary plot 与四桶回测净值曲线产出 |

| **M5** | W8 | `inference.py`（单基金 + 批量） | ① 单基金输出：得分(0-100) + Top5 正负特征 + 决策文本；② 批量接口返回排序 DataFrame；③ 得分区间文案与规约 6.3 节完全一致；④ Gitea `/docs` 与 Redmine 状态 100% 同步 |

### 里程碑前置依赖（Redmine 强制卡控）

```

Step 1 ──✓──> Step 2 ──✓──> Step 3 ──┐

                              ──✓──> Step 4 ──┤──✓──> Step 5 ──✓──> Step 6

                                              └───────────────────┘

```

- Step 5 任务开启 **必须** 等待 Step 3 和 Step 4 在 Redmine 中状态均闭合

- Step 6 任务开启 **必须** 等待 Step 5 闭合

---

## 八、模型训练时间规划（关键算力约束）

> **已确认决策**：Optuna 采用 **策略 A（单折搜索）**——Optuna 仅在 TimeSeriesSplit 最后一个 Train/Val 折上搜索超参，找到最优后用该超参在其余折做最终评估。搜索与评估解耦，兼顾效率与质量。

### Step 5 整体时间拆解（纯 CPU / 36核）

| 阶段 | 预估耗时 | 说明 | 时间属性 |

|------|---------|------|---------|

| ① 数据加载与 JOIN | 2-5 分钟 | Polars 读取 features + labels | 固定 |

| ② TimeSeriesSplit 数据切分 | < 1 分钟 | 纯索引操作 | 固定 |

| ③ 每折：截面标准化 + 共线性筛选 | 10-20 分钟（×5折） | 串行执行，每折独立 | 固定 |

| **④ Optuna 超参搜索（单折）** | **≤ 60 分钟** | ⚠️ **1小时硬限仅此阶段** | 硬限 |

| ⑤ 用最优参数 5 折重训最终模型 | 5-10 分钟 | 单次训练 | 固定 |

| ⑥ 评估：AUC / NDCG / 四桶回测 | 15-30 分钟 | 含回测净值曲线计算 | 固定 |

| ⑦ SHAP 归因分析 | 10-20 分钟 | TreeExplainer | 固定 |

| ⑧ MLflow 日志写入 | < 2 分钟 | Artifact 序列化 | 固定 |

| **Step 5 总计** | **约 2-3.5 小时** | 可设在非交易时段执行 | — |

**关键保障措施**：

- Optuna 配置 `early_stopping_rounds=50`，加速无效试验的提前终止

- 1 小时到达时通过 `optuna.study.Study.optimize(timeout=3600)` 强制截断，取已有最优超参

- 最终模型质量仍通过完整 5 折交叉验证评估，搜索与评估完全解耦

---

## 九、预算与资源分配

### 9.1 计算资源

| 资源项 | 规格 | 使用策略 |

|--------|------|---------|

| CPU | **36 核**（实体机） | Polars 重度计算节点显式指定 `n_threads=24`，预留 12 核给 OS / DuckDB IO 缓冲 |

| 内存 | **64 GB** DDR | DuckDB 硬限 `memory_limit='40GB'`；Polars 按年串行处理；整体峰值 ≤ 50GB |

| GPU | **无** | 不依赖，LightGBM 纯 CPU 训练 |

| 存储 | **SSD（容量充足）** | Parquet 分区 + MLflow Artifact 归档 + 日志 |

| 操作系统 | **Ubuntu 24** | Docker 部署，隔离运行环境 |

### 9.2 工具链

| 工具 | 用途 | 核心约束 |

|------|------|---------|

| Gitea | 代码仓库 + 技术真相源 `/docs` | 所有技术文档 Markdown 存放于仓库 `/docs` 目录 |

| Redmine | 任务管理 + 规约追踪中枢 | 规约条款写入自定义字段-验收标准 |

| MLflow | 实验追踪 + 模型版本管理 | Production/Archived 标签管理 |

| Docker | 运行环境隔离 + CI/CD | 质量红线强阻断/软预警 |

| DuckDB | Parquet IO / JOIN / 过滤 | 严禁滚动窗口（FW-2） |

| Polars | 滚动窗口 / 特征计算 / 标签生成 | 按年份串行（FW-3） |

| LightGBM | 模型训练 | 唯一允许隐式调 Pandas 的环节 |

| Optuna | 超参搜索 | 单折搜索，1小时硬限 |

---

## 十、关键风险预警

| 编号 | 风险项 | 触发条件 | 影响 | 应对策略（规约级防御） |

|------|--------|---------|------|----------------------|

| R-1 | 内存溢出 (OOM) | 违反 FW-3 多年份并发 Arrow 转换 | 🔴 致命 | ① DuckDB 硬限 40GB；② CI 设 cgroup 限 50GB 压测；③ 代码 Review 重点检查按年循环 |

| R-2 | Optuna 在 CPU 下搜索不充分 | 36 核 CPU、大训练集 | 🟡 可控 | 1小时硬限截断取最优；`early_stopping_rounds=50`；单折搜索策略最大化试验次数 |

| R-3 | T-1 未来数据泄露 | 标准化未执行 `.shift(1)` | 🔴 致命 | ① 单测强制覆盖首日输出 NULL；② CI 加专项断言；③ 代码 Review 最高优检查项 |

| R-4 | 8 周紧凑致规约妥协 | 并行开发时省略 Type Hints / 单测 | 🟡 可控 | CI 强阻断红线，PR 触发 Error 则绝对禁止合并 |

| R-5 | fund_basic_info 多余字段污染 | data_loader 未丢弃 4 列非规约字段 | 🟢 可防 | ① `data_loader.py` 显式指定列投影 `SELECT fund_id, fund_name, fund_type, create_date`；② M2 审计日志输出实际列名 |

| R-6 | 白名单覆盖率异常低 | 实际数据中白名单类型基金占比过低 | 🟡 待观测 | Step 2 审计日志必须输出精确的白名单保留率；若 < 15%，PM 组织专项评审 |

---

## 十一、项目经理职权

| 编号 | 职权 | 说明 |

|------|------|------|

| A-1 | 一票否决权 | 任何违背《最终设计规约 v1.0》的代码提交或设计妥协，直接打回 |

| A-2 | 流程阻断权 | Redmine 前置依赖未达"产物正确+单测全过+CI不报错"标准时，锁定下游任务 |

| A-3 | 资源调度权 | 64GB 内存约束下，随时要求研发调整 Polars 并发度或暂停非核心进程 |

| A-4 | 技术债登记权 | 客观原因导致临时偏离规约时，强制责任方在 Redmine 录入技术债单并设定清理 Deadline |

---

**项目经理签字：**

Henry Lin

**日期：**

2026-04-11