Entity linking & knowledge graphs

Named-entity recognition 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 in text to a specific entry in a knowledge base. And once you can identify entities and the relations between them, you can assemble a knowledge graph — the structured backbone behind search, question answering, and grounding.

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

Next

Entity linking starts from NER; the resulting knowledge graph powers GraphRAG and structured question answering. Graph structure itself is covered in graph theory.