בשנת 2019, עולם הקולנוע סער סביב "קפטן מארוול". עוד לפני שהסרט יצא לבתי הקולנוע, אתר דירוג הסרטים - Rotten Tomatoes הפך לזירה של קרב בין מבקרים מקצועיים לבין משתמשים אנונימיים. גל של ביקורות שליליות הופיע באתר, כשרובם הגדול כלל לא צפה בסרט. אולפני מארוול היו המומים. שובר קופות ענק היה תחת מתקפת reviews ממוקדת של קהל שאפילו לא ראה אותו עדיין. 

בעקבות המשבר, ב Rotten Tomatoes הבינו שיש כאן בעיית מדידה והחליטו לעשות שינוי מוצרי תקדימי. 

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

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

אז איך אנחנו יכולים לוודא שהמודל שלנו "מתנהג יפה" בפרודקשן לאורך זמן?

מהם בעצם LLM Evaluations (או בקיצור: LLM-Evals)?

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

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

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

עד כמה התשובה בהירה ושוטפת?

האם היא נכונה עובדתית (truthfulness)?

האם היא שומרת על טון מתאים למשתמש (למשל, שירותי ואדיב)?

כמה היא עלולה להיות רעילה (toxicity) או בעלת הטיות לא רצויות (bias)?

LLM-Evals, אם כן, היא קבוצה של כלים ושיטות להערכה אוטומטית (יחסית) של איכות התשובות שמודלי שפה מייצרים – בלי שנצטרך לגייס צוות ענק של מומחי תוכן שייתייגו את הדאטה ויעריכו כל תשובה ותשובה. בפוסט הזה, אתמקד בשיטת הערכה פופולארית שנקראת ״LLM-as-a-Judge" שבה נשלח הטקסט המג׳ונרט למודל שפה נוסף ששופט את טיבו (נקרא לו בפוסט הזה ״מודל שופט״). השיטה הזו מאפשרת לנו -מצד אחד- ליהנות מהסקיילביליות שנדרשת בפרודקשן, ומאידך לשלב איכויות שיפוט של מומחי תוכן כשהערכה גנרית לא מספיקה. 

׳LLM-evals are the new ‘Secret Sauce 

אז למה llm-evals פתאום מקבלים תהודה? אם לפני כמה שנים היינו מדברים על יתרון תחרותי המתבטא בקוד, היום היכולת "לייצר קוד" נמצאת בידיים של כולם. Everything is programmable כפי שטבע דארמש שאה, מייסד Hubspot. 

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

אם כן, איך מזהים סטארטאפים מבטיחים בעידן שבו הכל אפשרי? משקיעים כמו האקסלרטור המצליח Y Combinator שיצאו ממנו חברות כמו airbnb ו- Stripe  בוחנים חוסן של סטאראפ על סמך תשתית הAI evaluations שבנה, כאינדיקציה חזקה לנבדלות בעידן שבו זול וקל לבנות בן לילה מוצר AI מתחרה. מה שמבדל באמת חברת מוצר אחת ממשנתה הוא היכולת שלנו להעריך ולשפר את איכות התשובות שמודלי השפה מספקים, ולוודא שהן עונות על הצורך המדויק של המשתמש. 

LLM-evals: במגרש של מי זה יושב?

בעבר, איכות הפיצ׳ר הייתה משוייכת אוטומטית לאנשי הפיתוח וה-QA – הרי בסוף מדובר בקוד. אם פעם יכולנו להסתפק בבדיקות QA וקוד תקין, היום כמעט 100% מהערך של פיצ׳רים מבוססי LLM תלוי באיכויות הטקסטואלית שמייצר המודל. ולכן, הגדרת ה-Acceptance Criteria והסטנדרטים לאיכות המודל – ובעצם קביעה של מה נחשב "טוב" בעיני המשתמש – הופכת לאחריות מנהלי המוצר.

 אנחנו שומעים את מובילי המוצר של חברות כמו OpenAI ו-Anthropic מדברים על AI Evals כחלק מרכזי בתפקיד החדש של מנהלי המוצר. למעשה, האחריות על האיכות זולגת מהמפתחים ומהבודקים אל מנהלי המוצר. בעידן הנוכחי, שבו גם המתחרים משתמשים במודלים דומים, הערך האמיתי יגיע מפתרונות שמותאמים לעולם התוכן וליוזקייס הרלוונטי ביותר. כאן בדיוק נכנסת המומחיות של מנהלי המוצר, שמכירים לעומק את הפרסונה, התהליכים העסקיים והצרכים בשטח – ומסוגלים לבנות את מערך ה-Evals המדויק ביותר, ולהבטיח שהפלט באמת מועיל למשתמש. אנשי המוצר הופכים להיות שומרי הסף של תוצר המודל, ואחראים שהמוצר אכן מספק ערך אמיתי במקום סתם לייצר טקסט לא שימושי (או גרוע מכך, מטעה ומזיק).

