Why is entity resolution the hardest part of building a graph RAG index?

## The gap between extraction and identity Graph construction has two distinct steps that are easy to conflate. Extraction reads a chunk and emits entities and relations found in that chunk. Resolution decides which of those extracted mentions refer to the same real-world thing and merges them into one node. Extraction is the step people demo; resolution is the step that determines whether the graph is usable. The reason is scope. An extraction pass sees one chunk at a time. It cannot know that the "AHL" in a 2019 side letter and the "Acme Holdings Ltd" on a 2021 share purchase agreement are the same legal entity, or that "the Company" in a schedule refers to whichever party the parent contract defined. Every corpus produces this: people with initials and married names, products with SKUs and marketing names, drugs with generic and brand names, subsidiaries with pre- and post-rename identities. ## Two failure modes, asymmetric in cost **Under-merging** fragments one entity into several nodes. The consequences are graph-wide, not local: node degree is divided across the fragments, so each looks peripheral; two-hop traversal from one fragment cannot reach edges attached to another; community detection places the fragments in different clusters, so the global summaries describe the same entity twice, each partially. The visible symptom is a graph that looks rich but answers poorly — retrieval returns thin neighbourhoods and multi-hop questions come back empty. **Over-merging** is rarer and worse. Fusing two distinct subsidiaries creates edges between things that were never connected in any source document. The system will then answer, with a citation, that entity A signed an indemnity clause that entity B actually signed. This is not a retrieval miss you can detect by low confidence; it is a confident, sourced, wrong answer. In a due-diligence or pharmacovigilance setting that is the failure that ends the project. The asymmetry matters for threshold choice. In high-stakes domains you tune towards precision — merge only when confident, accept some fragmentation — and treat the remaining fragmentation as a known, measurable gap rather than an invisible fabrication. ## How resolution is actually done All-pairs comparison is quadratic and infeasible past a few thousand entities, so the pipeline is staged. **Blocking** cheaply groups candidates that could plausibly match — shared normalised tokens, phonetic keys, same entity type, approximate-nearest-neighbour search over name embeddings. Only within-block pairs are scored, which turns the quadratic problem into something tractable. **Scoring** combines several weak signals: string similarity on canonicalised names (case, punctuation, corporate suffixes like Ltd/Limited/LLC stripped), embedding similarity over the entity's generated description rather than just its name, and structural evidence — do the two candidates share neighbours, appear in the same documents, have compatible types and date ranges? **Adjudication** handles the ambiguous middle band. High-confidence pairs auto-merge, low-confidence pairs stay separate, and the middle is sent to an LLM given both entities' descriptions and a few source snippets, or to a human when the domain warrants it. Explicit alias tables and domain identifiers — company registration numbers, drug codes, employee IDs — should short-circuit all of this whenever the corpus contains them; a deterministic key beats any similarity score. **Relations need the same treatment.** After nodes merge, duplicate edges expressing the same relation in different words ("acquired", "purchased a controlling stake in") should be canonicalised to a relation vocabulary, or traversal filters by relation type become unreliable. ## Making it operable Three practices separate a resolution step that can be maintained from one that cannot. Record **provenance**: every merged node keeps the list of mentions and source chunks it absorbed, so a bad merge can be traced and reversed without rebuilding the index. Merges should be reversible data, not a destructive transformation. **Measure it.** Hand-label a few hundred candidate pairs as match/non-match and report precision and recall on merges, tracked over time. Without this, resolution quality is a matter of opinion and silently degrades as new documents introduce new naming conventions. **Re-resolve on ingest.** New documents introduce new surface forms for existing entities. If ingest only adds nodes and never revisits merge decisions, fragmentation grows monotonically and the graph degrades even though nothing visibly broke. Finally, be honest in an interview that entity resolution is a decades-old record-linkage problem that LLMs have made easier to bootstrap but have not solved. Treating it as a solved preprocessing detail is the single clearest sign someone has demoed graph RAG rather than run it.