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

נשמע מוכר ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בלי שלושת המרכיבים האלה, הערכת AI עלולה להפוך לעוד שכבה של רעש.

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

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

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

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

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

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

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

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

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

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

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

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

זהו ההבדל בין ארגון שמפעיל AI לבין ארגון שמנהל AI.

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