דלג לתוכן

תפיסת הזיות AI: 3 מעקות הגנה לצוותי B2B

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

איך נראות הזיות AI ב-workflows ב-B2B אמיתיים

הזיה היא כשהמודל מייצר תשובה שנשמעת בטוחה אך שגויה. ב-B2B היא מופיעה בשלוש צורות קלאסיות: (1) המצאת מספר הזמנה שאינו קיים בפניית תמיכה, (2) "ציטוט" תאריך שלא נמצא בחוזה בעת סיכומו, (3) המצאת קטגוריה חדשה בעת סיווג חשבוניות מחוץ לסט שהוגדר.

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

שלושה מעקות: מקור, כלל, אדם

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

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

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

בניית תהליך הערכה (eval) לפני ההשקה

אי אפשר לתפוס שיעור הזיות רק על ידי הצצה בפלטים; צריך סט בדיקה. בנו "golden set" של 50-200 דוגמאות אמיתיות עם תשובות נכונות ידועות, וודאו שהוא מכסה מקרי קצה — נתונים חסרים, שאילתות מעורפלות, בקשות מחוץ להיקף. הריצו את המודל מולו לפני כל שינוי בפרומפט או במודל, לא רק בהשקה.

עקבו אחרי שני מספרים נפרדים: דיוק (האם הוא קיבל את התשובה הנכונה) ושיעור הימנעות (abstention rate) (האם הוא אמר נכון "אני לא יודע" כשהיה צריך). מודל שלעולם לא נמנע נראה בטוח בעצמו אבל מסוכן יותר; מודל שנמנע לעיתים קרובות מדי מעצבן אבל בטוח יותר. הסף הנכון תלוי כמה יקרה תשובה שגויה בהשוואה לתשובה שהוחמצה.

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

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

אילו משימות נושאות את סיכון ההזיות הגבוה ביותר

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

מתודולוגיה

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

הערת מקורות

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

עדכון אחרון:

שאלות נפוצות

מהי הזיה של AI?

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

איך אפשר לזהות הזיות באופן אוטומטי?

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

אילו תהליכים עסקיים חשופים ביותר לסיכון ההזיות?

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