אוקי, אז איך זה עובד?

הכלי המרכזי שלנו הוא ה-Golden Dataset – זהו מעין בנצ'מרק שמשמש כנקודת ייחוס להערכה של פלט המודל. ה-Golden Dataset מכיל תסריטים שמדמים את הקלט (input) שנשלח למודל הראשי, את הפלט שהוא מחזיר (output) ואת הציון שהפלט מקבל. למשל, במקרה של מוצר צ׳אטבוט, נכניס דוגמאות שמייצגות שאילתות של המשתמשים. עבור כל שאילתא ב-Golden Dataset נגדיר תשובה ונעריך אותה על סמך הקריטריונים שהגדרנו. ה-Golden Dataset משמש לנו כמצפן: הוא מייצג את "האמת" או נקודת הייחוס (Ground Truth) שלפיה המודל השופט אמור לקבוע אם פלט מסוים הוא טוב או לא. ולכן, נרצה לספק למודל השופט מגוון רחב של דוגמאות טובות ורעות.

 ברגע שאנחנו יודעים איך נבדוק אם משהו טוב או לא טוב, אנחנו עוברים לשלב הבא – בניית ה-Eval Prompt. אלו הם בעצם "חוקי המשחק" שאנחנו נותנים למודל השופט על מנת להנחות אותו כיצד לנתח את הדוגמאות ולהעריך לפי הקריטריונים שהגדרנו.

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

שופט השוואתי: משווה בין שני פלטים ובוחר מי טוב יותר (נהדר להשוואה בין שתי גרסאות שונות של הפרומפט הראשי של הפיצ׳ר או להשוואה בין מודלים שונים).

שופט לפי קריטריונים גנריים: מודד בהירות (Clarity), טון (Tone), מידת אריכות (Verbosity) ועוד. אידיאלי למקרים שבהם יש שורה של מאפיינים גנריים ואובייקטיביים שמאפיינים תשובה "איכותית".

שופט קונטקסטואלי: בודק תשובה אל מול "אמת מוחלטת" שמוזרקת כחלק מהקונטקסט (למשל, שעות הפתיחה של סניף x). בדוגמה הזו, אם ground truth הוא "פתוחים א-ה בין 8:00 ל-15:00", שופט קונטקסטואלי יבדוק אם התשובה המדוברת תואמת את המידע המדויק.

המטרה שלנו היא לא רק להרשים בדמו הראשוני, אלא להבטיח שהפיצ׳ר יישאר איכותי ועקבי גם חודשים אחרי ההשקה – וישמור על עקביות אפילו אם נחליפו במודל אחר. כדי לעשות את זה, אנו מגדירים מראש מה בדיוק אנחנו רוצים לשפוט: לדוגמה, Truthfulness (נאמנות לעובדות), Clarity (בהירות), Toxicity (רעילות) או Bias (הטיה). לעתים נרצה קריטריונים ייחודיים יותר שנדרשים בעולם התוכן של המוצר.

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

בנוסף, ככל שנגדיר ערכים בינאריים (True/False) או לכל היותר סקאלה פשוטה וחד משמעית ("נכון לגמרי" / "נכון חלקית" / "שגוי לגמרי"), נצמצם את הסיכוי לטעות שיפוט או אי הסכמה בין שופטים. 

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

