מערכת AI לניתוח נתונים עם Text-to-Code: יצירה מהירה של SQL ו-Python

ניתוח נתונים ב‑AI: היכן נשבר המעגל הידני

ניתוח נתונים ב‑AI נתקע לא במודל, אלא במעגל הידני שמסביבו. השאלה העסקית מגיעה בניסוח בשפה טבעית, האנליסט מתרגם אותה לשאילתה, מתאם את לוגיקת הדגימה מול בעל המדד, ממתין לחילוץ הנתונים — וחוזר על אותו מסלול מחדש עבור כל ניסוח נוסף.

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

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

כל שאילתה כזו הופכת לשימושית מחדש: שאלות זהות מקבלות לוגיקה זהה, ולא תשע פרשנויות שונות של «לקוחות פעילים». גם התור משתנה — חלק מהשאלות נסגרות ישירות מהממשק, בלי להגיע לאנליסט.

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

האפקט של Text-to-Code בניתוח נתונים

Text-to-Code לא מחליף את האנליסט, אלא מסיר ממנו את השגרה. המודל מפרק את הניסוח בשפה טבעית, מצליב אותו עם סכמת הוויטרינות ומרכיב SQL או Python שיוצא מיד לביצוע. ההבדל ניכר לא בהדגמה, אלא בזרימת המשימות: פניות שגרתיות מפסיקות להמתין בתור.

כמה זמן חוסכת יצירת דגימות שגרתיות

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

היצירה מספקת טיוטה עובדת תוך שניות, והאדם בודק רק את משמעות התוצאה: אצל הלקוחות שלנו 55–70% מפניות כאלה נסגרות בלי אנליסט.

סוג השגיאות שנעלם יחד עם הקוד הידני

המקור העיקרי לשגיאות בקוד ידני הוא לוגיקת החיבורים: בחירה שגויה של סוג הקשר, אובדן שורות בחיבור פנימי במקום חיצוני, רמת פירוט שונה של מפתחות, כפילויות בקשרי «רבים לרבים».

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

«כל שאילתה שנוצרה עוברת בדיקת הרשאות ברמת התפקיד: אם למשתמש אין גישה לוויטרינה, היא לא תתבצע, גם כשהקוד נבנה כהלכה», — מהנדס בצוות שלנו.

יחד זה מפזר מחדש את העומס: אנליסטים עוברים מזרם של פניות אחידות למידול ולבחינת נתונים שנויים במחלוקת, וזמן התשובה לשאלה שגרתית נמדד בדקות במקום בימים.

מצבי יצירת שאילתות: השוואת אפשרויות

את מצב היצירה בוחרים לא לפי ה«עוצמה» של המודל, אלא לפי רגישות הנתונים ומחיר הטעות בשאילתה. להלן החלופות הממשיות שביניהן נעשית הבחירה, ומה מגביל כל אחת מהן בפועל.

היכן עובר גבול הישימות של המודל

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

מגבלות עומס ונפח נתונים

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

שלבי ההטמעה: מביקורת המקורות ועד למסירה

מתחילים לא מהמודל, אלא מספירת מלאי של הנתונים: כל עוד לא ידוע היכן מצויים המדדים ומי אחראי לנכונותם, המחולל מפיק מספרים משכנעים אך שגויים.

1. ביקורת מקורות הנתונים. קובעים מהיכן מגיע כל מדד, היכן הנתונים חלוקים ואילו טבלאות משכפלות זו את זו.
2. מילון מונחים. מתאמים את הניסוחים של המדדים והחתכים, ומשייכים לכל מונח את הטבלאות ואת נוסחת החישוב.
3. הרשאות ותפקידים. פותחים חיבורים לקריאה בלבד ומגדירים נראות לפי מחלקות.
4. חיבור למחסן הנתונים. טוענים את הסכמה, המילון וכללי החישוב, ובודקים את החיבור על שאלות אמיתיות.
5. שאלות ייחוס. מרכיבים סט בקרה של שאלות שגרתיות עם תשובות ידועות מראש.
6. מדידת דיוק. מצליבים את התשובות עם הייחוס, מנתחים פערים, ומשפרים את המילון עד לשיעור היעד של תשובות נכונות.
7. מסירת הפתרון. מוסרים הוראות, נוהל לעדכון המילון, ומכשירים את הצוות.

