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