# LinearRAG: relation-free GraphRAG with no LLM token cost at index time

> LinearRAG builds a graph from entities and semantic links instead of asking an LLM to extract relations, which removes token spend during graph construction. The trade-off is a SpaCy and embedding-model dependency and a repository that documents almost nothing beyond a single run.py invocation.

**DEEP-PolyU/LinearRAG** — [ICLR 2026] LinearRAG: Linear Graph Retrieval Augmented Generation on Large-scale Corpora

- Repository: https://github.com/DEEP-PolyU/LinearRAG
- Website: https://arxiv.org/pdf/2510.10114
- Stars: 552 · Forks: 68
- Language: Python
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/deep-polyu-linearrag

## What LinearRAG removes from the GraphRAG pipeline

Most GraphRAG systems spend a large share of their indexing budget on an LLM. The README of LinearRAG frames the project around exactly that: it calls itself "a relation-free graph construction method for efficient GraphRAG" and states that it "eliminates LLM token costs during graph construction". That is the whole pitch, and it is narrower than it sounds. LinearRAG does not replace the answering LLM. It replaces the step that turns a corpus into a graph.

The intended user is an engineer who has a corpus large enough that per-chunk relation extraction is a real line item, and who is willing to accept a graph whose edges come from entity recognition and semantic similarity rather than from typed relations such as works_for or located_in. If your downstream queries need typed edges, this is the wrong tool and no amount of speed fixes it.

## How the relation-free graph is actually built

The README lists three properties that describe the mechanism. Construction is "relation-free", built on "lightweight entity recognition and semantic linking". Retrieval is "semantic bridging", described as multi-hop reasoning "in a single retrieval pass without requiring explicit relational graphs". Complexity is claimed as linear in time and space.

Read together, the data flow is: chunk the corpus, run entity recognition over the chunks, link entities that are semantically close, and retrieve by walking that structure once rather than iterating over a relation graph. The entity recogniser is SpaCy, which is why the install step downloads en_core_web_trf rather than a general NLP bundle. The semantic part is the embedding model, which is why the run command takes an --embedding_model path pointing at a local all-mpnet-base-v2 directory.

What the README does not describe is the link threshold, how entity mentions are disambiguated across chunks, or what happens when a chunk contains no recognised entity. Those are the details that decide retrieval quality on a real corpus, and they are only in the paper, not in the repository documentation.

## Installing LinearRAG and running a first query

The README pins a specific stack. Python 3.9 is preferred, and requirements.txt pins numpy 1.21.0, pandas 1.3.0, scipy at 1.7.0 or above, scikit-learn 1.3.2, spacy 3.6.1, sentence-transformers 2.2.2, transformers 4.30.2, python-igraph 0.11.8, openai 1.54.5, httpx 0.25.2, tqdm 4.67.1, huggingface-hub 0.16.4 and pyarrow 12.0.1. Several of those are old pins, so install into a fresh virtual environment rather than into an existing one.

```bash
pip install -r requirements.txt
python -m spacy download en_core_web_trf
```

The first command installs the pinned packages. The second downloads the transformer-based English SpaCy model that the pipeline uses for entity recognition. For the medical dataset the README gives a different model, installed from a direct wheel URL:

```bash
pip install https://s3-us-west-2.amazonaws.com/ai2-s2-scispacy/releases/v0.5.3/en_core_sci_scibert-0.5.3.tar.gz
```

An OpenAI key and base URL are read from the environment. The README exports both variables, which means the answering side of the pipeline goes through an OpenAI-compatible endpoint even though graph construction does not.

```bash
export OPENAI_API_KEY="your-api-key-here"
export OPENAI_BASE_URL="your-base-url-here"
```

Datasets come from a HuggingFace repository and are copied into dataset/. The README's exact sequence is:

```bash
git clone https://huggingface.co/datasets/Zly0523/linear-rag
cp -r linear-rag/* dataset/
```

The embedding model must be present locally at model/all-mpnet-base-v2/ before the run will work; the README states this as a preparation step and does not give a download command for it, so you supply that directory yourself.

The entry point is run.py at the repository root. The README's quick start sets five shell variables and passes them as flags:

```bash
SPACY_MODEL="en_core_web_trf"
EMBEDDING_MODEL="model/all-mpnet-base-v2"
DATASET_NAME="2wikimultihop"
LLM_MODEL="gpt-4o-mini"
MAX_WORKERS=16

python run.py \
    --spacy_model ${SPACY_MODEL} \
    --embedding_model ${EMBEDDING_MODEL} \
    --dataset_name ${DATASET_NAME} \
    --llm_model ${LLM_MODEL} \
    --max_workers ${MAX_WORKERS}
```

