Keeping Match Confidence on the Graph Edge: Why Throwing Away Splink Scores Hurts Graph RAG

An engineer building er-api, a multilingual entity resolution service, preserved Splink match probabilities as edge properties in a knowledge graph instead of discarding them after thresholding. This enables per-use-case confidence filtering and worst-case confidence propagation in Graph RAG queries, allowing the same graph to serve both high-stakes legal compliance and exploratory business intelligence.

Most entity resolution pipelines throw away the most useful number they produce. You run a probabilistic linker — Splink, Dedupe, or a custom model — and it produces a match probability for every candidate pair. 0.95 for two records you are very confident share the same real-world entity. 0.71 for a pair that probably matches but has enough ambiguity to give you pause. Then you apply a threshold, classify each pair as a match or non-match, and discard the probability. The downstream system — a knowledge graph, a database table, an analytics pipeline — gets a binary signal: same entity, or different entity. This is a mistake when those resolved entities feed a knowledge graph. The match probability is information about how certain the resolution was. Once you cross the threshold gate, that information is gone. The knowledge graph treats a 0.95-confidence merge and a 0.71-confidence merge identically. Both become unconditional identity claims: "this is the same entity." For low-stakes applications, this is fine. For a knowledge graph that feeds retrieval systems, this is a quiet defect. In er-api https://er-api.hannune.ai , a multilingual entity resolution service for Korean, Japanese, Chinese, and English corporate data, I kept the match probability from Splink as an edge property in the graph rather than discarding it at the resolution boundary. The insert looks like this: python def create identity edge source node id: str, target node id: str, match probability: float, source record ids: list str , - dict: return { "source": source node id, "target": target node id, "relation": "SAME AS", "properties": { "match probability": match probability, "source record ids": source record ids, "resolved at": datetime.utcnow .isoformat , "resolver": "splink-3", "review status": "auto" if match probability = 0.90 else "pending", } } A 0.95-confidence match between Samsung Electronics records gets review status: "auto" . A 0.71-confidence match gets review status: "pending" and is queued for human review. The impact shows up most clearly at retrieval time. When a Graph RAG query traverses the graph, it may cross one or more SAME AS edges to connect records from different source systems. If those edges have unknown confidence, the traversal has no way to signal how certain the identity claims it relied on actually are. python def traverse with confidence start node id: str, relation: str, min confidence: float = 0.80, - list dict : results = for path in graph.find paths start=start node id, edge type=relation : identity edges = e for e in path.edges if e "relation" == "SAME AS" if not identity edges: results.append {"path": path, "path confidence": 1.0} continue worst case = min e "properties" "match probability" for e in identity edges if worst case = min confidence: results.append {"path": path, "path confidence": worst case} return sorted results, key=lambda x: x "path confidence" , reverse=True Three things change when confidence propagates through the graph: Per-use-case threshold filtering. A due-diligence query for legal compliance can set min confidence=0.95 . An exploratory search for business intelligence can use min confidence=0.70 . The same graph serves both use cases because the confidence data is available to filter on. Worst-case confidence on retrieved paths. If a traversal crosses a 0.68-confidence merge, the retrieval result carries that number. The LLM prompt can surface it explicitly: "Note: this answer relies on an entity match with 68% confidence." The LLM cannot author this signal — it can only surface it if the retrieval layer passes it through. Low-confidence merges become visible. Instead of being invisible assumptions baked permanently into graph structure, uncertain merges are flagged and queryable. You can find all SAME AS edges below a threshold and present them to domain experts for review without touching graph structure. In practice, running entity resolution on East Asian corporate data means dealing with cases where the right answer requires domain knowledge — knowing that "삼성SDI" and "Samsung SDI" are the same entity requires understanding the Korean naming convention, not just string similarity. The review status: "pending" flag on low-confidence edges gives you a clean queue: php def get pending review queue threshold: float = 0.90 - list dict : return graph.find edges relation="SAME AS", filters={"review status": "pending", "match probability": {"lt": threshold}}, order by="match probability", order="asc", Reviewers see the lowest-confidence merges first. They can confirm, reject, or flag for escalation. Confirmed merges update review status to "verified" . Rejected merges get split back into separate nodes. The graph stays queryable during review. Downstream systems that need only high-confidence data can filter to match probability = 0.90 . Systems that can tolerate more uncertainty can include pending merges. Neither has to wait for the review queue to clear. The common alternative to confidence-aware edges is running resolution at higher thresholds and treating everything as certain. This suppresses the 0.71-confidence merges entirely — they never enter the graph. The problem is that some of those 0.71-confidence pairs are correct. Multilingual corporate data has noise that systematically pushes correct matches below the high-confidence threshold: inconsistent romanization, abbreviated legal suffixes, different subsidiary naming conventions across source databases. A threshold high enough to eliminate incorrect merges also eliminates a meaningful fraction of correct ones. The confidence-on-edge approach lets you include them with explicit uncertainty rather than excluding them. Users and downstream systems can decide what confidence level they need. The probability on the edge is the mechanism that makes that decision possible. The match probability is information. Throwing it away at the resolution gate means the knowledge graph permanently forgets something it knew about the quality of its own structure. Building multilingual entity resolution and knowledge graph pipelines at er-api.hannune.ai and 2asy.ai. More at hannune.ai. Cover: Piret Ilver on Unsplash