Tránh lệch khóa thực thể trong Data Lake – Phần 2: Khi khớp mờ (Fuzzy Matching) không còn hiệu quả

Khi xử lý các mã định danh bị sai lệch, hầu hết kỹ sư dữ liệu thường chọn giải pháp quen thuộc: dùng một độ đo khoảng cách chỉnh sửa, đặt ngưỡng phù hợp và gộp các bản ghi có độ tương đồng đủ cao. Tuy nhiên, trong loạt bài về lệch khóa thực thể (entity key drift), tác giả đã chứng minh rằng cách tiếp cận này không chỉ thiếu an toàn mà còn có thể gây ra những sai lầm nghiêm trọng khi áp dụng vào mã thiết bị ngắn.

Kết quả đo lường với 719 trạm quan trắc môi trường cho thấy không có bất kỳ thuật toán khớp mờ nào có thể tách biệt hoàn toàn lỗi gõ chính tả khỏi các sản phẩm khác nhau. Hậu quả là toàn bộ kiến trúc phải chuyển sang hướng tiếp cận an toàn hơn: chỉ tự động gộp khi chuẩn hóa chứng minh được sự giống nhau, và mọi trường hợp còn lại đều chuyển cho con người xem xét với lớp nhãn có hiệu lực theo thời gian.

Vấn đề nền tảng: Khoảng cách chỉnh sửa và mã sản phẩm thực

Damerau-Levenshtein (D-L) là lựa chọn phổ biến để xử lý lỗi chính tả vì nó coi việc đảo vị trí hai ký tự chỉ là một lỗi duy nhất — ví dụ sds1001 và sds011 có điểm số là 1. Điều này phản ánh chính xác cách con người gõ sai. Tuy nhiên, chính đặc tính này lại trở thành con dao hai lưỡi.

Ví dụ điển hình: hdc1008 và hdc1080 là hai cảm biến độ ẩm thực sự khác nhau của Texas Instruments. D-L chấm cặp này chỉ 1 điểm — ngang bằng với một lỗi gõ chính tả thông thường.

Điều này khác hoàn toàn với khớp tên người (name matching), nơi mà tiền tố chia sẻ là bằng chứng cho thấy cùng một người. Mã thiết bị như bme280 và bmp280 chia sẻ 5/6 ký tự nhưng lại là hai sản phẩm riêng biệt. Thiết bị đo lường thường được nhà sản xuất đánh số có chủ đích để phân biệt, điều mà thuật toán mờ không thể hiểu được.

Đo lường với năm thuật toán khác nhau

Tác giả đã xây dựng một bộ dữ liệu gốc (ground truth) bằng cách thủ công tra cứu datasheet từ nhà sản xuất cho 16 mã chuỗi khác nhau, thu được 10 cặp để chấm điểm: 3 cặp lỗi chính tả và 7 cặp sản phẩm thực. Kết quả kiểm tra với cả năm thuật toán — edit distance, D-L, Jaro-Winkler, q-gram Jaccard và bộ khớp hai giai đoạn — đều cho thấy một thất bại nghiêm trọng.

So sánh kết quả của các thuật toán khớp mờ

Kết quả không có một thuật toán nào tách được hai nhóm: khi đặt ngưỡng đủ lỏng để bắt hết 3 lỗi chính tả, các thuật toán cũng gộp vào từ 1 đến 7 cặp sản phẩm khác nhau. Cặp hdc1008/hdc1080 đánh bại mọi thuật toán — với Jaro-Winkler nó đạt điểm 0.971, thậm chí cao hơn cả lỗi chính tả thật (0.963).

Bảng 1. Kết quả chấm điểm từng cặp với cả năm thuật toán. Bold đánh dấu cặp quyết định thất bại của toàn bộ nhóm thuật toán. Nguồn: tác giả.

Vì sao thuật toán thứ sáu không cứu được tình hình

Điểm mấu chốt không nằm ở việc lựa chọn thuật toán nào cho hợp lý. Thậm chí nếu tìm được một thuật toán hoạt động tốt trên bộ dữ liệu này, nó vẫn sẽ thất bại vì một lý do cấu trúc sâu xa hơn: sự thật quyết định danh tính của một mã không hề nằm trong bản thân chuỗi ký tự, mà nằm trong danh mục sản phẩm của nhà sản xuất — một nguồn dữ liệu bên ngoài và thay đổi theo thời gian.

