CodeGraph: A Wikidata-Grounded, Open-Taxonomy Knowledge Graph for Source Code

Meta description: CodeGraph labels 145M Stack-Edu files across 14 languages into a 158M node typed graph linked to 19.8K Wikidata entities for semantic code search.

Tags: CodeGraph, Stack-Edu, Wikidata, code knowledge graph, LLM labeling

Featured image: An abstract network of glowing code nodes over a dark gradient, with no text, logos, or people.

CodeGraph is a pipeline that turns a large code corpus into a typed graph. It starts from about 145M source files drawn from Stack-Edu, spanning 14 programming languages, and assigns four concept types to each file: domains, algorithms, paradigms, and design patterns. The goal is to give code retrieval systems more than raw text, adding structured labels that can connect source files to broader computing knowledge.

Background: why code needs concept labels

Large code corpora are useful for search and recommendation, but files often do not explain themselves. A file may contain an implementation of a sorting method, a game loop, or a parser, yet a keyword search may miss it if the wording in the file is not explicit. Concept labels can make semantic code search and automated algorithm selection more practical by giving each file a machine-readable description.

CodeGraph addresses this by using an LLM, specifically Qwen3-Coder-30B, to label the Stack-Edu files. The pipeline does not stop at raw labels. It converts many model-generated labels into a shared vocabulary, then connects that vocabulary to Wikidata, a public knowledge base. That linking is what moves the work from a collection of tags to a graph.

Development process: labeling, cleaning, and Wikidata linking

The first stage is concept extraction. Qwen3-Coder-30B labels about 145M source files across 14 languages with four kinds of concepts: domains, algorithms, paradigms, and design patterns. These outputs are then cleaned into a shared vocabulary of about 63K concepts. This step matters because an LLM can produce many similar or overlapping labels; a shared vocabulary makes the labels comparable across files and languages.

The next stage connects those concepts to Wikidata. The pipeline uses three steps. First, it performs a SPARQL lookup, which queries Wikidata’s structured data. Second, it uses a Deep Research Agent for ambiguous cases, where direct matching is not clear. Third, it imports each linked concept’s Wikidata parent categories, so the graph does not only store a concept but also some of its place in a broader hierarchy.

Latest progress: a typed property graph and quality checks

The result is a typed property graph with about 158M nodes and about 1.02B edges. In this graph, nodes can represent files, local concepts, and linked Wikidata entities, while edges express relationships between them. The graph ties files to the about 63K local concept vocabulary and to about 19.8K Wikidata entities.

That structure is much larger than the closest prior resource, GraphGen4Code. The scale gives CodeGraph room to represent many files and many relationships, which is useful when the intended uses include semantic code search and automated algorithm selection.

Label quality was checked with a small human-annotated gold set and with Devstral-2, an LLM verifier run over the whole corpus. The gold set provides a limited but important human reference point, while the verifier gives broader coverage across the corpus. The pipeline therefore pairs large-scale machine labeling with both human and automated quality review.

Where CodeGraph stands now

CodeGraph currently presents a complete pipeline from Stack-Edu source files to a large typed graph linked to Wikidata. It has a labeled vocabulary, linked parent categories, and a graph size of about 158M nodes and about 1.02B edges. Its next relevance depends on how well the graph supports retrieval, search, and algorithm selection tasks without overrelying on model-generated labels. The work shows how code datasets can be expanded from file collections into structured knowledge layers, using LLMs as labeling engines rather than as the final source of truth.