بحران هویت داده: مشتریت یک نفره یا سه نفر؟
هوش مصنوعیخلاصهٔ کاملتر
نویسنده، Sonal Goyal (بنیانگذار پروژهٔ متنباز Zingg.AI)، میگه یه جملهٔ Animesh Kumar وادارش کرده این مقاله رو بنویسه: چکهای کیفیت محلی از یکپارچگی یه محصول داده مراقبت میکنن، ولی هیچ تضمینی برای یکپارچگی کل سیستمی که اون محصول توش شرکت میکنه نمیدن. به گفتهٔ نویسنده، همینجاست که بیشتر تیمها گیر میکنن: محصولاتشون همهی تستهای محلی رو پاس میکنن، ولی بعد میفهمن محصول مشتری و محصول تراکنش سرِ اینکه یه آدم کیه با هم اختلاف دارن.
ریشهٔ مشکل به چیزی برمیگرده که نویسنده اسمش رو بحران هویت میذاره: قبل از اینکه محصولات روی داده ساخته بشن، هیچوقت این سؤال حل نشده که هر رکورد دقیقاً به کی یا چی اشاره میکنه. مثالهاش هم واقعیان؛ یه نفر بعد از طلاق اسم فامیلش رو تو دو سیستم عوض میکنه ولی تو چهار تای دیگه نه، یا یه ایمیل شخصی و یه ایمیل کاری میتونن مال یه نفر باشن یا دو نفر کاملاً جدا. نویسنده تأکید میکنه که این فقط حذف رکوردهای تکراری تو دیتابیس نیست؛ یه مسئلهٔ استنتاج احتمالاتی بین سیستمهای مختلفه، اونم روی صدها میلیون رکورد که مقایسهٔ همه با همه بهخاطر رشد O(n²) عملاً غیرممکنه.
نویسنده معتقده این کار باید داخل خودِ دیتاواروس یا lakehouse اجرا بشه، نه یه سیستم بیرونی. دلیلش هم اینه که جابهجا کردن میلیاردها رکورد به بیرون و برگردوندن نتیجه، هم گرانش داده رو نقض میکنه، هم بین رسیدن رکورد جدید و کاملشدن تشخیص، تأخیر میسازه، هم مجبوری کنترل دسترسی و لاگ و رمزنگاریای که وارهاوس داره رو دوباره از صفر بسازی.
معماریای که تو این مقاله پیشنهاد میشه سه لایه داره. اول بلاکبندی (blocking) که با کلیدهای سبک مثل کدگذاری آواییِ اسمها فضای مقایسه رو خیلی کوچیک میکنه؛ چند پاس با کلیدهای مختلف لازمه تا رکوردهایی که فقط یه غلط تایپی فاصله دارن هم کنار هم بیان. دوم تطبیق (matching) که برای هر جفت کاندیدا احتمال یکیبودنشون رو امتیاز میده؛ نویسنده میگه ترکیب قانونمحور (برای سیگنالهای قطعی مثل ایمیل دقیق یا شمارهی حساب) و یادگیری ماشین (برای موارد مبهم) بهتر از انتخاب فقط یکیه. سوم خوشهبندی (clustering) که امتیازهای جفتی رو به گروههای منسجم تبدیل میکنه و رویدادهای سختی مثل جدا کردن یه خوشهٔ اشتباهادغامشده رو مدیریت میکنه.
نویسنده میگه خودکارسازیِ کامل تو عمل میشکنه و آدمِ ناظر (human-in-the-loop) لازمه؛ ولی نه بهخاطر نبودِ بازبینی، بلکه بهخاطر طراحی درستش: کیفیت جفتهای آموزشی، تنظیم آستانهها بر اساس هزینهٔ واقعی خطا، جریان کاری برای دادن موارد کماطمینان به بازبینها، و قابلیت audit و override. آخر هم دو نمونهٔ واقعی میآره: فروشگاه ۳۰۰سالهٔ Fortnum & Mason و سازمان Orthodox Union که با اجرای تشخیص موجودیتِ مبتنی بر ML داخل وارهاوس تونستن دیدِ یکپارچهای از مشتری بسازن. جمعبندی نویسنده اینه که این کار نامرئی و بیزرقوبرقه، ولی همون پایهایه که همهی چیزهای روش رو ممکن میکنه.
نکات کلیدی:
- مشکل پنهون بیشتر استکهای داده اینه که هیچوقت مشخص نشده هر رکورد به کی اشاره میکنه
- تشخیص موجودیت (entity resolution) یه مسئلهٔ استنتاج احتمالاتی بین سیستمهاست، نه فقط حذف رکورد تکراری
- این کار باید داخل خودِ دیتاواروس اجرا بشه تا گرانش داده، تأخیر و تکرار حاکمیت پیش نیاد
- معماری سهلایه: بلاکبندی، تطبیق (ترکیب قانون + یادگیری ماشین)، و خوشهبندی
- خودکارسازیِ کامل جواب نمیده؛ آدمِ ناظر باید دقیقاً جایی باشه که تصمیمش نتیجه رو عوض میکنه