Một ví dụ sinh động: nếu Bosch phát hành BMP200 vào năm sau, mối quan hệ giữa bmp280 và bmp200 sẽ lập tức chuyển từ "lỗi chính tả" sang "hai sản phẩm khác nhau" mà không có một byte nào trong chuỗi thay đổi. Không có hàm toán học nào trên hai chuỗi ký tự có thể đọc được danh mục của nhà sản xuất.

Lịch sử số lượng khóa mới xuất hiện theo năm

Ngay cả mô hình học máy (learned matching) cũng không giải quyết được vấn đề. Những nghiên cứu như Magellan (2016) hay Ditto (2020) đều giả định có dữ liệu huấn luyện được gán nhãn, nhưng nếu dữ liệu huấn luyện đó lấy từ chính danh mục nhà sản xuất thì khác gì việc xây dựng kiến trúc thủ công — chỉ là kém minh bạch hơn và không có dấu vết kiểm toán.

Kiến trúc sống sót sau thất bại

Sau khi loại bỏ hoàn toàn phương án khớp tự động, kiến trúc cuối cùng bao gồm các nguyên tắc sau:

1. Chỉ gộp những gì chuẩn hóa chứng minh được giống nhau. Bước 1 đã làm điều này: từ 114 khóa giảm xuống 99 với rủi ro bằng không.

2. Khớp mờ tự động bị loại bỏ vì bằng chứng, không phải vì sự thận trọng. Thông tin cần thiết để đưa ra quyết định là không tồn tại trong chuỗi ký tự.

3. Mọi trường hợp còn lại chuyển cho con người, người có thể tham khảo danh mục nhà sản xuất — thứ mà chuỗi ký tự không mang theo. Quyết định này được lưu dưới dạng nhãn và áp dụng tại thời điểm truy vấn, để danh tính trong dữ liệu vẫn là một hàm thuần túy của những gì thực sự quan sát được.

Lớp nhãn: Ba yêu cầu bất biến

Để hệ thống vận hành ổn định, lớp nhãn phải đáp ứng ba điều kiện nghiêm ngặt:

Nhãn phải có hiệu lực theo ngày (effective-dated)

Việc một mã có phải là sản phẩm thực hay không thay đổi theo thời gian. Từ năm này qua năm khác, danh mục liên tục có thêm khóa mới — trong dữ liệu quan sát, 15 khóa mới xuất hiện ở năm đầu và 3 ở năm cuối. Nếu chỉnh sửa nhãn tại chỗ, bạn sẽ âm thầm nhóm lại toàn bộ lịch sử, khiến các báo cáo tổng hợp từ quý trước không thể tái tạo được.

Nhãn không bao giờ quay lại làm tín hiệu huấn luyện cho thuật toán

Ba lý do riêng biệt: (1) danh tính cần duy trì là hàm của nội dung bản ghi, không phải lịch sử xử lý; (2) hệ thống cần có khả năng giải thích trong kiểm toán; (3) một hệ thống tự tiêu thụ nhãn của chính mình chẳng khác gì tự xây dựng mô hình học máy vốn đã bị loại bỏ.

Nhãn cũng là dữ liệu — và dữ liệu sẽ trôi dạt

Trớ trêu thay, lớp nhãn được tạo ra để chống trôi dạt lại có thể tự gây ra trôi dạt. Do đó, nhãn phải từ một từ vựng có kiểm soát, được chuẩn hóa bằng chính hàm xử lý ở Bước 1, và phải ghi lại ai đã quyết định, khi nào, dựa trên bằng chứng gì. Tác giả thừa nhận chính mình đã vi phạm nguyên tắc này ngay khi đang viết bài — đổi nhãn thành "CONFIRMED REAL, PART NAME CORRECTED" đã khiến một hàng dữ liệu biến mất khỏi tập hợp hợp lệ chỉ sau 4 giờ.

Chi phí thực của việc chuyển cho con người

Việc chuyển toàn bộ cho con người nghe có vẻ tốn kém, nhưng kết quả đo lường lại cho thấy điều ngược lại. So sánh toàn bộ 99 cặp khóa tạo ra 4.851 cặp tiềm năng, nhưng sau khi áp dụng kỹ thuật chặn (blocking), con số giảm xuống còn 30 cặp — chỉ 0.62% không gian — và sau lượt đầu tiên, chỉ có khoảng 4 cặp mới mỗi năm cần xem xét.

Bảng 2. Các quy tắc chặn được đo lường với ba lỗi chính tả đã xác minh. Ba quy tắc rẻ hơn đều bỏ sót một lỗi thật. Nguồn: tác giả.

