Insight · October 6, 2026

Facts that know
how they connect.

Entity recognition, the answer box in Google, and the retrieval pattern spreading through AI products in 2026 all stand on the same structure. Here is what a knowledge graph is.

01 · The short answer

A map of things, and how they relate.

A knowledge graph is a network of facts. It stores real world things, people, places, products, concepts, as entities, and records how each one connects to the others as explicit relationships. Instead of rows in a table or words in a document, it holds meaning as a web you can follow from one thing to the next.

The name is specific. A relational database stores values in tables. A document store holds text. A knowledge graph stores the connections themselves as first class facts, so the link between two things is something you can query directly, not something you have to infer.

02 · The problem it solves

Strings on one side, things on the other.

For most of computing, a machine matched strings. Ask for the row that says Ortega and it returned the row that said Ortega. That works until the question is about meaning or connection. The words Barack Obama and the 44th president of the United States share almost nothing on the page, yet they point at one thing.

A knowledge graph closes that gap by recording the thing itself, the entity, and every relationship it holds, kept separate from the words any one document used. Google made the idea famous. On May 16, 2012 it launched the Knowledge Graph, and Amit Singhal framed the shift in three words: things, not strings. At launch the graph held 500 million objects and 3.5 billion facts and relationships, drawn from public sources like Freebase, Wikipedia, and the CIA World Factbook. It is the structure behind the answer box that tells you a director's height without making you open a page.

The one line to keep

“A knowledge graph does not store what a document said. It stores what is true, and how it connects.”

03 · The anatomy

Five parts, and the links are the point.

Entity

A single thing the graph knows about. A person, a company, a product, a place, a concept. Each one is a node, recorded once, no matter how many documents mention it.

Relationship

A named, directed link between two entities. Founded by. Located in. Reports to. The relationship is a fact in its own right, not a side effect of two things appearing near each other.

Triple

The unit the graph is built from. Subject, predicate, object. Ada Lovelace, worked with, Charles Babbage. The W3C standardized this shape as RDF, and a pile of triples is already a graph.

Graph

Connect the triples and the nodes and links become a network you can traverse. Start at one entity and follow the relationships outward, hop by hop, to reach facts no single document held together.

Query

You ask by pattern, not by keyword. Find every company founded by someone who worked at a given lab. The graph walks the links and returns the answer, because the connections were stored, not inferred.

04 · Not a vector index

Meaning as structure, not as distance.

This is the comparison that matters in 2026, because both now sit under AI products and they are easy to confuse. A vector index stores meaning as geometry. Every document becomes a list of numbers, and search returns the passages whose numbers sit closest to the question. We wrote the long version in what is a vector database. It is fast, it is fuzzy, and it is right when the answer lives in one or two passages.

A knowledge graph stores meaning as structure. It does not ask which passage is nearest. It asks which things connect, and how. When the answer is a fact you can look up, vectors win on cost and speed. When the answer lives in the connections between facts, spread across many documents, the graph is the one that can follow the trail. Becoming a thing the graph is sure of is its own discipline, the one we call entity SEO.

05 · The pattern spreading through AI

GraphRAG, and the dots vector search could not connect.

Retrieval augmented generation gives a model facts it can look up at answer time. The common version uses a vector index. GraphRAG uses a knowledge graph instead, and it exists to fix a specific failure. In February 2024 Microsoft Research put the problem plainly: baseline RAG struggles to connect the dots when answering a question requires traversing disparate pieces of information through their shared attributes, and it performs poorly when asked to holistically understand concepts over a large collection.

GraphRAG closes both gaps. Microsoft describes it as a modular graph based retrieval system that uses a model to extract structured data, an entity knowledge graph, from unstructured text. The From Local to Global paper, published by Microsoft Research in April 2024, builds that graph in two stages: derive the entities and relationships, then pregenerate summaries of each cluster of related entities. On global questions it improved on a vector RAG baseline for both the comprehensiveness and the diversity of answers, and reached competitive results at a fraction of the token cost of reading the source text in full.

question   →  find the entities   →  walk their relationships

relationships   →  gather the connected facts across documents

connected facts   +  question   →  model   →  answer across the corpus

A graph retrieval step · the model answers from connections, not from the nearest passage

06 · When it earns its cost

A graph is not free, so ask what the question needs.

Someone has to decide what counts as an entity, extract the relationships, and keep the graph current as the facts change. Graph retrieval does more work per query than a vector lookup, so it costs more and answers slower. The operator question is never which approach is more powerful. It is whether this question needs connection.

Reach for the graph when the answer depends on relationships: tracing who reports to whom, how a part moves through a supply chain, which rule depends on which other rule, or any question that has to chain several facts into one answer. Reach for the vector index when a single passage holds the answer and speed and cost matter more than the trail.

