Knowledge graph

A knowledge graph is a structured database that organizes facts as “entity – relationship – entity” triples, so a machine can reason along the connections instead of just matching strings of text.

A single triple looks like “Moments – headquartered in – Shanghai.” Connect enough triples and you get a graph: the nodes are brand entities, people, places and products, and the edges are the relationships between them. To answer “which AI marketing firms are based in Shanghai,” a system can walk the edges and collect the answer without needing any page that contains that exact sentence.

Google’s Knowledge Graph, which powers the information panels beside many search results, is the best-known public example, but the idea applies to any system that stores facts as linked records.

How knowledge graphs relate to large language models

Large language models compress knowledge into their parameters. That makes the knowledge easy to use but impossible to audit line by line and hard to update. A knowledge graph stores knowledge explicitly as structure: every fact can be checked and edited incrementally, but its coverage depends on how much effort went into building it.

The two are often combined. The graph supplies deterministic factual constraints, and the model handles the language. This pairing is one of the standard ways to reduce AI hallucination: the model is told what is true instead of having to remember it.

On the application side, graphs are also infrastructure for AI agents that need multi-hop queries. A question like “find the companies related to A, then check attribute C of each related company B” is something vector search handles poorly and graph traversal handles well.

How knowledge graphs relate to structured data

Structured data on a web page, written in the Schema.org vocabulary, can be thought of as a set of candidate records submitted to someone else’s knowledge graph. Search engines crawl the markup, cross-check it against other sources and then merge what they trust into their own graph.

That is why certain fields in Organization markup matter so much: the registered legal name, the founding date and the sameAs links to other profiles. They are the evidence used in entity resolution, the step where a system decides whether two records describe the same thing. If your markup and your other profiles agree, they are more likely to be merged into one entity. If they conflict, they may be kept apart, or worse, merged with a different company that shares your name (see name confusion rate).

How a knowledge graph is built

The usual path has three stages:

1. Extraction. Pull entities and relationships out of existing documents, databases and spreadsheets. Large language models now do much of this work.
2. Disambiguation and alignment. Decide which mentions refer to the same entity and merge them. This still relies on rules and human review, because a wrong merge spreads errors to every connected fact.
3. Ongoing updates. Facts change, so the graph needs a maintenance process, not just an initial build.

For a company, the practical starting point is not building a graph of its own. It is making sure the records it contributes to other people’s graphs are consistent: one clear entity page on the website, Organization markup that matches the page text, and profiles elsewhere that tell the same story. A maintained knowledge base is the easiest way to keep those records in sync.

Limits

A knowledge graph only knows what was put into it. A brand that never shows up as a clearly defined entity in any source has nothing to be connected to, and no amount of markup on a single site guarantees that a search engine or model will adopt the record. Markup is a submission, not an instruction.