When resolving entity matches, the confidence scores produced by tools are often discarded, negatively impacting the quality of knowledge graphs that power retrieval systems. It's better to retain these scores to improve data accuracy and classification.
Hey WondTech readers, did you know we might be making a common mistake that costs us dearly when building knowledge graphs? Simply put, most systems that resolve entity matches throw away the most important number they produce: the «match confidence score». This means we're losing really valuable information that could significantly improve our data accuracy. What does this mean for you? Well, when you use tools like Splink or Dedupe to figure out if two different records represent the same real-world entity (say, the same company), these tools give you a number. A 0.95 might mean very high confidence, while a 0.71 suggests moderate confidence. The problem is, we then apply a threshold, saying, «if it's above 0.8, it's a match; otherwise, it's not». And then, that original confidence score is discarded. Downstream systems, like knowledge graphs or databases, receive a simple, binary signal: either the entities are the same or they're different. This is where the issue lies. A knowledge graph treats a merge made with 0.95 confidence identically to one made with 0.71 confidence. Both become unconditional identity claims: «this is the same entity». For simple applications, this might be fine. But for knowledge graphs that feed information retrieval systems, this quiet defect can significantly impact the quality of results. Imagine a system relying on incorrect or uncertain information; how good will its responses be? The solution is simple and innovative. Instead of throwing away that confidence score, why not keep it as a property associated with the relationship within the graph? In a service like er-api, which handles multilingual entity resolution, they retained the Splink match probability as an edge property linking the matched entities. This allows for intelligent handling of different match types. For example, if the confidence score is 0.90 or higher, the system can automatically merge the entities. However, if it's less than 0.90, like 0.71, it's flagged for human review (pending). This way, highly confident matches are integrated quickly, while less certain matches are checked by a human expert before becoming part of the knowledge graph. This not only improves the accuracy of your graph but also saves time and resources. It's a small change with a big payoff for ensuring more reliable data for our smart systems.
