אופטימיזציה לסוכני LLM: איך לשפר ביצועים במערכות מבוססות מודלי שפה גדולים

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

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

גישה פרקטית לשיפור ביצועים של מערכות כאלה הופכת את התנהגות הסוכן למשהו שניתן למדוד, לנתח ולתקן באותה לוגיקה שבה מתקנים תוכנה. גישה זאת עומדת בבסיס מאמר שפורסם לאחרונה בשם ROAD: Reflective Optimization via Automated Debugging ליישור סוכנים ב Zero Shot מאת Natchaya Temyingyong ושותפים, שפורסם ב 29 בדצמבר 2025 כ preprint ב arXiv.

אופטימיזציה לסוכני LLM: למה שיפור ביצועים נשבר בפרודקשן

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

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

מחקר ROAD מציג ניסוי אמפירי שמנסה לפתור בדיוק את הפער הזה באמצעות לולאת דיבוג אוטומטית שמבוססת על trace של הריצה ועל יצירת patch לפרומפט. המחקר מציג שיפור ממוצע של 5.6% בשיעור ההצלחה, מ 73.6% ל 79.2%, ועלייה של 3.8% במדדי דיוק ואמינות לעומת בסיסים חזקים. מחקר ROAD גם מדווח על יעילות דגימה גבוהה יותר עם כ 19% פחות ריצות נדרשות כדי להגיע לביצועים דומים.

איך ROAD עובדת: דיבוג אוטומטי במקום כוונון ידני

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

רכיב Analyzer מזהה היכן ההיגיון השתבש, למשל בחירה שגויה של כלי, פרשנות שגויה של הוראת משתמש או תכנון חלקי. רכיב Optimizer מייצר patch בדמות פרומפט משופר, למשל הוספת guardrails, פירוק לשלבים או שימוש באנטי דוגמאות. רכיב Coach משמר patchים מוצלחים כ Skills, כלומר מודולים של פרומפט שניתן למחזר ולהפעיל לפי סוג משימה או דפוס כשל.

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

דוגמה פרקטית ליישום: סוכן אינטגרציה שנכשל בבחירת כלי

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

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

איך מחברים ROAD למסגרות שכבר עובדים איתן בארגונים

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

לדעתנו מדובר במגמה רחבה שבה ניהול פרומפטים הופך לניהול נכסים, בדומה לניהול קוד. ארגון יכול לנהל ספריית Skills בגרסאות, להצמיד לכל Skill מדדים כמו השפעה על success rate, עלות טוקנים ושיעור תקלות, ולבצע קידום בין סביבות בדומה ל CI CD. ארגון גם יכול לחבר את Analyzer למנוע סיווג כשלים פנימי כדי להבחין בין כשל הבנה, כשל כלי, כשל נתונים וכשל מדיניות.

מבחינה תפעולית, ארגון יכול להתחיל ביישום ממוקד על 1 תהליך קריטי, לבחור 3 עד 5 סוגי כשל נפוצים, ולהריץ ROAD על סט של 200 עד 500 ריצות סימולציה כדי לקבל בסיס לייצור patchים. ארגון יכול להרחיב בהדרגה ליותר תהליכים לאחר שהתקבעה ספריית Skills שמכסה מקרי קצה. ארגון יכול למדוד ROI באמצעות השוואה לפני ואחרי במדדי הצלחה, זמן טיפול ממוצע, ועלויות הרצה, תוך שמירה על רמת אמינות גבוהה יותר.

סיכום: לולאת דיבוג אוטונומית כסגירת פער בין דמו לפרודקשן

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

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