בדיקות קבלה למסווג AI: איך מגדירים הצלחה מעבר להדגמה?

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

מה מלמד המקרה של bunq על שיטה ותוצאה?

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

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

הגדירו תחילה מה כל סיווג מאפשר לעשות

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

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

בנו קבוצת בדיקה שהצוות לא מכוון אליה את הפתרון

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

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

הפרידו בין החמצות לבין התרעות שווא

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

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

בדקו את מסלול הבירור כחלק מהקבלה

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

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

מה למסור לבית התוכנה לפני הצעת מחיר?

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

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