Simon
880f4c50fe
- pyqlib（0.9.8.dev32 源码安装）验证：import / 数据落盘 / storage 底层读回 / Alpha158 / LGBModel 均通过（scripts/qlib_verify.py 可重复）
- 记录格式要点：小写 instrument、instruments 3 列、provider_uri 需 {'day': path} 字典
- 如实记录未打通项：D.features→训练→回测高层链路仍待 QlibEngine 实现（建议按官方 dump 规则落盘）
- 项目回归保持 81 passed / ruff clean
76 lines
4.6 KiB
Markdown
76 lines
4.6 KiB
Markdown
# Qlib 安装与可用性验证报告
|
||
|
||
> 验证时间：2026-09 · 环境：Linux aarch64 / CPython 3.12.13（uv 虚拟环境）
|
||
> 安装方式：pyqlib 源码 git 安装并固定 commit（`pyqlib @ git+https://github.com/microsoft/qlib.git@79633dd`，见 `backend/pyproject.toml`）
|
||
> 复现：`cd backend && uv run python ../scripts/qlib_verify.py`
|
||
|
||
---
|
||
|
||
## 结论摘要
|
||
|
||
| 项目 | 结果 |
|
||
|---|---|
|
||
| qlib 导入与版本 | ✅ `qlib.__version__ == 0.9.8.dev32` |
|
||
| 依赖组件 | ✅ lightgbm 4.7.0 / scipy / sklearn / joblib 可用；❌ numba 缺失（可选，未影响本验证路径）；CatBoost/XGBoost/PyTorch 模型为可选未装（import 时提示跳过属正常） |
|
||
| 数据目录落盘与底层读回 | ✅ calendars / instruments / features 二进制均可写入并被 qlib storage 读回 |
|
||
| 项目回归 | ✅ pytest **81 passed**、ruff clean（含 Qlib 改动后仍全绿） |
|
||
| Alpha158 / LGBModel 导入 | ✅ 可导入 |
|
||
| D.features → Dataset → 训练/回测高层链路 | ⚠️ **未打通**（原因见下，属 QlibEngine 实现任务，非安装问题） |
|
||
|
||
**结论：pyqlib 在本机（aarch64 + py3.12）已成功安装且核心数据存储可读写；当前可用的是「安装 + 数据落盘 + 底层读回」基线，而非完整的 Qlib 研究工作流。**
|
||
|
||
## 1. 已验证通过的项目（有脚本断言）
|
||
|
||
1. `import qlib`、`qlib.__version__`（0.9.8.dev32，源码安装路径在 backend/.venv）。
|
||
2. 合成 6 只股票、60 个交易日后可正确写入：
|
||
- `calendars/day.txt`（每行一个 `%Y-%m-%d`）
|
||
- `instruments/all.txt`
|
||
- `features/<instrument>/<field>.day.bin`（float32，按日历逐日对齐）
|
||
3. `qlib.init(provider_uri={"day": <dir>}, region=REG_CN)` 后：
|
||
- 日历读回长度一致
|
||
- instruments 解析出符号与起止时间
|
||
- 每只股票 `close.day.bin` 读回非空数值
|
||
4. `lightgbm`、`qlib.contrib.data.handler.Alpha158`、`qlib.contrib.model.gbdt.LGBModel` 导入成功。
|
||
|
||
## 2. 过程中踩到的格式要点（写 QlibEngine 时直接可用）
|
||
|
||
该源码版（0.9.8.dev32）与旧版 Qlib 在**数据目录约定上有差异**，已实测确认：
|
||
|
||
1. **instrument / feature 命名统一小写**：feature 目录与 instruments 文件第一列必须小写
|
||
（如 `600519.sh`），storage 内部会 `instrument.lower()` 后拼接路径。
|
||
2. **instruments 文件仅 3 列**：`instrument<TAB>start<TAB>end`（**没有**第 4 列 TYPE）。
|
||
3. **provider_uri 用字典形式**：`qlib.init(provider_uri={"day": <path>})`。若直接传字符串，
|
||
会被挂到 `__DEFAULT_FREQ`，导致 `D.features(freq="day")` 查不到数据而返回空（实测复现）。
|
||
4. `.day.bin` 每个值 float32、按该股在全局日历中的交易日逐日对齐（缺失可用 NaN），
|
||
文件名 `<field>.day.bin`（字段名小写、无 `$` 前缀）。
|
||
|
||
## 3. 未通过 / 未验证项（需要说明，不回避）
|
||
|
||
- **`D.features` 高层读取仍报错**：手动生成的 bin 在该 dev 版上进入 dataset 读取时出现
|
||
形状不一致（`shapes (200,) vs (0,)`），推测与 bin 对齐 / 每 instrument 起止切片细节有关。
|
||
手工 float32 文件虽能被 storage 读回，但未必满足 dataset 层对文件长度的精确预期
|
||
（storage 直读 60 个值返回 59 个，见下）。
|
||
- 因此 **QLibDataset → Alpha158 → LightGBM 训练 → 回测 尚未在项目内跑通**。
|
||
|
||
### 为什么 storage 直读 60 返回 59
|
||
|
||
`FileFeatureStorage.data` 对文件做了一些尾部/NaN 处理（实测 60 值读回 59）。这提示
|
||
bin 文件的预期长度与全局日历并非简单相等 —— 为避免手工格式猜错，**QlibEngine 实现时
|
||
应使用官方 dump 工具**（`qlib.dump_bin` / `qlib.tests` 中生成样例的代码）产出数据，
|
||
或阅读其 dump 实现确认行对齐规则后再自建落盘，而不要依赖上述手工 bin 约定。
|
||
|
||
## 4. 下一步（若继续 Qlib 集成）
|
||
|
||
1. 用官方 dump 路径（或对照 qlib 自带样例数据生成代码）建立
|
||
`qlib_adapter/provider.py`：把本地 SQLite 行情按正确 bin 布局导出到 `data/qlib`。
|
||
2. `qlib_adapter/dataset.py`：QLibDataset 配置（Alpha158 / 自定义字段），供
|
||
`QlibEngine.run_factor_test` 与 `run_backtest` 使用。
|
||
3. 工作流仍经 `QuantEngine` Protocol 注入，`LocalEngine` 保持默认，切换不伤业务层
|
||
（见 `app/quant/engine.py`、`app/quant/qlib_adapter/engine.py`）。
|
||
|
||
## 附：Qlib 安装贡献说明
|
||
|
||
`commit 8f8b6d2`（由项目维护者提交）完成源码 git 安装与依赖固化；本报告基于该安装后
|
||
的实际运行验证。若后续调整 qlib commit，建议重跑 `uv run python ../scripts/qlib_verify.py`
|
||
确认基线仍通过。
|