הערכת LLM: מבנצ'מרקים ציבוריים לסט הזהב שלך

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

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

גם הסדר חשוב, והספק שמוכר לכם את המודל אומר זאת בעצמו. מדריך ה־agents של OpenAI מצמצם את בחירת המודל לשלושה שלבים, בסדר הזה: ״הגדירו evals כדי לקבוע baseline ביצועים״, ״התמקדו בעמידה ביעד הדיוק שלכם עם המודלים הטובים ביותר הזמינים״, ״בצעו אופטימיזציה לעלות ול־latency על ידי החלפת מודלים גדולים במודלים קטנים יותר כשאפשר״.¹ הערכה באה ראשונה, כי שלבים שתיים ושלוש חסרי משמעות בלי מספר.

סט זהב הוא רשימת קלטים, לכל אחד תשובה כתובה, ו־grader שמחליט אם פלט מתאים. הוא משעמם, הוא קטן, והוא הארטיפקט היחיד בפרק הזה שהוא שלכם. זה שנבנה כאן כולל עשרים משימות על תיקייה של חמישה קבצים — לא השלושה של פרק 23, ולכן התשובות אינן אותן תשובות — וה־grader נכתב לפני שה־agent רץ:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

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

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

קראו את רווחי הסמך לפני המנצח. הריצות של זרוע B נעות מ־11% עד 47%; של זרוע A מ־3% עד 30%. הן חופפות לאורך רוב הטווח, וזה הממצא של פרק 4 שמגיע בדיוק למקום שהובטח: עשרים מקרים לא יכולים לדרג ארבע מערכות. פרק 15 חידד זאת דרך השאלה המזווגת — מתוך המקרים שבהם שתי זרועות חולקות, עד כמה החלוקה חד־צדדית? — כי הקושי המשותף של הסט מתקזז. הנה כל זוג:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

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

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

עכשיו הממצא שמשנה את האופן שבו תקראו כל benchmark שתראו אי פעם. קחו את אותם מאתיים תמלילים — עשרים משימות, עשר הרצות, אף token לא נוצר מחדש — ותנו להם ציון בשלוש דרכים:

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

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

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

כל עובדה נכונה בערך שלושה רבעים מהזמן; דרישה שכל השלוש יהיו נכונות בבת אחת חוצה את הציון, ו־$0.77^3 = 0.457$ קרוב מספיק ל־0.50 שנמדד כדי להראות מאיפה הגיעה הירידה. בהכללה:

קראו את שורת 0.90 מול שורת 0.95 ב־$k = 10$: שיפור של חמש נקודות לכל עובדה הופך לעשרים וחמש נקודות בצירוף. שום דבר לא רציף השתבש במודל. עקומה חלקה שנקראת דרך מדד הכול־או־כלום נראית כמו קפיצה — וזה בדיוק הטיעון של Schaeffer, Miranda ו־Koyejo על יכולות מתהוות, שפרק 10 דחה לכאן.² הביקורת שלהם מצאה שלכל היותר 5 מתוך 39 המדדים המועדפים של BIG-Bench מציגים emergence בכלל, כאשר שני מדדים דיסקונטינואיים אחראים ליותר מ־92% מהמקרים הנטענים.

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

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

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

התרומה של τ-bench היא המדד לזה. המאמר מגדיר אותו בפשטות: ״אנו מציעים מדד חדש – pass^k (pass hat k), המוגדר כסיכוי שכל k ניסויי המשימה הבלתי־תלויים והזהים יצליחו, בממוצע על פני משימות״.⁴ הריצו כל משימה $n$ פעמים, ספרו את $c$ ההצלחות, והאומדים חסרי ההטיה הם:

השני הוא pass@k המוכר מיצירת קוד: הסיכוי שלפחות אחד מתוך $k$ ניסיונות יצליח. שימו אותם זה לצד זה על אותם ספירות מדודות והם נעים בכיוונים מנוגדים:

