Hợp nhất danh tính & Golden Record

Bài tổng quan Customer 360 đã đặt vấn đề: muốn có "một hồ sơ duy nhất" cho mỗi khách hàng thì trước tiên phải trả lời được câu hỏi tưởng đơn giản mà cực kỳ khó — hai bản ghi này có phải cùng một người không?

Trong một ngân hàng, ông Nguyễn Văn A tồn tại đồng thời ở: core banking (mã CIF 0012345, tên NGUYEN VAN A), hệ thống thẻ (Nguyen V. An, số CMND cũ), CRM (Nguyễn Văn A, email [email protected]), hệ thống cho vay (đã đổi sang CCCD 12 số), và app mobile (đăng ký bằng số điện thoại). Không hệ thống nào biết bốn năm bản ghi kia cũng là ông. Nếu ta ghép cả năm nguồn lại mà không hợp nhất, Customer 360 sẽ đếm ông thành 4-5 "khách hàng" khác nhau — mọi phân khúc, mọi gợi ý sản phẩm, mọi số liệu đều sai.

Bài này đi vào identity resolution (hợp nhất danh tính) — công đoạn nền móng và khó nhất, quyết định chất lượng của toàn bộ Customer 360.

1. Vì sao hợp nhất danh tính lại khó

Nếu mọi hệ thống đều dùng chung một khoá định danh sạch, tuyệt đối duy nhất thì bài toán này không tồn tại — chỉ cần JOIN. Thực tế ngân hàng không như vậy:

• Nhiều định danh, không đồng bộ: CIF, số CMND 9 số (cũ), CCCD 12 số (mới), hộ chiếu, mã số thuế, số điện thoại, email. Một người đổi CMND → CCCD; một số điện thoại có thể được thu hồi rồi cấp cho người khác; email dùng chung trong hộ gia đình.
• Dữ liệu bẩn: sai chính tả (Nguyễn vs Nguyên), thiếu dấu (NGUYEN VAN A), viết tắt (Ng. V. A), đảo thứ tự họ tên, ngày sinh nhập nhầm (01/02 vs 02/01), địa chỉ mỗi nơi ghi một kiểu.
• Thay đổi theo thời gian: đổi tên sau kết hôn, chuyển nhà, đổi số điện thoại. Bản ghi "đúng" ở 2015 không còn đúng ở 2025.
• Trùng lặp nội bộ: ngay trong một hệ thống, cùng một người có thể được mở hai CIF do nhân viên không tra cứu kỹ lúc onboarding.
• Không có "sự thật nền" (ground truth): phần lớn trường hợp ta không biết chắc đáp án đúng, chỉ có thể suy luận theo xác suất.

Đây chính là lý do bài toán được gọi là entity resolution / record linkage / deduplication — các tên gọi khác nhau của cùng một họ vấn đề: quyết định xem tập bản ghi nào cùng trỏ về một thực thể thật ngoài đời.

2. Pipeline identity resolution

Quy trình chuẩn gồm bốn bước tuần tự. Sơ đồ tổng quan:

2.1. Normalize — chuẩn hoá

Trước khi so khớp, đưa mọi giá trị về dạng chuẩn (canonical form) để loại bỏ khác biệt hình thức không mang ý nghĩa:

• Tên: viết hoa/thường thống nhất, bỏ dấu tiếng Việt để tạo bản đối chiếu (Nguyễn → NGUYEN), chuẩn hoá khoảng trắng, tách họ / tên đệm / tên. Lưu cả bản có dấu (hiển thị) lẫn bản không dấu (so khớp).
• Ngày sinh: ép về YYYY-MM-DD, đánh dấu các giá trị mặc định đáng ngờ (01/01/1900, 00/00).
• Số điện thoại: chuẩn hoá về E.164 (+8490...), bỏ khoảng trắng/dấu gạch, xử lý đầu số cũ↔mới.
• Định danh: map CMND 9 số ↔ CCCD 12 số nếu có bảng đối chiếu; loại ký tự thừa.
• Địa chỉ: tách và chuẩn hoá đơn vị hành chính (phường/quận/tỉnh), viết tắt phổ biến (P. → Phường).

Chuẩn hoá tốt làm giảm mạnh số cặp cần dùng đến so khớp mờ ở bước sau.

2.2. Blocking — sinh khoá gom nhóm

Nếu có N bản ghi và so từng cặp thì độ phức tạp là N²/2 — với 5 triệu khách là hơn 12 nghìn tỷ cặp, bất khả thi. Blocking giải quyết bằng cách chỉ so những bản ghi có khả năng trùng, tức cùng rơi vào một "khối":

