machine-learning-for-trading 第 23 章实战：从 SEC 披露构建金融知识图谱、Graph RAG 与时序防泄漏特征工程

machine-learning-for-trading 第 23 章实战从 SEC 披露构建金融知识图谱、Graph RAG 与时序防泄漏特征工程【免费下载链接】machine-learning-for-tradingCode for Machine Learning for Trading, 3rd edition — from data sourcing to live execution.项目地址: https://gitcode.com/GitHub_Trending/ma/machine-learning-for-trading本指南完整讲解开源仓库 machine-learning-for-trading《Machine Learning for Trading》第 3 版配套代码中第 23 章Knowledge Graphs for Financial AI的技术路线从向量检索的局限出发说明何时值得为金融问题引入显式图结构随后以 10 个 notebook 为主线深入 LLM 辅助的供应链知识图谱构建、13F 机构持仓属性图、安全 Graph RAG、图衍生 ML 特征、统计金融网络、三时间戳防泄漏框架以及生产级工程决策。读完你将掌握一套可回放、可审计、防泄漏的金融知识图谱构建与评估方法论并能在仓库中直接复现全部流程。为什么金融问答需要显式图结构向量检索第 22 章的 RAG 基础让基于证据的金融问答成为可能但它作用于孤立的文本块。依赖所有权链条、供应商网络、风险传染路径或关系变更时点的提问需要的是可遍历、可审计、可复用的显式结构而不是文本块之间的模糊相似度匹配。知识图谱以节点表示实体、带类型的边表示关系、属性承载来源与时间信息provenance正好补齐了这一层。仓库 23_knowledge_graphs/README.md 开篇即点出本章的立场知识图谱的构建应当被当作治理问题身份 identity、模式 schema、来源 provenance来对待而不是为了追求新颖性。全章以 7 个小节推进对应关系如下小节主题核心观点23.1关系结构何时解锁金融洞察多跳、结构拥挤或时序演化的提问才值得为图买单23.2构建金融知识图谱LLM 提取 身份、模式、来源契约保证图谱可回放、可审计23.3Graph RAG确定性关系推理五阶段架构把关系逻辑交给数据库、把语言生成交给 LLM23.4从图谱到机器学习特征中心性、拥挤度、共同持股与跨图交互变成表格特征23.5金融网络从相关到组合经典 MST 与相关网络方法如何补充显式 KGGNN 的实用定位23.6时序完整性与防泄漏评估三时间戳模型事件、披露、提取与 cutoff 安全特征协议23.7构建 KG 就绪管线工程决策引擎选型、本体范围、text-to-Cypher 安全、schema 版本化23.1 先问这真的是图问题吗判断标准很直接查询是否多跳multi-hop、结构是否拥挤crowded、关系是否随时间演化temporally evolving。表格式数据库的强项是等值连接与聚合向量检索的强项是语义相似。而这两家基金共同持有哪些股票哪家公司同时被多家 SP 100 公司列为主要供应商谁通过机构持仓在两只股票之间构成间接通道这类问题在表上要做重复自连接self-join在图上只是一次两跳遍历。13F 数据集是天然的二分图季度披露持仓的机构institution连接它们持有的股票stock。05_institutional_holdings_kg.py 中共享持仓查询的 Cypher 等价写法如下MATCH (a:Institution {name: ...})-[:HOLDS]-(s:Stock) -[:HOLDS]-(b:Institution {name: ...}) RETURN s.label, s.issuer内存图实现里这一条查询对应两次集合求交inst1_stocks inst2_stocks。仓库同时给出一个重要提醒共享持仓只暴露潜在连接并不等于测量了价格共动——两个机构是否因共同持股而在抛售时放大价格冲击是下游 23.4 节特征要检验的假设notebook 本身不做此推断。23.2 供应链知识图谱LLM 提取 身份解析 UNWIND 批量加载数据准备SEC 披露语料01_sp100_sec_download.ipynb 从 SEC EDGAR 加载 SP 100 公司的 10-K 与 8-K 文件。仓库 02_supply_chain_kg_construction.py 通过data.load_sec_filings(10-K, universesp100)读取语料并断言必需的列symbol、company_name、form、filing_date、accession_no、year、text、text_length无缺失、(symbol, accession_no)无重复、text长度与text_length一致。随仓库分发的语料共601 份 10-K 文件覆盖 101 家公司2020–2025 年。有限关系词汇表与提取提示词模式设计的第一步是限定关系词汇。仓库只允许三种关系RELATIONSHIP_TYPES [HAS_SUPPLIER, COMPETES_WITH, HAS_CUSTOMER]提取提示词EXTRACTION_PROMPT明确约束了输出格式JSON 数组、键为subject/predicate/object、主词用全称官方名、宾语用缩写如TSMC而非全称、实体名不超过 5 个词、只提取显式陈述的关系。系统提示词 用户提示词截取文件前 6000 字符经apply_chat_template拼装后批量送入模型。批量推理管线核心提取函数extract_relationships_batch把多条文本在一次前向传播中完成生成paddingTrue, truncationTrue, max_length4096max_new_tokens512do_sampleFalse保证确定性JSON 解析器_parse_json_triples负责剥离多余前导/尾随文本只保留predicate在允许集合内的三元组。参数化单元格Papermill 可覆盖默认值参数默认值说明MAX_COMPANIES0限制送 LLM 的公司数仅当RERUN_EXTRACTIONTrue时生效0 全语料LLM_BATCH_SIZE2每 GPU 批的文本数Qwen2.5-7B 约 14GB2 条在 24GB 卡上留有余量RERUN_EXTRACTIONFalseFalse 时加载仓库自带的提取缓存无需 GPUMODEL_NAMEQwen/Qwen2.5-7B-Instruct可选Qwen/Qwen3-8B原生思考模式需ENABLE_THINKINGTrueMAX_NEW_TOKENS512思考模式下建议提到约 2048CoT 消耗 tokenSEED42全局随机种子提取性能是真实记录在案的实现事实仓库注明原始生产运行以批大小 2 处理 601 份文件在 NVIDIA RTX 3090 上约 27 分钟、占用约 14GB 显存且 CPU 再生不被支持。可回放的提取缓存仓库随包分发缓存 output/supply_chain_cache/extracted_triples.parquet约 11KB及其 sidecar 元数据extracted_triples.meta.json。缓存验证器_validate_cache做四重检查SHA-256 内容哈希比对、列名与(subject, predicate, object)精确一致、行数落在[100, 50_000]合理区间、行数与 meta 的row_count一致。任何一步漂移都会直接报错而不是静默使用损坏数据。meta 中记录model_name、max_companies、written_at把提取身份钉死在文件上——参数里改MODEL_NAME并不能追溯性地改变已提交缓存的生产者代码会明确打印缓存的生产者是 X而非声称当前参数。实体解析让同名实体收敛为同一节点实体解析是让图谱可用的关键。缓存中 133 个不同主词字符串里51 个原样匹配公司名61 个只是大小写/标点/词序变体21 个指向运营子公司或品牌——每个拼写若不合并都会成为独立节点污染下游所有度数统计。仓库采用三层解析规范键canonical keyentity_key剥离大小写、标点、公司后缀inc/corp/co/plc/ltd/llc/holdings/the/nv/sa/ag等 23 个并排序 token。排序是唯一能合并词序不同拼写的规则在缓存上恰好合并了SCHWAB CHARLES CORP与The Charles Schwab Corporation这一组四种拼写。文件者名册filer roster从语料本身构建官方名称表命中的实体直接采用官方拼写——这正是被列为竞争对手的实体与自己提交过 10-K 的实体成为同一节点的原因。别名表alias map覆盖从不向 SEC 提交文件的实体如Taiwan Semiconductor Manufacturing Company → TSMC、Foxconn Technology Group → Foxconn、Advanced Micro Devices → AMD、Amazon Web Services → AWS。此外还有通用实体过滤器GENERIC_ENTITY_NAMESsuppliers、third parties、consumers 等类别短语和谓词感知规则HAS_SUPPLIER宾语含 supplier 即拒绝防止把非命名实体写成节点。解析后用(subject, predicate, object)三元组去重。值得注意的设计取舍无法匹配名册的实体如被模型命名为KAYAK而实际属于Booking Holdings Inc.不强行合并保留为独立节点并在输出中显式列出名册无法覆盖的主词。生产管线会用公司层级corporate hierarchy解决这里如实标注边界。Neo4j 批量加载UNWIND MERGE加载采用UNWIND 批量事务单个 Cypher 语句把成百上千条关系在一次事务中写入而非逐条执行。每个谓词有独立的 MERGE 模板例如UNWIND $batch AS row MERGE (c:Entity {name: row.subject}) SET c:Company MERGE (s:Entity {name: row.object}) SET s:Supplier MERGE (c)-[:HAS_SUPPLIER]-(s)注释明确解释了为什么 MERGE 必须落在:Entity {name}上、角色只作为第二标签附加若按角色标签合并Microsoft 会因提交文件的公司 / 被列为供应商 / 被列为客户三个身份而分裂成三个节点。共享数据库的章节还要求清理时只删除本 notebook 创建的关系避免误伤08_8k_event_extraction写入的:Company事件边。供应链图谱的统计口径与边界图统计部分如实报告几乎每个被提取的供应商只被一家公司点名共享供应商只占少数。这是 10-K 披露性质的产物——文件者只列出被要求披露的供应商只有被多家依赖的供应商才会重复出现。因此共享供应商度数是提取图上的敞口集中度诊断不等同于中断概率或因果传播概率用前必须先人工复核被提取实体。23.3 Graph RAG把关系逻辑还给数据库Graph RAG 与向量检索的本质区别在 03_graph_rag_qa.py 中体现为一条安全协议问题先路由到预写 Cypher 模板而不是自由生成 Cypher生成的查询必须通过只读 schema 校验并强制日期约束与行数上限。五个阶段分别是问题路由 → 模板化查询 → 只读校验 → 确定性数据库执行 → LLM 用结果组织语言回答。只读 schema 白名单校验器持有三张白名单允许的标签{Institution, Stock, Sector}、允许的关系{HOLDS, IN_SECTOR}、允许的属性集合available_from, cik, cusip, equity_13f_value, issuer, label, name, report_date, sector, shares, value并设置禁用关键词集合BLOCKED_KEYWORDS { CALL, CREATE, DELETE, DETACH, DROP, LOAD CSV, MERGE, REMOVE, SET, }关键运行参数ROW_LIMIT 25、TIMEOUT_SECONDS 2.0确保任何生成的查询都无法全表扫描或长时间挂起。生产者快照契约查询层不自行定义事实查询层通过GraphSnapshot节点与生产者绑定读取ch23_13f快照的属性断言其source_sha256与本地 13F parquet 的 SHA-256 一致断言cohort_policy earliest-report-period formation, fixed forward并核对图内节点/关系计数与快照记录的institution_count/stock_count/holding_count完全吻合。as-of 日期由生产者拥有CUTOFF_DATE为空时读取latest_available_from用户传入更早日期是合法回看传入更晚日期则直接断言失败——因为图无法回答它没有文件支撑的日期。这类断言把查询层引用了一个生产者从未写过的图这类静默错误变成显式失败。点对点时间约束所有点位查询强制h.available_from $cutoff_date。13F 持仓有两个日期report_date季度末持仓基准日与available_from该季度持仓首次公开的提交日约晚六周。用report_date做时点查询是前视look-ahead用available_from做季度对比则错位一个季度——两个日期回答两种不同的问题05_institutional_holdings_kg.py 的report_period_calendar把每个报告期的提交窗口与lag_days打印出来让缺口可见而非假设。04_rag_comparison_benchmark.ipynb 则在真实 13F 数据上把图检索与向量检索sentence-transformers嵌入基线对照度量支持召回率support recall与检索 token 成本区分直接查找型与多实体型问题。23.4 从图谱到机器学习特征05_institutional_holdings_kg.py 定义了 13F 属性图 schema三类节点Institution(cik, name, equity_13f_value)、Stock(cusip, issuer, label, sector)、Sector(name)两类关系HOLDS(shares, value, report_date, available_from)与IN_SECTOR。注意两个命名纠偏equity_13f_value是管理人在形成季度的美国上市多头股票市值曾叫aum但 13F 不含现金、债券、境外与私募仓label是缩短的发行人显示名曾叫ticker但 13F 按 CUSIP 键控、根本没有 ticker。数据净化与形成队列真实 13F 数据经三处关键净化衍生品行拆分put_call为空的才是多头持股行期权行CALL/PUT被排除出图并单独汇报规模。把所有三类行加总会把 put 与持股混为一谈是符号错误而非舍入错误。形成队列formation cohort只在最早报告期一次性地选出机构与股票队列之后所有报告期沿用同一队列。若用全部报告期排名未来成员会泄漏进早期时点查询。CUSIP 合并拼写按 CUSIP 分组聚合发行人拼写MASTERCARD INC 与 MASTERCARD INCORPORATED 是一个证券取承载披露价值最多的拼写为canonical_issuer避免 Neo4j 按 CUSIP MERGE 后出现队列声称的规模大于图实际规模的矛盾。拥挤度与共同持股内存图InMemoryGraph提供节点/边插入与按边类型的邻接查询支撑四类教学查询共享持仓、拥挤度HOLDER_FLOOR 2即holder_count 2、跨机构网络路径、按板块聚合持仓。Jaccard 共同持股相似度把二分图投影为股票-股票相似图$$J(s_i, s_j) \frac{|,\text{Holders}(s_i) \cap \text{Holders}(s_j),|}{|,\text{Holders}(s_i) \cup \text{Holders}(s_j),|}$$仓库诚实标注了统计边界10 家机构的队列里 Jaccard 只能取少量小整数比头部存在大量并列前 N 相似对的排序主要由字母序决断因此代码打印并列组规模而非假装存在排序持仓重叠是否驱动价格共动是 23.5 节要检验的假设本 notebook 不测价格共动这个队列规模也测不出来。拓扑特征与跨图交互09_knowledge_graph_features.py 把供应链图Neo4j 中ch23_supply_chain快照与第 4 章 13F parquet 合并成特征矩阵输出宽/长两种格式拓扑类pagerank、betweennessnx.betweenness_centrality、clustering、in_degree、out_degree供应链集中度供应商 HHI赫芬达尔指数与竞争敞口机构拥挤度13F 持仓派生跨图交互supplier_dependency × ownership_hhi、betweenness × n_holders即systemic_exposure见pl.col(betweenness) * pl.col(n_holders)的实现、relationship_churn、centrality_momentum等动态列。特征元数据为每个特征给出分类与解读如 betweenness 为 Bridge or bottleneck position。这些特征的下游消费者是第 12 章表格模型与第 14 章潜在因子模型。23.5 统计金融网络相关网络、MST 与 GNN 的实用定位显式 KG 之外统计金融网络文献提供互补视角。10_network_portfolio_construction.ipynb 从美国股票构建相关网络与最小生成树MST按中心性给资产排序构造网络多样化组合并运行传染模拟。其方法论根基是 Mantegna1999的层级结构研究、Marti 等2021的二十年综述以及 Konstantinov 等2023的金融网络组合管理。06_gnn_feature_engineering.ipynb 在股票相关网络上训练简化的 **GAT图注意力网络**生成关系嵌入再把仅表格 ridge 回归与拼接学习嵌入的混合模型对照。仓库使用torch_geometric实现参考文献涵盖 GCNKipf Welling 2017、GraphSAGEHamilton 2018与 GATVeličković 2018。定位是务实的GNN 嵌入作为特征补充而非替代显式 KG其结论需经受与表格基线同等的评估纪律。23.6 时序完整性与三时间戳防泄漏三时间戳模型08_8k_event_extraction.py 从 SEC 8-K 文件提取结构化事件四元组subject, relation, object, timestamp用 FinReflectKG CheckRules 规则校验规范化实体格式把未通过 schema 的事件搁置hold back并以可回放 run identity加载事件图。8-K 语料约 1249 份文件 × 101 家公司 × 2020–2025MAX_FILINGS 50为默认演示规模0 全语料约 10 倍运行时长。每个图边携带三个日期分别回答三个不同的问题时间戳含义用途event time文件文本中提取的事件发生日事件本身何时发生public/disclosure time信息向公众公开的提交日时点查询的可见性边界extraction time管线产出该 KG 边的时间提取身份与快照排序07_dynamic_kg_temporal.py 明确警告了一个排序陷阱GraphSnapshot是共享标签13F 快照没有extraction_timeNeo4j 把 null 排在所有值之上因此ORDER BY extraction_time DESC LIMIT 1会选中 13F 快照而不是 8-K 快照。修复方式是显式命名生产者8-K 快照打上snapshot_kind: 8k_events标签查询按snapshot_kind匹配。cutoff 安全快照与关系更替代码用CUTOFF_LAG_DAYS 60从最新公开日回推 cutoffvisible_at_cutoff只保留public_time cutoff的边其余边被隐藏并计数验证cutoff 后的事件对可见图不可见。随后build_snapshots以WINDOW_DAYS 90的固定窗口滚动公开事件流每个窗口统计n_edges、n_subjects、n_objects相邻窗口间的**关系更替relationship churn与中心性漂移centrality drift**成为动态特征。关键概念辨析披露过滤器disclosure filter只按公开日过滤而三时间戳模型要暴露的是披露过滤器挡不住的那种泄漏——例如事件生效日effective date晚于宣布它的文件日代码在面板 (b) 中绘制从事件日到披露日的有符号滞后并明确不把滞后截断到零。23.7 生产级工程决策第 23.7 节把整章收敛为四类工程决策引擎选型Neo4j 承担持久化与 Cypher 查询networkx承担图分析与 MSTtorch_geometric承担 GNN轻量教学场景可用仓库自实现的InMemoryGraph。连接统一走环境变量默认bolt://localhost:7687用户neo4j/passwordverify_connectivity()在启动时即验证。本体范围关系词汇表有限且可枚举供应链 3 类、13F 2 类、8-K 事件类 CheckRules 校验拒绝自由形式的关系。text-to-Cypher 安全模板路由 只读 schema 白名单 禁用关键词 行数上限 超时 生产者快照契约层层设防代码还要求用**敌意控制集hostile control set**审计校验器——不仅用为通过而写的查询更要用试图绕过它的查询。schema 版本化缓存与快照携带内容哈希、生产者身份、写入时间与 run_id实体解析规则后缀表、别名表、通用实体表均为显式配置可版本化演进。在仓库中复现全部流程运行方式# 从仓库根目录运行任一 notebook 脚本 uv run python 23_knowledge_graphs/notebook.py # 测试模式Papermill 缩减数据 uv run pytest tests/test_notebooks.py -v -k 23_knowledge_graphs # 无显示环境headless MPLBACKENDAgg PLOTLY_RENDERERjson uv run python 23_knowledge_graphs/notebook.pyNeo4j 与 GPU 前提以下 notebook必须有运行中的 Neo4j 实例02_supply_chain_kg_construction、05_institutional_holdings_kg、08_8k_event_extraction、03_graph_rag_qa、07_dynamic_kg_temporal。典型启动方式notebook 文档块中给出的 docker compose 命令docker compose --profile kg up -d neo4j docker compose run --rm ml4t python 23_knowledge_graphs/02_supply_chain_kg_construction.py供应链与 8-K 提取管线默认使用经vLLM 兼容端点提供的 Qwen2.5-7B本地缓存路径默认无需 GPU重新提取RERUN_EXTRACTIONTrue需要 CUDA GPU 与ml4t-gpu镜像。13F 数据经data.load_institutional_holdings_13f()加载其 parquet 由 data/equities/positioning/13f_download.py 生成缺失时加载器抛出带下载指引的DataNotFoundError。Notebook 全景类别Notebook内容图构建01_sp100_sec_download.ipynb加载并检查 SP 100 的 10-K/8-K 文件提取前验证覆盖度与文本质量图构建02_supply_chain_kg_construction.ipynbQwen2.5-7B 提取供应商/客户/竞争关系实体解析加载 Neo4j可视化供应链图图构建05_institutional_holdings_kg.ipynb13F 属性图共享持仓与拥挤度查询Jaccard 共同持股相似度图构建08_8k_event_extraction.ipynb8-K 事件四元组提取FinReflectKG CheckRules 校验可回放 run identity 加载检索与评估03_graph_rag_qa.ipynb受控 text-to-Cypher 问答只读 schema 校验、日期约束与行数上限检索与评估04_rag_comparison_benchmark.ipynb图检索 vs 向量检索基准支持召回率与检索 token 成本特征与网络09_knowledge_graph_features.ipynb供应链拓扑PageRank/betweenness/HHI 13F 拥挤度 跨图交互特征矩阵特征与网络10_network_portfolio_construction.ipynb相关网络与 MST中心性排序网络多样化组合传染模拟特征与网络06_gnn_feature_engineering.ipynb简化 GAT 生成关系嵌入表格基线 vs 混合模型对照时序完整性07_dynamic_kg_temporal.ipynb三时间戳分离cutoff 安全快照关系更替与中心性漂移泄漏验证仓库还随包提供了供应链图的成品可视化 figure_23_3_supply_chain_network.png以及可交互版本supply_chain_d3.html/supply_chain_interactive.html便于在浏览器中探索 SP 100 供应链拓扑。依赖关系与章节定位上游依赖第 4 章基本面与另类数据13F 机构持仓加载器、第 10 章文本特征工程NER 与文件解析模式、第 22 章RAG 基础。下游消费第 12 章表格模型消费跨图特征、第 14 章潜在因子模型消费共同持股与拥挤特征、第 24 章自主智能体使用结构化检索、记忆与证据追踪。章节专属库neo4jCypher 客户端、networkx图分析与 MST、torch_geometricGAT、edgartoolsSEC EDGAR 文件摄入、sentence-transformersRAG 对照的嵌入基线。核心参考本章在多个关键点上引用了公开文献——FinReflectKG2025与 FinDER2025作为金融 KG 问答基准Graph RAGEdge 等2024作为查询聚焦摘要方法RAG 综述Peng 等2024金融 KG 构建高精度管线Elhammadi 等2020COLINGFinKG 核心金融知识图谱Kertkeidkachorn 等2023动态金融知识图谱Miao 等2019MST 与金融网络层级结构Mantegna 1999Marti 等 2021金融网络与组合管理Konstantinov 等2023JPM股票价格脆弱性Greenwood Thesmar 2011JFE与银行生态系统系统性风险Haldane May 2011Nature以及图神经网络系列GCN、GraphSAGE、GAT与反洗钱图卷积实验Weber 等2019。完整条目见 23_knowledge_graphs/README.md 的 References 节。小结第 23 章的价值不在于把数据放进图里这一动作本身而在于把图构建当作治理问题稳定实体身份规范键 名册 别名、有限关系词汇表、边级来源内容哈希、生产者身份、run_id、确定性关系查询Graph RAG 把关系逻辑留给数据库、泄漏感知的特征工程三时间戳模型与 cutoff 协议。这套纪律让知识图谱从新颖变成有用——可回放、可审计也能安全地服务于预测、组合构建与风险分析。【免费下载链接】machine-learning-for-tradingCode for Machine Learning for Trading, 3rd edition — from data sourcing to live execution.项目地址: https://gitcode.com/GitHub_Trending/ma/machine-learning-for-trading创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考