יבמ מוכיחה שפרומפט שנלמד לבד עוקף מודלים יקרים
במקום כוונון משקולות יקר או מעבר למודל הדגל, מנגנון הזיכרון ALTK-Evolve מזקק חוקי התנהגות מטעויות עבר וגוזר זמני תגובה קצרים יותר, בתנאי שיש לכם מטמון.
- בדקו אם ספק ה-LLM שלכם תומך ב-Prompt Caching לפני הוספת בלוק חוקים אוטומטי לסוכן.
לכל מפתח שבנה סוכן תמיכה יש רגע שבו הוא נשבר מול הלוגים. הלקוח ביקש החזר, המודל אישר את הזיכוי לפני שווידא מיקוד, ומסד הנתונים נשאר מעודכן בטעות שאי אפשר להחזיר אחורה. האינסטינקט הטבעי במצב כזה הוא לזרוק כסף על הבעיה: לעבור למודל החשיבה היקר ביותר בשוק או להקים מערך fine-tuning מורכב שמנסה ללמד את המשקולות לציית לחוקים. מחקר חדש שפרסמו חוקרי IBM Research מציג דרך אחרת לגמרי, שמראה שאפשר לעקוף את מודלי הדגל בלי לגעת באף משקל של המודל.
זיכרון במקום שדרוג מודל
בדיווחים שונים ברשת נטען כי יבמ פיתחה מודל שפה חדש, אך בפועל מדובר בכלי תוכנה מעשי. החוקרים הציגו בפוסט של IBM Research את ALTK-Evolve, מסגרת פייתון שמנתחת טעויות והצלחות של סוכן בריצות אימון ומזקקת מהן פלייבוק טקסטואלי קצר. ההנחיות הללו מוזרקות ישירות אל תוך ה-System Prompt כרשימת חוקי עבודה רגילה, ללא תיוג אנושי וללא שינוי במשקולות המודל.
התוצאות במבחן τ²-bench של חברת Sierra Research, הבודק התנהגות סוכנים מול סימולטור לקוחות מחמיר, הציבו סוכן ReAct בסיסי המבוסס על gpt-4.1 במקום הראשון בקמעונאות. הסוכן השיג אמינות Pass^4 של 67.5%, מדד שדורש הצלחה מלאה בכל ארבעה ניסיונות בלתי תלויים של אותה משימה. התוצאה הזו עקפה את כל מודלי הקצה וניצחה מודל ייעודי שעבר כוונון משקולות מלא כמו RAFT-30B-A3B שהגיע ל-61.4% בלבד.
טוב לגלות שלא צריך עוד מודל של מיליארדי פרמטרים על השרת.
המודל מנתח את ניסיונות המשימה באימון ומזקק הצלחות וכישלונות לחוקי התנהגות קצרים: כיצד לאמת לקוח, לאשר עסקה או לטפל בהחזרה.IBM Research בדוקומנטציה של ALTK-Evolve
יותר חוקים, פחות דיבורים
האינטואיציה הראשונית אומרת שהעמסת מאות שורות טקסט על הפרומפט תגרום לסוכן להתבלבל ולנהל שיחות ארוכות ומסורבלות. הנתונים מראים אחרת. בניתוח ריצות זהות שנפתרו בהצלחה לפני הוספת החוקים ואחריה, הסוכן עם ההנחיות קיצר את השיחה ב-0.43 תורות בממוצע בתחום הקמעונאות, מ-10.59 תורות ל-10.16. במקום לנחש מה השלב הבא, הסוכן פועל לפי הוראות ברורות: דורש אימות מזהה מראש, מבצע פעולת כלי יחידה בכל שלב, ומאשר שינויים מול הלקוח לפני הפעלת API.
קיצור תורות השיחה חוסך זמן השהיה קריטי מול הלקוח, אך המחיר עובר לטוקנים של הקלט. בלי שימוש במטמון, עלות השיחה הממוצעת בקמעונאות זינקה ב-65%, מ-0.084 דולר ל-0.139 דולר, בגלל בלוק ההנחיות שנשלח בכל קריאה. בייצור, לפי החוקרים, רוב תוספת העלות הזו ניתנת לקיזוז באמצעות Prompt Caching מאחר שבלוק ההנחיות זהה בכל קריאה.
| קונפיגורציה | מספר הנחיות (קמעונאות) | אמינות Pass^4 | עלות ממוצעת לשיחה | שינוי בסיבובי שיחה |
|---|---|---|---|---|
| baseline (ללא הנחיות) | 0 | 57.5% | 0.084$ | - |
| sup3 (ליבה מצומצמת) | 31 | 60.0% | 0.095$ | -0.05 |
| lossless (כל ההנחיות) | 292 | 67.5% | 0.139$ | -0.43 |
עניין של מינון
אחד הממצאים החשובים של החוקרים הוא שכמות ההנחיות אינה פתרון אחיד לכל סוגי השירות. בקמעונאות, שבה יש עשרות מקרים פרטיים של החלפות, זיכויים ואימותי כתובת, שמירה של כל 292 ההנחיות הניבה את התוצאה הטובה ביותר. לעומת זאת, בעולם התעופה התמונה התהפכה: סט מלא של 101 הנחיות הגיע לאמינות של 40.0%, בעוד שסינון של חוקי הליבה עם 14 הנחיות בלבד הקפיץ את האמינות ל-45.0%.
השיטה עובדת היטב גם כאשר משדרגים את מודל הבסיס. בניסוי תעופה שבו הופעל מודל gpt-5.5 הן לחילוץ ההנחיות והן להפעלת הסוכן, הוספת 146 הנחיות העלתה את הדיוק מ-72.5% ל-82.5% ואת מדד Pass^4 מ-55.0% ל-70.0%. ארכיטקט מערכת שבונה פתרון כזה צריך להתייחס לרף הסינון כאל חוגה שדורשת כיול לפי מורכבות התחום, ולא להעמיס כל חוק שנפלט.
סימולציה אינה משתמש עצבני
למרות ההישגים במבחן, יש פער שצריך להביא בחשבון לפני שמטמיעים את הפלייבוק במערכות חיות. המבחן של Sierra הפעיל את gpt-5.5 בתור לקוח מדומה שמציית לפרוטוקול שיחה מוגדר. לקוחות אמיתיים אינם סימולטור. הם קוטעים תהליכים, כותבים שגיאות כתיב קשות, ומנסים לקבל פיצוי שלא מגיע להם.
שאלה פתוחה נוספת היא ניהול סתירות פנימיות. ככל שמספר הריצות גדל, מאגר החוקים עלול לצבור הנחיות סותרות שנוצרו במקרים חריגים שונים. בנוסף, עבור צוותי פיתוח ישראליים שמשרתים קהל מקומי, הטמעת בלוק הנחיות גדול בעברית תגרור מספר טוקנים גבוה בהרבה בהשוואה לאנגלית בגלל מגבלות טוקניזציה. אם אין לכם שיעור פגיעה גבוה במטמון, העלות השוטפת תהיה כבדה.
לא הייתי ממהר להטמיע את זה בעברית לפני בדיקת עלויות יסודית.
מתי כדאי להתקין
הקוד של הפרויקט זמין כעת תחת רישיון Apache 2.0 בכתובת של AgentToolkit ב-GitHub. אם אתם מנהלים סוכן שירות לקוחות קיים שמתקשה לעמוד בכללי מדיניות קשיחים, אל תמהרו להחליף מודל או להשקיע שבועות באימון משקולות. הרצת אלגוריתם הזיקוק על לוגים של שיחות כושלות יכולה לספק פלייבוק יעיל בעלות תפעולית נמוכה בהרבה.
מנגד, אם התשתית שלכם אינה תומכת ב-Prompt Caching יציב או שהתחום כולל שינויי מדיניות תכופים מדי יום, עדיף להמשיך להחזיק פרומפט ידני מהודק ומנוהל גרסאות. לפעמים כל מה שבוט צריך כדי לעבוד כמו שצריך זה פשוט לקרוא את הדפים שמישהו אחר כבר טרח לרשום.
מה שואלים על זה
- ALTK-Evolve: How learned memory tops the τ²-bench leaderboard on customer service tasks wihuggingface.co · המקור
- AgentToolkit / altk-evolve Repositorygithub.com · קריאה נוספת
24 עובדות בכתבה נבדקו אחת־אחת מול המקורות המקושרים ומול חיפוש ברשת ב־21 באוקטובר 2026. מה שלא אומת הוסר או מסומן כטענה של החברה. הכתיבה נעשתה בעזרת AI מהמקורות האלה בלבד, בעריכה ובאחריות של סלבה מלנדוביץ׳. טעות? כתבו לנו.