A fraud analyst asks your AI assistant why an account looks suspicious. A plain lookup gives the account record. A broad summary pulls in too much noise. The useful answer sits nearby: connected devices, recent transactions, shared addresses, and linked accounts.
That is where local graph search helps. It starts from a relevant entity, expands through nearby relationships, and gives the LLM a focused slice of connected context.
In this post, we’ll look at when to use local graph search, how pivot-based retrieval works, and how to keep the neighborhood small enough to be useful.
What Is Local Graph Search?
Local graph search starts with a pivot.
A pivot is the node or set of nodes the rest of the retrieval depends on. It is the anchor for the local context.
In a GitHub Issues graph, the pivot might be an issue. In a product review graph, it might be a user or product. In a cybersecurity graph, it might be an alert, asset, or account.
The user might give the pivot directly:
Show me the related context around user ID
AGLOOCISSVGEGUCSSSSNHWZHOM60.
Once the pivot is found, the graph does what flat retrieval cannot do well: it follows relationships.
user question
↓
find the pivot
↓
expand nearby relationships
↓
rank and trim the neighborhood
↓
return compact context
Search gets you to the right starting point. Traversal gives you the surrounding evidence.
The Answer Lives Around the Node
Local graph search is useful when the answer is not stored as one property on one node.
It lives around the node.
For example:
- A fraud alert needs connected accounts, devices, merchants, and recent transactions.
- A reopened GitHub issue needs related issues, pull requests, labels, and users.
- A product page needs reviews, related products, parent products, and user behavior.
- A security alert needs users, permissions, services, events, and assets.
- A research paper needs authors, citations, methods, datasets, and follow-up papers.
These are not whole-corpus questions. They are also not clean lookup questions. They sit in the middle.
That is why local graph search is such a useful GraphRAG pattern. It handles the messy class of questions where the user points at one thing, but the answer depends on the surrounding structure.
A Local Graph Search Example
Imagine a pull request fixes a serialization bug in an open-source project. The PR may solve the immediate problem, but the surrounding issue graph can still contain related issues that were never linked to the PR, never updated, or never closed.
That is a local graph search problem.
In a GitHub Issues knowledge graph, issues can connect through labels and through RelatedTo edges derived from entity extraction over issue titles and descriptions. So the question is not only whether one PR fixed one issue. The better question is:
Which related GitHub issues should be updated or closed, and which community members should be informed?
A local graph search flow can start by embedding the phrase that describes the fixed problem:
CALL embeddings.text(
['serialization errors during concurrent edge writes on supernodes']
)
YIELD embeddings, success
Then vector search can find the most relevant starting points in the graph:
CALL vector_search.search('vs_index', 10, embeddings[0])
The system can also inspect the graph schema before running the next retrieval steps:
SHOW SCHEMA INFO;
From there, regular Cypher queries can expand from the matched issue or PR into related issues, labels, authors, commenters, and extracted relationships.
The value is not that the system finds one similar issue. Basic search can already do that.
The value is that local graph search recovers the surrounding context needed to decide what should happen next. Which issues are still open? Which ones describe the same underlying bug? Which community members were involved in earlier reports or discussions?
That neighborhood is the answer.
For the full walkthrough, watch Memgraph’s community call on Atomic GraphRAG.
How to Make Local Graph Search Easier to Debug
This is also where the Atomic GraphRAG pipeline becomes useful.
The GitHub Issues example is not a simple lookup. The pipeline has to embed the problem phrase, find a relevant starting point, inspect the schema, expand through related issues, and return the context that helps decide what should be updated or closed.
You can wire those steps together across separate scripts and services, but that makes the retrieval path harder to debug. If the answer is wrong, you need to check the embedding call, vector search result, traversal logic, filters, and final prompt assembly separately.
Atomic GraphRAG keeps more of that retrieval logic close to the graph. The benefit is that the path from question to context becomes easier to inspect, test, and change.
For local graph search, that matters because the quality of the answer depends on the path the system took through the graph.
Do Not Let the Neighborhood Become the Whole City
Local graph search can go wrong when the traversal expands too far.
One hop may give useful context. Two hops may reveal the pattern. Five hops can turn into graph confetti if you do not control it.
The job is not to return the biggest neighborhood. The job is to return the smallest neighborhood that still helps answer the question.
That means the pipeline needs guardrails:
- Limit the number of hops.
- Choose which relationship types matter.
- Rank nearby nodes by relevance.
- Cut low-value properties before prompt assembly.
- Return samples instead of dumping every connected node.
This is where local graph search differs from “just traverse everything.”
Traversal without ranking is noise. Traversal with constraints is retrieval.
Use a Different Pattern When the Question Shape Changes
Local graph search is the right fit when the user asks about context around a specific entity.
But it is the wrong fit when the question shape changes.
If the user asks for an exact value, use a query-shaped approach such as Text2Cypher.
Examples:
- How many open issues are labeled as bugs?
- Does this user ID exist?
- Which products have more than 100 reviews?
If the user asks for themes across a dataset, use a global retrieval pattern such as query-focused summarization.
Examples:
- What are the main themes across negative reviews?
- What gaps appear across this research corpus?
- What are the biggest product complaints across all categories?
A simple rule:
| If the User Needs... | Use... |
|---|---|
| An exact value or table | Text2Cypher |
| Context around one entity | Local graph search |
| Themes across the corpus | Query-focused summarization |
The retrieval pattern should follow the question shape. If it does not, the pipeline becomes noisy or shallow.
Wrapping Up
Local graph search is useful when the question starts from a specific entity but the answer depends on what surrounds it.
A fraud analyst does not only need the account record. A support engineer does not only need the issue title. A product assistant does not only need the product description. In each case, the useful context lives in nearby relationships.
That is the core value of local graph search. It helps a GraphRAG system retrieve a focused neighborhood instead of pulling in either too little context or too much noise.
The next step is to test this pattern on a graph where relationships already matter. Start with one entity type, define the relationships worth traversing, limit the number of hops, and inspect what context reaches the LLM.
For a deeper walkthrough of this pattern, Memgraph’s guide on local graph search for GraphRAG breaks down GitHub Issues and Amazon Reviews examples. The related community call on building an Amazon-scale knowledge graph for GraphRAG is also useful if you want to see the pattern applied to a large connected dataset.
Top comments (0)