למה דחינו חיסכון של 96% בטוקנים

מצאנו שרת MCP שחוסך 96% בטוקנים. הוא משתמש בכלי אחד: execute_code. במקום לקרוא לפונקציות ספציפיות, הסוכן כותב JavaScript כדי להשיג נתונים.

על הנייר, זה מנצח. עבור משימות מורכבות, הרצת קוד מנצחת קריאה לכלי (tool-calling) מבחינת יעילות.

אבל לא אימצנו אותו. במקום זאת, שמרנו על הכלים המוגדרים והבעלי השמות שלנו.

הנה הסיבה שבגללה הבחירה הברורה הייתה הבחירה הלא נכונה עבור הסוכן שלנו.

קהל היעד קובע את העיצוב

רוב האנשים בונים עבור מודלי קצה (frontier models) בחלון צ'אט. למודלים האלו יש תקציבי טוקנים עצומים. עבורם, הרצת קוד היא המלך.

אנחנו בונים עבור סוכן מבוסס קול (voice-first) על מודל מקומי קטן (Hermes 3 8B) על סירה.

עבור מודל קטן, המגבלה היא לא טוקנים. המגבלה היא אמינות.

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

בעיית ה"מייל האחרון" (The Last-Mile Problem)

הרצת קוד דוחפת את ה"מייל האחרון" של העבודה אל הסוכן. הסוכן חייב:

• לסנן את הנתונים
• למיין את התוצאות
• לעצב את הפלט

הכלים שלנו מבצעים את העבודה הזו בתוך השרת. לדוגמה, כששואלים על מצב הסוללה, הכלי שלנו מחזיר מחרוזת (string) מוכנה להמרה לדיבור (text-to-speech). הוא אומר "68 אחוז, 12.8 וולט" במקום מספרים גולמיים.

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

כלל ההיעדרות

על סירה, חיישנים יוצאים מקישוריות (go offline). במערכת שלנו, חיישן חסר מחזיר null נקי. זוהי קריאה מוצלחת.

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

צ'קליסט: אימוץ מול בנייה

לפני שאתם מאמצים או בונים שרת MCP, שאלו את השאלות הבאות:

• מי הסוכן המיועד? (מודל קצה לעומת מודל מקומי קטן) • מהי המגבלה המכריעה? (טוקנים לעומת אמינות) • מי מבצע את ה"מייל האחרון"? (האם הכלי מעצב את הנתונים או הסוכן?) • איך הוא מטפל בהיעדרות? (האם ערך חסר הוא שגיאה או null?) • מה עלות התחזוקה? (האם אתם יורשים בסיס קוד רדום?)

לא התעלמנו מהפרויקט השני. אספנו ממנו רעיונות. לקחנו את הלוגיקה שלהם לטיפול בהתראות וגילוי נתיבים והוספנו אותם למפת הדרכים (roadmap) שלנו.

יעילות היא דבר נהדר, אבל אמינות היא הכרחית כשאתם על המים.

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi