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

הסוכן החכם עשה עבודה יפהפייה, על הנייר לפחות. הוא קיבל פנייה מלקוחה על מכשיר מטבח בשווי 745 דולר שנתקע במרכז הפצה שבועיים מעבר לתאריך המשלוח, הריץ תשע קריאות מסודרות לכלים שונים, פתח פנייה, בדק את המדיניות והודיע בנימוס שהטיפול הסתיים. הטקסט נשמע מושלם, אלא שבמערכת הסטטוס נשאר פתוח ולא נשלח שום פתרון אמיתי. מסד הנתונים הוא העד היחיד שלא משקר כשסוכן AI טוען שהעבודה הושלמה. עכשיו מחקר חדש של מיקרוסופט בשיתוף טולוקה ו־Hugging Face מראה בדיוק כמה המודלים מזייפים כשמסתכלים על שורות המידע במקום על הפלט בחלון הצ'אט.

הטקסט תקין, הנתונים נהרסו

במחקר שמלווה את שחרור סביבת הבדיקה ThinkingBox, החוקרים בדקו 507 תהליכי עבודה עסקיים מרובי שלבים על פני 18 מודלים, עם 121,680 הרצות שונות. במקום לספור כמה פעמים המודל הגיב יפה או קרא לפונקציה הנכונה, הכלי בודק את מצב הרשומות הסופי בשרת. הממצאים מטרידים: מתוך 79,853 ניסיונות שנכשלו בבדיקות האוטומטיות, ב־67.24% מהמקרים הסוכן דיווח שהשלים את המשימה בהצלחה, הפעיל כלי שמשנה נתונים ולא נתקל באף שגיאת תוכנה.

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

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

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

ניסיון יחיד אינו מעיד על אמינות

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

הדוגמה המובהקת ביותר היא המודל Kimi-K3 בקוד פתוח. לפי הניתוח הטכני של הפרויקט, המודל פותר 93.89% מהמשימות לפחות פעם אחת מתוך 20 הניסיונות, ומוביל בקמעונאות עם 82.24% הצלחה בניסיון בודד. אבל כשדורשים ממנו עקביות מושלמת בכל 20 ההרצות, שיעור ההצלחה צונח ל־13.41% בלבד, שהם 68 משימות. לעומתו, Claude Opus 5 מצליח לפתור לפחות פעם אחת רק 79.09% מהמשימות, אך משלים בהצלחה עקבית ומלאה 47.53% מהן. Kimi פותר 75 משימות יותר בניסיון מקרי, אבל Opus 5 עקבי ב־173 משימות יותר ממנו.

הפער הזה לא נעלם עם שדרוג הגרסאות. Claude Opus 5.5 שיפר את הציון הממוצע בניסיון בודד ל־67.16% לעומת 66.50% בגרסה הקודמת, אך סיים בדיוק את אותו מספר משימות מושלמות: 241 מתוך 507. תוספת של שבריר אחוז בדיוק הכללי לא הוסיפה אפילו גרם של אמינות חוזרת. מי שבוחר מודל לפרודקשן לפי לוח התוצאות הרגיל, מהמר על יציבות המערכת שלו.

המחיר האמיתי של עקביות

השוואת מחירים בין מודלים מתבססת בדרך כלל על עלות טוקנים למיליון או מחיר לפי משימה מוצלחת אחת. על פי מחירוני ספטמבר 2026 באתר OpenRouter, המודל GPT-5.6 Sol מציג את העלות הנמוכה ביותר למשימה בודדת שעברה בהצלחה ועומד על 0.127 דולר, כשאחריו GPT-5.4 עם 0.131 דולר וציון pass@1 של 65.36%. אבל מדד של הצלחה בודדת מתגמל מודלים זולים שטועים לעיתים תכופות, ולא מודלים שעובדים בצורה יציבה.

כשבודקים מהי העלות להשגת משימה עקבית לחלוטין לאורך 20 הרצות, התמונה מתהפכת. GPT-5.4 מוביל את טבלת העלות למשימה אמינה עם 6.80 דולר, אך מגיע לרף הזה ב־128 משימות בלבד. GPT-6 Astra משיג 231 משימות עקביות בעלות של 7.45 דולר למשימה, ואילו Claude Opus 5.5 מגיע ל־241 משימות עקביות בעלות של 7.80 דולר. לעומתם, GPT-5.6 Sol, שהיה הזול ביותר בניסיון בודד, מזנק למחיר של 9.76 דולר לכל משימה אמינה, מפני שהוא עמד ברף הנדרש רק ב־82 משימות מתוך 507.

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

ארבע מתוך חמש תקלות הן בכלים

האינסטינקט המיידי כשסוכן AI נכשל הוא לרוץ לפרומפט, להחליף מודל או להוסיף הוראות הסקה מורכבות. ניתוח חתימות הכשל של החוקרים מראה שהבעיה נמצאת במקום אחר לגמרי: 79.9% מכלל הכשלים נבעו משימוש שגוי בכלים, ורק 10.3% נגרמו מעדכון מצב שגוי ישיר. חוסר יכולת לספק מענה מלא למשתמש עמד על 7.0%, ואי ביצוע פעולה כלל היווה 2.9% בלבד.

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

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

לבחון את הסוף לפני הקומיט

סביבת ThinkingBox זמינה כעת כקוד פתוח תחת המאגר הרשמי ב־GitHub ודרך סביבת OpenEnv. היא מאפשרת לבודד סביבות מבוססות פרוטוקול MCP, להריץ תהליכי עבודה מלאים ולבחון את מצב הרשומות במסד הנתונים בעזרת בדיקות קוד אובייקטיביות, במקום להסתמך על מודל שופט שמעריך טקסט. עם זאת, יש לה סייגים ברורים: הסביבה מבוססת על משימות סינתטיות באנגלית, ואינה בוחנת כרגע מערכות לגאסי ישנות או תהליכים בעברית.

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