• Tạo blocking key từ vài thuộc tính ổn định: ví dụ soundex(họ) + năm sinh, hoặc 4 số cuối SĐT + chữ cái đầu tên, hoặc mã tỉnh + ngày sinh.
• Chỉ so khớp các bản ghi trong cùng một khối → giảm số cặp xuống vài bậc.
• Rủi ro: khoá quá chặt sẽ bỏ sót cặp trùng thật (recall giảm); quá lỏng thì khối to, tốn tính toán. Thực tế dùng nhiều khoá blocking song song (multi-pass) để bù lẫn nhau — một cặp chỉ cần "gặp nhau" ở ít nhất một pass.

2.3. Matching — so khớp

Đây là trái tim của pipeline. Hai trường phái, thường kết hợp:

Deterministic matching (khớp tất định) — dựa vào một hoặc vài định danh mạnh khớp tuyệt đối:

• Nếu hai bản ghi cùng CCCD 12 số (đã xác minh) → gần như chắc chắn cùng người → auto-merge.
• Ưu điểm: nhanh, giải thích được, chính xác cao khi định danh sạch. Nhược điểm: mù trước dữ liệu bẩn/thiếu — chỉ cần một bên gõ sai một số là trượt.

Probabilistic / fuzzy matching (khớp xác suất/mờ) — khi không có định danh mạnh, tính điểm giống tổng hợp từ nhiều thuộc tính:

• Đo độ giống chuỗi bằng các hàm khoảng cách:
  • Levenshtein (edit distance): số phép chèn/xoá/thay để biến chuỗi này thành chuỗi kia — tốt cho lỗi gõ.
  • Jaro-Winkler: ưu tiên trùng phần đầu chuỗi — rất hợp cho tên người.
  • So khớp ngày sinh, mã tỉnh, 4 số cuối SĐT...
• Mô hình Fellegi-Sunter — nền tảng lý thuyết của record linkage: với mỗi thuộc tính, ước lượng hai xác suất:
  • m = P(thuộc tính khớp | hai bản ghi đúng là cùng người),
  • u = P(thuộc tính khớp | hai bản ghi khác người, khớp do ngẫu nhiên).
  • Trọng số của một thuộc tính = log2(m/u). Thuộc tính càng hiếm trùng ngẫu nhiên (ví dụ họ tên đầy đủ giống) thì u càng nhỏ → trọng số dương càng lớn khi khớp. Cộng dồn trọng số các thuộc tính ra tổng điểm (match score).

Sau khi có điểm, dùng hai ngưỡng:

Chọn ngưỡng là đánh đổi giữa precision (gộp nhầm hai người khác nhau — false positive) và recall (bỏ sót hai bản ghi cùng người — false negative). Trong ngân hàng, gộp nhầm nguy hiểm hơn nhiều nên ngưỡng match thường đặt bảo thủ, phần còn lại đẩy sang review.

2.4. Từ cặp khớp đến cụm thực thể

Matching cho ta các cặp "AB", "BC". Bước tiếp theo là gom cặp thành cụm (cluster): nếu AB và BC thì A, B, C thường thuộc cùng một thực thể (tính bắc cầu — transitive closure). Đây chính là chỗ đồ thị (graph) vào cuộc: mỗi bản ghi là một đỉnh, mỗi cặp khớp là một cạnh, mỗi connected component là một khách hàng. Cần cẩn thận với "over-merging": một cạnh sai (một cặp gộp nhầm) có thể kéo hai cụm lớn dính vào nhau.

3. Golden Record & survivorship

Sau khi biết cụm bản ghi nào là cùng một người, phải tạo ra một bản ghi đại diện tốt nhất — gọi là golden record (hoặc "best record", "single version of the truth"). Vấn đề: các bản ghi nguồn mâu thuẫn nhau ở từng trường (mỗi nơi ghi một địa chỉ, một số điện thoại). Survivorship (đôi khi gọi consolidation rules) là bộ luật chọn giá trị "sống sót" cho mỗi trường:

• Theo độ tin cậy nguồn (source of trust): với địa chỉ, tin core banking hơn app; với email, tin CRM hơn.
• Theo độ mới (most recent): lấy giá trị có updated_at gần nhất — hợp cho SĐT, địa chỉ.
• Theo độ đầy đủ (most complete): ưu tiên trường non-null, dài/đủ hơn.
• Theo tần suất (voting): giá trị xuất hiện ở nhiều nguồn nhất.

