Entity linking & knowledge graphs
NER finds that 'Apple' is an entity, but which Apple — the company or the fruit? Entity linking disambiguates a mention to a specific knowledge-base entry using context. Add relation extraction and the entities and their relations form a knowledge graph — the structured backbone behind search, QA, and GraphRAG.
Written and reviewed by Shreyash Prashu Last reviewed
What you'll learn
- Entity linking — disambiguating a mention to a knowledge-base entry
- Relation extraction and the (subject, relation, object) triple
- How entities and relations form a knowledge graph
- The IE pipeline, GraphRAG, and how LLMs both build and use KGs
Before you start
Named-entity recognition (NER, which marks the words in a text that name people, companies, places and so on) tells you “Apple” is an entity. It does not tell you which Apple, the tech company or the fruit. Resolving that is entity linking: map a mention (the words as they appear in the text) to a specific entry in a knowledge base (a database of known things, each with a unique ID). Once you can identify entities and the relations between them, you can assemble a knowledge graph. That is a network of facts, and it is the structured backbone behind search, question answering, and grounding (checking claims against trusted facts).
Entity linking: disambiguate by context
NER detects the mention; linking picks the right entity from candidates that share the name, using the surrounding context:
kb = { # candidate entities and their context cues
"Apple Inc.": {"iphone", "computer", "tech", "ceo"},
"apple (fruit)": {"eat", "fruit", "tree", "red"},
}
def link(mention, context): # pick the entity whose cues best match the context
ctx = set(context.lower().split())
scored = {e: len(ctx & cues) for e, cues in kb.items()}
return max(scored, key=scored.get)
for sentence in ["Apple released a new iphone and computer", "she ate a red apple from the tree"]:
print(f"{sentence!r}\n -> {link('Apple', sentence)}")'Apple released a new iphone and computer'
-> Apple Inc.
'she ate a red apple from the tree'
-> apple (fruit)Same surface string, two different entities — the context (iphone/computer vs red/tree)
decides. Real systems score candidates with embeddings and a popularity prior rather than keyword
sets, but the principle is exactly this: named-entity disambiguation resolves a mention to a
unique, canonical entity (the Wikidata/Wikipedia ID), so “Apple,” “Apple Inc.,” and “AAPL” all point
to the same node.
From entities to a knowledge graph
Linking gives you the nodes. Relation extraction gives you the edges: pull
(subject, relation, object) triples from text — “Steve Jobs founded Apple” becomes
(Steve Jobs, founded, Apple Inc.). Entities as nodes plus relations as edges is a knowledge
graph — Wikidata, DBpedia, and Google’s Knowledge Graph are exactly this, at billions of triples.
Why it matters: from IE pipeline to GraphRAG
The classic information-extraction pipeline chains what you’ve seen: NER → entity linking → relation extraction → knowledge graph. A populated KG powers structured search and QA (answer “who founded Apple?” by a graph lookup, not a text scan) and gives precise, verifiable facts.
In one breath
- Entity linking maps a mention to a specific knowledge-base entry — disambiguating
“Apple” (company vs fruit) by context (the demo:
iphone→ Apple Inc.,tree→ fruit) — so all surface forms point to one canonical node. - Relation extraction pulls
(subject, relation, object)triples (“Steve Jobs founded Apple”); entities as nodes + relations as edges form a knowledge graph (Wikidata, Google KG). - The classic IE pipeline is NER → linking → relation extraction → KG, powering structured search/QA with verifiable facts.
- LLMs build KGs cheaply (extract entities/triples from text) and use them: GraphRAG retrieves connected subgraphs for multi-hop questions flat retrieval misses.
- A KG also acts as a grounding check — verify generated claims against stored triples to catch hallucinations.
Quick check
Quick check
Next
Entity linking starts from NER; the resulting knowledge graph powers GraphRAG and structured question answering. Graph structure itself is covered in graph theory.
Practice this in an interview
All questionsNodes are the retrievable pieces of source content, carrying text, metadata, and relationships. A query engine retrieves relevant nodes and synthesizes an answer; wrapping it in QueryEngineTool lets an agent choose that RAG pipeline as a tool.
Keyword search (BM25) excels at exact term matching — product codes, proper nouns, rare abbreviations. Semantic search (dense embeddings) captures meaning and handles paraphrases. Hybrid search runs both in parallel and merges scores with Reciprocal Rank Fusion, giving the best of both worlds for most production RAG systems.
RAG couples a retrieval step — fetching relevant documents from an external store — with a generative model so the LLM can answer questions about knowledge it was never trained on. It solves the stale-knowledge and hallucination problems without retraining. The pattern is preferred when the knowledge base changes frequently or contains proprietary data.
Stemming uses heuristic, language-specific suffix rules to reduce words quickly and may produce non-words; lemmatization uses a lexicon, morphological analysis, and often part-of-speech information to find a canonical lemma. The right choice depends on the task: stemming can work well for lexical search, while lemmatization is preferable when readable or morphologically accurate forms matter.