איך מודדים איכות AI בלי תחושת בטן

איך מודדים איכות AI בלי להסתמך על תחושת בטן?#

שאלת "האם הבינה עובדת טוב?" אינה מדידה. צריך לפרק אותה למשימות ולתנאי קבלה: מה חייב להיות נכון, מה מותר שיחסר, מה אסור שיקרה, ומי מוסמך להעריך. מערכות AI דורשות גם בדיקות תוכנה רגילות וגם Evals — הערכה שיטתית של איכות התנהגות המודל. מקור: OpenAI Evaluation Best Practices.

שלוש שכבות בדיקה#

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

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

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

איך בונים מערך Eval ראוי#

תחילה מגדירים משימה וסיכונים; אחר כך אוספים סט קלטים שמתאים להתפלגות השימוש האמיתית. בתוכו צריך לכלול קלטים רגילים, חריגים, עמומים, חסרים, ארוכים, רב-לשוניים אם רלוונטי, וגם ניסיונות להטעות. אין מספר קסם של דוגמאות. עשרות מקרים יכולים לחשוף בעיות ראשוניות; הם אינם הוכחה לאחוז שגיאה נמוך בכלל האוכלוסייה. תוצאות של מערך קטן או מוטה לא הופכות את המוצר ל"99% מדויק". במדגם קטן יש גם אי-ודאות סטטיסטית: אחוז שחושב מ-20 מקרים מגיע עם רווח סמך רחב. חישובי Wilson עם דוגמאות מפורטות מופיעים בהערכה ובנצ'מרקים.

דוגמת Eval קטנה (להמחשה בלבד):

• קלט: "החזר כספי: קניתי לפני 10 ימים, האם מגיע לי?" ביחד עם מסמך מדיניות שמגדיר חלון של 14 יום.
• קריטריון: התשובה חייבת לציין שמגיע החזר, להסתמך על חלון 14 הימים ממסמך המדיניות, ולא להמציא תנאים שאינם בו.
• ציון: עבר/נכשל לכל קריטריון (3 קריטריונים). תשובה שעוברת את כולם מקבלת 3 מתוך 3. רושמים גם את נימוק השיפוט.

לזה קוראים Test Case — מקרה בדיקה מתועד; אוסף מתוחזק שלו יכול לשמש כ־Test Suite. כשמשתמשים באוסף קבוע להשוואה בין גרסאות, הוא משמש גם בסיס ל־Regression Testing (בדיקות רגרסיה). האוסף חייב להיבחן ולהתרחב כשהמוצר משתנה — סט קבוע בלבד עלול לפספס שימושים חדשים.

לכל מקרה שומרים: מזהה, גרסת נתונים, קלט מסונן, תוצאה רצויה או קריטריון, רמת חומרה, תוצאת הריצה ונימוק שיפוט. אם יש תשובת אמת מוכרת (Ground Truth — תשובת ייחוס אמינה ומוגדרת), ניתן להשוות אליה; אם לא, קובעים Rubric — מחוון הערכה שיטתי שבודקים מיומנים יכולים להפעיל בעקביות. מודל ששופט מודל (LLM-as-judge) יכול לעזור בהיקף גדול, אבל צריך לכייל את פסקי הדין שלו מול שופטים אנושיים ובדיקות עובדתיות; אחרת רק הוספנו עוד מודל לא ודאי לתהליך.

ארבעה מדדים שקל לבלבל#

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

יש למדוד גם false positives ו-false negatives כאשר מדובר בסיווג; לא תמיד נכון למזג אותן למספר אחד. מדד שחושב על בסיס 20 מקרים ובלי תיעוד התפלגות אינו הבטחת איכות ל-20,000 משתמשים.

לפני ואחרי שינוי במודל#

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

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

מה עוד לבדוק#

• רשמו בכל trace את גרסת המודל ואת גרסת הפרומפט.
• נטרו את עלות הטוקנים לכל משימה.
• הגדירו תקציב ומגבלת לולאה לסוכן.
• אמתו בקוד סכמה לארגומנטים שהמודל מעביר לכלים.
• בדקו אילו פרטים אישיים (PII) נשמרים ב-traces.

דוגמה לתיעוד Eval שאפשר לשחזר#

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

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