Graph RAG bottlenecks go beyond expansion: how two-stage Jev ranks evidence

Multi-hop questions often split their answers across documents: a question asks about drug side effects without naming the drug, or about a contract obligation without quoting the clause that defines it. Zilliz’s Vector Graph RAG stores relationships and source text in Milvus, then uses Jev in two passes to filter relations and rank evidence passages. The project reports 86.61% average Recall@5 for two-stage Jev 1.14 on 1,000 MuSiQue and 1,000 2Wiki questions. The figure deserves a closer look: what did it measure, and how far is it from end-to-end quality on a real knowledge base?

Key points

• Vector Graph RAG does not require a separate graph database: Milvus stores entities, relations and source text, while vector search finds starting points and IDs connect the expanded candidates.
• The project reports 86.07% Recall@5 for two-stage Jev 1.13 across 2,000 multi-hop questions and 86.61% for Jev 1.14. An independent analysis notes that the latter’s roughly 4.9-second API latency is an estimate calibrated from a small sample.
• Recall@5 measures whether evidence appears in the top five retrieval results. It is not answer accuracy, nor a promise about a reader’s corpus, indexing cost or total response time.

What the two passes rank

Vector Graph RAG does not begin by asking a large language model to answer the question. During indexing, it extracts triples from documents, keeps entities, relations and their source text, and stores them in Milvus. At query time, vector search finds likely entities and relations; linked IDs expand those starting points into a candidate subgraph. This is where graph retrieval faces its familiar tension: expand too little and miss a bridge between documents; expand too far and add relations that sound relevant but do not help answer the question.

The first Jev pass decides which relations are worth following. It scores candidate edges, retaining useful links and, when needed, intermediate relations that lead toward an answer. The system then fetches the original passages attached to those relations, combines them with passages found through direct vector search, and removes duplicates. The second Jev pass ranks text evidence rather than graph edges: it moves passages containing the information needed for the question toward the top before a generation model writes an answer.

The two passes make different judgments. A graph edge may be worth following even though its attached paragraph is not useful for this particular question. Conversely, direct vector search can find a valuable passage whose relationship was not represented in the graph. Merging both candidate sets before the second ranking pass is intended to reduce two errors: following an irrelevant path and finding a relevant relation but citing the wrong source text.

There is a cost. Relation extraction and indexing still use a generative model, while a query adds two decision-model calls. The design aims to make candidate screening more selective; it does not make Graph RAG model-free or latency-free. The distinction matters when comparing a retrieval architecture with a plain vector search baseline.

What 86.61% means

The WeChat article that prompted this review describes a test on MuSiQue and 2Wiki, two multi-hop question-answering datasets with 1,000 questions each. The reported measure is Recall@5: whether relevant evidence appears among the top five retrieved passages. The project evaluation and Zilliz’s write-up compare ordinary vector retrieval, HippoRAG 2, single-stage Jev, and reranking configurations using models including GPT-6 Luna and DeepSeek V4.1 Flash.

Configuration	Average Recall@5	Additional model API time reported	Source and caveat
Jev 1.13, one stage	80.04%	2.28 s	Project-reported result
Jev 1.13, two stages	86.07%	3.13 s	Project-reported result; the independent analysis discusses the full recipe
Jev 1.14, two stages	86.61%	about 4.9 s	Project-reported result; latency is estimated from a small calibration sample
GPT-6 Luna reranking	82.70%	5.35 s	Project comparison
DeepSeek V4.1 Flash reranking	83.34%	10.97 s	Project comparison

Sources: Vector Graph RAG’s evaluation notes, Zilliz’s technical post, and an independent analysis of the same project experiment. The latency figures are not end-to-end request times. Versions, datasets, generation models and retrieval settings should not be collapsed into an unconditional leaderboard.

Recall@5 answers a narrow question: did a labeled relevant passage make it into the first five candidates? It does not tell us whether the final answer is complete, whether citations support it, or whether the system correctly handles conflicting sources. Nor does it measure the quality of entity and relation extraction from raw documents. A system can retrieve the right passage and still fail during summarization, conflict resolution or attribution. So “beats LLM reranking” should be read as a claim about this project’s reported datasets and configurations, not as a general result for all Graph RAG systems, all large models or production corpora.