אותן הרצות, אותו grader, אותן עשרים משימות. עמודה אחת אומרת שהמערכת משתפרת עם יותר ניסיונות והאחרת אומרת שהיא מחמירה, ושתיהן נכונות, כי הן עונות על שאלות שונות. pass@k הוא המדד הנכון כשאדם מסנן את הפלט — יצירת קוד, טיוטות, סיעור מוחות — והניסיונות הנוספים זולים. pass^k הוא המדד הנכון כשה־agent פועל בלי מסנן, וזה מה ש־״agent״ אומר. פרסום הראשון במקום שבו השני חל הוא ההגזמה הנפוצה ביותר בתחום הזה, והכותרת של τ-bench עצמו היא הגרסה הישרה: gpt-4o בכ־61% pass^1 ב־retail יורד לכ־25% ב־pass^8.⁴

ועכשיו העוקץ במספרים שלי. pass^10 על פני עשרים המשימות שלי הוא 5.0%: בדיוק משימה אחת מתוך עשרים נפתרה בכל עשר ההרצות. המשימה הזו היא t19, ״האם deploy 42 הצליח?״, והנה שתיים מתוך עשר התשובות שה־rubric דירג כנכונות:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

הראשונה אף פעם לא עונה. השנייה מוסיפה טענה שקרית — deploy 41 בוצע לו rollback. שתיהן התאימו ל־/succe|yes/. המשימה היחידה שמחזיקה את pass^10 מעל אפס היא ארטיפקט של grader, ולכן המספר האמיתי הוא אפס, ושום אגרגציה לא הייתה מראה לי את זה. דגימת התמלילים שמאחורי המשימה עם הציון הטוב ביותר היא המקום שבו graders הולכים למות.

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

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

טווח של שלושים נקודות במערכת שלא השתנתה. אם תריצו את הסוויטה פעם אחת לפני שחרור ופעם אחת אחריו, ״שיפור״ של שמונה נקודות נמצא בתוך הפיזור הזה ותשיקו אותו מתוך אמונה שאתם גרמתם לו. לכן רווח הסמך המאוגם למעלה — 26.0% [20.4, 32.5] — צר מדי מכדי לצטט אותו לבדו: הוא מתייחס למאתיים ניסויים מתואמים כאילו היו מאתיים בלתי־תלויים. הסיכום הישר של הערכת agent הוא ממוצע וגם פיזור על פני חזרות, וכמעט אף אחד לא מפרסם את השני.

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

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

השופט אמר PASS שישים פעמים מתוך שישים. הוא היה מדווח על ה־agent הזה ב־100% דיוק על סט שבו האדם נותן לו 18%. שופט בלי כוח הבחנה אינו מכשיר רועש; הוא פונקציה קבועה, ופונקציה קבועה נותנת למערכת הטובה ביותר ולמערכת הגרועה ביותר שלכם אותו ציון.

Prompting לא הציל אותו. ארבע וריאציות, אותם שישים פריטים:

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

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

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

הוא בחר בעמדה A ארבעים פעמים מתוך ארבעים. ה־50% על נכונות אינם כשירות חלקית — זו אריתמטיקה, כי התשובה הנכונה יושבת בעמדה A בדיוק במחצית הניסויים. עקביות כאן מוגדרת כפי ש־MT-Bench מגדיר אותה, ״אחוז המקרים שבהם שופט נותן תוצאות עקביות כאשר מחליפים את סדר שני ה־assistants״, מה שמאפשר להשוואה להיות תפוחים לתפוחים: GPT-4 מקבל 65.0% במדד הזה, ו־few-shot prompting העלה אותו ל־77.5%.⁵ שלי מקבל אפס.

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

הערה מתודולוגית ששווה יותר מהתוצאה. הרצתי גם מבחן אריכות: אותה תשובה נכונה, עותק אחד מרופד במשפט בן 36 מילים שלא מוסיף דבר. השופט העדיף את הגרסה הארוכה בדיוק ב־50% מהניסויים — מה שנראה כמו היעדר הטיית אריכות ואינו כזה כלל, כי שופט שתמיד בוחר בעמדה A מקבל 50% בכל זיווג מאוזן שהוא. אי אפשר למדוד הטיה שנייה לפני ששולטים בראשונה. החלפת עמדות אינה שיפור שמוסיפים מאוחר יותר; היא מה שהופך כל מדידה אחרת לניתנת לפרשנות.

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

