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

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

למה "זה נראה טוב" לא מספיק

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

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

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

שלב 1: אוספים דוגמאות אמיתיות, לא מומצאות

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

שלב 2: מגדירים מראש מה נחשב תשובה טובה

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

שלב 3: מריצים את כל הסט ובודקים תבניות כשל

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

דוגמה אמיתית: איך בדיקה שיטתית מנעה תקרית

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

מה בודקים חוץ מ"נכון או לא נכון"

בדיקת סוכני AI היא לא רק שאלה של דיוק. שלושה דברים נוספים שאני תמיד בודקת:

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

הטרייד-אוף: כמה בדיקה זה מספיק

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

איך זה נראה בפועל – טבלת בדיקה פשוטה

לא צריך כלי מיוחד כדי להתחיל – טבלה פשוטה מספיקה בהתחלה:

שאלה/תרחיש	תשובה מצופה	מה הסוכן ענה בפועל	עבר?
"מה שעות הפעילות ביום שישי?"	שעות מדויקות מהמסמך	(התשובה בפועל)	כן/לא
"אני רוצה לבטל מנוי"	הפניה לתהליך ביטול מוגדר	(התשובה בפועל)	כן/לא
שאלה עם מידע חסר במכוון	הודאה שאין מידע + הפניה לנציג	(התשובה בפועל)	כן/לא

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

מתי לחזור ולבדוק שוב

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

מי בצוות צריך לעשות את זה

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

סיכום

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

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

בואו נדבר על זה >