Home / Foundations / Knowledge Graphs in Search: Entities and Relationships

Knowledge Graphs in Search: Entities and Relationships

A knowledge graph in search is a database of entities, such as people, places and products, connected by named relationships. A search engine uses it to understand what a query is about and to answer with facts rather than only documents. Each fact is stored as a triple of subject, predicate and object, such as (Paul Krugman, writesFor, The New York Times). Search uses the graph in four main ways. It can answer directly, expand a query with related entities, filter or boost results about a recognised entity, or supply connected facts to a language model, an approach known as GraphRAG. Google described its Knowledge Graph in 2012 with the phrase “things, not strings”. Knowledge graphs complement vector search rather than replace it. Vectors capture what text means, while graphs make relationships explicit. Weaviate represents relationships with cross-references and is often paired with a graph database in GraphRAG pipelines.

What is a knowledge graph?

A knowledge graph is a structured representation of knowledge as entities, which are the nodes, and typed relationships between them, which are the edges. Each entity has an identifier, a type and properties.

The basic unit is the triple. “Paul Krugman writes for The New York Times” becomes the subject Paul Krugman, the predicate writesFor and the object The New York Times. Weaviate’s data documentation uses this same example to explain cross-references. The fact has since aged: Krugman wrote his last regular column for the paper in December 2024, a reminder that graph edges need dates or updates. Chaining triples builds a graph: The New York Times is headquartered in New York City, so the graph connects Krugman to the city in two steps.

Entities have types, such as Person, Organization or Place, and the types constrain which relationships make sense. A Person can write for an Organization, and an Organization can be headquartered in a Place. This schema, sometimes called an ontology, is what lets software reason over the graph.

Two families of technology store knowledge graphs. RDF stores hold triples and are queried with SPARQL, a standard from the semantic web movement. Property graph databases attach properties to both nodes and edges and use query languages such as Cypher. Large public graphs include Wikidata and DBpedia. Search engines use them because queries are often about things.

Why do search engines use knowledge graphs?

Search engines use knowledge graphs because many queries name a specific thing, and a graph tells the engine what that thing is, what type it is and what it connects to. Text matching alone treats names as strings.

Google introduced its Knowledge Graph in 2012 in a blog post titled “Introducing the Knowledge Graph: things, not strings”. The idea was that a search for a landmark or a person should return facts about that entity, not only pages containing its name. The results appear as knowledge panels beside the usual links, as described in semantic search at Google.

Ambiguity is the main problem a graph solves. “Jaguar” can be an animal, a car maker or a sports team. A graph holds all three as separate entities with different types and neighbours. Words in the query, such as “speed” or “dealer”, point to one of them. Classic information retrieval, introduced in what is information retrieval, ranked documents by words and had no notion of entities.

Graphs also answer questions that need a relationship rather than a passage. “Which newspaper does Paul Krugman write for” is a single edge lookup. A document search must find a passage that states the fact and rank it first. Every one of these uses starts with the same step.

How does entity linking connect queries to a knowledge graph?

Entity linking connects queries to a knowledge graph by finding mentions of entities in text and mapping each mention to the right node, using the surrounding words to resolve ambiguity. It is the bridge between free text and structured facts.

The process has two parts. Mention detection finds spans that might name an entity, such as “krugman” in “krugman newspaper”. Disambiguation picks the right node among candidates, using context, entity popularity and how well the candidate’s neighbours fit the rest of the query.

Embeddings help with both parts. A model can compare the query context with descriptions of candidate entities and pick the closest, the same similarity idea explained in semantic similarity vs relatedness. Transformer encoders such as those in transformers and BERT in search and Sentence-BERT are common choices for this comparison.

Linking errors carry through everything that follows. If “jaguar” links to the car maker when the user meant the animal, every fact, expansion and filter that follows is wrong. Systems often keep the top few candidate entities and let ranking decide. Once linked, the graph can do several jobs.

What are the main uses of a knowledge graph in search?

The main uses of a knowledge graph in search are direct answers, query expansion with related entities, filtering or boosting results about a linked entity, and supplying connected facts to a language model. Each builds on entity linking.

Direct answers follow an edge. The query “krugman newspaper” links to Paul Krugman and a writesFor relationship, so the answer is The New York Times. Knowledge panels and answer boxes work this way.

Query expansion adds the names of related entities, or alternative names of the same one, to the search. A query for an abbreviation can add the full name, which eases the gap described in the vocabulary mismatch problem. Filtering and boosting restrict or lift results tagged with the linked entity, which helps when many documents mention a name but few are about it.

Supplying facts to a language model is the newest use. Instead of only retrieving passages, a RAG system also retrieves the linked entity’s neighbours and their relationships. That approach has its own name and pipeline.

How does GraphRAG combine knowledge graphs and vector search?

GraphRAG combines knowledge graphs and vector search by using a language model to extract entities and relationships from documents into a graph, then retrieving from both the graph and the text at question time. It targets questions that span many documents.

Weaviate’s article on RAG and GraphRAG describes GraphRAG as an umbrella term for RAG approaches whose retrieval uses knowledge graphs. It highlights Microsoft’s implementation, from Darren Edge and colleagues in 2024, which extracts entities and relationships with a language model, detects communities of closely related entities and writes summaries for them.

