GraphRAG · Product research
What does GraphRAG actually change?
A study of product value, from graph databases to generative AI.
GraphRAG combines graph structures with retrieval-augmented generation (RAG), allowing AI to use relationships between entities when answering questions.
It is not an upgrade to a graph database, nor is it necessarily more advanced than standard RAG.
The question worth asking is: When information is connected in complex ways, can GraphRAG help people understand, use, and discover information more effectively?
This article starts with the technology landscape, then examines cases at different stages of maturity to explore GraphRAG’s product value and boundaries. Implementation and performance evaluation are left for later technical work.
01｜Where GraphRAG fits
Databases, search engines, RAG, and GraphRAG all help people obtain information, but they suit different tasks.
A relational database is a good choice for checking an account balance. Full-text search can locate documents containing specific content. A graph database offers a more direct way to work with relationships when analyzing transfers between accounts.
GraphRAG is worth considering when users want AI to combine those relationships with supporting material to answer more complex questions.
The following four conceptual workflows compare how Naive RAG, GraphRAG, Agentic RAG, and LLM Wiki handle knowledge.
How do four approaches handle knowledge?
Naive RAG
Retrieve relevant material, then have an LLM generate an answer.
What is our business travel expense policy?
- User question
- Retrieve documents
- LLM reads results
- Generate an answer
Document retrieval · Context · Answer generation
GraphRAG
Use relationships between entities to support retrieval and answers.
Which customers will a delay to Project A affect?
- User question
- Find entities & linksKnowledge graph
- Get related material
- LLM synthesizes an answer
Structures can be built from raw text;
no existing graph database is required.
Knowledge graph · Entity relationships · Related evidence
Agentic RAG
Let an Agent decide how to investigate.
Why is Project A delayed?
- User question
- Agent decides next step
- Call tools / systems
- Enough evidence?
- Synthesize an answer
If evidence is insufficient, return to the Agent to decide the next step and retrieve again or call tools. If sufficient, synthesize an answer.
NoYesBased on intermediate results,
retrieve again / call tools
Agent · Tool use · Dynamic decisions · Iterative retrieval
LLM Wiki
Use an LLM to organize and maintain reusable knowledge in advance.
What is the latest information on Project A?
Before: maintenance
- Source material
- LLM organizes & links
- Wiki / knowledge base
Ongoing updates
The LLM continuously organizes and updates the Wiki. Later questions query this maintained knowledge base to generate answers.
Later: use
- User question
- Query the Wiki
- Generate an answer
Knowledge organization · Ongoing updates · Reuse
Conceptual flows, not the only implementations. Naive RAG refers to the basic retrieval-to-generation flow, not all non-GraphRAG methods. Agentic RAG need not use a graph. LLM Wiki is not a uniformly defined RAG architecture.
GraphRAG tends toward relationship-aware retrieval and synthesis, but other technologies can also handle such tasks.
Another term that can cause confusion is Knowledge Graph.
A knowledge graph organizes knowledge by representing entities, their attributes, and relationships. It may be stored in a graph database or provide a knowledge foundation for retrieval, analysis, or AI systems.
Knowledge Graph, Graph Database, and GraphRAG therefore describe different kinds of things.
A graph database focuses on storing, querying, and managing relationship data. GraphRAG focuses on using graph structures to support retrieval and generation.
They can be used together or separately.
02｜How GraphRAG developed
GraphRAG draws on three lines of development: data management, information retrieval, and language models.
Data and graph technologies
Relational databases enabled businesses to manage and query large amounts of structured data.
As social networks, financial transactions, and corporate ownership became important applications, relationships between entities themselves became a focus of analysis.
Graph databases offered a more direct model for storing, traversing, and analyzing those relationships. Knowledge graphs placed further emphasis on organizing and representing entities, concepts, and semantic relationships.
Information retrieval
Full-text search made it possible to find relevant information in large document collections. Semantic retrieval then used representations of meaning to move beyond keyword matching alone.
These technologies keep improving the same task: finding the information a current task needs within an expanding collection.
Language models and RAG
Language models gradually gave systems stronger capabilities for understanding and generating natural language.
RAG combines external retrieval with language generation. Instead of relying only on a model’s internal knowledge, it first retrieves relevant context from external material and uses that context to generate an answer.
GraphRAG explores a further question: Can graph structures help organize entities, relationships, and supporting evidence during retrieval and generation?
Data & graphs1970 · Relational model milestoneRelational models and graph technology
The relational model advanced structured data management and precise querying. Graph theory, network analysis, and graph querying also have long independent histories; relationship analysis did not begin with generative AI.
IBM: relational database history ↗Information retrievalThe long development of information retrievalKeywords and inverted indexes
Link terms to the documents containing them so people can locate sources in large collections. Retrieval developed alongside databases and language technology; later models have not replaced it wholesale.
Stanford: information retrieval textbook ↗NLP / LLMFrom statistical methods to neural networksLanguage modeling
Research into predicting and processing language from context. Later generation and summarization capabilities build on long-standing work; no single starting point captures this entire line of development.
Transformer paper: background and related work ↗Data & graphs2012 · Google Knowledge GraphRepresenting knowledge as a graph
Google brought its Knowledge Graph into search: a public product milestone, not the invention date of knowledge representation or knowledge graphs. A knowledge graph represents entities and their relationships.
Google：Introducing the Knowledge Graph ↗Information retrievalBeyond literal matchingSemantic and vector retrieval
Learned representations help find semantically related material. Keyword and vector retrieval can be combined. Relevance does not establish truth or guarantee complete cross-document connections.
RAG paper: dense retrieval and related work ↗NLP / LLM2017 · Attention Is All You NeedTransformer
Transformer underpins many later language models. It does not replace graph databases, and generating language does not itself provide reliable evidence verification.
Original Transformer paper ↗Data & graphsParallel developmentGraph queries and algorithms remain useful on their own
Paths, communities, and connection patterns can serve business systems directly without passing results to an LLM. Adding generation depends on whether users need natural-language synthesis and explanation.
Neo4j: pathfinding algorithms ↗Information retrieval2020 · RAG paperRAG · Retrieval-augmented generationThe basic retrieve → generate flow is often called Naive RAG.
RAG combines retrieval and generation: a retriever supplies external material for a generative model to use. This is an important paper milestone, not the sole origin of all retrieval-augmented ideas.
Retrieval-Augmented Generation ↗NLP / LLMConverging with information retrievalModels generate from retrieved context
Answers draw on retrieved context as well as knowledge in model parameters. Models can still overlook, misread, or misinterpret evidence; retrieval and generation need separate evaluation.
Original RAG paper ↗Information retrieval + language generation: RAG combines these capabilities.
Terminology: Naive RAG commonly names the basic retrieve → generate flow. It is not the formal name of the original 2020 paper, nor an umbrella term for every RAG method outside GraphRAG. Terminology reference (survey) ↗
Combining capabilities · not a chain of inheritance
Graph structures+Information retrieval+Language generation
Different GraphRAG methods
Representative milestone · 2024 Microsoft GraphRAG
The Microsoft paper and open-source project represent one implementation, not the sole destination of these three paths.
These technologies do not simply replace one another. Standard RAG remains useful for many document question-answering tasks, while graph databases continue to support relationship queries and analysis.
GraphRAG represents a new way to combine capabilities.
03｜What can GraphRAG do in products?
From a product perspective, two potential benefits are worth investigating.
Reduce manual work. Help users find related material, organize evidence, and explain complex information, reducing repeated queries and manual synthesis.
Support discovery. Help users notice previously overlooked connections, shared themes, or research leads across scattered information.
Neither benefit is unique to GraphRAG. The following four cases, at different stages of maturity, show what related technologies actually contribute to a product.
Case 1｜Anti-money-laundering: what happens after an anomaly is detected?
Banks monitor large volumes of transactions for unusual activity that may involve money laundering.
Some patterns are hard to notice when transactions are viewed individually. Bringing accounts, customers, and transfers into one network can reveal patterns worth investigating.
For example, funds might move through several accounts before returning to a related account.
Figure 3 · Entirely fictional accounts and transfers illustrate three stages: records, relationships, and investigation. A cycle is a lead, not proof of wrongdoing.
A · Inspect individual records
Start with three of six records. The other records are needed to reveal the complete path; drawing it creates no new evidence.
B · Add records and reveal transfer relationships
Select a record to locate its edge
No record selected; all six transactions are shown.
C · Follow connections to customer background and evidence
Query related accounts, retrieve customer and transaction records, then use AI to organize evidence for human verification. This only illustrates responsibilities; no model or live retrieval was run.
Graph databases and graph algorithms already help banks analyze complex transaction networks.
The Bank for International Settlements’ Project Aurora studied network analysis, machine learning, and cross-institution data collaboration for detecting money laundering. It was a research proof of concept, not evidence that GraphRAG has replaced traditional detection systems.
The more relevant opportunity for GraphRAG is the investigation that follows an anomaly.
Investigators still need to establish who the related customers are, when transfers happened, whether other suspicious records exist, and which evidence supports a judgment. That material may be spread across different systems.
If AI can combine account relationships, transaction records, and customer information to help retrieve and organize evidence, it may reduce repetitive information work.
Neo4j has also demonstrated a KYC investigation agent built with knowledge graphs and GraphRAG. That demo uses synthetic data and cannot be treated as a real bank’s application results.
In this scenario, graph analytics identifies suspicious connections; GraphRAG may help investigators understand them and organize evidence.
Relationships between accounts alone cannot establish wrongdoing, and the system cannot replace final human investigative judgment.
References:
Case 2｜Public comments: finding shared concerns across large volumes of feedback
Some products aim to discover questions worth investigating rather than find an answer already specified.
A government, for example, may receive thousands of public comments on AI policy. Some discuss employment, others education, privacy, safety, or technological development.
Analysts want more than topic counts. They also want to understand connections between different groups’ views, which concerns appear together, and whether important views are being overlooked.
Keyword statistics, topic clustering, and traditional text analysis solve part of this problem. Connections between views still deserve further investigation.
Microsoft has published a public-comment analysis practice that uses LLMs to extract views, organize connected information, and explore synthesis through GraphRAG-related methods.
- Raw public comments
- Extract views and connections
- Organize and synthesize related material
- Produce research leads to verify
One promising direction is helping analysts identify research questions they had not explicitly formulated.
Comments about employment changes and educational opportunity, for example, may share concerns worth examining. A system can help researchers notice that connection.
The connection alone does not establish causality, nor can automatically generated themes be assumed to represent public opinion accurately.
This published practice includes experimental methods such as LazyGraphRAG. Its results should not all be attributed to standard Microsoft GraphRAG Global Search.
The potential value is more than faster organization: it is expanding analysts’ ability to discover questions.
The idea may extend to market research, policy analysis, or scenario planning. Moving from a connection to a reliable judgment still requires further evidence.
References:
Case 3｜Business analysis: helping business users work directly with data
Many businesses do not lack data. The difficulty is that ordinary business users cannot easily use it directly.
A business lead at a gaming company might ask:
How much revenue growth did a particular promotion generate?
Answering may involve sales records, product information, promotions, time periods, and several business metrics.
The data lives in different tables and systems, whose schemas may not reflect the concepts business users work with.
Even when the data exists, users therefore still ask analysts to write queries and assemble the results.
A published customer case involving Deloitte Consulting LLP, Neo4j, and AWS combines a knowledge graph with AI agents.
The graph represents business concepts and their relationships to data structures. Agents use those relationships and the user’s question to organize queries and obtain data through Snowflake.
Deloitte: implementation partnerNeo4j and AWS also participate in the case. The diagram shows only disclosed core responsibilities.
- Ask a questionNatural language
Business users express an analytical need.
- Interpret business semanticsKnowledge graph / Neo4j
Supply business concepts and relationships to identify the data needed.
- Compose a querySQL
An LLM agent generates a query from the question and relevant semantics.
- Snowflake
Execute the data query and return business data.
- Compose an explanationAnswer
Answer from query results; definitions and correctness still need checking.
Neo4j reports efficiency improvements from this application. These are vendor-disclosed customer outcomes and have not been independently verified in this article.
Unlike the public-comment case, this approach does not require first dividing a large document collection into communities and generating community summaries.
Its focus is using existing business relationships to help AI interpret questions and access enterprise data correctly.
The product value is lowering the barrier to obtaining and analyzing data.
A knowledge-graph-enhanced agent is one possible approach. Enterprise semantic layers, data catalogs, and Text-to-SQL may meet similar needs.
The benefits of specific alternatives should therefore be compared, rather than attributing every improvement to GraphRAG.
References:
Case 4｜Water Margin: moving from lookup to exploratory reading
The final case is a product direction I want to investigate further.
Water Margin contains many characters and events, with relationships that continue and change across chapters. Readers may have several different needs.
If you forget the chapter in which a character first appears, search may find the answer. Understanding why Lin Chong eventually joins the outlaws at Liangshan requires bringing together events and experiences from several chapters.
Comparing characters with similar experiences or exploring indirect connections between them may require more systematic organization of relationships.
- Understand on demand
- Look up characters, revisit events, and find source passages within current reading progress.
- Explore proactively
- Compare experiences, observe changing relationships, and find connections worth reading further.
GraphRAG might organize connections between characters, events, and chapters, combining them with source passages to support answers. Whether this is better than standard RAG still requires experimentation.
A reading assistant has a particularly important constraint:
More complete information does not always better serve the reader.
If someone has read only to chapter ten, a system that knows the whole story should not reveal future events without permission.
The product must therefore decide what information it can provide based on reading progress, as well as find relevant connections.
This remains a product concept. Its research question is:
Can GraphRAG make a complex work easier to understand and help readers discover new ways to read it?
04｜How is GraphRAG implemented?
Despite their different settings, the cases involve a common question:
How can AI use relationships between information, rather than process an isolated passage of text?
There is no single architecture for achieving this.
Common elements of GraphRAG
Three main elements can be drawn from different implementations.
Organize relationships
Obtain connections between entities. These may come from existing databases or knowledge graphs, or be extracted from text. A separate graph database is not always necessary, and LLMs need not generate every relationship.
Retrieve information
Use graph structures to find entities, relationships, or material relevant to the user’s question. Vector retrieval, keyword search, and database queries may also be used.
Synthesize an answer
Organize the retrieved relationships and supporting evidence into context for a language model to generate an answer.
User question
Relationship-aware retrieval
Relevant context
LLM answer
Relationship information may come from an existing knowledge graph or be extracted from source material. Actual systems may use different retrieval and generation methods.
This is a shared conceptual diagram, not a mandatory pipeline for every GraphRAG system.
Different products can use different architectures
Nodes describe logical responsibilities, not separate services. Graph and DB may share a system. Solid arrows show query-time information flow; the dashed arrow supplies summaries prepared in advance.
ARelationship-query enhancement
Anti-money-laundering investigation
Available material
Account relationships, transactions, and customer records.
Query stage
Retrieve related evidence
Graph finds information
Follow Graph relationships to relevant entities, retrieve material from DB, and assemble Context for the LLM to explain.
This supports investigation after an anomaly. Separate graph algorithms or rules can still detect anomalies.
BKnowledge-graph-enhanced agents
Business analysis
Available knowledge
Semantic links between business concepts, metrics, and data structures.
Query stage
Graph guides the query
Graph helps the Agent understand business meaning, plan queries, and call tools. DB returns data for the LLM to answer from.
Graph informs the query; it need not supply the final answer itself.
CCommunity-summary enhancement
Themes across large document collections
Index stage · prepared in advance
Query stage
Use prepared summaries
Graph organizes knowledge in advance
Index documents into a Graph, identify communities, and generate summaries. At query time, obtain summaries as Context for LLM synthesis.
A representative pattern: the earlier Microsoft public-comment case did not necessarily use this standard architecture throughout.
These representative patterns illustrate technical differences. They are not mutually exclusive standard categories, and one system may combine several.
Microsoft GraphRAG is a representative implementation of the community-summary approach. It extracts entities and relationships from documents, builds a graph, and uses community detection and summaries to organize some knowledge in advance.
Local Search can retrieve relevant context for questions about specific entities. Global Search can organize information from multiple community reports for questions spanning a whole collection.
Entity-specific question
Local Search
- Related entities and relationships
- Source passages and other context
- LLM answer
Collection-wide question
Global Search
- Multiple community reports
- Synthesize information in batches
- LLM combines answers
Parallel uses, not successive upgrades. These examples do not represent every GraphRAG architecture.
This article does not go into community-detection algorithms, index parameters, or retrieval details. The important distinction is:
GraphRAG can use existing relationships during retrieval, or organize substantial connected knowledge in advance.
The approaches can differ in suitable tasks, information coverage, and construction costs. The former may not adequately answer broad questions; the latter adds preprocessing, summary maintenance, and update costs.
Architecture should follow the product’s problem.
References:
05｜Is GraphRAG worth using?
GraphRAG is worth considering when complex connections materially affect the user’s task and existing approaches struggle to handle those relationships effectively.
It may offer two benefits:
Reduce manual work: help find, organize, and explain complex relationships and their evidence.
Support discovery: help identify overlooked connections and research directions.
Neither capability is unique to GraphRAG.
Ordinary document Q&A may need only RAG. A precise relationship query may use a graph database directly. Real-time anomaly detection may be better served by graph algorithms and machine learning. Structured business data can also be queried using SQL, semantic layers, or Text-to-SQL.
GraphRAG can add graph construction, index updates, model calls, and fact-checking costs.
The real question is:
For the same user task, does GraphRAG provide an improvement over simpler approaches that justifies the investment?
If not, it may not be the right choice.
06｜The future of GraphRAG
GraphRAG is one option among many, but it points to an interesting direction:
AI that uses relationships between information, as well as finding and generating information.
As language models improve, the combination may change. Future models might understand large volumes of raw material more effectively, reducing the need to build knowledge structures in advance for some tasks.
Even then, enterprises may still need reliable, maintainable, and traceable knowledge relationships. Customer-company relationships, business metric definitions, and connections between data sources involve more than language understanding alone.
I therefore want to leave an open question:
Will GraphRAG become lasting knowledge infrastructure for the AI era, or a transitional response to the limits of today’s language models?
There is no certain answer yet.
Next: from product research to technical practice
This article stays at the product level. The cases reveal potential value and explain why GraphRAG does not suit every situation.
Questions still need testing: how should a knowledge graph be built? How do retrieval strategies differ? How much does graph structure improve answer quality? Could standard RAG complete the same task?
Next, I plan to continue exploring GraphRAG implementation using Water Margin. Starting from actual reading needs, I will investigate knowledge organization, relationship retrieval, and generation, comparing them with simpler approaches.
I will share the implementation process, experimental results, and problems in later articles.
Product research identifies questions worth investigating; technical practice tests those judgments.