A Knowledge Graph Project That Was Harder Than Expected, and Why

We scoped a knowledge graph project for a client as a few weeks of work — extract entities and relationships from their document corpus, build the graph, ship a query interface on top. The entity extraction part went roughly to plan. The project still took three months, and the entire overrun traces back to one problem we'd badly underscoped: entity resolution.

The problem we didn't see coming

Extracting "Acme Corp" as an entity from a document is the easy part. Realizing that "Acme Corp," "Acme Corporation," "Acme Inc.," and a misspelled "Acme Corp." in a scanned older document all refer to the same real-world entity, and should collapse into a single node in the graph rather than four disconnected ones, is the actual hard problem — and it's the problem that determines whether a knowledge graph is useful at all, because a graph full of duplicate, unresolved entities is barely better than no graph.

Extracting entities from text is the part of a knowledge graph project that looks hard and isn't. Resolving which entities are actually the same thing is the part that looks easy and isn't.

Why it took so long to get right

Simple string-matching resolution rules caught the obvious variants but missed enough edge cases — abbreviations, historical name changes, genuinely ambiguous references resolvable only with document context — that the graph still had a meaningful duplicate-entity problem after the first pass. We ended up layering a learned similarity model on top of the rule-based matching, trained on a hand-labeled set of known entity-pair matches and non-matches, which closed most of the remaining gap but took real iteration to get right.

• Rule-based matching (string similarity, known aliases) catches the easy majority of duplicate entities cheaply.
• A learned similarity model closes the harder remaining gap, but needs a real labeled dataset of match/non-match pairs to train on.
• Resolution quality should be scoped and budgeted as its own distinct project phase, not folded into general 'graph building' time.
• A knowledge graph with unresolved duplicate entities is worse than useless for anyone trying to query it — it actively misleads.

If I scope a knowledge graph project again, entity resolution gets its own explicit line item and its own realistic timeline from the start, informed by this one, instead of being treated as an assumed-solved subtask of extraction. It's the single biggest lever on whether the final graph is actually trustworthy to query.