ModelRefs / Knowledge Graph — AI Glossary
Knowledge Graph — AI Glossary
A structured representation of real-world entities and the typed relationships between them. A knowledge graph is not a vector database, and GraphRAG uses both.
Overview
Knowledge graphs power semantic search, GraphRAG, recommendation, and AI Overview eligibility. Entities (people, products, concepts) are nodes; relationships (works-for, relates-to) are typed edges. ModelRefs maintains a graph of models, providers, benchmarks, methodologies, glossary terms, and workflows.
Reference details
| Topic | knowledge |
|---|---|
| Last reviewed | 2026-06-24 |
Related terms
How it works
- Entities are resolved first. Every person, product, model or concept becomes a node with a stable identifier, and the hard part is deciding that 'Claude 3.5 Sonnet', 'claude-3-5-sonnet-20241022' and 'Sonnet 3.5' are one node rather than three — entity resolution, not storage, is where graphs fail.
- Relationships are typed, not implied. An edge carries a predicate — works-for, evaluated-on, supersedes, requires — so the graph can answer 'which models were evaluated on this benchmark' by edge type rather than by text matching.
- Triples are stored as subject-predicate-object, either in a native graph database with adjacency lists for traversal, or as rows in a relational table with indexes on both endpoints. The storage choice decides traversal cost, not expressiveness.
- A schema or ontology constrains which predicates may join which node types. Without it the graph accumulates synonymous edges — relates-to, related, is-related-to — and traversal silently misses paths.
- Queries traverse rather than filter. A two-hop query from a benchmark to its capability to the models strong in that capability returns a set no single table scan would produce, because the join path is the answer.
- Inference adds edges the data did not state: if A supersedes B and B supersedes C, a transitive rule materialises A supersedes C. Inferred edges need provenance, or a later reader cannot tell an asserted fact from a derived one.
Example: Why the second hop is the whole point
A flat table of 60 models with a benchmark-scores column answers 'what did this model score'. It cannot answer 'which models are strong at the capability this benchmark measures' without someone first deciding which benchmarks map to which capability. Put that decision in the graph as benchmark-to-capability edges and the question becomes a two-hop traversal. The cost shows in the fan-out: 60 models and 80 benchmarks could in principle carry 60 x 80 = 4,800 score edges, but with each model scored on 12 benchmarks on average there are 60 x 12 = 720. Add 80 benchmark-to-capability edges and the graph holds 800 edges rather than 4,800 — and the second hop is available at all, which it is not in the flat table.
Commonly confused with
A knowledge graph is not a vector database, and GraphRAG uses both. A vector store answers 'what is semantically near this text' and returns ranked chunks; a graph answers 'what is connected to this entity, by what relationship' and returns a path. Similarity is approximate and fuzzy, traversal is exact and typed. The confusion matters because teams reach for a graph to improve retrieval recall, which embeddings do better, or reach for embeddings to answer multi-hop relational questions, which they cannot do reliably at all.
When to use it
Reach for it when:
- Questions are relational and multi-hop — 'which of this provider's models were evaluated on benchmarks relevant to this use case' — where the answer is a path, not a document.
- Entities recur across many documents and need one identity, so that facts stated in different places accumulate on the same node.
- The relationships themselves are the product: a dependency map, an org chart, a supersession chain.
- You need to explain an answer. A traversal is auditable; a similarity score is not.
Reach for something else when:
- The corpus is unstructured prose and the questions are 'find me the passage about X'. Embeddings and a reranker will beat a graph at that, at a fraction of the build cost.
- Entity resolution is not solvable in your domain. A graph with duplicate nodes for the same entity is worse than no graph, because traversals silently return partial results.
- The schema is still moving weekly. Early-stage ontologies accumulate synonymous predicates, and migrating edge types is harder than migrating columns.
- Nobody owns it. A graph degrades faster than a table, because a missing edge produces a wrong answer rather than a visible null.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Knowledge Graph — AI Glossary.
Frequently asked questions
What is Knowledge Graph?
A structured representation of real-world entities and the typed relationships between them.
What concepts are related to Knowledge Graph?
Closely related concepts include semantic search, graphrag, embedding.