AI Data Cleaning: איך מודלי שפה משנים את פני ניקוי הנתונים בפרודקשן

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

מדריך ארכיטקטוני על AI Data Cleaning: זיהוי אנומליות, נרמול טקסט חופשי, השלמת ערכים חסרים באמצעות LLM, ואיפה חייבים עדיין ולידציה דטרמיניסטית.

אנליסט נתונים פותח טבלת Excel של 50 אלף שורות שהתקבלה מספק חיצוני ומגלה תאריכים בשלושה פורמטים שונים, שדה "מדינה" שמכיל גם "ישראל" וגם "IL" וגם "Israel", ועמודת מחיר שבחלק מהשורות מכילה מטבע מעורב. זו מציאות יומיומית בעולם ה-Data Engineering - נתונים גולמיים כמעט אף פעם לא נקיים, וניקוי ידני לא סקיילבילי מעבר לכמה אלפי שורות. Data Cleaning קלאסי נשען על כללים ידניים ורגקסים, אבל הדור החדש - AI Data Cleaning - משתמש במודלי שפה כדי לזהות, לנרמל ולתקן בעיות איכות נתונים בקנה מידה שלא היה אפשרי קודם.

שש קטגוריות בעיות איכות נתונים ש-AI פותר

לפני שבונים Pipeline, כדאי למפות את סוגי הבעיות. Missing Values - ערכים חסרים שדורשים השלמה חכמה על סמך הקשר. Inconsistent Formatting - אותו מידע מיוצג בפורמטים שונים (תאריכים, מספרי טלפון, כתובות). Outliers ו-Anomalies - ערכים חריגים שעלולים להיות שגיאת הזנה או תופעה אמיתית. Semantic Duplicates - ערכים כתובים אחרת שמייצגים אותו דבר ("ת"א" מול "תל אביב"). Structural Errors - שדות שהוזנו בעמודה הלא נכונה. ו-Domain Violations - ערכים שלא עומדים בכללי העסק (גיל שלילי, תאריך עתידי בשדה "תאריך לידה"). לכל קטגוריה יש גישת טיפול שונה, וחלקן מתאימות הרבה יותר לפתרון מבוסס AI מאחרות.

ארכיטקטורת Pipeline: Profile, Detect, Suggest, Apply, Validate

Pipeline בוגר ל-AI Data Cleaning בנוי מחמישה שלבים. שלב ה-Profiling סורק את הנתונים וממפה סטטיסטית כל עמודה - טווח ערכים, פיזור, שיעור ערכים חסרים, ו"טביעת אצבע" של הפורמט. שלב ה-Detection מזהה חריגות ובעיות על סמך הפרופיל - כאן LLM שימושי במיוחד לזיהוי דפוסים סמנטיים ("העמודה הזו אמורה להכיל מספרי טלפון ישראליים אבל 3% מהערכים לא תואמים"). שלב ה-Suggestion מייצר תיקון מוצע לכל בעיה שזוהתה - זה השלב שבו LLM תורם הכי הרבה ערך, כי הוא מסוגל להבין הקשר ("ניו יורק, ארהב" צריך להפוך ל-"New York, USA" בפורמט אחיד). שלב ה-Apply מיישם את התיקונים, ושלב ה-Validation מריץ בדיקות סטטיות אחרי התיקון כדי לוודא שהוא לא יצר בעיה חדשה.

נרמול טקסט חופשי: המקום שבו LLM זורח

המשימה שבה AI Data Cleaning עוקף בבירור גישות קלאסיות היא נרמול טקסט חופשי - כתובות, שמות חברות, תיאורי מוצר. גישה מבוססת רגקס דורשת כתיבת כלל נפרד לכל וריאציה אפשרית, ומתפרקת ברגע שמופיע פורמט לא צפוי. LLM, לעומת זאת, מבין את הכוונה הסמנטית - "רחוב הרצל 5 תל אביב" ו-"הרצל 5, ת"א" מזוהים כאותה כתובת ומנורמלים לאותו פורמט סטנדרטי, בלי שצריך לכתוב כלל מפורש לכל וריאציית כתיב.

Imputation חכם: השלמת ערכים חסרים בהקשר

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

זיהוי אנומליות: שילוב סטטיסטיקה ו-AI

זיהוי חריגים אפקטיבי לא מסתמך רק על LLM - השילוב היעיל ביותר הוא שיטות סטטיסטיות קלאסיות (Z-score, IQR, Isolation Forest) לזיהוי חריגים מספריים מהיר וזול, ו-LLM לזיהוי חריגים סמנטיים שדורשים הבנת הקשר עסקי - למשל זיהוי ששילוב של "מנהל בכיר" עם "שכר התחלתי" בשדה תפקיד ושכר הוא חריג לוגי, למרות ששני הערכים בנפרד נראים תקינים לגמרי מבחינה סטטיסטית.

למה חייבים עדיין שכבת ולידציה דטרמיניסטית

הטעות המסוכנת ביותר ב-AI Data Cleaning היא לתת ל-LLM "יד חופשית" לתקן נתונים בלי גבולות ברורים. מודלי שפה יכולים להזות (Hallucinate) תיקון שנשמע סביר אך שגוי לחלוטין - למשל להשלים מספר טלפון "סביר" שלא באמת שייך ללקוח. לכן ארכיטקטורה נכונה תמיד עוטפת את הצעות ה-LLM בשכבת ולידציה דטרמיניסטית: כללי Regex לבדיקת פורמט, טווחי ערכים חוקיים, וכללי עסק קשיחים שה-AI לא יכול לעקוף. ה-LLM מציע, המערכת הדטרמיניסטית מאשרת או דוחה.

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

הטעות הראשונה היא הרצת תיקוני AI ישירות על נתוני Production בלי Staging ובלי Dry Run - כל תיקון צריך לעבור קודם בסביבת בדיקה עם השוואה "לפני ואחרי" שאדם בודק לפני שהוא מוחל בפועל. הטעות השנייה היא חוסר עקביות - הרצת אותה בקשת ניקוי פעמיים על אותם נתונים עשויה לתת תוצאה מעט שונה בגלל האופי הסטוכסטי של LLM, מה שדורש Temperature נמוך מאוד ובדיקות Regression קבועות. הטעות השלישית היא התעלמות מעלות: הרצת LLM על כל שורה בטבלה של מיליוני רשומות היא יקרה ואיטית - צריך לסנן מראש רק לשורות שבאמת נדרש בהן טיפול AI, ולהשתמש בשיטות זולות (Regex, Lookup Tables) לרוב המקרים הפשוטים.

מתי AI Data Cleaning משתלם

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

מדידת שיפור איכות לאורך זמן

כדי לדעת אם שכבת AI Data Cleaning באמת עובדת, צריך מדד כמותי של איכות נתונים לפני ואחרי - Data Quality Score מורכב שמשלב כמה ממדים: שלמות (אחוז ערכים לא-חסרים), עקביות (אחוז ערכים שעומדים בפורמט התקני), ותקפות (אחוז ערכים שעוברים כללי עסק). ריצה תקופתית של המדד הזה, לצד מעקב אחרי כמות התיקונים שה-AI מציע וכמה מהם מאושרים בפועל על ידי בודק אנושי, נותנת תמונה ברורה האם המערכת משתפרת עם הזמן או שהיא תקועה על אותה רמת דיוק. ירידה פתאומית בשיעור האישורים האנושיים היא איתות מוקדם לבעיה - למשל שינוי בפורמט הנתונים במקור שהמודל לא הותאם אליו.

טיפול בשפות מרובות ובעברית בפרט

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

ניקוי נתונים לפני אימון מודל מול ניקוי בזמן שאילתה

יש הבדל ארכיטקטוני חשוב בין שתי גישות שימוש: ניקוי כ-Pipeline נפרד שרץ פעם (או תקופתית) על כל בסיס הנתונים ושומר את הגרסה הנקייה כתוצר קבוע, לעומת ניקוי 'זריז' (On-the-fly) שמופעל בזמן שאילתה בודדת בלי לשמור את התוצאה. הגישה הראשונה יעילה יותר לנתונים שמשמשים שוב ושוב (טבלאות ליבה במחסן נתונים) כי הניקוי מתבצע פעם אחת ולא בכל שימוש. הגישה השנייה מתאימה לנתונים חד-פעמיים או זמניים - למשל קובץ שהועלה על ידי משתמש לניתוח חד-פעמי - שם אין ערך בשמירת גרסה נקייה קבועה כי הנתונים לא ישמשו שוב.

שילוב עם Great Expectations ומסגרות ולידציה קיימות

מערכות AI Data Cleaning לא צריכות להחליף את מסגרות הולידציה הקיימות בארגון (כמו Great Expectations או dbt tests) אלא להשתלב איתן. תבנית עבודה טובה: הצעות הניקוי של ה-AI נכתבות כ-Expectations פורמליים בתוך אותה מסגרת, כך שכל תיקון עתידי גם הופך אוטומטית לבדיקת רגרסיה שרצה בכל ריצת Pipeline עתידית. זה מונע מצב שבו אותה בעיית איכות מתגלה שוב ושוב על אותם נתונים - ברגע שהיא זוהתה ותוקנה פעם אחת, היא הופכת גם לכלל ולידציה קבוע שתופס אותה מוקדם יותר בפעם הבאה.

סיכום

AI Data Cleaning הוא לא תחליף לתשתית ולידציה קלאסית, אלא שכבה חכמה שנוספת מעליה ומטפלת בדיוק במקרים שכללים סטטיים נכשלים בהם - טקסט חופשי, הקשר סמנטי, ואי-עקביות פורמט. הצלחה בתחום הזה תלויה בבניית לולאת אישור אנושי, ולידציה דטרמיניסטית שעוצרת הזיות, ומדידה מתמדת של איכות ההצעות. בפרויקטי ניקוי נתונים שמדיה דיל בונה, אנחנו תמיד מתחילים ממיפוי מדויק של סוגי הבעיות בנתונים הספציפיים - כי הבחירה הנכונה בין רגקס פשוט ל-LLM יקר היא לרוב ההבדל בין Pipeline יעיל לבין חשבונית API בלתי סבירה.

תגיות: AI Data Cleaning · Data Quality · LLM · Data Imputation · Anomaly Detection · Data Normalization · Data Profiling

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