In practice most serious systems run both. Vector search finds the entry point. The graph expands it into connected context. The skill is knowing which half of the question you are holding.

07 · When not to build one

Not every question is about connection.

If your questions are simple lookups, give me this record, show every invoice from March, a plain database answers faster and cheaper, and a graph adds nothing but maintenance.

If your content is a pile of independent passages with no real relationships between them, a vector index is enough, and the graph you would build would be thin. The structure only pays off when the connections carry information of their own.

And a graph is only as good as the facts inside it. A model that extracts entities and relationships will make mistakes, and a wrong relationship is a confident wrong answer waiting to happen. The discipline is the one every probabilistic system needs: verify the structure before you trust what it returns.

Closing

The web was always made of things. The graph writes down how they connect.

Search, answer engines, and the newest retrieval systems all reach for the same shape: entities and the relationships between them. Once you see the graph under them, you stop thinking in pages and start thinking in things.

Written by · October 6, 2026

Donny Smith · ECD, Founder, Bttr.

Over the past 15 years, he has led creative teams and contributed to products used by millions of people worldwide, working with companies including Apple, Opendoor, JP Morgan, GE Aerospace, Pepsi, and Alterra Mountain Company.

Sources · Google · Introducing the Knowledge Graph: things, not strings · May 2012 · Microsoft Research · GraphRAG: unlocking LLM discovery on narrative private data · February 2024 · Microsoft Research · From Local to Global: A Graph RAG Approach to Query-Focused Summarization · April 2024 · GitHub · microsoft/graphrag · 2026 · W3C · RDF 1.1 Concepts and Abstract Syntax · 2014 · facts current as of October 2026

Share this perspective

More insights

Adjacent perspectives.

9 min read

RAG vs Fine-Tuning

The teams that waste the most on AI pick RAG or fine-tuning before they name the problem. The two are not answers to the same question. RAG gives a model facts it can look up at answer time, retrieved from your own documents, cut into chunks, turned into embeddings, and searched by meaning. The fact never enters the weights. Anthropic notes that once a knowledge base passes roughly 200,000 tokens, retrieval is what lets a model draw on a corpus no prompt could hold. Fine-tuning does the opposite. It trains the base model on your examples until a tone, a format, or a task is set into the weights, which the OpenAI Cookbook notes can take thousands of worked examples and suits teaching a skill rather than a fact. The clean rule is RAG for facts, fine-tuning for behavior, and in production usually both. The Cookbook frames it as an exam: fine-tuning is studying a week ahead and risking a forgotten detail, RAG is the open notes exam with the answer in front of the model while it works. Freshness, cost, and the paper trail settle the rest. A fact that changes is a retrieval problem. A behavior that drifts is a training problem. Name the problem first and the tool picks itself.

8 min read

What Is Reranking

A retrieval system usually finds the right passage and then leaves it in the wrong place. The first stage is a bi encoder that turns the query and every document into separate vectors and compares them, which is fast but never reads the two together, so the best passage often lands in the middle of the list. Reranking is the second pass that fixes the order. A cross encoder reads the query and one candidate as a single input, scores how they actually relate, and reorders the short list so the most relevant passages rise to the top. It is slower because it computes a fresh score for every query and document pair, so it runs on about a hundred candidates, never the whole corpus. On the public MS MARCO benchmark the sentence transformers cross encoder models trade speed for accuracy across sizes, from a tiny model near 9,000 documents a second to larger ones a fraction of that. Anthropic measured the payoff on a real pipeline: retrieve 150 chunks, rerank, keep the top 20, and the failure rate fell 67%. Retrieval finds the passage. Reranking makes sure the model reads it first.

8 min read

What Is Chunking in RAG

A retrieval system never reads your whole document. It reads the passages you cut it into, and chunking is that cut. Split too coarse and one chunk carries three ideas, so its embedding blurs and the right query misses. Split too fine and a passage loses the context that made it mean anything, the way a line reading the company revenue grew by 3% no longer says which company or which quarter. There is no universal size. LangChain base text splitter defaults to 4,000 characters, LlamaIndex sentence splitter to 1,024 tokens, because the right cut depends on your documents and your queries. Anthropic reported that adding a short generated context to each chunk before embedding cut the failure rate for the top 20 retrieved chunks by 35%, and by 67% once reranking was stacked on top. Retrieval quality does not start at the model. It starts at the cut.

View all insights →

Bttr. Field Brief

The brief Bttr. writes for senior buyers.

Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.

Make your brand legible to the graph

Facts that know
how they connect.

A map of things, and how they relate.

Strings on one side, things on the other.