When Should You Use Query-Focused Summarization in GraphRAG?

A product lead asks your AI assistant what customers keep complaining about across thousands of reviews.

A Text2Cypher query cannot answer that directly. Local graph search may only explain one product or one user. The answer needs synthesis across a broader corpus. That is where query-focused summarization fits.

In this post, we'll look at when GraphRAG needs this global retrieval pattern, how it differs from Text2Cypher and local graph search, and why keeping the pipeline close to the graph matters.

Why Global Questions Need a Different Approach

Not every GraphRAG question has the same shape. Some questions are analytical:

How many issues are labeled as bugs?

Others are contextual:

Which issues are related to this pull request?

And some are global:

What are the recurring complaints across this product category?

The first question is best answered with Text2Cypher. The second is best answered with local graph search. The third is different.

The answer does not live in a single node, relationship, or graph neighborhood. It emerges from patterns spread across many connected records. Global questions often ask for:

recurring themes
blind spots
missing coverage
underrepresented topics
patterns across many connected records
signals that only become clear after grouping related parts of the graph

These questions require synthesis rather than lookup or neighborhood exploration.

That is where query-focused summarization becomes useful.

This distinction aligns with findings from Microsoft's GraphRAG research, which showed that traditional retrieval approaches often struggle with questions that require reasoning across an entire corpus rather than retrieving a handful of relevant passages. Their paper, From Local to Global: A GraphRAG Approach to Query-Focused Summarization, introduced a global retrieval workflow specifically designed for these broader questions.

What Query-Focused Summarization Does

Query-focused summarization, or QFS, creates a summary based on the user's question instead of producing a generic summary of the whole dataset.

That distinction matters.

A generic summary says:

Here is what this dataset is broadly about.

A query-focused summary says:

Here is what matters for this specific question.

In GraphRAG, QFS usually works by processing a broader slice of the graph, grouping related entities or communities, generating smaller summaries, and then reducing those summaries into a final answer.

The basic flow looks like this:

global question
      ↓
load a broader graph slice
      ↓
group related nodes or communities
      ↓
summarize each group against the question
      ↓
combine the partial summaries
      ↓
return a focused answer

The goal is not to inspect one neighborhood or execute one graph query.

The goal is to use graph structure to organize information at a larger scale and produce an answer that reflects broader patterns.

This approach is closely related to techniques used in large-scale information retrieval and multi-document summarization, where systems must aggregate evidence from many sources before generating an answer. The challenge becomes even more important as datasets grow beyond what can fit into a single LLM context window.

A GitHub Issues Example: Finding Product Blind Spots

Imagine a knowledge graph built over GitHub issues.

Issues are connected through labels, extracted entities, related issue links, community groupings, and summaries over those communities.

Now someone asks:

Where are the blind spots?

This question asks for a higher-level view of what the issue graph reveals. Which areas keep showing up? Which problems appear under-discussed? Which communities point to recurring product gaps?

A local graph search workflow can help explain relationships around a specific issue or entity. However, it is not designed to summarize patterns across hundreds or thousands of related issues.

Query-focused summarization can work across the broader issue graph, summarize different communities, and turn those partial summaries into a focused answer about product blind spots.

Query:

Output:

That is the global retrieval pattern. The value is not that the system finds a matching issue. The value is that it can surface a pattern across many related issues.

If you're interested in how graph communities are identified before summarization, Memgraph's GraphRAG workflows can combine graph algorithms and community detection techniques to organize related information before it reaches the LLM.

Why Atomic GraphRAG Helps With Global Retrieval

Global retrieval has more moving parts than either Text2Cypher or local graph search. Query-focused summarization requires additional orchestration.

The pipeline may need to select a broader graph slice, group related nodes, apply graph algorithms, summarize communities, rank partial summaries, and assemble the final answer.

You can split those steps across scripts, services, prompt chains, and post-processing code. It may work, but it gets painful to debug.

If the answer is weak, where did the failure happen? Was the graph slice too broad? Were the communities wrong? Did the summaries ignore the query? Did the final reduction step drop useful context?

This is where the Atomic GraphRAG pattern becomes useful. The benefit is that more of the retrieval plan can stay close to the graph, where the data, relationships, and grouping logic already live.

For global questions, that matters because the answer depends on how the system moves through the graph before it ever reaches the LLM.

A good QFS pipeline should make that path easier to inspect, test, and adjust.

Many teams implement these workflows through Atomic GraphRAG pipelines, where retrieval patterns such as Text2Cypher, local graph search, and query-focused summarization can be composed while keeping graph operations close to the data.

When Query-Focused Summarization Is Too Much

QFS is powerful, but it is not the right choice for every GraphRAG question.

If the user wants an exact answer, use a query-shaped pattern such as Text2Cypher.

Examples:

How many issues are labeled as bugs?
Does this user ID exist?
Which products have more than 100 reviews?

If the user wants context around one entity, use local graph search.

Examples:

Which issues are related to this pull request?
Which accounts are connected to this suspicious transaction?
Which reviews and products are closest to this user?

QFS is for broader questions.

Examples:

What themes keep showing up across negative reviews?
Where are the blind spots in this issue graph?
What recurring risks appear across incident reports?
Which areas of this research corpus are undercovered?

A simple way to choose:

If the User Needs...	Use...
An exact value, count, table, or lookup	Text2Cypher
Context around one entity	Local graph search
Themes, gaps, or patterns across a corpus	Query-focused summarization

This mirrors a broader principle in retrieval-augmented generation: different retrieval strategies solve different classes of problems. Research from organizations such as Microsoft, Stanford, and Meta consistently shows that retrieval quality depends heavily on matching the retrieval method to the user's intent rather than relying on a single retrieval approach for every query.

Wrapping Up

Query-focused summarization is the GraphRAG pattern for global questions.

Use it when the answer does not live in a single query result or a single graph neighborhood. Use it when the reader needs a focused synthesis across a larger graph or corpus.

That makes QFS useful for questions about themes, blind spots, gaps, recurring complaints, and broad patterns.

The next step is to test this pattern on a dataset where the same signal appears across many related records. Start with one broad question, define the graph slice worth summarizing, group related entities, and inspect the partial summaries before trusting the final answer.

For a deeper walkthrough, read Memgraph's guide on Query-Focused Summarization in Atomic GraphRAG or explore the GraphRAG pipeline docs.