Quan trọng: golden record không xoá bản ghi nguồn. Ta giữ cross-reference (xref) — một bảng ánh xạ golden_id → (source_system, source_key) — để:

• Truy vết giá trị golden đến từ đâu (lineage), phục vụ audit và tuân thủ.
• Un-merge khi phát hiện gộp nhầm: chỉ cần gỡ liên kết, không mất dữ liệu gốc.

# Pseudocode: survivorship cho trường "address"
def pick_address(records):
    # records: các bản ghi trong cùng một cụm
    candidates = [r for r in records if r.address is not None]
    if not candidates:
        return None
    # 1) ưu tiên nguồn tin cậy nhất
    ranked = sort_by_source_trust(candidates)      # core > crm > loan > app
    top_source = ranked[0].source
    same_source = [r for r in ranked if r.source == top_source]
    # 2) trong cùng nguồn, lấy bản mới nhất
    return max(same_source, key=lambda r: r.updated_at).address

4. MDM — Master Data Management

Identity resolution không phải chạy một lần rồi thôi; nó phải là một năng lực vận hành liên tục khi dữ liệu mới đổ về mỗi ngày. Đó là phạm vi của MDM (Master Data Management) — kỷ luật quản lý các dữ liệu chủ (master data) như khách hàng, sản phẩm, tài khoản để chúng nhất quán trên toàn tổ chức. Với Customer 360, master data cần quản trị là customer master.

Ba phong cách triển khai MDM, khác nhau ở chỗ golden record "sống" ở đâu và ai làm chủ:

Nhiều ngân hàng bắt đầu bằng consolidation cho Customer 360 phân tích, rồi tiến dần lên coexistence khi độ chín tăng.

MDM đi kèm data governance / stewardship: có người chịu trách nhiệm (data steward) xử lý hàng đợi review, phê duyệt merge/un-merge, và các luật chất lượng dữ liệu — liên hệ trực tiếp với quản trị chất lượng dữ liệu. Chất lượng đầu vào càng cao (ít null, định danh sạch) thì matching càng chính xác; ngược lại, identity resolution cũng là một cơ chế phát hiện lỗi dữ liệu (trùng lặp, mâu thuẫn) rất giá trị.

5. Household & mối quan hệ

Hợp nhất ở cấp cá nhân mới là một nửa. Nhiều bài toán ngân hàng cần cấp cao hơn — household (hộ) và quan hệ pháp nhân:

• Household: gộp các cá nhân sống chung / cùng kinh tế (vợ chồng, cha mẹ - con) dựa trên chung địa chỉ, chung tài khoản, người thụ hưởng, đồng sở hữu. Dùng để tính tổng tài sản hộ, tránh gửi trùng ưu đãi cho cùng một nhà, đánh giá rủi ro theo hộ.
• Quan hệ doanh nghiệp: một tập đoàn với công ty mẹ - con, người đại diện pháp luật, chủ sở hữu hưởng lợi (UBO). Rất quan trọng cho tín dụng (giới hạn tín dụng theo nhóm liên quan) và AML.

Cả hai bản chất là bài toán đồ thị: đỉnh là người/pháp nhân, cạnh là quan hệ (cùng địa chỉ, đồng sở hữu, đại diện...). Nhiều nền tảng hiện đại lưu customer master dưới dạng graph để trả lời các câu hỏi "ai liên quan ai" — nối tiếp ý tưởng ở tổng quan đồ thị dữ liệu.

6. Thách thức đặc thù ngân hàng

• KYC & định danh pháp lý: ngân hàng bị ràng buộc phải định danh chính xác (CCCD/hộ chiếu). Identity resolution phải nhất quán với dữ liệu KYC pháp lý, không được tạo golden record mâu thuẫn hồ sơ định danh chính thức.
• Rủi ro gộp nhầm (false merge): gộp nhầm hai người khác nhau là lỗi nghiêm trọng — một người có thể nhìn thấy tài khoản/giao dịch của người khác, hoặc bị đánh giá tín dụng dựa trên lịch sử người lạ. Vì thế: ngưỡng match bảo thủ, luôn giữ xref để un-merge, log đầy đủ mọi quyết định merge.
• Dữ liệu nhạy cảm & quyền riêng tư: hợp nhất kéo toàn bộ dấu vết một người về một chỗ — đúng nghĩa "hồ sơ 360" — nên phải tuân thủ nghiêm về bảo mật, phân quyền, và mục đích sử dụng (quyền riêng tư & tuân thủ). Nhiều khoá match (SĐT, CCCD) chính là dữ liệu định danh cá nhân cần bảo vệ.
• Giải thích được: khi bị khiếu nại "sao tài khoản tôi lẫn với người khác", đội ngũ phải giải thích được vì sao hệ thống gộp — deterministic dễ giải thích, probabilistic cần lưu điểm và các thuộc tính đóng góp.

