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.”

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 · synthesis