Bound GraphRAG expansion for multi-hop answers

Learning objective

Combine graph traversal with vector retrieval (GraphRAG) for multi-hop reasoning.

Core idea

Vector search finds text whose meaning resembles a query. Graph traversal follows explicit connections between entities. Combine them when a question requires a relevant starting point and relationships that cross document boundaries: a project uses a service, the service depends on a library, and the library has a reported vulnerability.

The vector result supplies a candidate entry point; the graph supplies candidate paths. Neither guarantees the final conclusion. A similarity score is not the truth probability of an edge, and a connected path is useful only if its predicates, scope, and supporting passages answer the question. The model and extraction controls from 1.7.1 and 1.7.2 remain prerequisites.

How it works

Retrieve entry points, then expand relationships

NVIDIA’s Context-Aware RAG exposes retriever_function.type: graph_retrieval, using an LLM and a graph database. Its configuration documents Neo4j and ArangoDB backends. In the Neo4j implementation, the chunk retriever uses Neo4jVector and VECTOR_GRAPH_SEARCH_QUERY to combine semantic retrieval with graph expansion.

The query begins with a retrieved chunk and score, then follows PART_OF to its Document. It applies a document uuid filter when one is supplied. From the chunks, HAS_ENTITY finds entities used as expansion seeds. This connects text relevance to explicit entity relationships rather than asking a generator to invent the missing bridge between two passages.

The same database can hold vectors and graph structure. GraphRAG does not require a separate vector database, and storing vectors beside nodes does not by itself establish a useful traversal strategy. Here the retrieval query, not the physical number of databases, defines the combination.

Understand what the traversal actually bounds

The Neo4j VECTOR_GRAPH_SEARCH_QUERY uses entity embedding similarity to choose its expansion. With an entity cosine score from 0.3 through 0.9, it collects paths of zero or one relationship; above 0.9, it collects paths of zero through two relationships. Missing entity embeddings take the shorter branch. Lower-scoring entities take the entity-only branch. These are constants and branches in this implementation, not universal GraphRAG thresholds.

The path pattern excludes HAS_ENTITY and PART_OF relationships and excludes Chunk and Document endpoint labels. It traverses domain relationships without specifying a direction in that pattern. A returned path therefore needs interpretation using each stored edge’s direction and predicate. Undirected exploration is a discovery mechanism, not permission to reverse the meaning of ownership or dependency.

The query keeps at most VECTOR_GRAPH_SEARCH_ENTITY_LIMIT (40) seed entities per retrieved document, ranked by how many retrieved chunks mention them. It returns at most 20 or 40 paths per seed entity in the shorter and longer branches respectively. Total seeds therefore scale with the number of retrieved documents, and total paths scale with the number of seeds. A LIMIT bounds returned matches at that point; it is not a complete wall-clock deadline or proof that every relevant path was explored.

After expansion, the query deduplicates nodes and relationships across chunks and assembles graph content with retrieved text. This reduces repeated context, but no deduplication step repairs a wrong entity merge or an unsupported edge. When a required bridge is absent, return an incomplete answer or retrieve more support rather than completing the chain from model knowledge.

Each seed’s entity score picks how far the query expands it, and every branch then ends in deduplication and assembly.

Choose fixed expansion or planned retrieval

For questions needing iterative exploration, Context-Aware RAG documents adv_graph_retrieval, a planner-driven retrieval function. Its tool list includes chunk_search for semantic chunk search, entity_search for similar entities and related chunks, and bfs for finding nodes one hop away. Repeated exploration can assemble a multi-hop path while intermediate results guide the next search.

The documented advanced function requires a reasoning llm, a vision-capable vlm, a graph db, and image_fetcher. NVIDIA’s feature page and compatibility matrix list both Neo4j and ArangoDB for the planner. When applying this video-oriented implementation to enterprise text, adapt the visual-tool dependencies explicitly.

Its max_iterations parameter defaults to 20 and becomes RunnableConfig(recursion_limit=...) in planner_retrieval.py. That limits the graph runtime’s recursion, not elapsed seconds or a guaranteed number of business hops. Planner steps can search chunks, read content, or inspect entities; a three-step reasoning run need not traverse three edges.

Key distinctions and trade-offs

Choose a retrieval path by the work the question requires:

top_k controls retrieved entry results; hop depth controls distance from them; path limits control returned expansion volume. Raising one does not substitute for the others. More seeds can improve coverage while increasing duplicated neighborhoods and prompt tokens. Deeper traversal can reveal a missing link while bringing unrelated hubs into context.

Measure end-to-end answer correctness alongside seed relevance and path completeness. Keep a labeled set of questions with the required entity paths and supporting passages. A retriever that returns the correct project but misses its library dependency has good entry-point relevance and inadequate multi-hop recall. Assign those failures to traversal or graph coverage rather than adjusting the generator’s wording.

Architecture / decision scenario

A software security assistant answers employee questions about application exposure. Its test corpus contains project descriptions, service inventories, and dependency reports. The required chain is project → service → library, while the vulnerability details sit in a separate bulletin. The interactive service has a four-second latency objective.

In a team benchmark, vector-only retrieval produces complete supported answers on 64 of 100 multi-hop questions at 1.1 seconds p95. Fixed graph expansion reaches 91 at 3.2 seconds p95; a planner reaches 95 at 7.4 seconds. These are scenario measurements, not NVIDIA performance claims.

The tempting proposal enables the planner for every question because its completeness is highest. The service owner chooses fixed expansion for the interactive path because it satisfies the four-second objective, and offers a separate background investigation for unresolved chains. The graph data owner checks canonical service and library identifiers; the retrieval owner tunes seeds and expansion against the labeled paths.

For an answer to name an exposed project, retrieved text must support the vulnerability and the graph must support both dependency edges. A similar project description alone is insufficient. If a required edge or document revision is missing, the interactive response names the unresolved dependency instead of declaring the application safe. That distinguishes missing support from a negative finding.

Common exam traps

• Calling vector similarity multi-hop reasoning without a relationship path.
• Assuming GraphRAG requires two separate databases.
• Treating an undirected search result as a symmetric business relation.
• Equating top_k, hop depth, path limits, and max_iterations.
• Assuming the advanced planner runs unchanged on a text-only stack: its documented tools include a vision-capable vlm and image_fetcher.

What to remember

Use semantic retrieval to find entry points and explicit traversal to connect them. Bound seeds, paths, context, and runtime separately. Choose planned exploration only when its extra retrieval flexibility fits the workload’s latency budget, and require source support for the complete reasoning chain.

Knowledge check

References

• NVIDIA, Context-Aware RAG features
• NVIDIA, Advanced setup
• NVIDIA, Context-Aware RAG configuration
• NVIDIA, Neo4j storage implementation
• NVIDIA, GraphRAG query constants
• NVIDIA, Planner retrieval implementation