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

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

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

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

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

1) ציטוט מקור: המודל מחזיר כל תשובה עם המזהה או מספר השורה של מסמך המקור. אין מקור → "אינני יודע". ההזיות יורדות בכ-80%.

2) בדיקת-קדם לפי כללים: ולידציה של הפלט מול כללי דומיין לפני שהוא מגיע — האם מספר ההזמנה הוא 8 ספרות? האם קטגוריית החשבונית ברשימה? האם פורמט התאריך תקין? בדיקות Python זולות אלה תופסות את הרוב.

3) אישור אנושי מקדים: פעולות בסיכון גבוה (החזרים, חתימת חוזה) מוצעות על ידי ה-AI ומאושרות על ידי אדם. ה-AI מטפל בכ-95% לבד; 5% החריגים מגיעים אליכם לבדיקה.

שלושתם יחד: בביקורת חיצונית עצמאית שיעור ההזיה צונח מתחת ל-2%.

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

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

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

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

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

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

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

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

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

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