The independent analysis dated October 22, 2026 adds useful qualifications. Jev 1.14’s 86.61% comes with an approximately 4.9-second latency estimate that the author says was calibrated on a small sample. The improvement from single-stage to two-stage Jev 1.13 also comes from the complete recipe, which adds direct passage retrieval; the result does not isolate the second ranking pass as the sole cause. In an earlier evaluation with different datasets and conditions, the same author found single-stage Jev behind GPT-5-mini on harder multi-hop questions. Those results cannot be merged with the October benchmark, but together they show why performance depends on candidate quality, question difficulty and configuration.

The trade-off behind no graph database

Graph RAG does not always require a dedicated graph database. But “graph data stored in a vector database” should not be read as “the vector database provides native graph traversal.” The official Milvus Graph RAG tutorial also retrieves starting points with vector search and expands relationships in application code using adjacency information. Vector Graph RAG keeps entities, relations and source passages within the Milvus stack, then uses ID links to build the retrieval path. The goal is to reduce separate infrastructure and deployment work.

For a team already using Milvus, this may lower the cost of an experiment; the default Milvus Lite backend can start from a local file. For teams with a mature graph platform, complex traversal requirements or fine-grained graph constraints, replacing it with vector retrieval plus ID joins may not simplify the system. Relation updates, index consistency, concurrency and observability still need evaluation. The project documents incremental updates and deletes by source, but says source updates are not transactionally atomic across all collections. An interrupted operation may need to be retried to restore consistency.

Graph expansion also has a cost of its own. A 2026 EMNLP study on iterative Graph RAG says naive expansion can introduce noise; simple questions may not benefit, and bridge evidence can still be difficult to retrieve. Two-stage filtering is meant to control candidate growth, but its success depends on relation extraction quality, vector recall and the ranking budget. If the source documents do not express a relationship clearly enough to extract, a later reranker cannot invent the missing edge.

“No graph database” does not mean “free indexing.” The official quick start uses OpenAI by default; document processing, entity and relation extraction, embeddings and final answer generation all consume model or embedding resources. Jev’s relation selection and passage ranking add another service dependency. A fair cost model should include storage and operations, offline extraction, vector search, per-query filtering calls and final generation — not just the two or three seconds reported for reranking.

Test it on your questions first

Vector Graph RAG is a plausible fit when answers span documents, relation paths can be described, and ordinary vector search often misses evidence. It is not a default upgrade for every knowledge base. If most questions are answered by one passage, start with a vector baseline; only add graph relations and two-stage ranking if the added complexity produces a measurable gain.

A useful evaluation should record four kinds of results. First, evidence retrieval: Recall@5 or a metric closer to the product’s needs. Second, answer quality: manually check correctness, completeness and whether citations support the answer. Third, end-to-end cost: extraction failures, index update time, model calls per query and total latency. Fourth, consistency: after source updates or deletions, verify that relations, passages and vectors still agree. Break results out by simple questions, multi-hop questions, missing-edge cases, conflicting documents and unanswerable questions; a single average can hide the failure modes that matter.

Start with a few dozen real questions and label the evidence each one needs. Run ordinary vector retrieval, one-stage Jev and two-stage Jev with model version and candidate count held constant. Review outputs blind rather than comparing only with the README’s numbers. If two stages improve candidate recall but do not make answers or citations more reliable, users may not notice the gain. If bridge-heavy questions improve consistently, then invest in incremental updates, monitoring and access controls.

The interesting part of Vector Graph RAG is not simply that it is another Graph RAG framework. It gives two decisions separate jobs: choose which relations to follow, then choose which source passages to cite. That makes the quality-latency trade-off easier to inspect, while leaving the remaining gaps visible: the published benchmark covers specified datasets and settings, and independent reproduction on a real corpus is still necessary. See our Vector Graph RAG project entry for installation, then compare SAG-Wiki and LEANN for other ways to reduce the fixed costs of a RAG system.