The README notes one optional flag: --use_vectorized_retrieval, which it says uses matrix-based retrieval for GPU acceleration and otherwise falls back to BFS iteration. That comment is the only performance guidance in the repository, and it is a one-line note rather than a benchmark.

## Where LinearRAG breaks down

The dependency pinning is the first practical failure mode. numpy 1.21.0 and pandas 1.3.0 predate wheels for current Python releases, and the README's own preference for Python 3.9 confirms the project expects an older interpreter. Coexisting with a modern data stack in one environment is unlikely without a container or a separate virtualenv.

The second is the embedding model path. model/all-mpnet-base-v2/ is a hard-coded directory expectation, and the README does not say how to populate it, which model revision to use, or whether a different sentence-transformers checkpoint is acceptable. If the directory is missing or the model differs, the run fails at load time with no documented error message.

The third is the absence of any documented evaluation or serving interface. The repository has src/ and scripts/ directories but the README never describes their contents, so the only supported entry point is run.py with the flags above. There is no documented way to index incrementally, to delete a document from an existing graph, or to query a graph that has already been built without re-running the full pipeline. For a batch experiment that is fine. For a service that ingests new documents daily, it is a blocker until you read the source.

## LinearRAG against agentic RAG

The comparison people ask about is LinearRAG versus agentic RAG. The two solve different problems. An agentic system keeps an LLM in the loop at query time, issuing repeated retrieval calls and deciding when to stop; its cost scales with query volume and its behaviour is hard to bound. LinearRAG moves the expensive decision to index time and then performs what the README calls a single retrieval pass with semantic bridging. Index cost is bounded and paid once; query cost is lower and more predictable.

The cost of that choice is adaptability. An agent can reformulate a question, follow a citation, or abandon a dead-end retrieval. A single-pass graph walk cannot. If your queries are exploratory and phrased loosely, the agentic approach will absorb that variance and LinearRAG will not. If your queries are numerous and similar, paying an LLM per query is the worse deal. That is the actual dividing line, not benchmark scores.

## Maintenance, licence and upgrade cost

The last push to the repository was on 2026-07-05, which is recent, and the repository is not archived. There are no retrieved releases, so there is no tagged version to pin against: the install path is a clone of main plus requirements.txt, and any upgrade means re-reading the diff. The README's news section shows the same group shipping several other GraphRAG papers and repositories through 2026, which suggests LinearRAG competes for attention with sibling projects rather than being the sole focus.

The licence is GPL-3.0, recorded in LICENSE.txt at the repository root. That is a copyleft licence. If you modify LinearRAG and distribute the result, or ship it as part of a larger distributed work, the licence terms attach to that distribution. Internal use does not trigger the same obligation, but embedding the code in a distributed product is a different matter. This is a description of the licence, not legal advice; get counsel if the distinction matters to your product.

## Conclusion

Adopt LinearRAG if you already run Python 3.9, can host en_core_web_trf and an all-mpnet-base-v2 embedding model locally, and want a graph index whose construction does not bill tokens. Do not adopt it if you need a documented API, a supported upgrade path, or a licence you can embed in a closed product, since GPL-3.0 applies to the whole repository. Before committing, verify that src/ exposes the retrieval entry points you need, that the dataset layout under dataset/ matches the HuggingFace clone, and that the embedding model exists at model/all-mpnet-base-v2/.

## FAQ

### What is a linear graph in LinearRAG?

The name refers to the complexity claim rather than a specific graph shape. The README states that the method has linear time and space complexity, and that graph construction is relation-free, using entity recognition and semantic linking instead of LLM-extracted relations.

### What is linear RAG?

LinearRAG is a GraphRAG method for large corpora whose defining property is that graph construction consumes zero LLM tokens. It builds the graph from lightweight entity recognition and semantic linking, then retrieves through semantic bridging in a single pass.

### How does LinearRAG differ from agentic RAG?

The README describes LinearRAG as performing multi-hop reasoning in a single retrieval pass without an explicit relational graph, and as eliminating LLM token costs during graph construction. An agentic approach keeps an LLM issuing retrieval calls at query time, so its cost scales with query volume instead of being paid once at index time.

## Sources

- [DEEP-PolyU/LinearRAG on GitHub](https://github.com/DEEP-PolyU/LinearRAG)
- [Issues](https://github.com/DEEP-PolyU/LinearRAG/issues)
- [License: GPL-3.0](https://github.com/DEEP-PolyU/LinearRAG/blob/main/LICENSE)
- [Project website](https://arxiv.org/pdf/2510.10114)
- [README](https://github.com/DEEP-PolyU/LinearRAG/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/deep-polyu-linearrag