Knowledge Graph
Facts as a network of entities and relationships — symbolic AI's one commercial survivor, and RAG is rediscovering it.
When not to use it
- For fuzzy or judgement-based questions. Graphs hold facts. Judgement isn't a triple.
- When the schema changes weekly. Ontology churn will consume the project.
- Without solving entity resolution. Wrong merges propagate confidently across every hop.
- When single-hop retrieval suffices. If vector search answers it, you don't need this.
Reach for something else instead
- Vector search / RAG — similarity, not structure. Fine for "what does the doc say."
- SQL — if it's relational and shallow, a database is simpler.
- GraphRAG — the hybrid, for multi-hop questions over documents.
- LLM extraction into a graph — how you build one now, with the accuracy caveats.
Sources & further reading
- Hogan et al. (2021), Knowledge Graphs — the comprehensive modern survey.
- Bordes et al. (2013), Translating Embeddings for Modeling Multi-relational Data — TransE; making the graph differentiable.
- Edge et al. (2024), From Local to Global: A Graph RAG Approach to Query-Focused Summarization — where similarity search fails and structure wins.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Underestimating entity resolution. It's where the projects die and most of the work.
- Building a graph when vector search would do. Structure costs; buy it only if you need hops.
- Treating extracted triples as reliable. A graph with wrong facts propagates error across hops with confidence.
- Missing that RAG is rediscovering this. Chunking and retrieval are 1980s IR with embeddings.