The article walks through local search, one of the retrieval modes Microsoft’s GraphRAG offers alongside global and DRIFT search. First, Weaviate’s semantic search finds the entities most relevant to the question. Their IDs are then mapped to nodes in a Neo4j graph, where a Cypher query traverses relationships to collect connected entities and community context. The combined context goes to the language model.

Weaviate’s introduction to RAG explains the motivation. Traditional RAG handles questions answered by a few passages, but struggles to draw conclusions over an entire knowledge base. A graph of extracted relationships lets the system compare and summarise across documents. Building the graph costs many language model calls, so GraphRAG suits collections where those cross-document questions are common. Relationships can also live in the vector database itself.

How does Weaviate represent relationships between objects?

Weaviate represents relationships between objects with cross-references, directional links from a property on one object to objects in another collection. They support filtering and retrieval across the link but do not change vectors.

from weaviate.classes.config import Configure, Property, DataType, ReferenceProperty
from weaviate.classes.query import Filter, QueryReference

pubs = client.collections.create(
    name="Publication",
    properties=[Property(name="name", data_type=DataType.TEXT)],
    vector_config=Configure.Vectors.self_provided(),
)
authors = client.collections.create(
    name="Author",
    properties=[Property(name="name", data_type=DataType.TEXT)],
    references=[ReferenceProperty(name="writesFor", target_collection="Publication")],
    vector_config=Configure.Vectors.self_provided(),
)
nyt = pubs.data.insert({"name": "The New York Times"}, vector=[1.0, 0.0])
authors.data.insert({"name": "Paul Krugman"}, references={"writesFor": nyt}, vector=[0.9, 0.1])

res = authors.query.fetch_objects(
    filters=Filter.by_ref(link_on="writesFor").by_property("name").equal("The New York Times"),
    return_references=QueryReference(link_on="writesFor", return_properties=["name"]),
)

The code stores the triple (Paul Krugman, writesFor, The New York Times) as a cross-reference and queries across it, filtering authors by the name of the publication they write for. The toy vectors only show the shape of the call. The pattern was run against a local Weaviate instance as an API check and returned Paul Krugman linked to The New York Times.

Weaviate’s documentation sets out the limits. Cross-references are one-way, so a two-way relationship needs a second property. They do not affect vectors, so a vector search cannot match on a referenced object’s text. Queries that involve them can be slower at scale. The documentation recommends embedding related information directly in objects where possible. The ref2vec-centroid module, added in version 1.16, offers one bridge: it sets an object’s vector to the centroid of the vectors it references, which Weaviate’s release notes link to knowledge graph representation.

How do knowledge graphs compare with vector embeddings?

Knowledge graphs and vector embeddings compare as explicit and implicit knowledge: a graph states relationships as named edges, while an embedding encodes meaning as a position in a vector space. Each is strong where the other is weak.

Embeddings, from early models such as those in Word2Vec and GloVe to modern sentence encoders, place similar texts close together in a high-dimensional vector space. They need no hand-built schema and handle paraphrase well. They do not say why two things are close, and they blur exact facts such as who wrote for which newspaper in which year.

Knowledge graphs state facts precisely and can be queried and audited. They are expensive to build and keep current, and they only contain what someone, or some extraction model, put in. Earlier attempts to capture meaning statistically, such as the vector space model and latent semantic indexing, sat on the implicit side of this divide.

The two combine naturally. Vectors find candidate entities and passages from fuzzy wording; the graph supplies exact relationships around them. The detailed trade-off is set out in semantic search vs knowledge graph search. Building a graph for your own search raises practical questions.

When should you add a knowledge graph to your search?

You should add a knowledge graph to your search when queries often name specific entities, when answers depend on relationships between them, or when users need facts traced to a structured source. Otherwise metadata and filters may be enough.

Good fits include product catalogues with brands, compatible parts and categories; research collections with authors, institutions and citations; and company knowledge with people, teams and systems. In each, many questions are about how things connect, and the connections are known or can be extracted.

Start small. Often a few entity types stored as properties on objects, with filters on them, give most of the benefit without a separate graph database. Weaviate’s documentation suggests exactly this, embedding author information in book objects instead of linking two collections. A separate graph pays off when relationships are many, change often or need multi-step traversal.

Plan for cost and freshness. Entity lookups for popular queries repeat, so caching them helps, as covered in cache hits and misses. Extraction with language models needs review, because wrong edges produce confident wrong answers. High-dimensional embeddings bring their own costs, described in the curse of dimensionality.

A knowledge graph stores entities and their relationships as triples, letting search treat names as things with types and connections. Entity linking maps query words to the right entities. From there the graph gives direct answers, expands queries, filters or boosts results, and supplies connected facts to a language model in GraphRAG. Weaviate links objects with directional cross-references that do not change vectors, and is paired with graph databases in GraphRAG pipelines, where vector search finds the entry entities and graph traversal collects the context. Graphs make relationships explicit; vectors capture fuzzy meaning; most strong systems use both.