LinearRAG: relation-free graph construction for GraphRAG

The cost LinearRAG removes from the GraphRAG pipeline

Indexing a corpus into a knowledge graph normally means asking a language model to read passages and emit subject-predicate-object triples, then asking it again for each chunk that needs repair. On a small benchmark that is tolerable. On a corpus with millions of passages the extraction pass becomes the line item that decides whether the project ships. LinearRAG targets exactly that line item. The README describes it as a "relation-free graph construction method for efficient GraphRAG" that "eliminates LLM token costs during graph construction." The claim is narrow and testable: no LLM calls during the build phase. The audience is teams that already accept graph retrieval as useful and are blocked by the indexing bill, not teams looking for a first introduction to GraphRAG.

How the graph gets built without relations

The README names two components: "lightweight entity recognition and semantic linking." Entity recognition is handled by spaCy rather than an LLM, which is why the install steps download en_core_web_trf and, for the medical dataset, en_core_sci_scibert. Semantic linking is what replaces relation extraction. Instead of labelling an edge with a predicate, the pipeline connects entities that are semantically close, and the retrieval step walks those links. The README calls this "semantic bridging" and claims it enables "multi-hop reasoning in a single retrieval pass without requiring explicit relational graphs." The stated complexity is linear in time and space. That is the whole design: nodes are mentions, edges are similarity, and multi-hop behaviour emerges from the path structure rather than from declared relationships. A consequence worth stating plainly is that the graph carries no predicate vocabulary. You cannot query for a specific relation type because none was ever recorded.

Getting it running: the actual commands

The install path is short. The README asks for Python 3.9 preferably, then pip install -r requirements.txt, then python -m spacy download en_core_web_trf. The medical dataset needs a separate model, installed from the scispacy release URL given in the README. Configuration is environment variables: OPENAI_API_KEY and OPENAI_BASE_URL. Note that the LLM key is still required even though graph construction is token-free, because generation happens at answer time. Datasets come from the HuggingFace repository Zly0523/linear-rag, cloned and copied into dataset/. An embedding model must sit at model/all-mpnet-base-v2/. The entry point is run.py, and the README's quick start passes five flags: --spacy_model, --embedding_model, --dataset_name, --llm_model and --max_workers. There is one optional flag, --use_vectorized_retrieval, documented as using "vectorized matrix-based retrieval for GPU acceleration if Strong GPU is available, otherwise use BFS iteration." That flag is the main performance knob, and it is a hardware decision rather than a quality decision.

Where the relation-free design breaks

Dropping relations is not free, and the README does not discuss the cost. If a question turns on a specific predicate (who acquired whom, which drug interacts with which), a graph of similarity edges has no place to store that distinction. The retrieval has to recover it from the underlying text, which pushes the burden back onto the generator and the embedding model at answer time. The method is therefore the wrong tool for relation-typed question answering over a domain where the relation itself is the answer. A second limitation is dependency weight. The default path pulls a spaCy transformer model, a scispace model for medical text, and a sentence embedding model, all running locally. That is a real install footprint and a real runtime cost, and it is not the kind of thing you drop into a constrained container without checking. Third, the README gives no release history and no versioned artefacts; the repository has no releases retrieved, so there is no pinned version to upgrade against.

How this differs from LLM-extracted knowledge graphs

The obvious comparison is Microsoft's GraphRAG, which builds a graph by prompting a model to extract entities and relationships and then summarises communities over that graph. The difference is architectural, not incremental. GraphRAG spends LLM tokens at index time to obtain a typed, annotated graph and then spends more on community summaries. LinearRAG spends none at index time and keeps only entity nodes plus similarity edges. The payoff is that indexing cost stops scaling with model pricing and starts scaling with spaCy throughput and embedding computation. The cost is that you give up the typed structure that makes community summarisation and relation-specific queries possible. If your workload is global summarisation over a corpus, the typed graph is doing work that LinearRAG has no equivalent for. If your workload is multi-hop fact lookup where the hops are associative rather than predicate-typed, LinearRAG's approach is a defensible fit.

Maintenance, licence and upgrade surface

LinearRAG is GPL-3.0. That matters if you intend to link it into a proprietary service rather than run it as a separate process, because the copyleft terms attach to distributed derivative work. This is not legal advice; read the licence text and talk to counsel if the distribution model is unclear. On maintenance, the repository is not archived and the last push is recent, and the news section shows an active research group shipping adjacent systems (MemGraphRAG, ProbeRAG, LegalGraphRAG, LogicPoison, and a GraphRAG benchmark) through 2026. That is a signal of an active lab, not a signal of API stability. There are no releases, so upgrades mean tracking main. The practical upgrade cost is low if you stay on run.py's flag surface and high if you fork the graph construction code, because there is no version boundary to diff against.

What to check before you commit

Run the quick start on 2wikimultihop first, since that is the configuration the README actually shows, and confirm the pipeline completes with your own OPENAI_BASE_URL. Then swap in one dataset from your own domain and look at whether the semantic links connect the entities your questions need to traverse. That check is cheap and it answers the only question that matters for adoption: does similarity-based bridging reach the same passages that a relation-typed graph would have reached? If it does, the token savings are real and the design holds. If it does not, no amount of linear complexity will fix the retrieval quality, and you should look at an extraction-based graph instead. The repository ships no evaluation harness beyond the bundled datasets, so this comparison is on you.

Editorial conclusion

Adopt LinearRAG if your corpus is large enough that LLM relation extraction is the dominant cost and your questions can be answered by chaining entity mentions. Do not adopt it if your queries depend on named relation types, since the method deliberately discards them. Before committing, verify the licence terms for your distribution model, confirm that a spaCy transformer model and an embedding model at model/all-mpnet-base-v2/ are acceptable local dependencies in your environment, and check that the bundled datasets in the HuggingFace repository cover the domain you care about.

Official sources

1. DEEP-PolyU/LinearRAG on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README