Data Transformation באמצעות LLM: מייצור כללים ידניים ליצירת קוד אוטומטית

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

מדריך טכני על שימוש ב-LLM לבניית שכבת טרנספורמציית נתונים: יצירת קוד dbt/SQL אוטומטית, Prompt Engineering לטרנספורמציות, ולמה בדיקות עדיין הכרחיות.

אנליסט נתונים צריך להמיר עמודת "כתובת מלאה" בשפה חופשית לשלוש עמודות נפרדות - רחוב, עיר, מיקוד - עבור 40 טבלאות שונות במחסן הנתונים, כל אחת עם דפוסי כתיבה קצת אחרים. כתיבת לוגיקת Parsing ידנית לכל טבלה היא עבודה משעממת וארוכה. Data Transformation באמצעות LLM מציע גישה שונה לגמרי: תיאור המשימה בשפה טבעית, וקבלת קוד טרנספורמציה (SQL, dbt model, פונקציית Python) שמבצע אותה - כאשר האדם נשאר בעל הבית על הקוד הסופי, לא רק על ההגדרה המילולית.

שני מודלים שונים לשימוש ב-LLM בטרנספורמציה

יש שתי גישות עיקריות, וההבדל ביניהן קריטי. הגישה הראשונה, Code Generation, משתמשת ב-LLM כדי לייצר קוד טרנספורמציה סטטי - שאילתת SQL, מודל dbt, פונקציית Python - שנבדק, נכנס ל-Version Control, ורץ שוב ושוב ב-Production בלי תלות נוספת ב-LLM. הגישה השנייה, Inference-time Transformation, מפעילה את ה-LLM בזמן ריצה על כל שורה או batch - הטרנספורמציה עצמה היא קריאת API בזמן אמת. הגישה הראשונה זולה, מהירה, וצפויה - אידיאלית לטרנספורמציות שהלוגיקה שלהן ברורה ויציבה. הגישה השנייה גמישה יותר אבל יקרה ואיטית משמעותית, ומתאימה בעיקר למקרים שבהם הלוגיקה עצמה משתנה מרשומה לרשומה בצורה שקשה לתמצת לכלל קבוע.

Code Generation בפועל: מפרומפט לקוד dbt נבדק

ה-Workflow המומלץ מתחיל בתיאור בשפה טבעית של הטרנספורמציה הרצויה, כולל דוגמאות קלט-פלט קונקרטיות (Few-shot Examples) - זה משפר דרמטית את דיוק הקוד שנוצר לעומת תיאור מילולי בלבד. ה-LLM מייצר קוד ראשוני, שרץ מיד על סט דגימה קטן ומוצג לבודק אנושי בהשוואת "לפני ואחרי". רק אחרי אישור, הקוד נכנס ל-Pull Request רגיל שעובר Code Review כמו כל שינוי קוד אחר בצוות - כולל בדיקות אוטומטיות. הנקודה החשובה: הקוד שנוצר הוא Artifact קבוע וגלוי, לא קופסה שחורה שרצה בזמן אמת. זה מה שמאפשר לצוותי הנדסה לסמוך על הפתרון בטווח הארוך.

Prompt Engineering לטרנספורמציות נתונים

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

טרנספורמציות מורכבות: פירוק לשלבים

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

אימות ובדיקות: הכרחי, לא אופציונלי

קוד שנוצר על ידי LLM חייב לעבור את אותה רמת בדיקות כמו קוד שנכתב ידנית - ואולי אפילו רמה גבוהה יותר, כי הוא לא נכתב על ידי מי שמכיר את כל היסטוריית הנתונים. בדיקות Unit על מקרי קצה ידועים, בדיקות Regression שמריצות את הטרנספורמציה על נתוני Production היסטוריים ומשוות לתוצאה הצפויה, ובדיקות Data Quality שרצות אחרי כל ריצה בפרודקשן (בדיקת טווחי ערכים, שיעור null, עקביות סכמה) - כל אלה חייבים להיות חלק אינטגרלי מה-Pipeline, לא תוספת אופציונלית.

עלות וביצועים: מתי Inference-time מוצדק

למרות היתרון של Code Generation, יש מקרים שבהם Inference-time Transformation אכן נחוץ - בעיקר כשהלוגיקה עצמה דורשת הבנה עמוקה שקשה לתמצת לכלל: למשל סיווג טקסט חופשי לקטגוריה על סמך משמעות (לא מילות מפתח), או תרגום בין שפות. במקרים כאלה, מומלץ להשתמש במודל קטן וזול ככל האפשר שמספיק למשימה, להריץ Batch Inference (לא קריאה אחת לכל שורה) לחיסכון בעלות, ולשמור Cache של תוצאות עבור ערכי קלט חוזרים.

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

