כשקוראים שGrok 4.6 עקף את Fable 5, או שמודל חדש של OpenAI הוא החזק ביותר שיצא, נדמה שמישהו התרשם. בפועל, מאחורי כל אחת מהכותרות האלה עומד תהליך מדידה מוגדר ומשעמם למדי, ולו קוראים eval.
זה עובד כך: לוקחים אוסף משימות שהתשובה הנכונה בהן ידועה מראש, מריצים עליו את המודל, ונותנים ציון לכל תשובה. בסוף מקבלים מספר. המספר הזה הוא מה שמניע את כל טבלאות ההשוואה שאתם קוראים.
עכשיו החלק המעניין. הדיסציפלינה הזאת שולטת בכל מה שקורה במעבדות. ברגע שה-AI יוצא מהן ונכנס לעסק אמיתי, היא נעלמת כמעט לחלוטין.
איפה המדידה נעצרת
מי שמטמיע היום AI בעסק כמעט אף פעם לא מגדיר מראש איך יידע אם זה הצליח.
הרצף מוכר: מישהו בונה תהליך אוטומטי, זה נראה משכנע בהדגמה, הצוות מתחיל להשתמש, וכעבור כמה שבועות אף אחד לא יודע להגיד אם המערכת עובדת. לא בגלל שה-AI נכשל. בגלל שלא הוגדר מה נחשב הצלחה.
The Rundown University, שמפעילה קורסים בתחום, הקדישה לפער הזה סדנה שלמה שהוכרזה השבוע. הניסוח שלהם היה חד: פרויקטים לא מתים מכישלון טכנולוגי, הם מתים מכך שאיש לא הגדיר איך מודדים.
התוצאה היא שוק שלם שמתנהל לפי התרשמות. וזה מוזר במיוחד כשזוכרים שזו אותה טכנולוגיה שבמעבדה נמדדת עד הפסיק.
למה כולם מדלגים על זה
ארבע סיבות, וכולן הגיוניות בפני עצמן.
המילה מפחידה. eval נשמע כמו משהו שדורש מהנדס נתונים ותקציב. הוא לא. הוא דורש טבלה.
התוצאה עלולה להיות מביכה. כל עוד לא מדדתם, המערכת עובדת מצוין. מדידה מסכנת את הסיפור הזה, ובעיקר מסכנת את מי שאישר את התקציב.
מודלי שפה מנסחים היטב. זה הכשל הכי ערמומי. תשובה יכולה להיות מנוסחת בצורה מושלמת ולהיות שגויה לגמרי, והעין קולטת קודם את הניסוח. אצל בני אדם ניסוח טוב הוא בדרך כלל סימן לידיעה. אצל מודל, זו בדיוק היכולת הבסיסית ביותר שלו.
אין תמריץ מצד הספק. ספק שמוכר מערכת AI לא מרוויח דבר מכך שהלקוח יתחיל לספור. התרשמות טובה היא לקוח שממשיך לשלם, מספר הוא לקוח ששואל שאלות.
איך בונים אחד. באמת
הנה התהליך המלא, בלי כלים ובלי קוד:
- אוספים 20 מקרים אמיתיים מהארכיון של העסק. פניות, שאלות, בקשות. מגוונים ככל האפשר, כולל אחד או שניים חריגים
- רושמים לכל מקרה מה הייתה התשובה הנכונה. לא היפה, הנכונה. זה הצעד היחיד שדורש מאמץ אמיתי
- מריצים את המערכת על אותם 20 מקרים בדיוק
- נותנים ציון לכל תוצאה מול מה שנרשם בשלב 2
- סופרים
הצעד השני הוא זה שנוטים לדלג עליו, והוא כל העניין. כל עוד לא כתבתם מראש מה נכון, כל תשובה שתקבלו תיראה סבירה. זו לא בעיה של AI, זו בעיה מוכרת של מבחן בלי מחוון.
מה מודדים, בפועל
ציון אחד כללי לא שווה הרבה. עדיף לפרק לארבעה, ולתת לכל אחד ציון נפרד:
- דיוק עובדתי. האם הנתונים שנמסרו נכונים? זו הקטגוריה היחידה שבה טעות היא התחייבות משפטית ולא אי נעימות
- הבנת כוונה. האם המערכת זיהתה מה האדם באמת ביקש, או ענתה למילים שהוא הקליד?
- ידיעת הגבול. האם היא העבירה לאדם ברגע הנכון? מוקדם מדי זה בזבוז, מאוחר מדי זה נזק
- תוצאה. האם התהליך התקדם לאנשהו, או רק התנהל בנימוס?
שימו לב שאיכות הניסוח לא ברשימה. לא כי היא לא חשובה, אלא כי היא הדבר היחיד שאפשר להניח שכבר עובד.
המלכודת של טבלאות ההשוואה
יש כאן עוד שכבה, ושווה להיות מדויקים לגביה.
הציונים הפומביים שמודלים מקבלים נמדדים על מבחנים כלליים: הסקה, מתמטיקה, קוד, ידע. מודל יכול להוביל בכולם ולהיכשל דווקא במשימה הצרה שלכם, כי המשימה שלכם דורשת הכרה של נתונים שהמודל לא ראה מעולם.
זה גם ההסבר לתופעה שנראית תמוהה מבחוץ: מודל חזק יותר שלא מתאים לכל שימוש. חזק יותר במבחן כללי הוא לא בהכרח מדויק יותר במקרה פרטי.
לכן ה-eval היחיד שבאמת קובע הוא זה שנבנה על הנתונים שלכם. הציון הפומבי אומר לכם מי במרוץ. הוא לא אומר לכם מי מתאים למשימה.
למה זה מתחיל להיות דחוף
כל עוד AI רק ניסח טקסטים, הנזק מטעות היה מביך. ככל שמערכות מקבלות הרשאות לפעול בפועל, לגשת למערכות ולבצע פעולות, הפער בין "נראה טוב" ל"נכון" מפסיק להיות אקדמי.
הפריצה לסוכן של OpenAI הראתה מה קורה כשמערכת עם גישה רחבה פועלת בלי בקרה מספקת. בקרה מתחילה בזה שמישהו הגדיר מה אמור לקרות, ובודק אם זה מה שקרה.
מה שווה לעשות מחר
מי שכבר מפעיל מערכת AI בעסק יכול לבנות את הבדיקה הזאת בערב אחד. 20 מקרים מהארכיון, עמודה של תשובות נכונות, ריצה, ספירה. מי שרק שוקל להיכנס לתחום יגלה שהאוסף הזה הוא גם מסמך הדרישות הטוב ביותר שהוא יכתוב, כי הוא מראה בדיוק אילו שאלות חוזרות ואיפה התהליך נשבר. מי שרוצה להבין קודם את הלוגיקה, כתבנו על שלושת הצעדים לבניית סוכן AI מותאם.
ובכל מקרה, כשספק מציג מערכת, שווה לבקש לראות אותה על עשרים מקרים אמיתיים מהעסק ולא על הדגמה מוכנה. התשובה לבקשה הזאת היא לרוב אינפורמטיבית יותר מההדגמה עצמה.
