Entity Resolution באמצעות AI: מעבר מכללים סטטיים להבנה סמנטית

מאת צוות מדיה דיל · 02.08.2026 · Data Engineering · 9 דק׳

איך מודלי שפה ו-Embeddings משנים את פני ה-Entity Resolution הקלאסי: מבנה Pipeline מודרני, Blocking בקנה מידה, ואיפה AI תורם ואיפה הוא עדיין מסוכן.

מערכת מלאי של רשת קמעונאית מכילה את הרשומות "מקרר Samsung RT38" ו-"מקרר סמסונג דגם RT-38 לבן" כשני מוצרים נפרדים לגמרי, כי אין ביניהם התאמת מחרוזת מדויקת. זו בעיית Entity Resolution קלאסית - הזיהוי שרשומות שונות במבנה, בשפה או בפורמט מייצגות בפועל את אותה ישות בעולם האמיתי. הבעיה הזו קיימת עשרות שנים בעולם מסדי הנתונים, אבל הכניסה של מודלי שפה גדולים ומודלי Embedding שינתה מהותית את הארכיטקטורה של הפתרון - ומאפשרת לתפוס דמיון סמנטי במקום רק דמיון מילולי.

מבנה Pipeline קלאסי: Blocking, Matching, Clustering

לפני שמדברים על AI, חשוב להבין את שלד ה-Pipeline שכל מערכת Entity Resolution בנויה עליו. שלב ה-Blocking הוא קריטי מבחינת ביצועים: השוואת כל רשומה מול כל רשומה אחרת היא בעיה בסיבוכיות O(n²), שלא ישימה כשיש מיליוני רשומות. Blocking מחלק את הרשומות לקבוצות (Blocks) על סמך מפתח משותף גס - למשל שלוש האותיות הראשונות של השם, או קוד מיקוד - ומשווה רק בתוך כל קבוצה. שלב ה-Matching מחשב ציון דמיון בין זוגות בתוך אותו Block. שלב ה-Clustering מקבץ את כל הרשומות שהתאימו זו לזו (ישירות או דרך שרשרת התאמות) לכדי Cluster אחד שמייצג ישות בודדת.

איפה בדיוק AI נכנס לתמונה

מודלי Embedding כמו sentence-transformers או מודלים דומים ממירים כל תיאור טקסטואלי לוקטור במרחב רב-ממדי, כך שתיאורים דומים סמנטית מקבלים וקטורים קרובים - גם בלי חפיפת מילים ישירה. "מקרר Samsung RT38" ו-"מקרר סמסונג דגם RT-38" יקבלו וקטורים קרובים מאוד למרות ההבדל בפורמט. זה פותר בעיה שאלגוריתמי דמיון מחרוזות קלאסיים (Levenshtein, Jaccard) פשוט לא מסוגלים לתפוס - כי הם עובדים ברמת התו ולא ברמת המשמעות.

יתרון נוסף הוא ש-Embedding נותן פתרון חינם גם ל-Blocking: במקום מפתח בלוקינג ידני, אפשר להשתמש ב-Approximate Nearest Neighbor Search (ANN, למשל דרך FAISS או HNSW) כדי למצוא במהירות את השכנים הקרובים ביותר לכל וקטור, מה שמחליף לוגיקת Blocking מסורבלת בשכבת אינדוקס וקטורי יעילה בהרבה, ומצליח לתפוס גם דמיונות שכללי בלוקינג ידניים היו מפספסים.

LLM כשופט (LLM-as-Judge) להתאמות גבוליות

גם עם Embedding מדויק, יש תמיד אזור אפור - זוגות רשומות עם ציון דמיון בינוני שקשה להכריע עליהם אוטומטית. כאן נכנס שימוש נוסף ל-LLM: הצגת שני התיאורים המלאים למודל שפה עם פרומפט ממוקד ("האם שתי הרשומות הבאות מתארות את אותו מוצר בעולם האמיתי? נמק בקצרה") ושימוש בתשובה כשכבת החלטה נוספת. הגישה הזו יקרה יותר מחישוב Embedding (כי דורשת קריאת API בזמן ריצה לכל זוג גבולי) אבל מספקת גם הסבר קריא לאדם - יתרון גדול לצורך אודיט ו-Trust בתהליך.

