typed judge במקום קריאה למודל: מה מדדתי ולמה לא קידמתי דבר

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

יש החלטות ב-workflow שקוד לא יכול לקבל, אבל התשובה שלהן סגורה: כן או לא, אחת מכמה אפשרויות, דירוג. היום language model מלא עונה עליהן. Jev הוא model מסוג אחר, "System One": הוא לא כותב טקסט, הוא מחזיר תשובה מוקלדת עם התפלגות. בדקתי אם הוא יכול להחליף את ה-model הגדול בנקודות כאלה. לא קידמתי דבר, ובדרך מצאתי כמה דברים שהמדידה שלי עצמה פספסה.

השאלה

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

הכלל לפני המדידה

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

ההגדרה

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

הזרימה

1. בחירת skill. על 65 מקרים שהוכרעו על ידי judge, ה-harness בחר את ה-skill הנכון ב-75% ו-Jev ב-43%. אבל Jev חסם 10 מתוך 14 טעינות מיותרות, וה-harness אפס מתוך 14. טעינה מיותרת עולה כ-2.7 אלף tokens. לכן החלטתי להשתמש בו כשער ולא כבוחר.
2. פער בנהלים, נקודה ראשונה. על 59 מקרים התאמה של 37% להכרעות קודמות. זה לא היה דיוק, ולא היה מדד בכלל: התוויות נגרדו מפרוזה, וחמש אי ההסכמות הראשונות היו כולן שגיאות פענוח. התוצאה נפסלה, והלקח הוא שתווית רעה מפילה ניסוי לפני שה-judge נבחן.
3. שאלה בלי שאלה. השער שמחליט אם ללמוד לא שלח שאלה בכלל. הקריאה נכשלה בקוד יציאה 2, והשער פשוט נשאר סגור. זה נראה כמו "אין שימוש", כי "אין שימוש" ו"שבור" נראים אותו דבר בדוח. תיקנתי: כעת הוא שואל שתי שאלות ראיה, ובמקום להפיק פסק דין מה-model אני מחשב אותו בקוד.
4. שאלות שהן תחזיות. בבדיקה החיה הראשונה סיווג המסלול יצא לא ודאי בשתי הקריאות, כי "האם זה יימשך יותר משעה?" הוא תחזית ולא עובדה בטקסט. ניסחתי מחדש כבדיקות טקסט פשוטות. בהרצה השלישית: 120 קריאות, ו-6 מתוך 94 הצבעות לא ודאיות, ואות מושתל שקיבל 0.01 מול 0.99.
5. 100 המקרים. ציפיתי ל-100 מקרים עד כאן. בפועל: 2,192 קריאות, אבל 0 הצבעות חיות שהוכרעו. 848 מהקריאות באו מהערכה לא מקוונת אחת, שמדדה הסכמה עם מתכנן ולא תוצאות, ו-24 הצבעות חיות נרשמו בשתי ריצות סינתטיות. החלטתי לא לקדם דבר: אף שדה לא עומד בכלל שנקבע.
6. מבחן מול מה שקרה. נרשם מראש, ורץ על 535 קריאות חדשות. ראו בטבלה.
7. השוואה ישירה. במקום לסגור את הקו הפעלתי השוואה מול Sonnet 5 בכל נקודת החלטה, במצב צל, עם כלל שמירה או פרישה שנכתב לפני שורה אחת של נתונים. תיקו הוא לא שמירה, ועלות לא שוברת שוויון.
8. מה נשבר בחיבור. wiring tests אמיתיים מצאו עשרה פגמים ש-unit tests העבירו, בהם שתי זרועות שענו על מצב ריק, ו-Sonnet שענה בשמות skills מותקנים ולא באפשרויות שהוצעו. חבילות ה-tests כתבו 216 שורות מזויפות עד שהוגנו. אחר כך הקריאות ל-Jev נכשלו, והמעטפת רשמה "bad_json" בעוד שהשירות החזיר 402, תשלום נדרש. 104 מתוך 194 שורות בהשוואה נפגעו, והדגימה לתיוג ידני כמעט בזבזה חצי מהתוויות שלי.

