
이번 여름방학에는 Entity Resolution 공부를 해보려합니다. 교안은 O'Reilly의 Hands-On 시리즈에서 선택했고, 한국어 버전은 없습니다(ㅠㅠ). 그래도 실습교재이기 때문에 내용이 그렇게 어렵진 않아서 한 챕터씩 정리(번역 아님)를 해보고 기록을 남겨보겠습니다!
현대 사회에서는 수많은 데이터가 수많은 주체에 의해서 생산되고 저장된다. 이 과정에서 동일한 데이터도 생산/기록 주체에 따라서 다르게 조직되고 분류된다. 따라서 서로 다른(heterogeneous) 데이터를 결합하여 더 풍부한 인사이트를 얻기 위한 과정은 쉽지 않고, 이를 위해 Entity Resolution이 필요한 것이다.
Entity Resolution은 '현실에서 동일한 개체로 간주되는 데이터 레코드를 인식하는 분석 기법'이다. 동일한 출처 내에서 중복되는 값들은 지우고, 서로 다른 출처의 값들은 모아서 고유한 식별자를 부여한다. Entity Resolution는 개체 간의 관계를 파악할 수 있도록 하여 마케팅이나 금융, 헬스케어 등과 나아가 머신러닝이나 AI 분야에서도 활용될 수 있다.
현실 세계에서 개개인은 상황에 따라 주민등록번호, 회원번호, 사번 등 다양한 식별자로 구분된다. 소규모의 지역 사회 단위에서는 면대면 상호작용으로 개별 사람에 대한 정보를 파악할 수 있어 이런 식별자가 필요 없지만, 그 범위가 넓어지면 개별적으로 명확한 구분자가 필요하다. 따라서 중복 가능성이 있는 이름 수준을 넘은 machine-readerable한 식별자가 필요한 것이다.
그러나 고유한 식별자를 부여할 때는 해당 개체가 기존의 개체와 정말 다른, 새로운 개체인지에 대한 판별이 필요하다. 예를 들어, 고객의 ID를 부여할 때, 기존에 100명의 고객의 ID는 유니크하게 부여할 수 있지만 새로 등록한 고객이 기존의 100명과 전혀 다른 사람이라는 것을 판단하게 위해서는 그 사람에 대한 정보들을 종합적으로 검토해야 한다. 또한 이 사람이 또 다른 마켓의 고객 ID에서 어떻게 매칭할 수 있는지에 대한 차원의 문제도 존재한다. 식별 체계에 대한 표준이 없음에 따라 다른 조직에서는 또 다른 방식으로 ID를 부여했을 것이기 때문이다.
두 개체를 비교하는 방법은 이름과 같은 각 속성들을 비교하는 것이다. 그러나 이게 그렇게 간단하지 않다는 것을 책에서는 몇 가지 예시로 설명한다.
Lack of Unique Names
개체의 이름이나 라벨을 중복은 많을 수 밖에 없다.
Inconsistent Naming Conventions
이름은 다양하게 표현될 수 있다. 특히 서양 이름은 middle name이 있기도 하고 이를 대표 알파벳으로 표현할 때도 있고, 약어로 쓰기도 하며 하이픈(-)을 사용하기도 해서 하나의 이름이 책의 예시와 같이 6개로 표현될 때도 있다.
이때의 이름은 개체를 표현하는 '텍스트'의 개념으로 이해했다. '남산타워'는 타워의 이름이고, 이는 'N타워', '서울 N타워', '서울 남산타워' 등과 같이 다양한 이름으로 불린다
Data Capture Inconsistencies
윗 부분과 비슷한데, 이 역시 이름을 기록하는 과정에서 오류가 발생할 수 있음을 설명한다. 표기 형식의 차이가 있을 수 있고 철자나 오타가 발생할 수 있으며, 국가에 따른 표기 관행의 차이가 있을 수 있기 때문이다.
또한 이어지는 내용에서는 이런 오류가 이름 뿐만 아니라 출생년월을 기록할 때(1/4/Jan, 4 January 1970 등) 등 여러 차원의 차이가 있을 수 있음을 설명한다.
Deliberate Obfuscation
의도적으로 다른 개체로 인식하도록 한 경우 존재할 수 있는데, 이는 범죄와 관련될 수 있으므로 주의해야 한다.
Match Permutations
적은 양의 데이터는 금방 매칭할 수 있지만, 대규모 데이터는 하나씩 비교할 때 연산량이 엄청나게 늘어난다.
Blind Matching?
지금까지의 가정은 개체의 모든 속성을 다 안다는 것이었는데, 실제로는 개인정보나 법적/정치적 요인으로 데이터의 모든 속성을 확인하지 못하는 경우가 존재한다고 한다. 그럼에도 crytographic(암호화 기술?)와 같은 방법이 있는데, 이는 Chapter10에서 다룬다고 한다.
비교하려는 데이터가 속성의 비교가 가능한 일관된 데이터인지에 대한 검토가 우선적으로 필요하다. 또한 가능한 속성들의 포맷을 일관되게 만들거나 null을 제거하는 등의 전처리가 필요하다.
모든 속성을 다 비교하는 것은 어렵기 때문에, 사전에 비교할 매칭될 확률이 높거나 필수적인 세트를 미리 지정하고 subset들만 비교하는 작업을 수행할 수 있다.
위에서 선택한 속성들에 한해서 비교를 진행하는 단계로, 두 레코드 쌍의 동등함을 비교한 결과가 도출된다.
마지막 단계는, 도출된 결과가 실제로 매칭된다고 볼 수 있는지 판단하는 파트이다. 이 판단은 정해진 규칙에 따라 매뉴얼하게 진행되거나 머신러닝을 통한 확률적 접근을 할 수 있다.
분류를 마친 뒤에는 클러스터링을 통해 묶을 수 있다. 이때 클러스터는 특정 threshold가 넘는 쌍들만 묶고 그렇지 않은 것들은 독립적인 개체가 된다. 한편, 매칭 기준에 따라 A와 B는 유사하고 B와 C는 유사하지만 A와 C가 유사하지 않는 것과 같은 경우가 하나의 클러스터에 묶여서 더 느슨한 구조를 가질 수도 있다고 한다(이를 '이행성(intransitive)'이 없는 경우라고 표현함).
Cnonicalization은 정규화를 의미하는 것으로 normalization과는 다소 다르게 접근된다. normalization은 예를 들어, Apple과 apple의 대소문자를 맞춰주는 것으로 python에서는 strip이나 lower, trime등과 같은 라이브러리를 사용해서 진행한다. 이는 데이터 전처리 과정에서 직접적으로 데이터를 수정해서 맞춰주는 작업이다. 반면, canonicalization은 normalization이 진행된 뒤, 형태가 바뀐 데이터 중에서 동일한 개체를 의미하는 여러가지 값들 중 대표값을 정하는 작업을 의미한다. 즉, 여러개의 속성이 있을 때 우선순위를 정한다는 것이다. 이때 우선순위를 정하는 방법은 일반적으로 표준화된 표기법이 있는지 먼저 확인해보고, 확률적으로 접근할 수도 있다.
한편, normalization과 canonicalization은 순서를 결정해야 할 수도 있다. normalization을 진행한 다음에는 canonicalization이 필요 없을 수도 있고, 혹은 이후 규칙을 만들어 표준화를 진행해야 할 수도 있다. 이 표준/정규화 작업은 데이터를 다루는 과정에서 항상 어려운 문제로 존재하며, 여전히 ML과 같은 기법을 사용하지만 쉽지 않은 작업이다.
Worked Example에서는 속성을 비교할 때 가중치를 부여할 수 있다는 내용도 설명하는데, 예를 들어, 핸드폰 번호가 같은 경우는 생년월일이 같은 경우에 비해 더 높은 일치 가능성이 있으므로 가중치를 부여하는 것이다. 또한 흔함과 드묾에 따른 확률론적 가중치도 부여가 가능하다고 한다. 이와 관련해서는 Chapter4에서 더 자세히 다룰 예정이다.