כיצד מודדים מודל — ומה מספרים לא מגלים?

דמו מוצלח אינו הערכה#

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

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

הערכה בשבעה צעדים#

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

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

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

להבחין בין שלושה סוגי מדדים#

איכות משימה: Precision/Recall לסיווג; שיעור שגיאת מילים לתמלול; שיעור תשובות נכונות לבעיה מתמטית; כיסוי ושלמות עבור סיכום; Groundedness לטענות מול מקור.

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

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

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

איכות מערכת: למה ממוצע זמן תגובה מטעה#

גם מדדי המערכת דורשים זהירות. נניח שמדדנו 10 קריאות, בשניות: 1.1, 1.2, 1.2, 1.3, 1.4, 1.4, 1.5, 1.6, 1.8 ו־9.5 (המחשה, מספרים מומצאים). הממוצע הוא 2.2 שניות, החציון 1.4, והאחוזון ה־90 (בשיטת הדירוג הקרוב ביותר) הוא 1.8. הקריאה החריגה היחידה, 9.5 שניות, מושכת את הממוצע מעלה. משתמשים לא חווים ממוצע. הם חווים את הקריאה האיטית שלהם. לכן מדווחים חציון ואחוזונים גבוהים, וגם שיעור הקריאות שחרגו מזמן מקסימלי שהוגדר מראש. עשר קריאות הן כמובן מדגם זעיר: במערכת אמיתית דוגמים הרבה יותר.

מטריצת בלבול: כשמספר גבוה אחד מטעה#

כדי לדבר על Precision ו־Recall צריך קודם לספור ארבעה סוגי תוצאות. מטריצת בלבול (Confusion Matrix) סופרת אותם: חיובי אמיתי (TP), אזעקת שווא (FP), פספוס (FN) ודחייה נכונה (TN). שלושת המדדים נגזרים מהן [3]:

Precision = TP / (TP + FP)
Recall    = TP / (TP + FN)
Accuracy  = (TP + TN) / (כל המקרים)

עכשיו מערכת אחרת, על אותן 1,000 הודעות: TP=12, FP=8, FN=8, TN=972. Accuracy היא 984 מתוך 1,000, כלומר 98.4%. Precision היא 12 מתוך 20, כלומר 60%. Recall היא 12 מתוך 20, כלומר 60%.

שימו לב: ההפרש בין שתי המערכות ב־Accuracy הוא 0.4 נקודות אחוז. ההפרש ביכולת למצוא תלונות דחופות הוא עצום. כשקטגוריה נדירה, Accuracy גבוהה היא כמעט ברירת מחדל. תיעוד scikit-learn מציין שדיוק רגיל עלול להיות מנופח במערכי נתונים לא מאוזנים, ומציע Balanced Accuracy, ממוצע ה־Recall של כל קטגוריה [3]. במערכת העצלה היא תהיה 50%, כלומר רמת ניחוש.

המטריצה גם מזכירה שהמחיר של שתי השגיאות שונה. מערכת שמסמנת 79 הודעות כדי למצוא 19 מתוך 20 תלונות (המחשה: TP=19, FP=60, FN=1) מקבלת Recall של 95% אך Precision של כ־24%. אם בדיקה אנושית של הודעה עולה דקה, אולי זה מחיר סביר. אם כל סימון מפעיל פיצוי אוטומטי, כנראה שלא.

סף ההחלטה: מדד אחד, כמה תוצאות#

מודל סיווג מחזיר בדרך כלל ציון, ולא רק "כן" או "לא". מי שקובע מאיזה ציון ומעלה מסמנים "כן" קובע גם את האיזון בין Precision ל־Recall.

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

מדדי סיכון: מה בודקים מעבר לאיכות#

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

מהו Benchmark ואיך אפשר להטעות איתו?#

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

• Data contamination: משימות ההערכה או פתרונותיהן הופיעו בנתוני האימון.
• Selection bias: בחרנו במודלים או בשאלות שהציגו תוצאה יפה.
• Prompt sensitivity: שינוי קטן בניסוח משנה ביצועים.
• Evaluator bias: שופט אוטומטי מעדיף סגנון או שם מודל.
• Distribution shift: השאלות בבנצ'מרק אינן דומות לפניות לקוחות אמיתיות.
• Tool confounding: מודל נבחן עם חיפוש, אחר בלי; לא ברור מה מקור ההבדל.

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