זהו פאנל ה־Python השלישי והאחרון שהוכרז בקורס, והסיבה היא המקום שממנו מגיעים המספרים הציבוריים. lm-evaluation-harness מכסה ״יותר מ־60 benchmarks אקדמיים סטנדרטיים ל־LLMs, עם מאות תתי־משימות ווריאנטים ממומשים״ והוא ״ה־backend של Open LLM Leaderboard הפופולרי של Hugging Face״; HELM, SWE-bench ו־τ-bench הם חבילות Python עם נקודות כניסה ב־Python.⁶ להריץ את המודל שלכם מול מספר שפורסם פירושו להריץ את הקוד שלהם, וביום שבו תרצו להשוות למספר שמישהו ציטט, זו האקוסיסטמה שבה אתם נמצאים:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

הסיבה השנייה היא שמדידה אחת בפרק הזה בלתי אפשרית מעל HTTP. Contamination — דליפת סט הבדיקה לנתוני האימון — הוא הכשל שהופך benchmark ציבורי לחסר משמעות בשקט, והחיישן החד ביותר עבורו צריך את ה־loss של המודל עצמו, שאף chat API לא מחזיר. זו cross-entropy לכל token מפרק 8, מכוונת לשאלה על זיכרון:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

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

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

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

שלוש מתוך חמש המחרוזות המפורסמות הושלמו מילה במילה משש מילים; אף אחת מחמש הטריות לא. זה מודל של חצי מיליארד פרמטרים מדקלם את MIT License. אם ה־benchmark שלכם נמצא ברשת הציבורית, הניחו שהוא נמצא במשקלים. זה גם הטיעון של כל הפרק: סט זהב שכתבתם מהנתונים שלכם, ושמרתם מחוץ לכל repository ש־crawler קורא, הוא סט הבדיקה היחיד שאתם יכולים להיות בטוחים שמעולם לא אומן עליו.

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

קחו את הטבלה ולא אף שורה בודדת. ה־benchmarks ה־agentic כולם מציבים בני אדם הרבה מעל מודלים, ההפך מה־benchmarks של ידע וזה הסיכום הטוב ביותר בשורה אחת למצב התחום; המספרים שלהם מזדקנים בתוך חודשים, אז צטטו אותם עם התאריך שבו קראתם אותם; וכל אחד מהם מודד משימה שאינה שלכם.

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

עלות לכל משימה שנפתרה, לא לכל קריאה. ה־agent עולה $0.001345 לכל ניסיון ו־$0.005172 לכל משימה שבאמת נפתרה — פי 3.85 יותר, כי שלושה רבעים מהניסיונות לא מייצרים כלום. Latency מתנהג באותה דרך: 1,213 ms לכל ניסיון, 4,667 ms לכל משימה שנפתרה. כל retry, כל שאלה חוזרת, כל מסלול שננטש נמצאים במספר השני ובלתי נראים בראשון.

דיאגנוסטיקה שמנצחת דיוק. ב־123 מתוך 200 ניסיונות ה־agent ענה בלי לקרוא אפילו לכלי אחד — הוא ניחש במקום לבדוק. בפיצול לפי זה:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

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

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

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

וכלל בירושה מפרק 17: לעולם אל תבצעו assert על פלט מדויק. בצעו assert על תכונות — JSON תקין, schema נכון, הכלי הנכון נקרא, מספר בתוך tolerance, תת־מחרוזת נדרשת נוכחת. עמודת ההתאמה המדויקת בתחילת הפרק היא מה שקורה כששוברים את הכלל הזה.

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

מדדו את ההטיה, אל תניחו אותה. מה שלא תאמינו על התנהגות מודל מול שמות, ניבים, מגדרים או לאומים, זו תכונה מדידה של ה־pipeline שלכם, והמכשיר הוא זה שכבר יש לכם: קחו את סט הזהב, שנו רק את המאפיין, והשוו בזוגות. HELM קיים בדיוק כי דיוק לבדו דווח במקום שבו גם הטיה, רעילות, כיול ו־robustness היו ניתנים להכרעה.⁸ model card של ספק היא נקודת התחלה, לא ראיה על הקלטים שלכם.

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

