HarnessDev: מודלי שפה גדולים (LLMs) בונים את התשתית שלהם בעצמם
ByteDance וקבוצה של אוניברסיטאות השיקו את HarnessDev, מסגרת עבודה (framework) המאפשרת למודלי שפה גדולים (LLMs) לכתוב את "מערכות ההפעלה של הסוכנים" שלהם, הנקראות Agent Harnesses. הצוות מספק ל-LLM ערכת התחלה בסיסית ונותן לו להרחיב את שאר החלקים, ובכך מראה כיצד בינה מלאכותית יכולה לבנות את שכבת הבקרה שמריצה לולאות שימוש בכלים משלה, שלבי אימות וטיפול בשגיאות — מבלי שאדם יקליד כל שורה ושורה.
למה חשיבות יש ל-harness שנבנה בעצמו
סוכני AI התפתחו מסוכנים המבוססים על הנחיה (prompt) בודדת לעובדים רב-שלביים הקוראים ל-APIs, מבצעים שאילתות במסדי נתונים ומחברים תוצאות יחד. עד כה, מפתחים יצרו באופן ידני את קוד הניהול (orchestration) שאומר למודל מתי להשתמש בכלי חיפוש, כיצד לשמור מצב ביניים וכיצד לאמת תשובה סופית. HarnessDev הופכת את המודל הזה: seed harness מספק רק תשתית בסיסית (scaffolding) — פונקציות בסיסיות ללולאות, בחירת כלים ומעקב אחר מצב — וה-LLM מרחיב אותה לסביבת זמן ריצה (runtime) בעלת יכולות מלאות.
במדד הביצועים (benchmark) של המאמר, המודל ייצר 18 harnesses נפרדים, והוסיף יותר מ-17,000 שורות קוד ל-seed המקורי. כל harness ניהל את מחזור החיים המלא של המשימה: הרצת לולאות, בחירת הכלי המתאים, שמירה על הקשר (context), מעקב אחר מצב, אימות תוצאות והתאוששות משגיאות.
העלויות הנסתרות שהמחקר חשף
המספרים נראים מרשימים, אך המחברים מזהירים שמימוש גולמי אינו שווה לשימוש מעשי.
- רכיבים שלא נעשה בהם שימוש – חלק ניכר מהקוד שנוצר מעולם לא רץ במהלך ביצוע המשימה בפועל. ה-LLM כתב פונקציות שהסוכן מעולם לא קרא להן, מה שגרם לנפח קוד מיותר ללא ערך מוסף.
- תלות במודל (Model lock-in) – ה-harnesses נטו להיות מותאמים ל-LLM הספציפי שיצר אותם. כאשר אותו harness הועבר למודל אחר, הביצועים ירדו באופן ניכר, מה שמרמז על כך שללוגיקת הבקרה שנוצרה אוטומטית מוטמעות תכונות ייחודיות של המודל.
- פערי אימות – harness בדיקה אחד דיווח על שיעור הצלחה של 99% (99 מתוך 100 הרצות), אך היה נכון רק ב-48% מהמקרים. ללא אימות חזק, סוכן יכול להציג תשובות שגויות בביטחון רב.
- עומס טוקנים (Token overhead) – השימוש בטוקנים — מדד לעלות החישוב — השתנה באופן דרמטי. harness אחד דרש פי שבע יותר טוקנים מאחר כדי להשיג את אותה תוצאה, מה שמעלה חששות לגבי יכולת גדילה (scalability) בסביבות ייצור.
ממצאים אלו מדגישים את הצורך בעיצוב ממושמע, גם כאשר הקוד נוצר על ידי LLM.
מה מפתחים צריכים לקחת בחשבון
- התייחסו לתכנון ה-harness כאל ארכיטקטורה – אל תסתמכו על כך שהמודל "פשוט יעבוד". הגדירו מודולים ברורים לבקרת לולאות, בחירת כלים, ניהול מצב ואימות לפני שתתנו ל-LLM למלא אותם.
- בנו אימות חזק – הכניסו בדיקות מפורשות המשוות את טענת הסוכן אל מול האמת בשטח (ground truth) או מודל משני. רמת הדיוק של 48% במחקר, למרות שיעור הצלחה עצמי מדווח של 99%, מראה שאימות לא יכול להיות דבר שנחשב בדיעבד.
- שימו לב לתקציב הטוקנים – harnesses מורכבים יותר עלולים להוביל לזינוק במספר הטוקנים. בצעו פרופיל (profile) לגרסאות שונות של ה-harness בשלב מוקדם כדי למנוע התפוצצות עלויות נסתרת.
- בצעו בדיקות על פני מודלים שונים – הריצו את אותו harness עם מספר גופי מודל (LLM back-ends). אם הביצועים יורדים בחדות, ייתכן שתזדקקו לעיצוב אגנוסטי למודל (model-agnostic) או ל-harnesses נפרדים לכל מודל.
בשורה התחתונה: HarnessDev מוכיח ש-LLMs יכולים לנסח קוד בקרה משלהם, הדומה למערכת הפעלה.