מה בנצ'מרק מודד, ומה הוא משאיר בחוץ#

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

זיהום נתונים בפועל. צוות מחקר בנה בנצ'מרק חדש, GSM1k, בסגנון ובקושי של GSM8k הקיים. הם בדקו אם הציונים הגבוהים נובעים מכך ששאלות דומות הופיעו באימון. לפי התקציר, אצל חלק מהמודלים נרשמה ירידה של עד 8% בדיוק, ונמצא קשר בין הסבירות שמודל ייצר דוגמאות מ־GSM8k לבין הפער בין שני הבנצ'מרקים. אבל התקציר מציין גם שמודלים רבים, ובעיקר מודלים מתקדמים, הראו סימני התאמת יתר מועטים [4]. המסקנה המדויקת היא שזיהום אפשרי ושווה לבדוק, לא שכל ציון בנצ'מרק מנופח.

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

חוק גודהארט. כשמדד שימושי הופך ליעד שמייעלים אותו בכל מחיר, הוא מפסיק למדוד את מה שרצינו. זהו הניסוח הנפוץ של החוק. התקציר של Manheim ו־Garrabrant אינו מצטט אותו; הוא מתאר ייעול יתר של מדד שבו המשך האופטימיזציה אינו יעיל או מזיק, ומציין שזה מכונה לפעמים חוק גודהארט. המאמר מסווג מנגנונים שונים של התופעה [6]. בהקשר שלנו: אם צוות מכוון את המודל לציון בנצ'מרק מסוים, ייתכן שהציון יעלה בלי שהמוצר ישתפר. זה אחד ההסברים למה כדאי לשמור ערכת בדיקה פרטית, שלא משתמשים בה לכיוונון.

רשימת בדיקה לקריאת דוח בנצ'מרק#

כשמוצג מספר, שאלו:

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

נבנה ניסוי קטן משלנו#

לצורך הלימוד יש 20 בקשות פיקטיביות להפיק הצעת מחיר. ב־8 מהן יש חסר בשדה מידות; ב־12 האחרות המידות קיימות. לפני ההרצה מחליטים:

• יעד ראשי: לא לפברק מידות חסרות.
• יעד משני: לחלץ נכון כמויות ומחירים כשהם מופיעים.
• כלל הכרעה: שדה לא קיים → null + בקשת הבהרה.
• מדד: שיעור המצאות, שיעור חילוץ נכון, שיעור תשובות שמסמנות מקור.
• דגימה: לפחות שלוש הרצות לפריטים פתוחים אם נצפתה שונות.
• כלים: אותן הוראות ואותו מידע עבור כל מודל; אם יש יכולת שלא קיימת אצל אחד, מדווחים על חוסר התאימות.

תוצאות המחשה מומצאות בלבד:

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

שלושה מקרים שבהם התמונה משתנה#

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

מה הטבלה הזאת באמת מאפשרת להגיד#

נחשב שיעורים מהטבלה המומצאת, יחד עם טווח Wilson של 95% (הורץ בפייתון). שיעור ההמצאה: A בכ־12.5% (טווח כ־2% עד 47%), B ב־0% (כ־0% עד 32%), C בכ־37.5% (כ־14% עד 69%). שיעור החילוץ הנכון: A בכ־91.7% (כ־65% עד 98.5%), B בכ־83.3% (כ־55% עד 95%), C ב־100% (כ־76% עד 100%).

מה אפשר להסיק? שהטווחים רחבים מאוד, כי 8 ו־12 מקרים הם מעט. ההבדל בין A ל־B בהמצאה, מקרה אחד, אינו מובהק. ההבדל בין B ל־C נראה גדול יותר, אך גם הוא מבוסס על 3 מקרים. מה אי אפשר להסיק? שהמערכות אכן נבדלות באופן כללי. זה מסביר למה הניסוי הקטן נועד לגלות כשלים ולהחליט איזה מקרה לחקור הלאה, ולא להכריע לבדו בין מערכות.

למה חוות דעת אנושית לבדה אינה מספיקה?#

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

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

רובריקה: איך הופכים "נראה טוב" לציון#