הטעות הראשונה היא הרצת Inference-time Transformation על כל שורה בלי Caching - אם אותו ערך קלט חוזר על עצמו (למשל שם מדינה), אין סיבה לקרוא ל-LLM בכל פעם מחדש. הטעות השנייה היא היעדר Fallback - כשקריאת ה-LLM נכשלת (Timeout, Rate Limit), ה-Pipeline חייב מנגנון נפילה מסודר (Retry עם Backoff, או דילוג עם סימון לטיפול מאוחר יותר) ולא קריסה של כל האצווה. הטעות השלישית היא לא לנעול את גרסת המודל - טרנספורמציה שהתבססה על גרסת מודל מסוימת עלולה להתנהג אחרת כשהספק משדרג את המודל בשקט, ולכן חשוב לנעול גרסה ולבדוק מחדש לפני שדרוג מכוון.

מתי להשתמש ב-LLM לטרנספורמציה ומתי לא

Code Generation מבוסס LLM משתלם מאוד בשלב הפיתוח - הוא מקצר משמעותית את הזמן מכתיבת מפרט ידני לקוד עובד. Inference-time Transformation מוצדק רק כשהלוגיקה דורשת הבנה סמנטית עמוקה שאי אפשר לתמצת. לטרנספורמציות פשוטות וידועות מראש (המרת יחידות, פורמט תאריך סטנדרטי), כתיבת קוד ידני נשארת מהירה, זולה וצפויה יותר מכל גישת AI.

אינטגרציה עם dbt ותשתיות Transformation קיימות

רוב צוותי Data Engineering מודרניים כבר עובדים עם dbt (data build tool) לניהול טרנספורמציות SQL כקוד גרסאתי. שילוב LLM בתוך זרימת העבודה הזו לא דורש מהפכה - הוא נכנס כתוסף בתהליך הפיתוח: מהנדס כותב תיאור מודל dbt חדש בשפה טבעית, ה-LLM מייצר את קובץ ה-SQL הראשוני כולל Tests ו-Documentation Comments בפורמט dbt הסטנדרטי, והמהנדס ממשיך משם עם עריכה ואישור רגילים. היתרון המרכזי הוא שהפלט נשאר בתוך אותה מסגרת עבודה מוכרת - Git, CI/CD, dbt Cloud - ולא דורש כלי נפרד שהצוות צריך ללמוד.

טרנספורמציות דו-כיווניות: מבנה לטקסט וטקסט למבנה

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

בדיקות רגרסיה אוטומטיות לקוד שנוצר על ידי LLM

קוד טרנספורמציה שנוצר על ידי LLM צריך סוויטת בדיקות מקיפה יותר מקוד רגיל, כי אין למי שכתב אותו הבנה עמוקה של כל היסטוריית הנתונים והחלטות עיצוב קודמות. גישה מומלצת: יצירת בדיקות Golden Dataset - קבוצת דוגמאות קלט-פלט ידועות ומאושרות שנשמרות ב-Version Control לצד הקוד עצמו, ורצות בכל Pull Request. כל שינוי עתידי בטרנספורמציה - בין אם נוצר שוב על ידי LLM או נערך ידנית - חייב לעבור את כל הבדיקות בסט הזה לפני מיזוג. זה מוודא שקוד שנוצר על ידי מודל שפה לא רק 'נראה נכון' על דגימה חד-פעמית, אלא באמת שומר על נכונות לאורך זמן ולאורך שינויים עתידיים.

הסבר קוד לצוותים לא-טכניים

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

סיכום

LLM הפך את תהליך כתיבת קוד טרנספורמציה למהיר משמעותית - אבל הערך האמיתי מגיע מהשימוש בו כמייצר קוד נבדק וגלוי, לא כמנוע Runtime שמחליט הכל בזמן אמת. השילוב הנכון של Code Generation לרוב המקרים, ו-Inference-time רק כשבאמת נדרש הבנה סמנטית, הוא מה שהופך את הגישה הזו ליציבה מספיק לפרודקשן. בפרויקטי Data Pipeline שמדיה דיל בונה, אנחנו מתייחסים לקוד שנוצר על ידי LLM בדיוק כמו לקוד שנכתב על ידי מתכנת ג׳וניור - שימושי מאוד, אבל חייב Code Review לפני שהוא נכנס לפרודקשן.

תגיות: Data Transformation · LLM · Code Generation · dbt · ETL · Prompt Engineering · Data Pipeline

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