Ability — 엔티티 해결
Ability는 지저분하고 중복된 레코드를 하나의 깔끔하고 추적 가능한 엔티티 집합으로 변환합니다. 5단계로 작동하며 소스 데이터를 절대 파괴하지 않습니다. 모든 병합된 레코드는 원본 레코드에 대한 링크를 유지합니다.
레코드 연결은 일치하는 수학입니다(레코드 A가 레코드 B와 일치합니까?). 엔티티 해결은 전체 작업입니다: 일치, 일치 항목을 엔티티로 클러스터링, 신뢰도 점수 매기기, 출처 유지. 전체 작업을 수행하세요.
시작하기 전: 정렬 확인
지저분한 요청은 정상입니다. 오타와 약어를 의도로 읽고 철자에 대해 절대 언급하지 마십시오. 실제 작업 전에 사용자가 비용을 들여 경로를 수정할 수 있도록 세 줄을 짧게 명시하십시오:
SAID: <사용자가 문자 그대로 요청한 내용>
INFERRED: <해결해야 할 실제 문제>
ASSUMED: <당신이 하고 있는 주요 가정 — 정말 막혔다면 최대 한 가지 질문>
빠른 질문의 경우 건너뛰고, 데이터를 처리하거나 파이프라인을 설계하려고 할 때 사용하십시오.
5단계 파이프라인
1. 프로파일링
일치시키기 전에 모든 필드를 살펴보십시오. 필드별로 보고: null 비율, 고유 값 개수, 상위 값, 형식 패턴, 인코딩 문제(UTF-8 vs Latin-1). 프로파일링은 일치에 신뢰할 수 있는 필드와 ("Smith", "123 Main St"와 같이) 너무 흔해서 일치가 의미가 없는 값을 알려줍니다.
2. 표준화
비교하기 전에 정규화하지 않으면 점수가 잘못됩니다: 소문자 변환, 구두점 제거, 약어 확장(St → Street), 이름을 부분으로 구문 분석, 전화번호를 숫자로 정규화, 회사 접미사 정규화(Inc., Ltd, LLC), 주소 표준화(가능한 경우 우편 확인).
지저분한 실제 데이터에는 거의 항상 다음도 필요합니다:
- 별명 테이블 (Bob/Robert, Peggy/Margaret, Sasha/Alexander, Trish/Patricia) 및 이니셜("J.")은 해당 문자로 시작하는 모든 이름과 호환되는 것으로 처리.
- 필드 교환 이름 — 이름과 성을 바꾼 것도 비교.
- 모호한 날짜 — "04/05/1990"은 4월 5일 또는 5월 4일이 될 수 있습니다. 두 해석을 모두 유지하고 일/월 전환을 충돌이 아닌 부분 일치로 처리.
3. 블로킹
모든 레코드를 다른 모든 레코드와 비교하는 것은 N²입니다. 100만 개 레코드는 약 5000억 쌍을 의미합니다. 블로킹은 키를 공유하는 레코드만 비교합니다. 다른 키로 여러 번의 패스를 사용하여 한 필드의 오타가 실제 일치를 숨기지 않도록 합니다:
- 음성 성(Soundex / NYSIIS) + 출생 연도
- 우편번호 접두사 + 집 번호
- ID의 마지막 4자리 + 우편번호
- 전화 또는 이메일
- 텍스트가 많은 데이터의 경우: 토큰 집합에 대한 MinHash LSH 또는 임베딩 + 최근접 이웃 검색 (FAISS/HNSW)
측정하십시오:
- 감소 비율 = 1 − (비교된 쌍 ÷ 가능한 모든 쌍) — 99% 이상 목표
- 쌍 완전성 = 일부 블록에 포함된 실제 일치 항목 ÷ 모든 실제 일치 항목 — 95% 이상 목표
4. 점수 매기기 — 3단계 캐스케이드
먼저 저렴하고 확실한 검사를 실행하고 필요한 경우에만 비용이 많이 드는 검사를 실행하십시오.
- 확정적: 신뢰할 수 있는 고유 ID 일치 (국가 ID, 세금 ID, 계좌 번호, 확인된 이메일) → 일치.
- 퍼지: ID 일치 없음 → 필드별 올바른 알고리즘(표 참조)으로 필드를 비교하고 Fellegi-Sunter 가중치로 결합.
- 머신러닝 / 사람 검토: 여전히 모호함 → 레이블이 지정된 데이터가 있는 경우 분류기(예: 필드 유사성 특성에 대한 로지스틱 회귀), 그렇지 않으면 사람 검토 큐로 라우팅.
| 필드 유형 | 사용 |
|---|---|
| 사람 이름 | Jaro-Winkler (일치하는 접두사 보상) + 별명 목록 |
| 회사 이름 | 접미사 정리 후 토큰 정렬 비율 (단어 순서 무관) |
| 주소 | 표준화 후 Levenshtein; 집 및 동 번호는 정확히 일치해야 함 |
| ID, 전화, 이메일 | 정규화 후 정확히 일치 |
| 긴 텍스트 | 토큰에 대한 Jaccard / cosine |
Fellegi-Sunter 요약 — 각 필드 k에 대해:
- m = P(필드 동의 | 레코드 실제 일치) — 필드의 신뢰도
- u = P(필드 동의 | 레코드 불일치) — 우연히 동의하는 빈도
- 동의 가중치 = log2(m/u); 불일치 가중치 = log2((1−m)/(1−u))
- 총 점수 = 각 필드 결과에 대한 가중치 합계
드문 값은 더 많은 증거를 전달합니다. "Lebowski"(매우 작은 u)에 동의하는 것은 "Smith"에 동의하는 것보다 훨씬 강력합니다. 가능한 경우 값별 u를 사용하십시오. 실제로: 드문 전체 이름과 정확한 생년월일은 주소, 전화, 이메일이 모두 변경된 경우(사람이 이사한 경우)에도 강력한 증거입니다. 흔한 이름과 생년월일은 그렇지 않습니다.
쌍의 점수를 매기려면 수동으로 계산하는 대신 scripts/fs_score.py를 실행하십시오. 가중치를 적용하고 점수를 사전 확률이 주어진 일치 확률로 변환하며 결정 대역을 할당합니다. python scripts/fs_score.py --help를 실행하여 사용법을 확인하십시오.
전체 공식, 작업 예제 및 m/u 추정(EM 포함)은 references/methods.md에 있습니다. 사용자가 수학을 원하거나 가중치를 조정해야 할 때 읽으십시오.
점수만으로는 잡을 수 없는 두 가지 함정:
- 가구. 쌍둥이, 배우자, 룸메이트는 성, 주소, 때로는 생년월일을 공유하므로 점수가 거의 확실한 일치처럼 보일 수 있습니다. 이름이 다르고(서로의 별명이 아닌 경우) 개인 연락처(이메일, 전화)가 충돌하는 경우 점수와 관계없이 분리하거나 검토로 보내십시오.
- 플레이스홀더 값. 2000-01-01 또는 1900-01-01과 같은 날짜, 555-0000과 같은 전화번호, [email protected]과 같은 이메일은 채우기 값이며 증거가 아닙니다. 프로파일링(1단계)에서 의심스럽게 반복되는 값을 플래그 지정해야 합니다. 가중치를 부여하지 마십시오.
결정 대역 (레이블이 지정된 데이터로 조정; 다음은 시작점입니다):
| 일치 확률 | 조치 |
|---|---|
| ≥ 0.95 | 자동 일치 |
| 0.80 – 0.94 | 사람 검토 큐 |
| < 0.80 | 불일치 |
5. 병합 — 생존 및 골든 레코드
일치하는 쌍을 엔티티로 그룹화합니다 (연결된 구성 요소 / 그래프 클러스터링 — AB 및 BC이지만 A≁C인 체인을 주의하십시오. 검토를 위해 분할). 각 엔티티에 대해 명시된 규칙으로 각 필드를 선택하여 하나의 골든 레코드를 구축합니다:
- 최신 (가장 최근 타임스탬프) — 주소, 전화
- 가장 완전한 (null이 아닌, 가장 긴) — 이름, 설명
- 신뢰할 수 있는 출처 (시스템 순위) — ID, 법적 이름
원본을 덮어쓰거나 삭제하지 마십시오. 저장: 골든 레코드 ID → 소스 레코드 ID 목록, 각 필드를 선택한 규칙, 함께 결합된 일치 점수.
결과 검증
작은 레이블이 지정된 세트(몇 백 쌍 정도의 일치/불일치 표시)를 요청하거나 구축을 도우십시오. 정밀도, 재현율, F1을 보고하고 블로킹에 대한 감소 비율과 쌍 완전성을 보고하십시오. 검증 없이 임계값은 추측에 불과합니다 — 레이블이 지정된 세트가 없을 때 그렇게 말하십시오.
증거 태그
결과를 주장할 때 어떻게 알았는지 말하십시오:
- [DOC] — 사양 또는 문서에서, 실행되지 않음
- [RAN] — 이 세션에서 실행됨
- [PASS] — 레이블/테스트 데이터와 대조 확인됨
체크포인트 검토
긴 작업 중(약 5 작업 턴마다, 사용자가 실수를 보고할 때, 또는 "checkpoint" 또는 "dream"을 입력할 때): 프로젝트 작업을 일시 중지하고 최근 자신의 턴을 간략히 검토하십시오. 사용자가 명시한 제약 조건에서의 각 실수 또는 이탈, 원인 및 앞으로 적용할 수정 사항을 나열하십시오. 그런 다음 재개하십시오. 검토를 산출물 밖에 두십시오 — 사용자의 데이터나 문서가 아닌 대화를 위한 것입니다.
일치 작업에 대한 출력
완료된 작업을 다음으로 종료하십시오:
ENTITIES: <입력 레코드> → <해결된 엔티티> (<발견된 중복>)
BANDS: 자동 <n> | 검토 <n> | 불일치 <n>
QUALITY: 정밀도 <x> | 재현율 <x> | F1 <x> (또는 "검증되지 않음 — 레이블이 지정된 세트 없음")
FILES: <골든 레코드, 크로스워크, 검토 큐가 저장된 위치>
개인정보 보호
일치 작업에는 종종 개인 데이터가 포함됩니다. 로컬에서 처리하고, 식별자를 URL이나 외부 서비스에 붙여넣지 말며, 조직 간 연결 시 개인정보 보호 연결(블룸 필터 이름 인코딩, Dice 유사도로 비교)을 제안하십시오 — 자세한 내용은 references/methods.md에 있습니다.