Retention, אימון ו־residency, נקרא ב־7 בספטמבר 2026. אלה משתנים, לכן רשמו את התאריך ליד התשובה. דף המדיניות של Anthropic קובע: ״כברירת מחדל, לא נשתמש בקלטים או בפלטים שלכם מהמוצרים המסחריים שלנו (למשל Claude for Work, Anthropic API, Claude Gov וכו') כדי לאמן את המודלים שלנו״, למעט תוכן שאתם מגישים במפורש כמשוב, שנשמר ״עד 5 שנים״.¹⁶ תיעוד בקרות הנתונים של OpenAI קובע ש״נתונים הנשלחים ל־OpenAI API אינם משמשים לאימון או לשיפור מודלי OpenAI (אלא אם בחרתם במפורש לשתף איתנו נתונים)״, מתאר שמירת ברירת מחדל של שלושים יום ללוגים לניטור שימוש לרעה, ומציע Zero Data Retention, ש״מחריג תוכן לקוחות מלוגי ניטור שימוש לרעה״, וכן data residency ניתן להגדרה על פני רשימת אזורים.¹⁷

ארבע שאלות לקבל בכתב לפני קריאת הפרודקשן הראשונה, כי לכל אחת יש בעלים אחר: האם הנתונים שלי משמשים לאימון; כמה זמן הם נשמרים ועל ידי מי; איפה הם מעובדים ומאוחסנים; ומה קורה לכל זה אם אני משתמש ב־reseller, gateway או aggregator ולא ישירות בספק. האחרונה היא המקום שבו רוב ההפתעות גרות, ושום benchmark לא יספר לכם.

עכשיו יש לכם את המכשיר: סט זהב בבעלותכם, רווח סמך על כל מספר, מבחן מזווג לכל השוואה, pass^k להרצות שלא הראיתם לאף אחד, שופט מדוד, וחיישן לשאלה אם ציון ציבורי אומר משהו. את טענת הסיום של פרק 23 אפשר עכשיו לבדוק במקום להצהיר — harness הופך agent לבר־משילות, לא לנכון — והבדיקה לקחה מאתיים הרצות ושמונה דקות.

יש תכונה אחת של agent שכל זה לא מודד, והיא זו שבגללה אנשים מפוטרים.

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

פרק 30 הוא זה: prompt injection, הטריפקטה הקטלנית של נתונים פרטיים, תוכן לא מהימן ותקשורת חיצונית, ומה עולה לתת ל־agent הרשאות אמיתיות. הוא נפתח בתצפית שהפרק הזה נמנע ממנה — שאותו ציון עובר תואם גם ל־agent שעושה בדיוק מה שתוקף כתב בקובץ שנאמר לו לקרוא.

כל מספר למעלה הופק על מכונה אחת, ושום דבר מזה לא נגע ב־endpoint בתשלום. ה־agent הוא ה־loop של פרק 23 עם שניים מארבעת הכלים שלו על פני תיקייה של חמישה קבצים; המודל מאחורי הפורט הוא Qwen/Qwen2.5-0.5B-Instruct, חשוף דרך שרת קטן באותה צורה כמו endpoint של chat completions בדיוק כמו בפרק 23, אבל ב־half precision על GPU צרכני אחד במקום על ה־CPU של אותו פרק. העלויות משתמשות בתעריפים של פרק 16 — $2.00 למיליון input tokens ו־$12.00 למיליון output — מיושמים על ספירות token מדודות. ההרצות החוזרות משתמשות ב־temperature 0.7 עם seeds קבועים כך שכל הסט ניתן לשחזור; טבלת ארבע הזרועות היא greedy. רווחי הסמך הם Wilson ב־95%, השוואות מזווגות הן מבחני סימן מדויקים דו־צדדיים על הזוגות הלא־תואמים; רווח Wilson הוא של פרק 4 ומבחן הסימן המזווג המדויק הוא של פרק 15, שניהם בשימוש חוזר ללא שינוי. התוויות האנושיות הן שלי, הוחלו על שישים תשובות תחת הכלל הכתוב שצוטט בטקסט. קראו כל סדר גודל כאן כתכונה של מודל בן חצי מיליארד פרמטרים וכל שיטה כניתנת להעברה: מודל גדול יותר מעלה את כל המספרים ולא מזיז אף אחד מהמכשירים.