איך לבדוק ש-AI Agent על BI עונה לפי ההגדרה העסקית הנכונה

קטגוריה: BI ואינטגרציות | תאריך: ספטמבר 2026

AI Agent שמחובר ל-BI יכול להחזיר תשובה שנשמעת ברורה ומשכנעת בתוך שניות. אבל תשובה מנוסחת היטב אינה בהכרח תשובה עסקית נכונה. אם המנהל שואל "כמה הזמנות פתוחות יש?", הסוכן צריך לדעת מה נחשב הזמנה, אילו סטטוסים נחשבים פתוחים, לאיזה תאריך מתייחסים, האם מבטלים נכללים ואילו חברות או יחידות מותר למשתמש לראות.

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

הנה דרך מעשית לבנות בדיקת תשובות ל-AI Agent על BI לפני שמרחיבים את השימוש בו.

למה תשובה שנראית סבירה יכולה להיות שגויה

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

הסוכן עלול לטעות בכמה דרכים:

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

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

להתחיל ממילון מדדים מאושר

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

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

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

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

לבנות שאלות ותשובות ייחוס

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

לכל בדיקה כדאי לשמור:

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

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

לבדוק כמה ניסוחים לאותה שאלה

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

• "כמה בקשות פתוחות יש כרגע?"
• "מה נשאר לטיפול?"
• "תן לי את מספר הבקשות שעדיין לא נסגרו."
• "כמה פתוחות יש ביחידה שלי מסוף החודש?"

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

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

להכריח את הסוכן להבהיר שאלות עמומות

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

יש להגדיר מראש מתי הסוכן חייב לשאול שאלת הבהרה. למשל:

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

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

לבדוק מסננים, זמן ורמת פירוט בנפרד

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

מסננים

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

זמן

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

רמת פירוט

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

לאמת הרשאות כחלק מנכונות התשובה

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

בדקו לפחות:

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

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

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

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

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

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

למדוד יותר מהתאמה מספרית

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

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

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

להריץ בדיקות רגרסיה אחרי כל שינוי

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

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

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

איך נראה POC ממוקד לבדיקת AI על BI

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

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

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

שאלות נפוצות

האם מספיק להשוות את תשובת הסוכן לדוח BI קיים?

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

מי צריך לאשר את תשובות הייחוס?

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

האם AI Agent צריך לענות תמיד?

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

איך בודקים שאלות על נתונים שמשתנים כל הזמן?

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

מתי אפשר לעבור מקריאה בלבד להצעת פעולה?

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

להתחיל משאלות ייחוס, לא מהדמו

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

Adaptico עוסקת ב[פתרונות BI, AI ואינטגרציה למערכות ארגוניות](/#services). אם אתם רוצים לבדוק AI Agent על Qlik או על סביבת BI אחרת, אפשר [לקבוע שיחת התאמה](/#contact) ולהגדיר POC קטן עם מדדים מאושרים, סט בדיקות וגבולות שימוש ברורים.