Schema Alignment: כשהמקורות מדברים שפות שונות

בעיה נפרדת אבל קשורה היא שרשומות ממקורות שונים לא רק כתובות אחרת - הן גם מובנות אחרת. מקור אחד שומר "שם פרטי" ו"שם משפחה" בשני שדות, מקור אחר שומר "שם מלא" בשדה בודד. לפני שאפשר בכלל להשוות רשומות, צריך ליישר את הסכמה (Schema Alignment). מודלי שפה עוזרים גם כאן - הם יכולים להסיק אוטומטית מיפוי בין שדות על סמך שמות העמודות והדגימות שלהן, מה שחוסך עבודה ידנית ארוכה בכל פעם שמתווסף מקור נתונים חדש. עם זאת, מדובר בהצעה ראשונית בלבד שדורשת אישור אנושי - טעות במיפוי סכמה מתפשטת לכל רשומה שעוברת בצנרת.

עלות וביצועים: איפה AI לא כדאי

שימוש ב-LLM לכל זוג רשומות פוטנציאלי הוא יקר ואיטי מדי לקנה מידה גדול. ארכיטקטורה נכונה משתמשת ב-AI במשורה: Embedding לשלב ה-Blocking וה-Matching הראשוני (זול, מהיר, ניתן להרצה במקביל), ו-LLM-as-Judge רק לאחוזים בודדים של המקרים הגבוליים ביותר שבאמת דורשים שיקול דעת. ניסיון להריץ LLM על כל צמד אפשרי בסט נתונים של מיליוני רשומות הוא טעות תכנון קלאסית שמייצרת חשבונית API בלתי סבירה ו-Latency שלא עומד ב-SLA.

טעויות נפוצות בפרודקשן

הטעות הראשונה היא לסמוך על Embedding בלי לבחון את איכותו על נתוני הדומיין הספציפי - מודל Embedding כללי שאומן על טקסט אנגלי כללי לא בהכרח יודע להבדיל בין שני דגמי מוצר טכניים שדומים מאוד מילולית אך שונים מהותית. פתרון נפוץ הוא Fine-tuning קל של מודל ה-Embedding על זוגות דוגמה מתויגים מהדומיין. הטעות השנייה היא הזנחת Threshold Calibration - סף ההחלטה בין "התאמה" ל"לא התאמה" צריך כיול מחדש בכל פעם שמשנים מודל או מקור נתונים, אחרת מצטברים False Positives או False Negatives בשקט. הטעות השלישית היא היעדר לולאת Feedback - Data Stewards שמתקנים החלטות שגויות צריכים שהתיקון שלהם יחזור למערכת כדוגמאות אימון, אחרת אותה טעות חוזרת שוב ושוב.

מתי כדאי AI-based Entity Resolution ומתי מספיקים כללים

כשמדובר בנתונים מובנים היטב עם שדות מזהים ברורים (למשל מספרי קטלוג עקביים), כללים דטרמיניסטיים פשוטים עדיין הכי מהירים והכי זולים - אין צורך ב-AI. AI-based Entity Resolution מוכיח את עצמו כשהנתונים מגיעים בשפה חופשית, בפורמטים לא עקביים, או ממקורות רבים עם מוסכמות שונות - למשל איחוד קטלוג מוצרים מכמה ספקים, או ניקוי בסיס נתוני לידים ממקורות שיווק מגוונים.

הערכת ביצועים: מדדים שצריך לעקוב אחריהם

הערכת מערכת Entity Resolution דורשת יותר ממדד דיוק כללי. Precision מודד כמה מההתאמות שהמערכת הצהירה עליהן נכונות בפועל; Recall מודד כמה מההתאמות האמיתיות הקיימות בנתונים אכן זוהו. ב-Entity Resolution יש גם מדד ייחודי חשוב - Cluster Purity, שבודק האם כל אשכול שנוצר מכיל אך ורק רשומות של אותה ישות אמיתית, בלי "זיהום" מרשומות של ישויות אחרות שהצטרפו בטעות. בניית סט Ground Truth מתויג ידנית (לפחות כמה מאות זוגות) היא השקעה הכרחית לפני פריסה לפרודקשן - בלעדיה אין דרך אמיתית למדוד האם שינוי במודל או בסף שיפר או פגע בביצועים.

