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

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

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

1. בוחרים משימה תחומה עם אדם שבודק את התוצאה

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

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

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

2. מחליטים באיזה מידע מותר להשתמש

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

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

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

3. בונים אוסף בדיקות קטן לפני הניסוי

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

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

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

4. מודדים ערך מקצה לקצה, לא מהירות יצירת טקסט

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

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

5. נותנים לניסוי תנאי עצירה ברורים

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

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

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

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

לקריאה נוספת

NIST: AI Risk Management Framework היא מסגרת וולונטרית לניהול סיכונים ואמינות של מערכות בינה מלאכותית. NIST: Generative AI Profile עוסק בסיכונים הייחודיים לבינה מלאכותית יוצרת. ההצעות לתהליך ולניסוי כאן הן יישום עריכתי של העקרונות, ולא אישור בטיחות או עמידה בדרישות משפטיות.