98.9% במבחן ו-90.5% בשאלות שהמודל לא ראה. באיזה מהמספרים לסמוך כשמדובר בפיצ'ר ה-AI שלכם?
דמיינו ש-Claude בונה מבחן לבוט התמיכה שלכם ומשפר את הפרומפט בשינוי אחד בכל סבב, כשחלק מהשאלות מוסתר ממנו. כך עובדים build-eval ו-hillclimb ב-Claude Code.
במספרים
במאמר הזה8
/claude-api build-eval ו-/claude-api hillclimb הן שתי תת-פקודות של הסקיל claude-api שמגיע מובנה ב-Claude Code (פוסט של Anthropic מ-28 בספטמבר 2026). build-eval בונה בתוך הריפו שלכם סט בדיקות (eval) לפיצ'ר שעובד מול Claude API: דוגמאות מפרודקשן, מטיקטים או שכתבתם ביד, בודק (grader, קוד או מודל-שופט שני), והרצת בסיס עם רווח סמך. hillclimb משפר את הפיצ'ר מול הסט הזה בשינוי אחד בכל סבב ומחזיק חלק מהדוגמאות מוסתר כדי לתפוס התאמת-יתר. בדוגמה של Anthropic בוט תמיכה הגיע ל-98.9% על 30 הטיקטים שעליהם רץ החיפוש, אבל המספר הכן אחר: 90.5% על 14 טיקטים מוסתרים מול 78.6% בהתחלה, בערך בחמישית מהעלות. הפעלה: claude update, ואז הפקודות בתוך Claude Code. משלמים רק על הטוקנים של ההרצות.
כל מי שהכניס מודל למוצר מכיר את הרגע הזה. שיניתם את הפרומפט, הרצתם את חמש הדוגמאות האהובות, נראה טוב יותר. העליתם. שבוע אחר כך התמיכה מביאה טיקט שפעם נפתר נכון, ועכשיו לא.
את ה"נראה טוב יותר" אף אחד לא מדד. את חמש הדוגמאות שאתם זוכרים בעל פה הפרומפט עובר בכל מקרה: הוא נכתב סביבן.
ב-28 בספטמבר Anthropic פרסמה הסבר איך בונים מבחן כזה ומשפרים מולו פיצ'ר בלי לרמות את עצמכם. היא גם הוסיפה לסקיל claude-api שתי תת-פקודות שעושות את העבודה בשבילכם: build-eval ו-hillclimb. החלק הכי שימושי בפוסט הוא דוגמה עם שני מספרים שהסיכומים ברשת כבר הספיקו לבלבל ביניהם.
למי זה מתאים
Eval (סט בדיקות) הגיוני בכל מקום שבו לקריאה למודל יש תשובה נכונה, או לפחות קריטריון איכות ברור. למשל:
- בוט תמיכה שמחליט אם להחזיר ללקוח כסף;
- מסווג שמנתב מיילים או פניות לתורים;
- פרומפט שכותב תשובה ללקוח, כשאתם יודעים לומר מה חייב להופיע בתשובה טובה.
הפוסט של Anthropic עצמו מדגים נתב מיילים. אם הפיצ'ר שלכם דומה למשהו ברשימה, ההמשך בשבילכם.
build-eval: המבחן נבנה מהנתונים שלכם
/claude-api build-eval מתחיל בראיון: Claude שואל אתכם על הפיצ'ר, בונה את הסט ישר בתוך הריפו ובכמה נקודות מחכה לאישור שלכם.
- 1
דוגמאות
לפי סדר עדיפות: תמלילים מפרודקשן (קודם Claude ישאל על שמירת נתונים ומידע רגיש), אחר כך דיווחי באגים וטיקטים של תמיכה, אחר כך 5–10 מקרים שאתם כותבים ביד, ורק בסוף מקרים שנוצרים מהקוד. מותר להשתמש בנתונים סינתטיים, אבל הם נשענים על כמה דוגמאות אמיתיות שלכם.
- 2
עמוד בדיקת קלטים
הסקיל יוצר עמוד פשוט עם כל הקלטים ומחכה עד שתאשרו אותם.
- 3
בודק
Claude מציע את הבודק (grader) הזול ביותר שמתאים לפורמט התשובה. עוד על כך בהמשך.
- 4
בדיקת הבודק
Claude מעריך בעצמו כמה מקרים ושואל אם הייתם נותנים למישהו מהם ציון אחר.
- 5
גודל והרצת בסיס
הסקיל אומר מה גודל ההרצה (מקרים × חזרות × מודל וזמן משוער), מריץ את הגרסה הנוכחית ומדפיס תוצאה עם רווח סמך.
- 6
אבחון
בזמן הרצת הבסיס ה-grader רץ פעמיים על אותה תשובה, ונבדקים timeouts, שגיאות API ותשובות קטועות. אם הבסיס כבר בסביבות 95% ומעלה, הסקיל יזהיר שאין לאן לטפס באיכות.
כשגרסת הבסיס כבר מגיעה לסביבות 95%, אין טעם לרדוף אחרי איכות: כל שינוי טובע ברעש. במקרה כזה הסקיל ממליץ לכוון לעלות או לזמן תגובה.
איזה בודק Claude יבחר
אם התשובות האפשריות מעטות ומוגבלות, הבדיקה נכתבת בקוד: התאמה מדויקת, תווית מרשימה סגורה, JSON לפי סכמה, טסטים שעוברים. זה זול ולא מתווכח עם עצמו.
אם יש הרבה תשובות נכונות אבל קריטריון ברור, נכנס LLM-as-judge: מודל שני קורא את הקלט, הפלט ומחוון (rubric). המחוון כתוב כטענות שאפשר לבדוק, לא כסולם מ-1 עד 5. אם יש גרסת בסיס להשוואה, השופט קורא את שתי התשובות בסדר אקראי, בלי לדעת איזו מהן הבסיס, ובוחר את הטובה יותר. את מודל השופט בוחרים אתם, והוא לא אמור להיות המודל שנבדק. את אותו עיקרון, "מי שבנה לא מאשר", ראינו בסקיל ביקורת האבטחה של Cloudflare.
אחרי build-eval נשארים בריפו המקרים, ה-grader, סקריפט ההרצה (runner), שורת JSON אחת ותמליל מלא אחד לכל מקרה, ועמוד report.html עם רשימת הציונים וקישור לתמליל של כל מקרה. אם צריך גרף, בקשו, ו-Claude יבנה אותו כעמוד נוסף לידו. עמודים כאלה סטטיים כברירת מחדל: הם נפתחים מקומית ולא טוענים כלום מהרשת.
hillclimb: שינוי אחד בכל סבב
/claude-api hillclimb לוקח eval קיים ומשפר מולו את הפיצ'ר. מה מותר לשנות, מחליטים אתם: פרומפט המערכת, סקילים וקובצי הוראות, תיאורי כלים, מודל, effort ופרמטרים אחרים של ה-API, קוד המעטפת (harness). גם המטרה שלכם: איכות, או עלות כשהאיכות נשמרת.
- 1
חלוקה ל-train ו-test
הסט מחולק באקראי לשני חלקים. על train Claude מחפש שיפורים, את test הוא לא רואה.
- 2
בדיקת רעש
לפני הסבב הראשון Claude בודק שהרעש של ה-eval קטן מהשיפור הקטן ביותר שבגללו הייתם משנים משהו. אם לא, הוא אומר את זה ומציע עוד חזרות או עוד מקרים.
- 3
סבב
Claude קורא את תמלילי ה-train של הסבב הקודם ומציע שינוי אחד כ-patch. הוא מכוון לשורש הכשל: לשכתב סעיף, להוסיף כלל חסר, ולא לנסח מחדש שורה.
- 4
החלטה
גם train וגם test עלו: ה-patch נשאר. רק train עלה ו-test עומד: חשד להתאמת-יתר, חוזרים אחורה. הייתה נסיגה: חוזרים אחורה.
- 5
תקיעה
אם הציון עומד שניים-שלושה סבבים, Claude לא משנה כלום אלא ממיין את כל הכשלים שנשארו ב-train לפי סיבה. כך מתגלים מקרים דו-משמעיים, שגיאות במעטפת ופיזור אקראי. לסבבים הבאים נכנסים רק כשלים אמיתיים.
- 6
סיום
הקוד נשאר בגרסה שהייתה הטובה ביותר על test לפי המטרה שלכם. הדוח משווה את test לבסיס עם רווחי סמך. אם השיפור בתוך הרעש, Claude אומר במפורש לא למזג.
מלבד החלוקה ל-train ו-test, לסקיל יש עוד שתי הגנות מפני התאמת-יתר. תוכן הכשלים אף פעם לא מודבק לפרומפט, אחרת המודל ילמד בעל פה את התשובות למבחן. והתשובות הנכונות מוחזקות מחוץ להישג ידו של המודל, כי מודלים לפעמים מוצאים אותן ישירות.
הדוגמה של Anthropic: איזה מספר אמיתי
Anthropic הריצה hillclimb על בנצ'מרק תמיכה פנימי, במטרה להוריד עלות ולשפר איכות. בסט היו 44 טיקטים: 30 לחיפוש ו-14 בצד. נקודת ההתחלה: Opus 4.8 ב-effort ברירת המחדל (high), דיוק החלטות של 74.4% על טיקטי החיפוש ו-4.6 סנט לטיקט.
המסלול נראה כך. קודם ביקורת על הפרומפט, שהוציאה ממנו "טקסים" חובה של קריאות לכלים, שלב טיוטה (scratchpad) וכללים סותרים. אחר כך Opus 5.5 ב-low effort: 87.8% ו-1.9 סנט. אחר כך דרגה אחת למטה, Sonnet 5 ב-low effort: 88.9% ובערך סנט. ולבסוף כללי ניתוב והפניה הדדית לתקרת ההחזר בפרומפט הביאו את Sonnet 5 ל-98.9% בערך באותה עלות.
כאן הסיכומים טועים: 98.9% זה הציון על 30 הטיקטים שעליהם רץ החיפוש, אלה ש-hillclimb קרא סבב אחרי סבב.
| 30 טיקטי חיפוש (train) | 14 טיקטים מוסתרים (test) | |
|---|---|---|
| הגדרה מקורית: Opus 4.8, high effort | 74.4% | 78.6% |
| סופי: Sonnet 5, low effort, פרומפט משופר | 98.9% | 90.5% |
| עלות לטיקט | 4.6 סנט → בערך סנט | בערך חמישית מהמקור |
התוצאה הכנה נמצאת בעמודה השנייה. על טיקטים שהחיפוש לא ראה, הדיוק עלה מ-78.6% ל-90.5% והעלות ירדה בערך פי חמישה. זו תוצאה טובה. אבל הפער בין 98.9% ל-90.5% הוא בדיוק התאמת-היתר שבשבילה קיים ה-test. להציג את 98.9% כתוצאה פירושו לחזור על הטעות שהסקיל נועד למנוע.
חלק מהחיסכון הגיע מהמחירים: ב-Opus 5.5 טוקני קלט ופלט זולים ב-20% מאשר ב-Opus 4.8, וקריאה מה-cache זולה ב-60%. למה עלות משימה היא לא עלות טוקן, הסברנו בהשוואה בין GPT-6 Sol ל-Opus 5.5.
דוגמה שנייה: סקיל ששיפר את עצמו
Anthropic הריצה hillclimb גם על הסקיל claude-api עצמו. ה-eval נבנה מהתיעוד שלהם ובודק אם הסקיל כותב קוד נכון ל-API שלהם. במשך 24 סבבים הציון עלה מ-66.1% ל-87.9%, והממצאים בדרך מעניינים יותר מהמספר.
קודם Claude מצא שבסקיל חסר כיסוי לשמונה פיצ'רים. סעיפים עליהם נתנו 74%, ותיקון טבלאות הטיפוסים של C# ו-Java נתן 77%. אחר כך הציון נתקע לשני סבבים, ומיון הכשלים לפי סיבה הראה שהתוכן כבר שם, אבל Claude כותב צורות ישנות של ה-API מהזיכרון. בראש הסקיל נוספה טבלה "איך שאתה זוכר → איך שזה עכשיו", למשל מ-extended thinking עם תקציב קבוע ל-adaptive thinking. זה נתן 80%.
הממצא השלישי הכי שימושי בשבילכם. משימות שלא השתפרו בכלל התבררו כפגומות. אחת ביקשה קוד שתופס סוג שגיאה אחד, וה-grader שלה ציפה לשרשרת של לפחות שלוש. ההוראות של grader אחר סתרו את התיעוד, ובדיקה מול ה-API האמיתי הראתה שהתיעוד צודק. אחרי התיקונים האלה ועוד כמה שינויים בסקיל הציון הגיע לבערך 88%.
איפה זה לא יעבוד
את המגבלות Anthropic מפרטת בעצמה, וכדאי לקרוא אותן לפני ההרצה.
- Eval הוא לא פרודקשן. הדוגמה מהפוסט: ה-eval מרוויח מזיהוי טקסט בתמונות (OCR), hillclimb מוסיף כלי OCR למעטפת, הציון עולה, ובפרודקשן OCR כמעט לא נחוץ.
- צריך מרווח. המודל החזק ביותר ב-effort המקסימלי צריך לקבל ציון נמוך בבירור מ-100%, אחרת אין מול מה להשוות שינויים.
- אל תבחרו מקרים רק כי המודל של היום נכשל בהם. כך ה-eval ימדוד את נקודות התורפה של מודל אחד, ולא את מה שקשה במשימה שלכם. גם תנועת משתמשים יכולה לנטות לקל: אנשים מנסים את מה שהם מצפים שיעבוד.
- רעש מתחבא בסביבה. קובץ או היסטוריית git שנשארו מהרצה קודמת יכולים לגלות לסוכן את התשובה.
- בקשה פתוחה "שפר את המעטפת" נתקעת. hillclimb עובד הכי טוב איפה שהשינוי זול ואפשר לייחס את הציון לעריכה: פרומפטים, סקילים, תיאורים. כמה עולה המעטפת סביב מודל מלכתחילה, הראה מחקר HarnessTax.
- המספרים של שתי הדוגמאות מבנצ'מרקים פנימיים של Anthropic. במוצר שלכם הם יהיו אחרים.
איך מריצים אצלכם
הסקיל claude-api מגיע בתוך Claude Code, אז אין מה להתקין בנפרד. עדכנו והפעילו את תת-הפקודות:
$ claude update> /claude-api build-eval> /claude-api hillclimb
אפשר לכוון את build-eval על ידי גישה לדוגמאות, למשל ל-traces. את hillclimb מריצים כשכבר יש eval, ומגדירים מראש את המטרה: איכות, או עלות כשהאיכות נשמרת.
לפקודות אין מחיר משלהן. משלמים על הטוקנים של הרצות ה-eval לפי תעריפי ה-API הרגילים, והסקיל אומר את גודל ההרצה והזמן המשוער לפני הרצת הבסיס. Anthropic לא נותנת סכום להרצה: הוא תלוי במספר המקרים, בחזרות ובמודל. מגרסה 2.1.285 אי אפשר להריץ את /claude-api מלקוחות Remote Control. באותה גרסה תשובות שנקטעו ב-max_tokens מסומנות כ-truncated ונספרות בנפרד, במקום להיכנס לממוצע.
הדעה שלנו: להתחיל עם build-eval ומבט כן בעמוד הציונים, לא עם hillclimb. אם קראתם תריסר תמלילים עם ציון ואתם לא מסכימים עם הבודק, שום כמות סבבים לא תעזור אחר כך. Anthropic כותבת אותו דבר: טעויות בציון הן בין הסיבות הנפוצות ביותר לכך ש-eval מוגדר לא נכון.
גרסאות ומחירים נכון ל-5 באוקטובר 2026
תיאור הפקודות לפי הפוסט של Anthropic מ-28 בספטמבר 2026 וה-changelog של Claude Code בגרסאות 2.1.284–2.1.285. מודלים, המחירים שלהם וההתנהגות של הסקיל מתעדכנים: לפני הרצה בדקו את גרסת Claude Code שלכם ואת תעריפי ה-API העדכניים.
מקורות3להרחיב
- Lance Martin, Anthropic, “Automating eval design and hillclimbing with Claude”, claude.dev, 28 בספטמבר 2026 — https://claude.dev/blog/automating-eval-design-and-hillclimbing/
- Claude Code changelog, גרסאות 2.1.284 ו-2.1.285, 28–29 בספטמבר 2026 — https://code.claude.com/docs/en/changelog
- anthropics/claude-code, CHANGELOG.md — https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
תגובות