קנה מידה תעשייתי: מיליארדי רשומות

כשמדובר בקנה מידה תעשייתי אמיתי - קטלוגי מוצרים גלובליים, רישומי בריאות, מאגרי זהות ממשלתיים - אפילו Blocking עם Embedding לא מספיק לבדו. פתרונות בקנה מידה כזה משתמשים בארכיטקטורת Sharding שמפזרת את הבעיה על פני אשכול מחשבים, כאשר כל Shard אחראי לתת-קבוצה של הנתונים (למשל לפי אזור גיאוגרפי או קטגוריית מוצר), ומריצה Entity Resolution פנימי במקביל. שלב נוסף, Cross-shard Reconciliation, מטפל במקרים הגבוליים שבהם ישות אחת מפוצלת בין Shards שונים - זה מוסיף מורכבות הנדסית משמעותית אך הכרחי כדי לשמור על זמני עיבוד סבירים כשמדובר בכמויות נתונים שלא נכנסות לזיכרון מחשב בודד.

Active Learning: איך לשפר את המודל עם פחות תיוג ידני

תיוג ידני של זוגות רשומות לצורכי אימון או הערכה הוא יקר ואיטי - מומחה דומיין צריך לבחון כל זוג ולהחליט אם מדובר בהתאמה. גישת Active Learning מייעלת את התהליך: במקום לבחור זוגות אקראיים לתיוג, המערכת בוחרת באופן אקטיבי את הזוגות שהמודל הכי לא בטוח לגביהם (ציון דמיון קרוב לסף ההחלטה), ומבקשת תיוג אנושי רק עליהם. כל תיוג כזה משפר את המודל הרבה יותר מתיוג אקראי, כי הוא ממוקד בדיוק במקום שבו המודל הכי זקוק לעזרה. בפרויקטים בפועל, Active Learning מצליח להגיע לאותה רמת דיוק עם עשירית מכמות התיוג הידני הדרושה בגישה אקראית - חיסכון משמעותי בזמן ובעלות.

שילוב Entity Resolution בתהליכי אינטגרציה שוטפים

Entity Resolution לא אמור להיות ריצה חד-פעמית שמתבצעת פעם בפרויקט - הוא צריך להיות שלב קבוע בכל צנרת אינטגרציה שמכניסה נתונים חדשים מספקים או שותפים. הדרך הנכונה ליישם זאת היא כשלב בדיקה אוטומטי (Gate) בתוך ה-CI/CD Pipeline של הנתונים עצמו: כל אצווה חדשה עוברת דרך מנוע ה-Entity Resolution לפני שהיא נכנסת למחסן הנתונים הראשי, וכל רשומה עם ציון ביטחון נמוך נשלחת אוטומטית לתור בדיקה אנושית במקום להיכנס ישירות ולזהם את בסיס הנתונים.

סיכום

Entity Resolution מבוסס AI לא מחליף את שלד ה-Pipeline הקלאסי - Blocking, Matching, Clustering - אלא משדרג כל שלב בו עם הבנה סמנטית עמוקה יותר. הארכיטקטורה הנכונה משלבת Embedding מהיר וזול לרוב המקרים, ו-LLM יקר יותר רק למקרי הקצה הגבוליים שבאמת דורשים שיקול דעת. בפרויקטים שמדיה דיל בונה בתחום הזה, אנחנו רואים שוב ושוב שההבדל בין הצלחה לכישלון הוא לא בחירת המודל הכי מתקדם, אלא בבניית לולאת Feedback שממשיכה לשפר את הדיוק לאורך זמן.

תגיות: Entity Resolution · AI Matching · Embeddings · LLM-as-Judge · Blocking · Schema Alignment · Data Deduplication

← חזרה לבלוג · צור קשר