כיצד מתארים מונחים עסקיים עבור המודל

מונח מתואר בשלושה חלקים: איך העסק מכנה אותו, מאילו טבלאות נלקחים הנתונים, ולפי איזו נוסחה מחושב המדד. מילים נרדפות של מחלקות משייכים לאותו מונח — השאלות «הכנסות לפי אזור» ו«מכירות במחוז» מובילות לאותו חישוב.

כיצד בודקים דיוק על סט שאלות בקרה

את הסט מרכיבים משאלות אמיתיות של הלקוח עם תשובות שחושבו ידנית. לאחר כל תיקון במילון ההרצה חוזרת — ורואים שהשיפור לא שבר שאילתות שנכונות היו קודם.

מה מוסרים ללקוח יחד עם המערכת

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

• סכמת המקורות והקשרים — אילו טבלאות, חילוצים וטבלאות עזר משתתפים בניתוח, לפי אילו מפתחות הם מתחברים והיכן אפשריים פערים.
• מדיניות גישה ותפקידים — מי רואה נתונים גולמיים, מי עובד רק עם אגרגציות, ומי מוסמך לשנות את כללי יצירת השאילתות.
• סט שאלות בקרה — ניסוחים שגרתיים של אנליסטים עם תוצאת ייחוס: לפיהם בודקים את המערכת אחרי כל עדכון.
• הוראות לאנליסטים — כיצד לנסח את השאלה כדי לקבל שאילתה נכונה, ומה לעשות כאשר יש פער מול הציפייה.
• קטלוג שאילתות שמורות — סקריפטים מאומתים ב‑SQL וב‑Python, עם סימון אילו ניתן להשתמש בהם מחדש.

מילון המונחים וכללי התרגום

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

נוהל ליווי בעת שינוי הסכמה

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

מקרה בוחן: הסרנו חילוצים ידניים והאצנו את הדגימות

מה היה לפני ההטמעה

המחלקה הרכיבה דיווח תפעולי באופן ידני: כ‑45 שאילתות בשבוע עברו לאנליסטים, והתור התארך ל‑2-3 ימים. כל דוח הורכב מחילוצים מכמה מערכות, ואותו מדד בקבצים שונים חושב באופן שונה — שיעור הפערים הגיע ל‑15%. החלטות התקבלו לפי נתונים שהספיקו להתיישן בזמן הכנת הדוח.

חיברנו שכבת Text-to-Code מעל מחסן הנתונים הקיים: העובד מנסח שאלה במילים, המערכת בונה שאילתה אל הוויטרינות המאושרות ומחזירה תוצאה תוך שניות. הרשאות הגישה, טבלאות העזר והגדרות המדדים נשארו כשהיו — רק הדרך לקבל דגימה השתנתה.

התוצאה במספרים ומה השתנה בתהליך

• 68% מהשאילתות נסגרות באופן עצמאי, בלי אנליסט: דוח «ברגע זה» במקום המתנה בתור.
• זמן ההמתנה לדוח הצטמצם מ‑2-3 ימים לדקה, וחישוב חוזר — מיד לאחר הבהרת הניסוח.
• שיעור השגיאות בחישובים ירד מ‑15% ל‑3%: התשובות נבנות לפי סמנטיקה אחת של מדדים, וההעתקה הידנית נעלמה.
• זרם הפניות לאנליסטים ירד מ‑45 ל‑13 בשבוע — הזמן שהתפנה עבר למידול ולאיכות הנתונים.

«פעם חצי מישיבות התכנון התחילו בשאלה למה המספרים לא מסתדרים. עכשיו אנחנו מתווכחים על החלטות, לא על חילוצי נתונים», — מנהל תחום האנליטיקה ב‑Nordline Retail.

במה שונה יצירת שאילתות מלוחות דוחות?

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