כשאין תשובה נכונה אחת, בונים רובריקה: רשימת קריטריונים עם הגדרה לכל רמת ציון. עבור סיכום שיחת לקוח, למשל: האם כל הפעולות שהוזכרו נכללו (0, 1, 2)? האם נוסף פרט שלא הופיע בשיחה (כן/לא)? האם המקור לכל טענה מסומן (כן/לא)? קריטריון בינארי וברור, כמו "נוסף פרט שלא הופיע", קל יותר לשיפוט עקבי מקריטריון כמו "איכות כללית".

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

שופט אוטומטי: LLM-as-a-judge#

כשיש אלפי תשובות פתוחות, אנשים אינם יכולים לדרג את כולן. אפשר לבקש ממודל שפה לשמש שופט. מאמר של Zheng ואחרים בדק זאת על MT-Bench ו־Chatbot Arena. לפי התקציר, שופט חזק כמו GPT-4 הגיע ליותר מ־80% הסכמה עם העדפות אנושיות, רמה דומה להסכמה בין בני אדם. אותו תקציר מזהה גם הטיות: הטיית מיקום (העדפת התשובה שהוצגה ראשונה, למשל), הטיית אורך והעדפה עצמית של תשובות מאותו מודל, וכן יכולת הסקה מוגבלת [7].

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

דוגמה מחושבת: כמה אפשר לסמוך על שופט אוטומטי?#

75% נשמע סביר, אבל חלק מההסכמה נובע מצירוף מקרים: אם שניהם נוטים לאשר, הם יסכימו לעיתים קרובות גם בלי שיש להם קשר. מדד Cohen's Kappa מנכה את ההסכמה הצפויה במקרה. כאן ההסכמה הצפויה היא 59%, ולכן Kappa הוא (0.75 פחות 0.59) חלקי (1 פחות 0.59), כלומר כ־0.39 (הורץ בפייתון). לפי הסולם הנפוץ של Landis ו־Koch, ערכים בין 0.21 ל־0.40 מתויגים "fair" (סבירה), כלומר הסכמה חלשה יחסית ולא גבוהה (הסולם עצמו שרירותי במקצת). ושימו לב לכיוון הטעות: השופט האוטומטי אישר ארבע תשובות שאדם פסל, ופסל רק אחת שאדם אישר. אם השופט מחמיר מדי או מקל מדי, אפשר להחליט לשנות את הקריטריון או להשאיר בדיקה אנושית על תשובות מאושרות.

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

ערכת בדיקה קטנה משלכם: 10 עד 30 מקרים#

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

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

איך קוראים תוצאה. נניח ש־A עבר 17 מתוך 20 מקרים ו־B עבר 15 מתוך 20 (המחשה, מספרים מומצאים). A נראה טוב יותר: 85% מול 75%. אבל בחישוב טווח ביטחון של 95% בשיטת Wilson (הורץ בפייתון) מתקבל ל־A טווח של כ־64% עד 95%, ול־B כ־53% עד 89%. הטווחים חופפים בהרבה. עם 200 מקרים ואותם שיעורים (170 ו־150) הטווחים הם כ־79% עד 89% ו־69% עד 80%, והם כמעט נפרדים. כלומר, ערכה קטנה טובה לגילוי כשלים, פחות להכרעה בין שתי מערכות קרובות.

אזהרה: רווחי Wilson אינם מבחן להפרש. רווח Wilson מתאר שיעור אחד, בנפרד. כששתי המערכות נבדקות על אותם מקרים, הנתונים מזווגים, וחפיפה (או היעדר חפיפה) בין שני רווחים נפרדים אינה מבחן ישיר לשאלה אם ההפרש ביניהן אמיתי. להשוואה מזווגת משתמשים במבחן McNemar או ב־paired bootstrap, שמתבוננים רק במקרים שבהם המערכות לא הסכימו.

מקורות: תיעוד statsmodels ל־mcnemar [9] (מבחן מדויק מבוסס התפלגות בינומית על המקרים שבהם המערכות נבדלות). Dietterich (Neural Computation, 1998) מוזכר כרקע: לפי התקציר, כשאפשר להריץ אלגוריתם פעם אחת בלבד, McNemar הוא המבחן היחיד שנמצא בו שיעור סביר של שגיאה מסוג I.

Confidence אינו Accuracy#

