רוב צוותי ההנדסה עדיין מעריכים סוכני AI באותה הדרך שבה הם בודקים שיעורי בית במתמטיקה. הם מסתכלים על הפלט הסופי. אם התשובה נכונה, הם נותנים אור ירוק לשחרור וממשיכים הלאה. זהו קיצור דרך מסוכן. תשובה נכונה יכולה להסתיר מערכת שבורה לחלוטין.
הסיפור האמיתי טמון במסלול שעבר הסוכן כדי להגיע לשם. המסלול הזה נקרא agent trajectory. הוא כולל כל tool call, כל החלטת ניתוב (routing decision), וכל עצירה שבה הסוכן עוצר כדי לשקול מחדש. אפשר לחשוב על זה כעל עקבות הלחם של הסוכן. ואם אתם בודקים רק את היעד, אתם מפספסים את כל סימני האזהרה המפוזרים לאורך הדרך.
הבעיה במסלולים מבולגנים
סוכן יכול להגיע לתשובה הנכונה תוך כדי התנהגות כמו נהג שיכור. הוא מתנועע בין הכלים הלא נכונים, חוזר אחורה ל-router, וחוזר על תהליכי חשיבה מיותרים לפני שהוא סוף סוף נתקל במשהו נכון. המשתמש רואה תוצאה נקייה. מאחורי הקלעים, המערכת "מדממת" משאבים ואוגרת סיכון.
איך הבלאגן הזה נראה בפועל?
ראשית, ישנה קריאה מיותרת לכלי (redundant tool call). הסוכן מבצע שאילתה במסד הנתונים של הלקוחות שלכם, מקבל את התוצאה, שוכח אותה חמש שניות לאחר מכן, ומבצע שאילתה על אותה רשומה שוב עם פרמטרים זהים. זו אינה בעיית נתונים. זו בעיית trajectory. הסוכן נכשל בשמירה על ה-state, ולכן הוא חוזר על עבודה שכבר נעשתה.
לאחר מכן ישנו דפוס של "הכלי הלא נכון תחילה" (wrong-tool-first pattern). סוכן קוד עשוי לנסות לחפש ברשת הגדרה של פונקציה שכבר קיימת ב-local repository. או סוכן תמיכה עשוי לפנות ל-billing API כאשר שאלת המשתמש דורשת בבירור את הכלי own account settings. כל בחירה שגויה שורפת tokens, מוסיפה latency, ומגדילה את הסיכוי שמגבלות ההקשר (context limits) ייפרצו לפני שהעבודה האמיתית מתחילה.
לולאות ניתוב (router loops) הן נורה אדומה נוספת. צומת ההחלטה (decision node) אינו יכול להתחייב. הוא שולח את המשימה לענף A, משנה את דעתו, מושך אותה חזרה, מעביר אותה לענף B, ואז מנתב אותה דרך צומת fallback כללי ללא סיבה. כל לולאה מוסיפה קפיצה ברשת (network hop) ושכבה נוספת של בלבול ליומן הדיבאג (debug log) הסופי.
לבסוף, ישנה אנליזה חוזרת. הסוכן ממשיך להסיק שוב ושוב את אותה מסקנה בכל שלב במקום להתייחס אליה כאל מסקנה סופית. זה כמו נגר שמודד את הלוח עשר פעמים לפני כל חיתוך. המדידה הראשונה הייתה בסדר. תשע המדידות הבאות הן תנועה מבוזבזת.
לצעדים הנוספים הללו יש השלכות ממשיות. ה-latency מצטבר. בממשק צ'אט סינכרוני, שלוש שניות נוספות מרגישות כמו נצח. בקנה מידה גדול, השניות הללו מתורגמות לאלפי דולרים של compute. גם הסיכון לכשל עולה. כל קפיצה מיותרת היא הזדמנות נוספת ל-API חיצוני להגיע ל-timeout, לחלון ההקשר (context window) לגלוש, או למצב של race condition להופיע. וכאשר משהו אכן נשבר, בהצלחה בדיבאג של trace שנראה כמו ספגטי. תבזבזו שעות על שחזור הסיבה לכך שהסוכן ביצע את שלב שבע, רק כדי להבין ששלב שבע מעולם לא היה אמור להתקיים.
מה המשמעות האמיתית של convergence
אם ה-trajectory הוא המסלול, ה-convergence הוא המדד ליעילות שלו. convergence אומר לכם כמה קרוב הסוכן נצמד למסלול הקצר ביותר והיעיל ביותר בין בקשת המשתמש לבין הפתרון הנכון.
זה לא אותו דבר כמו accuracy. accuracy הוא כלי גס. הוא שואל האם המצב הסופי נכון. convergence שואל האם המסע היה הגיוני. סוכן עם accuracy גבוה ו-convergence נמוך הוא נטל שמתחזה להצלחה. סוכן עם convergence גבוה ו-accuracy בינוני הוא בדרך כלל קל יותר לתיקון, כי הלוגיקה שלו נקייה והטעויות שלו ממוקדות.
ניתן לחשב ציון convergence גס על ידי השוואת השלבים שהסוכן מבצע בפועל מול המסלול הקצר ביותר שהגדרתם עבור סוג המשימה הזה. אם שאילתת החזר כספי סטנדרטית אמורה לדרוש בדיוק שלוש קריאות לכלי והסוכן השתמש בתשע, יחס ה-convergence שלכם נפגע. ניתן לדייק זאת על ידי מתן משקל לסוגים שונים של בזבוז. קריאה שגויה אחת לכלי עשויה לעלות יותר מקריאה מיותרת אחת, תלוי ב-latency ובמחיר של הכלי. לולאת router שאינה מוסיפה שום ערך עשויה לשאת את העונש הכבד ביותר מכולם, כיוון שהיא מאותתת על ארכיטקטונית