7. Công cụ

Không cần tự viết từ đầu. Một số lựa chọn (nêu làm ví dụ, không phải khuyến nghị cụ thể):

• MDM thương mại: Informatica MDM, IBM InfoSphere MDM, SAP MDG, Reltio, Semarchy — trọn gói hub + matching + stewardship UI + governance.
• Thư viện mã nguồn mở (Python):
  • Splink — record linkage quy mô lớn dựa trên mô hình Fellegi-Sunter, chạy được trên Spark/DuckDB, ước lượng m/u bằng EM.
  • dedupe — active learning để gán nhãn cặp, phù hợp dữ liệu vừa.
  • RecordLinkage — bộ công cụ giáo khoa: indexing (blocking), so sánh, phân loại.

Chọn công cụ tuỳ quy mô, yêu cầu vận hành (batch phân tích hay real-time), và mức độ cần stewardship UI.

8. Ví dụ minh hoạ

8.1. Logic fuzzy match + survivorship (pseudocode)

# Minh hoạ — không phải code sản phẩm
def match_score(a, b):
    s = 0.0
    # deterministic: CCCD khớp -> gần như chắc chắn
    if a.cccd and a.cccd == b.cccd:
        return 1.0
    # probabilistic: cộng dồn trọng số theo từng thuộc tính
    s += 0.45 * jaro_winkler(a.name_nodiacritic, b.name_nodiacritic)
    s += 0.25 * (1.0 if a.dob == b.dob else 0.0)
    s += 0.15 * (1.0 if a.phone_last4 == b.phone_last4 else 0.0)
    s += 0.15 * (1.0 if a.city == b.city else 0.0)
    return s

MATCH, REVIEW = 0.85, 0.65
def decide(a, b):
    sc = match_score(a, b)
    if sc >= MATCH:   return "MERGE"
    if sc >= REVIEW:  return "REVIEW"     # đẩy cho data steward
    return "NO_MATCH"

8.2. Phát hiện trùng bằng SQL

Trong sandbox chỉ có một bảng customers(id, full_name, city, created_at) phẳng, ta có thể dùng nó như một màn sàng blocking thô — tìm các bản ghi nghi trùng vì cùng tên (đã chuẩn hoá hoa/thường + khoảng trắng) và cùng thành phố. Đây đúng là bước đầu của identity resolution: khoanh vùng ứng viên để con người/mô hình soi tiếp.

-- ▶ Chạy được
SELECT lower(trim(full_name)) AS name_key,
       city,
       COUNT(*)                       AS n_records,
       MIN(id)                        AS keep_id,
       array_agg(id ORDER BY created_at) AS all_ids
FROM customers
GROUP BY lower(trim(full_name)), city
HAVING COUNT(*) > 1
ORDER BY n_records DESC, name_key;

Lưu ý thực chiến: kết quả này chỉ là ứng viên, chưa phải kết luận — hai người trùng tên cùng thành phố hoàn toàn có thể là hai người khác nhau. Đó chính là lý do ta cần thêm ngày sinh, định danh, và điểm số ở bước matching thực sự.

Use case thực tế

Bối cảnh NCB. Trước dự án Customer 360, NCB có ba nguồn dữ liệu khách hàng chính không đồng bộ: core banking (khách tiền gửi/vay, khoá CIF), hệ thống thẻ (khoá theo số thẻ + CMND), và CRM (khoá nội bộ CRM, có email/SĐT do sale nhập tay). Ước tính ban đầu tổng cộng ~2,1 triệu bản ghi khách cộng gộp thô từ ba nguồn.

Vấn đề đo được:

• Một khách vừa gửi tiết kiệm (core) vừa dùng thẻ tín dụng (card) vừa được sale chăm (CRM) bị đếm thành 3 khách → báo cáo "số khách hàng hoạt động" bị thổi phồng.
• Chiến dịch email/SMS gửi trùng cho cùng một người 2-3 lần → phiền khách, tốn chi phí.
• Hồ sơ mỗi nguồn thiếu mảnh: core không có email, CRM không có số dư, thẻ không có nghề nghiệp → không nguồn nào đủ để phân khúc.

Cách làm (minh hoạ, số liệu ước lượng):

