// term 58 · Retrieval & Knowledge
Knowledge Graph
Connected Entity Networks
A structured network of entities and their typed relationships — customers, products, contracts, people, linked by edges that mean something. Knowledge graphs make relationships first-class data, enabling the multi-hop questions and explicit reasoning that documents and embeddings can't deliver alone.
// Structure
triples
Entity-relationship-entity statements — supplier A provides component B for product C — composable into traversable networks.
// Superpower
multi-hop
Questions spanning several relationships — answered by graph traversal where document search structurally fails.
// AI synthesis
GraphRAG
Knowledge graphs feeding LLM context — explicit relationships grounding generation that embeddings alone can't connect.
// full definition
What Knowledge Graph actually is
Most enterprise knowledge is locked in documents — and the relationships between facts are locked harder still. Which customers depend on the component this supplier just discontinued? Document search finds documents; the answer lives across several of them, connected by relationships no single text states. Knowledge graphs make those connections the data itself: entities as nodes, typed relationships as edges, queryable by traversal. The structure answers questions that search can only gesture at.
Construction is the hard part, and increasingly an LLM task. Entities and relationships are extracted from documents and systems; entity resolution merges duplicates (“IBM,” “International Business Machines,” “I.B.M.”) into single nodes; an ontology defines the types and rules the graph respects. What was historically a manual curation bottleneck is now substantially automated — language models extract structured triples from unstructured text at scale — though resolution quality and ontology design remain where graph projects succeed or stall.
The payoff is reasoning you can inspect. Graph queries traverse explicit edges — supplier to component to product to customer — with every hop auditable, which contrasts sharply with both the fuzzy neighborliness of embeddings and the opaque associations of LLM parametric memory. Fraud rings surface as suspicious relationship patterns; compliance dependencies trace as paths; impact analysis becomes traversal. Where the question is fundamentally about connections, the graph is the right database.
The frontier is the LLM-graph synthesis. GraphRAG retrieves connected subgraphs — not just similar passages — as generation context, letting models answer multi-hop questions with explicit relationship evidence and citations. The complementarity runs deep: graphs supply the precise, current, auditable relationship structure LLMs lack; LLMs supply the natural-language interface and extraction labor graphs always needed. The combination is becoming the architecture of record for relationship-heavy enterprise AI.
// how it works
From scattered facts to connected knowledge
A knowledge graph is built by extraction and resolution — entities identified, duplicates merged, relationships typed — then queried by traversal.
Ontology Design
Entity types and relationship vocabulary are defined — the schema deciding what the graph can express.
Extraction
Entities and relationships are pulled from documents and systems — increasingly by LLMs converting text to structured triples.
Entity Resolution
Duplicate references merge into single nodes — the deduplication discipline on which graph integrity rests.
Graph Assembly
Resolved triples load into a graph store — the network forming as facts connect.
Traversal & Query
Multi-hop questions execute as path queries — relationships followed explicitly, every step auditable.
AI Integration
Subgraphs feed LLM context (GraphRAG) — connected evidence grounding generation that similarity search can't assemble.
// anatomy
The components teams must understand
01
Entities
The nodes
Customers, products, people, contracts — the discrete things the organization reasons about, each a single resolved node.
02
Typed Relationships
The edges
supplies, owns, depends-on, reports-to — semantics on the connections, making traversal meaningful rather than associative.
03
Ontology
The schema of meaning
The agreed vocabulary of types and rules — where domain expertise becomes graph structure, and where projects bog down without discipline.
04
Entity Resolution
Identity integrity
Merging name variants into single nodes — the quality gate deciding whether traversal finds truth or fragments.
05
Graph Store & Query
The engine
Databases and query languages (Cypher, SPARQL) built for traversal — relationship workloads relational joins handle poorly.
06
GraphRAG Layer
The LLM bridge
Subgraph retrieval as generation context — explicit relationship evidence replacing similarity-only grounding.
// strategic implications
What this changes for the business
01 · Capability
Relationship questions get real answers
Supply-chain exposure, fraud rings, compliance dependencies, customer-impact analysis — the questions that matter most often span multiple hops, where document search structurally fails. If your hardest questions are about connections, the graph is the missing database, not a nice-to-have.
02 · Synthesis
Graphs and LLMs fix each other's weaknesses
LLMs hallucinate relationships and can't trace their associations; graphs hold precise, auditable structure but spoke query languages nobody learned. GraphRAG pairs them — explicit relationship evidence under a natural-language interface — and LLM-powered extraction simultaneously collapses the graph-building cost that stalled the last decade of projects.
03 · Investment
Ontology and resolution are the real project
Graph value tracks data discipline: a clean ontology and rigorous entity resolution make traversal trustworthy; their absence makes an expensive hairball. Scope graph initiatives around high-value relationship questions, and staff the curation — the technology is the easy half.
// common misconceptions
What Knowledge Graph is not
Myth
“Vector search makes knowledge graphs redundant.”
Reality
Embeddings capture similarity; graphs capture explicit, typed, auditable relationships — different questions, different structures. Multi-hop and compliance-grade queries need edges, not neighborhoods; production stacks increasingly run both.
Myth
“Knowledge graphs require armies of manual curators.”
Reality
LLM-based extraction now automates the bulk of triple generation from documents — the historical bottleneck. Human effort concentrates where it should: ontology design, resolution quality, and validation of high-stakes edges.
Myth
“A knowledge graph is just a database with extra steps.”
Reality
Relationship traversal at depth is precisely what relational joins do worst — graph stores exist because the workload is different. For connection-shaped questions, the “extra steps” are the entire point.
// from literacy to leverage
Know the term. Now build the strategy.
Vocabulary is the entry fee. Turning these primitives into pipeline, moats, and margin is the work. That's the conversation.