פיתוח AI Data Analyst — אנליטיקאי נתונים דיגיטלי Text-to-SQL

מדוע AI Data Analyst טועה בנתונים ומערער את האמון

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

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

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

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

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

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

אפקט ההטמעה: זמני תגובה ומהימנות הנתונים

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

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

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

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

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

אפשרויות מימוש והמגבלות הטכניות שלהן

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

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

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

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

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

מה נשאר אצלכם: קונפיגורציות, סכימות, תקנונים

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

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

מקרה בוחן: כיצד העלינו את שיעור התשובות הנכונות מ-62% ל-94%

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

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

מה שינו

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

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

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

מה קרה בסופו של דבר

שיעור התשובות הנכונות עלה מ-62% ל-94% על אותו סט; השאר — שאלות מחוץ לתחום, והמערכת דוחה אותן ביושר. זמן הכנת המספר הממוצע הצטמצם משניים-שלושה ימים לכמה דקות, יחד עם בדיקת המקור.

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

במה שונה אנליסט AI מדיווח שגרתי?

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

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

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

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

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

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

ספקות לגבי איכות הנתונים, הרשאות ועומס

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

לעובדים הרשאות שונות, לא כולם רואים את הטבלאות הנדרשות

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

האם העומס על מחסן הנתונים לא יגדל

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

הסכימה תשתנה אחרי ההטמעה — הכול ישבר

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

נדון במשימה: מה להכין לשיחה

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

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

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