המספרים

בדיקה	Jev	הצד השני	קריאה
בחירת skill (65 מקרים)	43%	75% (ה-harness)	ה-harness בוחר טוב יותר
טעינה מיותרת שנחסמה (14 מקרים)	10	0	Jev שער טוב
עקביות, אותו סדר (2,309 קריאות)	96% עד 100%		יציב
סדר אפשרויות הפוך, סיכון	0.873 (79 זוגות)		חוסר יציבות ברב-ברירה
סיכון מול תוצאות (178 משימות)	AUC 0.61	0.63 (מתכנן)	אין הבדל
מאמץ מול תוצאות (37 משימות)	ρ 0.44	0.32 (מתכנן)	אין הבדל
תפקיד מול קבצים ששונו (44 משימות)	75%	73% (מתכנן)	מעט מדי נתונים

שאלות כן או לא לא התהפכו אף פעם (הפרש של 0.007 לכל היותר). שאלות רב-ברירה כן.

מה השתנה אצלי

לא קידמתי דבר: מול התוצאות האמיתיות Jev משתווה למתכנן ולא עולה עליו באף שדה בביטחון. בהחלטה על בחירת skill הוא נשאר שער ולא בוחר. הכלל לא השתנה: 100 מקרים מוכרעים וסובלנות שנכתבה מראש.

הסתייגויות

• רוב המדידות נשענות על תוויות של מתכנן או של model, לא של אדם. הבדיקה בעברית היא בדיקה אחת על מאמר אחד (177 עריכות), ולכן אין כאן אימות של ה-judge בעברית.
• ב-178 המשימות רק 103 נבחנו על סיכון, ו-23 מהן נדחו, תיקון או חריגה. התוצאה של "אין הבדל" אומרת שלא הצלחתי להבדיל, לא שהם שווים.
• ההשוואה מול Sonnet 5 חמושה ורצה, אבל תוצאת ה-judge העיוור לא כלולה במקורות שלי, ולכן אני לא טוען כאן מי ניצח.
• המדידה היא של גרסה אחת, jev-1.13.0, ושל ה-workflow שלי בלבד. אין בה כלום על workflows אחרים.

מה אפשר לקחת מזה

• כותבים את הסובלנות לפני המדידה, ומקדמים רק עם לפחות 100 מקרים מוכרעים. כאן 2,192 קריאות הניבו 0 הצבעות חיות שהוכרעו, ולכן ההחלטה הייתה לא לקדם.
• judge מוקלד מתאים לשער, לא לבחירה. בבחירת skill הוא צדק ב-43% מול 75% של ה-harness, אבל חסם 10 מתוך 14 טעינות מיותרות וה-harness אפס.
• מבקשים ראיות ומחשבים את פסק הדין בקוד. לפי דוחות שקראתי מהשטח, שאלת פסק דין יכולה להיות אקראית כמעט גם כשכל שאלות הראיה באותה בקשה כמעט ודאיות. אצלי שאלה שהיא תחזית ("האם זה יימשך יותר משעה?") נשארת לא ודאית. כל שאלה צריכה להיות ניתנת לתשובה מקריאת המצב.
• בודקים כל חיבור חי מקצה לקצה. עשרה פגמים עברו את ה-unit tests, ובהם שתי זרועות שענו על מצב ריק, ו-216 שורות מזויפות נכתבו עד שהוגנו.
• שאלות רב-ברירה מתהפכות כשסדר האפשרויות משתנה, שאלות כן ולא לא. הפרש של 0.007 לכל היותר בכן/לא, מול 0.873 בסיכון. התיקון שתכננתי הוא הצבעה על שלושה סדרים.