graphrag-knowledge-graphs
verifieda7a601db-c0ec-4e8b-9176-b04fcf11deda
Build GraphRAG over your corpus ā entity/relation extraction, entity resolution, community detection, and graph-enhanced retrieval.
Metadata
Skill file
# GraphRAG with Knowledge Graphs
Use when vanilla vector RAG struggles because answers need **multi-hop
reasoning** (connecting several documents/pieces through shared entities:
people, organizations, systems, products, events) or cross-corpus thematic
questions that a similarity search can't assemble. Vector search retrieves
similar chunks; a knowledge graph stores *relationships* that let you traverse.
GraphRAG = extract entities + relationships from your docs into a graph, then
retrieve by walking the graph (and often combining with vector search) to build
the LLM context.
## The hard part is graph construction, not retrieval
Extraction quality *is* retrieval quality. A noisy graph yields answers worse
than plain RAG. The pipeline:
1. **Named entity recognition (NER)** ā pull people/orgs/systems/products.
2. **Relation extraction** ā pull typed triples `(EntityA, relation, EntityB)`,
e.g. `(ServiceA, depends_on, ServiceB)`, `(Alice, manages, TeamX)`.
3. **Coreference resolution & canonicalization** ā `"J. Smith"`, `"John Smith"`,
`"Dr. Smith"` must map to one node.
4. **Entity resolution (de-duplication)** ā the step that decides whether
`"Joe's Building Co LLC"` and `"123 First Street"` refer to the same real-world
business. Skip it and your graph fragments into near-duplicate nodes that
break traversal. There's no universal algorithm ā expect per-domain heuristics:
name normalization, address normalization, fuzzy matching on keys.
5. Load into a graph store (Neo4j or any graph DB) with entities as nodes and
relations as boldtyped relationships, optionally with a property/value payload
per node.
Relation extractors hallucinate connections; NER misses entities; entity linking
picks wrong matches. Every staged model output should be spot-checked on a small
golden set before you trust extraction at scale.
## Approaches to pick from
- **Microsoft GraphRAG** (open-source library): faithful to the research paper ā
does ingestion, extraction, **community detection (Leiden)** and hierarchical
community summarization. Best for research/prototyping and "global / thematic"
questions; not tuned for high-throughput production workloads.
- **LlamaIndex `PropertyGraphIndex`**: Python-native, slots into an existing RAG
pipeline, supports dynamic or custom schema + vector similarity on nodes.
- **Custom pipeline + Neo4j/LangChain**: full control and production work, most
effort (entity resolution is on you).
## Community detection for "global" questions
Microsoft's key insight: run hierarchical clustering (Leiden) over the graph to
find communities of densely connected entities, then have the LLM summarize each
community. Answering a broad, corpus-wide question then draws on these
community summaries rather than any single retrieved chunk ā this is what makes
GraphRAG good at thematic, across-the-corpus queries where vector RAG gives
piecemeal chunks.
## Indexing cost is real
As the paper warns, extraction is LLM-token expensive: large corpora can consume
significant API tokens just to build the graph. Start small, on a sample, and
measure cost before indexing everything.
## Pitfalls
- Treating extraction output as ground truth ā validate with a golden set.
- Skipping entity resolution and paying for it in fragmented traversal.
- GraphRAG for simple factual lookup where plain RAG is cheaper and equally good.
- Unbounded schema that produces an unmanageable, inconsistent graph.
- Building the graph without a dedup/canonicalization pass and shipping an
answer generator that walks duplicate nodes.
## Verify
- Construct a small golden set of multi-hop questions, each with a known answer
that requires joining ā„2 entities. Confirm GraphRAG answers them and note where
vector RAG fails them.
- Check entity resolution: count near-duplicate nodes for known-real entities
(should be ā1).
- Measure indexing token cost per 1K docs before rolling out.