Vector search returns similar chunks but cannot answer what connects these companies. Knowledge graphs add the relationship dimension, and GraphRAG made them fashionable again. Here is a stack you can actually run and a weekend-sized experiment.

📜 Table of Contents

• When You Actually Need a Graph
• The Five Steps
• Prompt the Schema, Not the Vibes
• Storage and Queries
• Hybrid Retrieval
• Cost Reality
• FAQ
• Related

Knowledge Graphs for AI 2026: GraphRAG, Entity Extraction and Real Use Cases

Vector search returns similar chunks but cannot answer what connects these companies.

When You Actually Need a Graph

Three signals:

• Questions require joining facts across documents (which products does supplier X's recall affect?).
• Questions are multi-hop (parent company, subsidiary, supplier chain).
• You need aggregate views (what themes exist across this corpus) - GraphRAG's community summaries.

Counter-examples: single-document QA, similarity-only retrieval, corpora of a few hundred docs. A good chunking strategy is enough there; a graph is just a bill.

The Five Steps

1. Chunk by paragraph/semantics, keep source IDs.
2. Extract entities and triples per chunk with an LLM.
3. Resolve entities - normalise names, cluster by embedding similarity, spot-check.
4. Build the graph: nodes with type, edges with source chunk ID and confidence.
5. Query by traversal from entities, or via community summaries for global questions.

Prompt the Schema, Not the Vibes

EXTRACT_PROMPT = '''Extract entities and relations. Output JSON only.
{"entities":[{"name":"","type":"org|product|person|place","desc":""}],
 "relations":[{"head":"","relation":"","tail":""}]}
Allowed relations: supplies, owned_by, invests_in, employs, partners_with, competes_with.
Return empty arrays if nothing found.

TEXT:
{chunk}
'''

Set temperature=0, use structured output, retry failed parses twice, and park the rest for human review instead of writing garbage edges.

Storage and Queries

Embedded graph DBs are fine for experiments; Neo4j for production. Cypher makes multi-hop traversal explicit:

MATCH (s:Supplier {name:$name})-[:SUPPLIES]->(part:Part)<-[:USES]-(p:Product)
RETURN DISTINCT p.name AS product

There is no equivalent one-liner in a vector store; you end up stitching multiple retrievals and missing links.

Hybrid Retrieval

hits = vector_store.search(query, k=5)
ents = [e for h in hits for e in extract_entities(h.text)]
facts = graph.expand(ents, hops=2, limit=30)
context = render(hits) + render(facts)

Cap hops and fact count. Unbounded expansion fills the context, raises cost and lowers answer quality.

Cost Reality

Graph building is one-off, but document updates need incremental extraction. The sustainable pattern: graph only the 5-10% of questions that are genuinely multi-hop.

FAQ

Is GraphRAG always more accurate? No - better on multi-hop and global questions, no edge on similarity lookup, and more expensive.

Is entity resolution optional? No. Unresolved aliases break traversal paths.

Can a cheap model extract? Yes, with spot checks. Bad edges are permanent and harder to detect than bad retrieval.

How often to rebuild? Incrementally, with your document updates. Full rebuilds only for schema changes.

Note: capabilities and limits of each graph database and GraphRAG implementation follow official docs.

Related

• Open-source RAG frameworks compared
• GraphRAG vs vector RAG