A knowledge graph represents knowledge as a network of entities (nodes — people, places, products, concepts) connected by relations (edges — labeled links describing how entities relate to each other). The atomic unit of a knowledge graph is the triple: (subject, predicate, object), such as (Marie Curie, discovered, Polonium) or (Paris, capital-of, France). A knowledge graph is simply a large collection of such triples, forming a graph where entities are nodes and relations are directed, typed edges between them.

This representation makes implicit structure explicit. Instead of a fact being buried somewhere in unstructured text that a model has to infer from context, it's stored as a discrete, queryable, verifiable statement. Knowledge graphs power things like search engine "knowledge panels," product recommendation systems that reason over relationships, and structured question-answering systems.

Note

Individual triples are simple, but chaining them enables reasoning a single fact can't: (Marie Curie, born-in, Warsaw) + (Warsaw, capital-of, Poland) lets a system answer "what country was Marie Curie born in?" without that fact ever being stored directly — it's derived by traversing two edges.

Grounding LLMs with structured facts

Large language models encode knowledge implicitly in their weights, learned statistically from training text. This has well-known failure modes: the knowledge can be outdated (frozen at training time), can be wrong in subtle, confident-sounding ways (hallucination), and is hard to audit or update — you can't simply "edit" a specific fact inside billions of opaque parameters.

Knowledge graphs address this by providing an external, explicit, updatable source of ground truth that a system can consult rather than rely on memorized parameters alone. A common pattern — a form of retrieval-augmented generation (RAG) specialized for structured data — is: take a user's query, identify relevant entities, traverse the knowledge graph to retrieve the relevant triples or subgraph, and feed those retrieved facts into the LLM's context so it generates an answer grounded in current, verifiable structured data rather than purely from memorized weights. Updating a fact becomes editing one triple in the graph, instantly reflected in every future query, instead of retraining or fine-tuning a model.

python

Graph embeddings vs. text embeddings

Text embeddings (from models like BERT or sentence-transformer models) map a piece of text into a dense vector such that semantically similar text ends up nearby in vector space, learned from patterns in how words and sentences co-occur in a text corpus. They capture semantic similarity of language, but have no explicit notion of discrete relations between entities.

Graph embeddings (from methods like TransE, Node2Vec, or graph neural networks) instead map entities and relations into vector space such that the graph's structure is preserved — nodes connected by similar relational patterns end up nearby, and in models like TransE, the arithmetic relationship embedding(subject) + embedding(predicate) ≈ embedding(object) is explicitly optimized for, so vector arithmetic can approximate relational reasoning. Graph embeddings are learned from the graph's topology and edge types, not from natural language co-occurrence, which is why they capture relational structure (who-is-connected-to-whom-and-how) that a text embedding of the same entities' names wouldn't reliably encode.

Graph embeddings vs. text embeddings

Aspect	Text embeddings	Graph embeddings
Learned from	Word/sentence co-occurrence in text corpora	Graph topology — entities, relations, triples
Captures	Semantic similarity of language	Relational structure between entities
Typical use	Search, semantic similarity, RAG over documents	Link prediction, entity resolution, relational reasoning
Example models	BERT, sentence-transformers	TransE, Node2Vec, graph neural networks

Note

Modern systems often use text embeddings to find relevant entities in a knowledge graph (semantic search over entity descriptions) and then use the graph structure itself for relational reasoning or retrieval — treating text and graph embeddings as complementary tools rather than substitutes for each other.

Building and maintaining knowledge graphs

Knowledge graphs are built from structured databases, extracted from text via information extraction (named entity recognition plus relation extraction), or curated manually for high-stakes domains. Maintaining accuracy at scale is a genuine challenge: entities need disambiguation (is "Washington" the person, the state, or the city?), relations need consistent typing, and automatically extracted triples need some process for catching extraction errors before they propagate into every downstream query that relies on the graph.

What's next

Knowledge graphs are one way to ground models in structured, external truth. The actual day-to-day work of building, querying, and experimenting with the models that consume this kind of structured and unstructured data happens largely in one tool. The next lesson, Jupyter Notebooks for Machine Learning, covers that workflow and its common pitfalls.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →