# Entity resolution Entity resolution is a data-processing technology for matching and linking related records across applications, channels, and data stores. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to Keep Your AI Agent's Knowledge Graph Clean DevFeed: [How to Keep Your AI Agent's Knowledge Graph Clean]() Original publisher: [Read original article]() Author: Paul Iusztin Published: 2026-06-02T05:00:53Z Content type: tutorial Language: en Sources: [Decoding ML]() Topics: [Entity resolution](), [Graphs](), [AI Agent](), [data](), [Large Language Model](), [Neo4j]() Tags: [agent](), [ai-agent](), [code](), [knowledge-graph](), [llm](), [pipeline](), [rag](), [review]() ### AI overview This tutorial explains how to keep an AI agent's knowledge graph clean by separating entity resolution for naming from deduplication for identity. It presents a pipeline covering LLM extraction, embeddings, deduplication, and safety reviews to reduce incorrect merges as the graph grows. ### Source excerpt The resolution, deduplication, and review pipeline that keeps agent memory usable as it grows. ## An overview of end-to-end entity resolution for big data DevFeed: [An overview of end-to-end entity resolution for big data]() Original publisher: [Read original article]() Author: adriancolyer Published: 2020-12-14T14:37:00Z Content type: article Language: en Sources: [Adrian Colyer]() Topics: [Entity resolution](), [big-data](), [data]() Tags: [algorithms-and-data-structures](), [article](), [big-data](), [blocking](), [clustering](), [comparisons](), [overview](), [uncategorized]() ### AI overview This article summarizes an ACM Computing Surveys survey on end-to-end entity resolution for big data. It explains the main pipeline stages: blocking to reduce comparisons, block processing to remove redundant and superfluous comparisons, matching entity-description pairs, and clustering matches into resolved entities. It also outlines classification dimensions including schema awareness, matching process, and batch or incremental processing. ### Source excerpt An overview of end-to-end entity resolution for big data, Christophides et al., ACM Computing Surveys, Dec. 2020, Article No. 127 The ACM Computing Surveys are always a great way to get a quick orientation in a new subject area, and hot off the press is this survey on the entity resolution (aka record linking) problem. It's an ... Continue reading An overview of end-to-end entity resolution for big data ## Retrofitting Position IDs to Addepar Non-Intrusively DevFeed: [Retrofitting Position IDs to Addepar Non-Intrusively]() Original publisher: [Read original article]() Author: Calvin Wu Published: 2017-11-08T14:11:00Z Content type: article Language: en Sources: [Addepar]() Topics: [data](), [Graphs](), [Entity resolution](), [integrity](), [import](), [Architecture & Design]() Tags: [data](), [data-pipeline](), [edge](), [fintech](), [graph](), [import](), [integrity](), [mapping](), [node](), [reconciliation](), [validation](), [verification]() ### AI overview Addepar describes its Financial Graph and data pipeline for importing portfolio data from many custodians. The article explains how node matching identifies accounts and securities, connects them through ownership edges, and addresses verification and data-integrity problems through a non-intrusive pipeline change. ### Source excerpt Every day, Addepar's data pipeline consumes portfolio data from hundreds of different custodians and imports it to millions of nodes and edges in our Financial Graph. To ensure that the data can be trusted and used to correctly calculate performance, it's crucial that we not only import it in a timely fashion, but also run verification checks with what already exists on our platform. The data is complex, and data integrity check failures can be caused by a lot of different issues -- for example, missing data, incorrect raw data from custodian, incorrect transaction mapping, problematic validation logic, and incorrect security mapping. As our platform grows, we're continually improving and extending our methods. The following is an example of how we addressed one type of verification problem -- node matching -- by non-intrusively introducing a core change to a critical pipeline. Node Matching The Financial Graph is used to represent the ownership structure of portfolio data, where a node represents an entity (such as a brokerage account, an asset owner, a legal entity, a stock, or a bond), and an edge (or a position in financial terms) represents the ownership relationship between two nodes. The from node is often an account, and the to node refers to the portfolio's holding -- the actual security. When importing data, we need to do a few things: Identify the account node. Identify the security node via node matching. We search for the security node in our system using the security attribute information the custodian provided. The search criteria could be the name of the security or security identifiers. Each security type may have different preferred strong and weak identifiers that drive the matching. Our matching logic may evolve over time as we learn more about the data. This is similar to the entity resolution problem, where we have to identify the same node across different data sources. Find the edge. Once both the account node and security node are identified, th