כאשר מודל כותב "אני בטוח ב־95%" אין מדובר אוטומטית בהסתברות תקפה. אפילו ציון הסתברותי פנימי מחייב Calibration: אם ל־100 מקרים הוקצה סיכוי של 0.8, האם בכ־80 מהם התשובה אכן נכונה? במערכות עם טקסט חופשי ההגדרה של "נכון" לעיתים דורשת בדיקה פרטנית ברמת הטענה.

דוגמה מחושבת לכיול#

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

מה לגבי "מודלים מובילים בשנת 2026"?#

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

תרגול מסכם#

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

איפה הגישה הזאת נכשלת#

הדוגמאות כאן פשוטות בכוונה, ויש להן גבולות:

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

מה לא להסיק#

• "Accuracy של 98% פירושו שהמערכת טובה." ראינו מערכת עם 98% ו־0% איתור.
• "בנצ'מרק גבוה אומר שהמודל מתאים למשימה שלי." רק אם המשימה והנתונים דומים.
• "הפרש של נקודות אחוז בערכה קטנה הוא הכרעה." בדקו טווחי אי־ודאות.
• "שופט אוטומטי שמסכים עם בני אדם ב־80% הוא תחליף להם." הסכמה ממוצעת אינה מבטיחה התאמה למקרה שלכם.
• "אם המודל כותב אחוז ביטחון, זו הסתברות." רק כיול על נתונים מוכיח זאת.

תרגיל#

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

1. כמה מהמקרים ללא תאריך קיבלו "המצאה"?
2. מה Accuracy, ומה Recall על המקרים עם תאריך? האם הם מספרים את אותו סיפור?
3. האם התוצאות זהות בשתי ההרצות?
4. נניח ש־13 מתוך 15 עברו. האם 87% מספיק כדי להכריע שהמערכת מוכנה?

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

1. אין תשובה אחת. אם אפילו מקרה אחד, התייחסו לכך כממצא ובדקו מה בקלט גרם לו.
2. אם מערכת ממציאה תאריך ב־3 מתוך 5 המקרים החסרים וצודקת בכל 10 האחרים, Accuracy היא 12 מתוך 15, כלומר 80%, אבל הסיכון הראשי (המצאה) מופיע ב־60% מהמקרים הרלוונטיים. מדד כללי הסתיר זאת.
3. אם לא, זו שונות. דווחו על שתי ההרצות או הריצו שוב.
4. 13 מתוך 15 הם 86.7%. טווח Wilson 95% הוא כ־62% עד 96% (חושב בפייתון). ערכה כזו לא מכריעה; היא ממחישה שעדיף להוסיף מקרים ולבחון את הכשלים.

מקורות#

1. NIST — AI Risk Management Framework: Generative AI Profile, July 2024. תקן/מסגרת (NIST AI 600-1, פורסם 26.7.2024), לשימוש וולונטרי.
2. Stanford CS229 — metrics and generalization. קריאה נוספת; לא מצוטט בגוף הפרק.
3. scikit-learn — Metrics and scoring (User Guide, גרסה 1.9.1). תיעוד יצרן/ספרייה: הגדרות Precision, Recall, Accuracy ו־Balanced Accuracy.
4. Zhang et al. (מאי 2024, גרסה אחרונה נובמבר 2024) — A Careful Examination of Large Language Model Performance on Grade School Arithmetic. מאמר מחקר (arXiv): GSM1k וחשש לזיהום נתונים.
5. Miller (נובמבר 2024) — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations. מאמר מחקר (arXiv).
6. Manheim, Garrabrant (מרץ 2018, גרסה אחרונה פברואר 2019) — Categorizing Variants of Goodhart's Law. מאמר מחקר (arXiv).
7. Zheng et al. (יוני 2023, גרסה אחרונה דצמבר 2023) — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. מאמר מחקר (arXiv): הטיות של שופטי LLM והסכמה עם בני אדם.
8. Guo et al. (יוני 2017, ICML 2017) — On Calibration of Modern Neural Networks. מאמר מחקר (arXiv): כיול ו־temperature scaling.
9. statsmodels — mcnemar (contingency_tables). תיעוד ספרייה. מבחן McNemar, אפשרות exact (בינומי) מול קירוב חי־בריבוע.