CodeGraph 用开源分类法把 1.45 亿个源码文件标注成含 10 亿条类型化边的知识图谱，并把概念锚定到 Wikidata

构建了面向源码的开放分类法语义标注流水线，把文件级元数据从词法/句法层面提升到算法、范式、设计模式与应用领域四类高层语义。 既有代码资源要么是超大规模但只暴露原始 token 与语言标签的语料（如 The Stack v2），要么是任务受限的监督资源（如 CodeSearchNet 的函数级 docstring、Project CodeNet 的题目 ID 与执行元数据）；本文改为让模型生成自由标签、事后做规范化归并，从而在预训练规模上附加语义层。 在 Stack-Edu 的 1.45 亿个文件（14 种编程语言，Markdown 子集被排除）上实际运行，抽取阶段约消耗 40 万 GPU 小时、使用 LEONARDO 超算上的 256 块 NVIDIA A100；提示按四条正交语义轴拆分并强制严格 JSON schema，无支持时要求返回空数组，把静默遗漏转为显式负例。

提出三阶段 Wikidata 落地流程，使本地抽取词表获得公共知识库的共享语义参照与多级分类结构。 与把全部消歧交给模型的做法不同，本文先用带类层次过滤的确定性 SPARQL 处理无歧义概念，仅把歧义或空结果的残差交给由另一开源权重模型（Qwen3.6-27B）驱动的 Deep Research Agent，最后用两跳 wdt:P279 遍历导入父类闭包，形成本地词表与 Wikidata 全局分类并存的“双层概念层”。 落地覆盖四类概念；规范化后各轴落地比例分别为领域、算法、设计模式与范式中的相应份额，且落地概念沿 Wikidata 标识空间进一步收敛，说明相当一部分长尾是共享同一百科指称的词法变体；未落地概念主要集中在算法轴。

给出可校准的质控协议，把 LLM 评审器变成逐条标注的可靠性过滤器，并公开抽取与评审两方决策以便下游自选工作点。 相比只在窄场景使用固定分类法或缺少逐条可靠性层的做法，本文用小型人工金标集刻画任务难度、在统一协议下比较六个代码模型选出生产评审器，再在全语料上做银标级复核。 金标集为 127 个分层抽样文件、17 位标注者、292 条判断，覆盖 6 种语言与 4 类语义；整体 68.4% 判为 Okay、17.7% NotOkay、13.9% Unsure，Fleiss’ κ 整体偏低且按类别差异明显（领域与算法较高，设计模式与范式明显较弱）；六个候选评审器在 1,536 组模型—人工比较对上 F1 介于 84.9% 与 88.5% 之间，Devstral-2 2512 以 80.6% 准确率、82.1% 精确率、96.0% 召回率、88.5% F1 被选为生产评审器；在 10,000 文件银标子集上各轴接受率为范式 93%、算法与领域各 88%、设计模式 82%，跨语言接受率落在 87–90% 区间。

在真实语料上给出可查询的图谱统计与两类用例，展示跨领域复现的算法原语与语义检索、自动算法选择的可能性。 与最接近的代码知识图谱 GraphGen4Code（130 万 Python 文件、仅句法构件）相比，CodeGraph 在规模上大约高出两个数量级，并增加了高层语义元数据；其查询面向“文件讲的是什么”，而非程序内部的调用与数据流。 图谱约 1.58 亿节点、约 10 亿条类型化边，平均度较低、整体稀疏；语料语言分布偏斜，Java 30.6%、Python 16.9%、C++ 11.2% 合计 58.7%；领域分布同样偏斜，web development 以 6,210 万文件居首，超过 database（2,710 万）两倍以上，其后为 data science（2,490 万）与 game（1,640 万）；算法头部是计算原语而非教科书算法（linear search 600 万、string operation 400 万、input validation 290 万、JSON 290 万、regular expression 230 万、string-searching algorithm 220 万）；约 75.1% 的领域与 38.8% 的算法关联文件少于 1,000 个。

该结果面向需要按算法、范式、设计模式与应用领域检索或筛选代码的开发者与研究者，适用于以 Stack-Edu 这类经质量过滤的公开代码语料为对象、且以文件为标注单位的场景；图谱的双层结构允许把细粒度概念沿 Wikidata 层级上卷到更宽语义族，也允许在统一标识空间下跨语言比较概念。作者把领域与算法视为可支撑定量结论的轴，把范式与设计模式作为探索性信号发布，并建议下游定量分析优先使用前两者。方法层面，确定性 SPARQL 负责无歧义部分、Deep Research Agent 只处理残差，这一分工使落地过程在可确定处保持确定；抽取与评审两方决策都保留在图中，使用者可按自身精度/召回偏好选择工作点。

人工金标集仅 127 个文件、292 条判断，作者说明按每文件每轴两分钟估算全量人工标注约需 9,500 人年，因此该规模是任务内在难度所致；Fleiss’ κ 整体偏低且设计模式与范式明显更弱，作者据此把这两轴作为探索性信号。银标接受率（整体约 88%）高于金标 Okay 率（68.4%），作者把两者视为精度估计的上下界，并指出差距与假阳性行为及把人工 Unsure 转为 Okay 有关；在限定为已落地 Wikidata 的标注子集上，除范式外各轴接受率明显下降，作者提出的工作假设是算法与设计模式标签通常对应单个函数或类，与整文件判定之间存在粒度错配，更精确的刻画（可能采用函数级评估）留待后续。约 75.1% 的领域与 38.8% 的算法关联文件少于 1,000 个，稳健统计结论因此限于高频标签。未落地概念集中在算法轴，作者认为 Deep Research Agent 在架构上可吸收这部分长尾，前提是 SPARQL 召回与候选生成得到改进。全量语料发布、扩展的跨领域分析以及对 AI 模型训练的影响均被作者列为未来工作。