רגע, קצת בעייתי לתת למודל "לשפוט" את עצמו, לא?

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

ועדיין, עולה התהייה אם אנחנו לא בעצם נותנים למודל ״לשמור על השמנת״ כאשר הוא שופט את ביצועיו. לכן הגישה הרווחת עושה שימוש במודל אחר שישפוט את פלט המודל הראשי. גם השיטה הזו לא חפה מבעיות; מחקרים מראים שלמודלי שפה גדולים עלולה להיות הטיה (Bias) זה נגד זה. כדי להתגבר על הקושי הזה, פותחה גישה נישתית בשם "LLM-as-a-Jury": במקום מודל שפה גדול כשופט, משתמשים במספר מודלי שפה קטנים שמעריכים את אותה תשובה משקללים את הממוצע. כך מצמצמים את ההטיה, ובנוסף נהנים מתהליך זול באופן משמעותי יותר (זול פי 7).

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

אז מה עושים מחר בבוקר?

הגדרת דרישות ופרמטרים

לכל פיצ'ר מבוסס LLM מגדירים מראש מה הופך את התשובה ל”מספקת”: דיוק (Accuracy), טון (Tone), בהירות (Clarity), הימנעות מדיסאינפורמציה, ועוד – תלוי בצרכים של המוצר.

בניית Golden Dataset ראשוני

תתחילו בקטן: אספו כמה עשרות או מאות שאלות אפשריות ביחס לפיצ’ר שיצרתם. תייגו תשובות כ”טובות” או “לא טובות” (או לפי סקאלה פשוטה שהגדרתם). למשל, בצ’אטבוט של חנות: וריאציות על השאלה “מהן שעות הפתיחה לסניף בראשון לציון?”, עם תשובות נכונות, חלקיות או שגויות.

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

כתיבת Evaluation Prompt

הסבירו למודל השופט מה הקריטריונים (Accuracy, Tone, וכו’), איך למדוד אותם, ואיך עליו להגיב לתשובות שעומדות או לא עומדות בסטנדרט שהצבתם. אם יש הרבה פרמטרים, אפשר להפריד לפרומפט ייעודי לכל פרמטר.

הרצה, השוואה ושיפור

הריצו את המודל השופט על ה-Golden Dataset שהכנתם, בחנו את התוצאות, וראו היכן הוא מסווג תשובות כשגויות או מוצלחות. הסוד הוא איטרציות. תריצו ותכווננו הן את הפרומפט הראשי של המודל (שמייצר את התשובות) והן את הפרומפט השיפוטי – עד שתגיעו לרמת איכות שעומדת בדרישות. 

ברגע שהמערכת עומדת בקריטריונים שהגדרתם, תוכלו לעקוב באופן שוטף גם אחרי עלייה לפרודקשן, להריץ בדיקות תקופתיות ולוודא שהאיכות נשמרת או משתפרת. קיימים בשוק לא מעט כלים שיאפשרו לכם לבנות בקלות את ה-llm evals שלכם. כמה דוגמאות הן  snorkle, mlflow arize ואפילו openai יצאו בחודשים האחרונים עם בטא לevals.  

״הכל אפשרי״* עם כוכבית

אנחנו חיים בעידן שבו “הכול אפשרי” בזכות הבינה המלאכותית—אבל לפעמים הגמישות הזו פותחת דלת גם למצבים פחות מחמיאים, אם לא מקפידים על בדיקות נכונות. אז תבנו Golden Dataset מדויק, תכתבו Eval Prompts חכמים ותפעילו מערך Evals קבוע. תראו איך כל התהליך הזה עושה את ההבדל בין מוצר “חמוד בדמו” למוצר שבאמת כובש את השוק.

 בפוסט הבא נקח את הAI evals לרמה הבאה כשנדבר על יצירת ״שופטים״ עבור Agents. כשנכנסים לממלכה הזו, כבר אי אפשר להסתפק רק ב”תשובה נכונה”- המודל צריך לנווט בשטח מורכב, לקבל החלטות ולהמשיך למסלול הבא בלי ללכת לאיבוד. ועד אז… may the evals be ever in your favor