Entity resolution (graph deduplication)

Deciding when two extracted nodes are the same thing: "doctor" and "doctors", "doctor" and "medical practitioner", Acme Inc. and Acme Incorporated. Every knowledge-graph builder in this wiki hits it, because an LLM extracting from many chunks has no memory of what it named the same thing last time. Left unresolved, the graph fragments — one concept becomes five weakly-connected nodes, degree and community structure go wrong, and multi-hop traversal breaks at exactly the joins that made the graph worth building.

Four answers, spanning the augment→automate axis

Unattended, on a schedule. gbrain dedups and re-cites in a "dream cycle" while you sleep. No human in the loop by design.
Human-gated. sift-kg runs automatic pre-dedup (Unicode normalization, fuzzy match, optional embedding clustering), has the LLM propose merges as DRAFT, then requires explicit confirmation: "no merges occur without explicit approval."
Structural, at query time. GraphRAG-family systems lean on community detection and summarization, so near-duplicate nodes landing in one community are partly absorbed by the summary rather than merged in the graph.
Not at all, and said so. rahulnyk-knowledge-graph ships without it and lists embedding-based dedup as its first open request, with the doctor/doctors example.

Why the concept-vs-entity choice makes it harder

Extracting entities gives you strings with a reasonable chance of matching, and a long pre-LLM literature (record linkage, fuzzy matching) to lean on. Extracting propositions — "pleasant weather in Bangalore" — gives richer nodes that almost never match on surface form, which is why embeddings rather than string distance are the proposed fix. Expressiveness at the node level and mergeability trade against each other.

The unresolved part

(Written 2026-07-27; partly answered below, and kept because it says what the corpus looked like before the numbers arrived.)

Nobody in this corpus measures it. sift-kg asserts a pipeline, GBrain asserts a cycle, this project asserts a gap, and no source reports how many merges were right. It's the same evidence hole graphrag-bench opened for graph retrieval generally: the mechanisms are described in detail and evaluated barely.

And the measurement is harder than "just report precision" (2026-08-05)

er-evaluation-framework complicates the paragraph above rather than answering it. Its finding is that naive pairwise precision computed on a benchmark data set is biased upward — "often close to 1, even when the true precision for the entire data set may be much lower" — because benchmarks are built by sampling schemes that hunt for matches in a haystack of non-matches, and so are enriched for easy positives. Combined into F1, the bias is enough to produce "performance rank reversals."

So if any of the four systems above had reported a precision figure, that figure would probably have been too high, and comparing two of them on it could have picked the wrong winner. The gap in this corpus is not only that the number is missing; the naive version of the number would have misled.

The paper's fix is to sample fully resolved entities instead of pairs — inside a known cluster every pair matches, across its boundary every pair doesn't — and to estimate global pairwise, cluster and b-cubed metrics from cluster-wise errors. On PatentsView it costs a few hundred labeled clusters to get roughly 4× closer than assuming the system is perfect. That is a tractable amount of labeling, and it is the concrete thing any of these builders could do.

Caveat on transfer, and it bites hardest exactly where this wiki lives: the validation is classical record linkage over name strings. The sampling idea is node-agnostic, but "an annotator can tell whether this cluster is fully resolved" is a much stronger assumption for a proposition node ("pleasant weather in Bangalore") than for an inventor.

A number, finally, and it is large

core-kg and link-kg measure duplicate nodes in graphs an LLM built, before and after a fix. Unmodified GraphRAG duplicates 27% of its nodes on short documents and 36% on long ones; the best of the three pipelines still duplicates 10.6% and 17.8%. So the fragmentation this page describes at the top — one concept becoming five weakly-connected nodes — happens to something like a third of the graph when nobody intervenes.

That lands hardest on the structural answer in the list above. GraphRAG's position was that community detection and summarization absorb near-duplicates well enough that merging is optional. It is now clear how much absorbing that asks for.

The measurement is fuzzy string matching over intra-type entity pairs plus expert review of the resulting clusters, so it inherits exactly the restriction this page names two sections up: it works because the nodes are people and places. The proposition-shaped nodes remain unmeasured, and after er-evaluation-framework we also know that the naive way of measuring them would read too high. Both halves of the gap are now specific rather than general — the open question is no longer "does anyone measure this" but "does anyone measure it where surface form does not carry identity."

A fifth answer: ship it, and report the speed (2026-08-18)

semantica adds a case the four answers above did not cover — entity resolution running in a product, at a size the research systems don't report. Its dedup is blocking plus semantic matching (DuplicateDetector, EntityMerger, a DuplicateGroup carrying confidence=0.91 and strategy="semantic+blocking"), and it sits in the pipeline before graph construction, alongside a conflict-detection stage that flags contradictory facts instead of merging them silently.

The published numbers are from a 118,000-node production graph: semantic deduplication 6.98× faster, candidate generation 63.6% faster with blocking, node search 24 ms → 0.004 ms. Every figure is a speed. How many of those merges were correct is not stated anywhere in the README, and the confidence in the example is an output of the matcher, not an evaluation of it.

So the largest deployed graph in this corpus reproduces the gap rather than closing it, and it does so in the way that is hardest to argue with: a team optimizing dedup by 6.98× clearly has the labeled data and the runs to know how good the merges are. Reporting throughput and not precision is a choice about what the buyer asks for. er-evaluation-framework's point sharpens it — the naive precision figure they might publish would read too high anyway, so the useful number costs a few hundred labeled clusters that nobody in this corpus has yet paid for.

knowledge-graph · sift-kg · gbrain · rahulnyk-knowledge-graph · graphrag · leiden-algorithm · graphrag-bench · er-evaluation-framework · olivier-binette · core-kg · link-kg · dipak-meher · graph-construction-quality · semantica · synthesis

When the units are not names (added 2026-08-22)

Everything above assumes a node with a name that a matcher can compare. orkg-predicate-redundancy measures the case where it isn't: relations in a live scholarly graph, where has evaluation and evaluated on are the same idea and no string comparison says so. Thirty percent of the Open Research Knowledge Graph's 13,457 predicates are potentially removable, and — the number worth carrying — 54.7% of them land in a "Review" bucket the method refuses to decide, handing the call to a curator.

That is the shape to expect for claim-shaped nodes, only worse: predicates are a small vocabulary someone actually looks at, while extracted propositions are numerous and unread.