Tuy nhiên, cạm bẫy nguy hiểm nhất nằm ở việc tối ưu hóa theo khối lượng (volume triage). Lọc bớt các cặp chỉ có ít quan sát để giảm khối lượng việc từ 30 xuống 6 nghe có vẻ hợp lý, nhưng nó cũng loại bỏ toàn bộ 3 lỗi chính tả đã xác nhận. Lỗi chính tả vốn hiếm — đó là bản chất của chúng — nên bất kỳ bộ lọc tần suất nào cũng sẽ tự động xóa đi chính quần thể bạn đang tìm kiếm.

Giới hạn trung thực của kiến trúc

Kiến trúc này không giải quyết được mọi vấn đề. Vấn đề bí danh (alias) — khi cùng một sản phẩm có hai tên hoàn toàn khác nhau như dht22 và AM2302 — nằm ngoài tầm với của mọi quy tắc chặn dựa trên khoảng cách chuỗi. Hai chuỗi này không chia sẻ một ký tự nào, nên chúng không bao giờ xuất hiện trong cùng một nhóm để con người xem xét. Đây là một khiếm khuyết có thật mà kiến trúc này phải chấp nhận — nó từ chối đoán mò, nhưng điều đó không có nghĩa là công việc đã hoàn thành.

Sáu bài học quan trọng nhất

1. Xây dựng dữ liệu gốc từ bên ngoài dữ liệu, trước khi chấm điểm. Phân loại sau khi chấm điểm sẽ khiến bạn vô tình phân loại theo kết quả.

2. Thuật toán tinh vi hơn lại nguy hiểm hơn. Khả năng nhận biết đảo chữ của D-L chính là thứ mà các dòng sản phẩm thực lợi dụng, vì nhà sản xuất thường đánh số sản phẩm liên quan bằng cách hoán vị một chữ số.

3. Với mã chữ-số ngắn, yếu tố quyết định nằm ngoài chuỗi ký tự. Một danh mục từ nhà sản xuất — bên ngoài, thay đổi theo thời gian — mới là nơi giải quyết mọi tranh chấp.

4. Bộ lọc tần suất có xu hướng xóa đi đúng nhóm hiếm bạn đang tìm. Lỗi chính tả hiếm, nên việc lọc theo khối lượng là cái bẫy chứ không phải đường tắt.

5. Gán ngày hiệu lực cho nhãn; đừng sửa ngược lịch sử. Giá phải trả là mọi người dùng hạ nguồn phải cung cấp tham số thời gian khi truy vấn.

6. Sản phẩm cuối cùng không phải dữ liệu đã sửa, mà là sự chắc chắn rằng dữ liệu đúng. Quy trình rà soát chỉ di chuyển 5 quan sát trên 4.301, nhưng đã đưa 56% dữ liệu từ trạng thái "có thể phân mảnh" sang "xác minh là nguyên vẹn".

Tóm tắt và hướng tiếp theo

Bộ khớp (matcher) ban đầu được xây dựng để hoàn thành những gì chuẩn hóa còn bỏ dở, nhưng kết quả đo lường cho thấy nó không thể tồn tại dưới dạng an toàn. Năm thuật toán khác nhau đều chồng chéo khi đối chiếu với thực tế đã xác minh, và một cặp linh kiện TI có thật trông giống lỗi chính tả hơn cả lỗi chính tả thực. Kiến trúc còn lại: chỉ tự động gộp khi chuẩn hóa chứng minh được an toàn, cộng với lớp nhãn do con người xem xét, có hiệu lực theo ngày và hoàn toàn nằm ngoài mô hình — với chi phí 30 cặp ban đầu và khoảng 4 cặp mỗi năm sau đó.

Phần 3 sẽ đề cập đến nhịp động và lọc nhiễu — tốc độ các mã định danh mới xuất hiện cần được đánh giá. Phần 4 nói về lưu trữ khả biến và snapshot bất biến, nơi nhãn có phiên bản gặp gỡ dữ liệu đã niêm phong.

Mã nguồn tham khảo có tên anchorkey, được cấp phép Apache-2.0, nằm dưới các tầng nhận dạng thiết bị như Eclipse Ditto và Eclipse Hono. Nếu bạn đã từng đối mặt với vấn đề này trong pipeline của mình — đặc biệt nếu bạn tìm được một thuật toán khớp hiệu quả cho mã ngắn — tác giả rất mong được lắng nghe kinh nghiệm của bạn.