גוגל משפרת סוכני AI בלי לגעת במודל הבסיס

כל מי שניסה לתת למודל שפה לשפר את הקוד של עצמו מכיר את הרגע שבו הסוכן הופך לתלמיד גרוע שפשוט למד את המבחן בעל פה. הוא משיג ציונים מעולים במשימות התרגול המוכרות, אבל ברגע שהוא פוגש משימה חדשה מחוץ לסט, הוא מתרסק. ב־4 באוקטובר 2026 הציגו חוקרים מ־Google Cloud AI Research ושותפיהם בדיווח שפורסם ב־The Decoder גישה שפותרת את הכשל הזה, בלי לגעת במשקולת אחת במודל הבסיס.

הבעיה היא לא המוח

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

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

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

חמישה בלמים בלולאה

הפיתוח של גוגל נקרא RRSI (ראשי תיבות של Regularized Recursive Self-Improvement of Agent Harnesses). השיטה משאירה את קוד המעטפת פתוח לשינויים, אך מרסנת את תהליך החיפוש האוטונומי. המערכת עושה זאת בשתי נקודות בקרה: ברגע הצעת השינויים, וברגע ההחלטה אילו מהם ייכנסו לקוד הקבוע. במקום לתת למודל חופש פעולה בלתי מוגבל, מוטל עליו תקציב עריכות שמצטמצם בהדרגה (annealing). בסבבים הראשונים מותרים שכתובים נרחבים. ככל שהתהליך מתקדם, המערכת מתירה רק שינויים קטנים וממוקדים שניתן לייחס ישירות לתוצאה מדודה.

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

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

ההבדל במבחן הלא מוכר

החוקרים בדקו את RRSI על שמונה בנצ'מרקים בשלושה תחומים: כתיבת קוד, משימות משרדיות ותכנון הנדסי. מודל הבסיס במחקר היה Claude Opus 4.8, שנשאר קפוא לחלוטין לכל אורך הניסויים. צוות המחקר השווה את RRSI למעטפת בסיס נקייה ולעוד ארבע שיטות אופטימיזציה קיימות.

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

לצד הדיוק, המעטפת המרוסנת דרשה את מספר הצעדים הנמוך ביותר והשתמשה בכ־30% פחות טוקנים בזמן ריצה ביחס לגרסאות ללא רגולריזציה, אם כי מעטפת הבסיס המקורית עדיין נותרה רזה יותר. לפי המאמר, מנגנוני המעטפת שנלמדו גם אינם תלויים במודל ששימש לגילויים: מעטפת קוד שעברה אופטימיזציה באמצעות Gemini 3.5 Flash העלתה את הדיוק של המודל החלש יותר Gemini 3.1 Flash Lite מ־11.2 ל־14.6 נקודות ללא שום התאמה ידנית.

העלות שלא כתובה בכותרת

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

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

משיכה אחת מ־GitHub

קוד המקור של המערכת זמין כעת תחת רישיון Apache 2.0 במאגר ה־GitHub של גוגל. המערכת כוללת תמיכה בספריית LiteLLM, מה שמאפשר להריץ את תהליך האופטימיזציה מול מודלים מקומיים או שירותי ענן, בלי להיות כבולים ל־Vertex AI או למודלים של גוגל בלבד.

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

ההוצאה על קריאות ה־API בתהליך החיפוש אולי תכאב, אבל לפחות הקוד של גוגל פתוח לכולם.