1. Normalize tên (bỏ dấu, chuẩn hoá khoảng trắng), SĐT về E.164, map CMND 9 số → CCCD 12 số bằng bảng đối chiếu từ đợt cập nhật KYC.
2. Blocking hai pass: (soundex họ + năm sinh) và (4 số cuối SĐT) để không bỏ sót.
3. Matching: deterministic trên CCCD/CIF trước (auto-merge ~68% khối lượng); phần còn lại probabilistic (Jaro-Winkler tên + ngày sinh + SĐT + thành phố), ngưỡng MERGE 0.88, REVIEW 0.70.
4. Survivorship: email/SĐT lấy CRM mới nhất, số dư/sản phẩm lấy core, địa chỉ lấy nguồn updated_at gần nhất.
5. Giữ xref golden_id → (system, source_key) cho audit & un-merge.

Kết quả ước lượng: ~2,1 triệu bản ghi thô hợp nhất còn ~1,45 triệu khách hàng duy nhất (giảm ~31% trùng lặp). Vùng xám cần steward review khoảng 1,8% số cặp. Độ đầy đủ hồ sơ (tỷ lệ khách có đủ email + SĐT + ít nhất một sản phẩm) tăng từ ~54% lên ~89%. Nhờ đó các bài sau — tích hợp dữ liệu, phân khúc, next best action — mới có nền dữ liệu đáng tin.

(Các con số trên là ước lượng minh hoạ để bạn hình dung độ lớn tác động, không phải số liệu công bố.)

Ghi nhớ

• Identity resolution là bài toán khó nhất của Customer 360: một người tồn tại dưới nhiều bản ghi, nhiều định danh, dữ liệu bẩn và thay đổi theo thời gian — không thể chỉ JOIN.
• Pipeline 4 bước: normalize → blocking (giảm số cặp so sánh) → matching → survivorship. Bỏ qua blocking là bất khả thi về tính toán (N²).
• Deterministic vs probabilistic: khớp định danh mạnh (CCCD) thì tất định, auto-merge; thiếu định danh thì tính điểm giống mờ (Jaro-Winkler, Levenshtein, khung Fellegi-Sunter với trọng số log2(m/u)).
• Hai ngưỡng, không một: trên ngưỡng cao thì merge, dưới ngưỡng thấp thì tách, vùng xám đẩy cho data steward. Ngân hàng đặt ngưỡng bảo thủ vì gộp nhầm rất nguy hiểm.
• Golden record = survivorship: chọn giá trị đúng nhất theo nguồn tin cậy / mới nhất / đầy đủ nhất; luôn giữ xref để truy vết và un-merge, không xoá bản ghi nguồn.
• MDM biến việc hợp nhất thành năng lực vận hành liên tục (registry / consolidation / centralized), gắn chặt với chất lượng dữ liệu và stewardship.
• Household & quan hệ là bài toán đồ thị (graph) ở cấp cao hơn cá nhân.
• Rủi ro ngân hàng: gộp nhầm hai người là lỗi nghiêm trọng (lộ dữ liệu, sai tín dụng); dữ liệu nhạy cảm phải tuân thủ quyền riêng tư; mọi quyết định merge cần giải thích được.
• Công cụ ví dụ: MDM thương mại (Informatica, Reltio...) hoặc thư viện (Splink, dedupe, RecordLinkage) — chọn theo quy mô và nhu cầu real-time/stewardship.

Nguồn tham khảo

• Fellegi, I. P., & Sunter, A. B. (1969). "A Theory for Record Linkage." Journal of the American Statistical Association, 64(328), 1183–1210 — bài báo nền tảng của mô hình xác suất m/u cho record linkage.
• Winkler, W. E. (1990). "String Comparator Metrics and Enhanced Decision Rules in the Fellegi-Sunter Model of Record Linkage." Proceedings of the Section on Survey Research Methods, American Statistical Association — nguồn gốc của đo độ giống chuỗi Jaro-Winkler.
• Christen, P. (2012). Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection. Springer — sách tham khảo chuẩn về normalize, blocking, matching, đánh giá.
• Splink Documentation — thư viện record linkage của UK Ministry of Justice, ước lượng tham số Fellegi-Sunter bằng EM, chạy trên Spark/DuckDB.
• dedupe — Documentation và dedupeio/dedupe (GitHub) — thư viện Python dùng active learning để dedup và entity resolution.
• Python Record Linkage Toolkit — bộ công cụ giáo khoa cho indexing (blocking), so sánh và phân loại cặp bản ghi.
• DAMA International — DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.), chương Master Data & Reference Data Management — khung MDM, golden record, survivorship và data stewardship.