יצירת דגימות שרירותיות מתחילה במקום שבו השאלה מופיעה מהר יותר משמצליחים לתאר אותה בדוח. האנליסט מנסח אותה במילים, המערכת מרכיבה SQL או סקריפט ב‑Python לפי סכמת הנתונים האמיתית, מצליבה שמות טבלאות ושדות ומחזירה תוצאה.

העיקר כאן אינו «קסם השפה», אלא שתי הגבלות: הבנייה נעשית רק לפי הסכמה המתוארת ועם הרשאות קריאה, והשאילתה עצמה נשארת ניתנת לבדיקה — אפשר להראות אותה, לתקן ולשמור.

האחד אינו מחליף את השני: הלוח צפוי, זול בחישוב ומתאים למדדים שוטפים, שבהם כולם מסתכלים על אותם מספרים. אנליטיקה לפי דרישה מנצחת בגמישות, אבל דורשת משאבים לביצוע וּולידציה של התוצאה — בלעדיה קל לקבל תשובה נכונה תחבירית וחסרת משמעות. לכן סביר להחזיק את שתי השכבות יחד, ולחלקן לפי הייעוד.

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

ספקות טכניים לפני תחילת הפרויקט

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

האם דגימות כבדות יפילו את מחסן הנתונים היצרני?

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

כיצד מגבילים גישה בין מחלקות?

ההרשאות עוברות בירושה ממערכת האימות שלכם, וכללי הנראות מוגדרים ברמת טבלאות ושורות — עובד של תחום אחד לא יראה נתונים של תחום אחר, גם אם ינסח את השאלה כהלכה. כל פנייה למודל וכל שאילתה שנוצרה נרשמות ביומן עם ציון המשתמש, הזמן והישויות שנגעו בהן.

האם אפשר לעבוד בלי שירותים חיצוניים?

כן. במעגל סגור נפרסת מודל תרגום משלנו לשאילתה, בלי פניות ל‑API חיצוניים — הנתונים אינם יוצאים מההיקף שלכם. את דרישות החומרה אנחנו מחשבים מראש, לפי נפח המטא-נתונים ומספר המשתמשים במקביל.

מה עם מחסן נתונים שכבר פרוס?

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

נדבר על המשימה ונחזור עם אומדן ותוכנית

כדי שהשיחה על מערכת ניתוח נתונים ב‑AI תעבור מיד לאומדן, ולא לדיון כללי ביכולות הטכנולוגיה, כדאי לבוא עם נתונים קונקרטיים.

להלן מה שמשפיע באמת על הארכיטקטורה ועל לוחות הזמנים: לפי נקודות אלה אנחנו מחשבים את מאמץ העבודה, בוחרים את אופן החיבור למחסני הנתונים וקובעים את גבולות הבדיקות.

• רשימת מקורות הנתונים: אילו מסדי נתונים, מחסנים וקבצים נמצאים בעבודה, באיזו תדירות משתנה הסכמה, והאם יש ויטרינות עם מדדים שכבר אושרו.
• דוגמאות לשאלות שגרתיות: 15-30 ניסוחים של אנליסטים ומנהלים — עליהם מכווננת יצירת השאילתות, ולפיהם נמדד הדיוק בקבלה.
• דרישות הרשאה: חשבון לקריאה בלבד, סכמות מותרות, היכן המערכת רשאית לכתוב את התוצאה, ומה אסור לקרוא ולשמור ביומנים.
• מגבלות המעגל: היכן נפרסת המערכת, האם יש מקטע מבודד, כללים משלכם לשמירת היסטוריית שאילתות ולטשטוש נתונים.
• קריטריוני תוצאה: מה נחשב להצלחה — שיעור השאלות שנסגרות בלי מהנדס, הזמן עד לתשובה הראשונה, שיעור החישובים עם בדיקה אנושית מחייבת.
• בעלים וקבלה: מי אחראי למדדים ומי מאשר את שלבי תוכנית ההטמעה.

תארו את המשימה בצורה חופשית — נחזור עם אומדן לפרויקט ותוכנית הטמעה, שבה לכל שלב קבועים התוצאה המצופה ונקודת הבדיקה.