一句话概括
打开 knowledge-pipeline 的项目状态文档,我先看到的不是一条漂亮的收益曲线,而是一个文件名:final_adjudication.json。一次限定为 5 轮的研究里,3 次 hosted 输出无效,另外 2 次形成 6 个候选,最后 0 个通过 factor-divergence gate,B replay 也保持为 0。系统给出的终态是 falsified_paused。
这组数字有点冷,但它很准确地说明了 Knowledge Pipeline(KP)在做什么:把 PIT 数据、候选生成、FactorIR、研究评估、独立 replay / backtest 和治理判决连成一条可追溯、可复核、可否决的量化研究证据链。
KP 不负责自动下单。它管候选、证据、合同和 gate;独立的 stock_autocn 服务负责权威 replay / backtest 及其 persisted native metrics。当前定位是 Research Governance / Formal RD Lab alpha。
为什么需要它
量化研究很容易在几个上下文之间断掉:数据团队说字段已经齐了,研究脚本说 IC 是正的,回测页面给出一条曲线,最后又有人把这几件事拼成“策略有效”。但字段什么时候可见、候选是否真的用了新信息、回测由谁计算、失败后有没有偷偷改过搜索空间,往往没人能从结果页上回答。
KP 把这些问题拆成了明确的合同:
- 数据时间语义:
observed_at < tradable_from,知道数据不等于当时能交易 - 研究边界:用 ResearchPlan、FactorIR、预算和窗口限制候选生成
- 评估权威:研究期 IC 与收益指标分开,后者只认 StockAutoCN v4 原生持久化结果
- 证据绑定:score、request、certificate 与 result 用内容哈希和签名串起来
- 失败语义:
blocked、degraded、hosted_output_invalid和falsified_paused各自有含义
这里最重要的产品判断是:缺少证据时,系统应该留下 reason 和 artifact,停住;不能用降级结果把流程染成绿色。
系统架构
完整链路可以压缩成五个业务平面、一个控制面和一个独立裁判:
| 层 | 代码落点 | 负责什么 |
|---|---|---|
| Data / Evidence | source_hub/、finance_layer/ |
来源、PIT、vintage、冻结、缺失与 lineage |
| Research | agents/rd_loop/ |
ResearchPlan、FactorIR、候选、TrialRegistry |
| Evaluation | knowledge_graph/eval/、replay modules |
研究诊断、score materialization、replay 合同 |
| Governance | research_artifacts/、GateSuite |
哈希、证书、ledger、晋升与真金门禁 |
核心管道:从 PIT 数据到治理裁决
Step 1 · 先固定“当时能知道什么”
KP 当前的 iFinD PIT v2 资产不是一张随手导出的因子表。它把 exact 1971 个标的、207 个周度 snapshot、8 个特征以及数据的可用时钟一起冻结。随后形成 1971 × 945 个决策日 × 8 个 frames 的 daily research bundle;2026-05-28 至 2026-06-30 的尾部只供 forward label 使用。
这里还有一个容易被忽略的细节:原始缺失要保留。研究 frame 里的中性零不能被写成“真实观测值”。PCT_CHANGE、SAFE_DIV,以及没有 PIT 行业标签支持的 GROUP_DEMEAN,都会被 fail-closed 拒绝。
Step 2 · 用 ResearchPlan 和 FactorIR 约束搜索
LLM 只看到有界的研究上下文、Finance feature catalog、coverage 和代表性 row hash;全量 PIT rows、完整 TrialRegistry 以及 sealed / fresh feedback 留在本地。候选必须先编译成 FactorIR,再经过 divergence、correlation、residual、ablation 与 overlap 等研究门禁。
bounded context + Finance catalog
→ hypothesis
→ FactorIR compiler
→ research diagnostics
→ divergence gate
这条路径有明确预算。当前记录的一次 POC 最多 5 次 hosted attempt,不自动 retry,也不把 fallback 偷换成新一轮实验;父 Job 3 次、子 Job 2 次,通过内容寻址的 parent chain、TrialRegistry prefix 与 ResearchPlan 接续。
Step 3 · 让独立回放成为收益权威
研究期的 IC、residual IC、correlation 和 ablation 只回答“候选有没有资格继续”。年化收益、总收益、Sharpe、Sortino、最大回撤、Calmar 和胜率则只认 StockAutoCN v4 persisted native result。
FactorIR score
→ immutable content hash
→ replay request
→ certificate + signature
→ StockAutoCN native result
→ contract / provenance validation
路径只负责定位文件,sha256-v1:<hex> 和 replay-signature-v1: 才绑定内容。POST 成功不等于回放通过,带有 replay 字样的失败记录也不能混入 winner 或 promotion gate。
Step 4 · 把“能研究”与“能晋升”分开
在 KP 里,research admission、diagnostic replay eligibility、单策略晋升、组合 allocation 和 real-money authorization 是不同状态。backend/agents/rd_loop/loop_os/ 下面甚至有独立的 burn_budget_guard.py、external_action_gate.py、real_money_gate.py 和 window_registry.py。
这会让流程显得慢一点,但也让一句“策略可用”必须回答:哪个 universe、哪个窗口、哪份冻结输入、谁算的收益、哪道 gate 通过、证据 hash 是什么。
一个负结果,为什么值得保留
2026-07-23 的冻结快照里,5/5 次调用已经用完:3 次 hosted_output_invalid,2 次有效响应形成 6 个单字段 Finance 候选,0 个通过 factor-divergence,B replay 为 0。最终裁决是范围受限的 falsified_paused,授权随之过期,系统不允许“再试一次”。
其中一条 debt_to_assets 候选曾出现 residual IC 0.01816、z=2.82、最大相关 0.0504。这个数字很容易被单独截出来写成亮点,但当轮 ablation 缺失;修复后,它也没有在五轮预算内形成正式联合通过。所以仓库给出的结论仍然是:Alpha 未获证明。
我反而觉得这是项目目前最有价值的部分。研究基础设施不应该只保存“赢了什么”,也要能准确保存“在哪个冻结合同内,为什么没有赢”。这才让下一轮修的是 structured output、compiler 表达面或数据证据,而不是悄悄移动门槛。
产品工作台
KP 并不只有一组后台脚本。仓库里有 FastAPI、React/Vite 和 Typer CLI 三个操作面:
| 工作面 | 主要入口 | 用途 |
|---|---|---|
| Inbox | /inbox/* |
信息、搜索、事件、watch 与 live 状态 |
| DataHub | /datahub/sources、/datahub/research |
来源、研究数据和 Finance evidence |
| Graph | /graph |
实体、关系与证据投影 |
| Studio | /studio/rd、/studio/formal-rd |
ResearchPlan 与正式研究合同 |
| Alpha Factory | /studio/alpha-factory |
候选、试验与评估工作流 |
| Governance | /governance/* |
风险、研究组织和治理状态 |
路由存在只证明入口已经落地,不证明最新 iFinD v2 readiness 和 Job artifact 已经有完整的专用 UI。仓库自己的 current docs 也把这件事列在未闭合项里。
快速上手
默认环境是 macOS、Docker Desktop 和本地 shell。完整本地栈包含 backend、frontend、Celery worker / beat、Redis、Postgres、Neo4j、Qdrant 与 MinIO:
git clone https://github.com/DeepSeedx/knowledge-pipeline.git
cd knowledge-pipeline
cp backend/.env.example backend/.env
docker compose config --quiet
docker compose up -d --build
docker compose ps
启动后检查两个主要入口:
curl http://127.0.0.1:8110/health
open http://127.0.0.1:5183
/health 可能返回 ok,也可能返回带原因的 degraded。Knowledge Graph 启动或 attach 失败时,应用会保留部分可用能力,同时把具体阶段写进响应,而不是静默假装依赖全绿。
CLI 使用同一个 kp 入口:
cd backend
uv sync
uv run python -m cli.main doctor
uv run python -m cli.main rd list
Apple Silicon 用户要注意:pyqlib 0.9.7 的 Linux wheel 没有 arm64 版本,Compose 因此把 backend 和 Celery runtime 固定到 linux/amd64。
项目结构
knowledge-pipeline/
├── backend/
│ ├── agents/rd_loop/ # Research loop、FactorIR、Loop OS
│ ├── finance_layer/ # PIT 数据、冻结与研究投影
│ ├── research_artifacts/ # Ledger、GateSuite、hash contracts
│ ├── source_hub/ # 来源、connectors、evidence workflow
│ ├── api/routers/ # FastAPI 产品入口
│ └── cli/ # kp 命令行
├── frontend/src/ # React/Vite operator workbench
├── docs/ # 架构、产品、治理、Spec 与 runbook
├── skills/ # 项目研发与 Finance 契约
├── docker-compose.yml
└── outputs/ # 本地运行证据,不作为 GitHub clone 的事实源
适合谁看
- 量化研究员:想把候选生成、研究诊断与独立回放分层
- 数据与证据负责人:关心 PIT、vintage、缺失、冻结和 lineage
- Agent / LLM 工程团队:需要约束 hosted prompt、预算、重试与外部动作
- 治理审核者:希望每次晋升都能下钻到 reason、hash、certificate 和 artifact
当前边界
- Harness Loop Architecture 1.0 已落地,不代表已经发现或证明 Alpha
- 当前没有通过 gate 的 B 候选,也没有 native A/B uplift 结论
- 没有项目级 true sealed / fresh OOS、certified best、资金分配或真金许可
- hosted structured-output 稳定性和多字段 compiler 表达面仍未闭合
- active hosted HTTP 的 principal、nonce、expiry、quota 与 rate-limit 合同仍待补齐
我还没有完全想清楚的一点是:当 hosted output 的格式稳定性本身变成研究瓶颈时,系统应该优先扩展 compiler 的表达面,还是先把生成端收得更窄。KP 目前选择先停住,不降低门槛。这个选择不轻松,但至少让下一次继续有一个干净的起点。
项目地址:https://github.com/DeepSeedx/knowledge-pipeline
访问提示:本文写作时该 GitHub 仓库为 Private;未获 DeepSeedx 授权的账号无法查看源码。
本文基于仓库 main@9a1d847、2026-07-23 current architecture / project state / product docs,以及关键配置与源码入口整理。文中架构图按项目已提交责任边界重绘。