Agent Cost Attribution — מי בארגון "צרך" איזה טוקן

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

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

מנהל תשתיות בחברת פינטק קיבל חשבונית AI חודשית של כמעט 40,000 דולר, וכשניסה להבין מאיפה היא מגיעה גילה שכל תשעת הצוותים בארגון משתמשים באותו מפתח API יחיד, דרך אותו gateway פנימי, בלי שום תיוג. אי אפשר היה לדעת אם עלייה חדה בעלות נובעת מפיצ'ר חדש בצוות המוצר, מבאג בלולאת retry בצוות התשתיות, או משימוש כבד של צוות אחד בבדיקות ידניות מול הפרודקשן. התשובה שהתקבלה בסוף הייתה "כולם קצת אשמים", שזו בעצם דרך מנומסת להגיד שאי אפשר לדעת בכלל. הפתרון לא היה לצמצם שימוש — הוא היה לבנות שכבת cost attribution שמייחסת כל טוקן בודד למקור שיצר אותו, לפני שמנסים לקבל החלטה כלשהי על קיצוץ או תעדוף.

למה מפתח API אחד לכולם הוא בעיה מובנית

הדפוס הנפוץ בארגונים שמתחילים עם AI הוא מפתח או פרויקט אחד משותף, כי זה הכי מהיר להקמה. הבעיה מתחילה כשצריך לקבל החלטות: איזה צוות לתעדף כשמגיעים ל-rate limit, איזה פיצ'ר הכי יקר ביחס לערך שהוא מייצר, האם עדכון מודל חדש שיפר או הרע את יעילות העלות. בלי ייחוס ברור, כל השאלות האלה נענות באמצעות ניחוש או פוליטיקה ארגונית במקום נתונים. זו בדיוק אותה בעיה שמתוארת ברמת הבקשה הבודדת במאמר Token Economics — רק שכאן השאלה היא לא "כמה עולה המשימה" אלא "מי בארגון יוצר את העלות הזו ובאיזה היקף".

שלוש רמות תיוג שצריך לבנות

מערכת cost attribution אמינה דורשת תיוג בשלוש רמות שונות, שכל אחת עונה על שאלה אחרת:

• תיוג ברמת הצוות/מחלקה — כל שירות פנימי שקורא למודל מזוהה עם צוות בעל השירות. הרמה הבסיסית ביותר, מספיקה לדוחות תקציב רבעוניים.
• תיוג ברמת הפיצ'ר — בתוך אותו צוות, פיצ'רים שונים (סיכום שיחה, תרגום, חילוץ מידע) מתויגים בנפרד, כדי לזהות אילו פיצ'רים ספציפיים יקרים יחסית לערך שהם מייצרים.
• תיוג ברמת הלקוח/משתמש קצה — קריטי במיוחד במוצרי SaaS multi-tenant, שבהם צריך לדעת אם לקוח ספציפי צורך משאבים בצורה לא פרופורציונלית למה שהוא משלם, לפני שהוא הופך ללקוח מפסיד.

שלוש הרמות האלה חייבות להיות חלק מכל קריאת API, לא תוספת בדיעבד — לרוב באמצעות metadata או headers שמועברים דרך שכבת gateway מרכזית שכל השירותים הפנימיים חייבים לעבור דרכה.

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

מבנה נתונים למעקב עלות שאפשר לחתוך לפי צירים שונים

כדי שהתיוג יהיה שימושי בפועל, כל אירוע צריכה (usage event) צריך להישמר עם צירי מטא-דאטה שמאפשרים חיתוך גמיש: מזהה צוות, מזהה פיצ'ר, מזהה לקוח, מודל שנקרא, מספר טוקני קלט ופלט (וטוקני חשיבה בנפרד, אם רלוונטי), עלות מחושבת בפועל, וחותמת זמן. עם מבנה כזה, אפשר לענות על שאלות שונות באותם נתונים בלי לשנות את שכבת האיסוף: "מה העלות הכוללת של צוות X החודש", "איזה פיצ'ר צרך הכי הרבה טוקני חשיבה", "האם עלייה בעלות נובעת מנפח בקשות גבוה יותר או ממחיר גבוה יותר לבקשה". החיתוך האחרון חשוב במיוחד — הוא ההבדל בין "אנחנו גדלים" (טוב) לבין "משהו הפך פחות יעיל" (דורש בדיקה), וקל לבלבל ביניהם בלי לפרק את העלות למרכיביה.

דוגמה מעשית: עלות חודשית שעלתה ב-25% יכולה לנבוע משתי סיבות הפוכות לחלוטין מבחינת המסקנה התפעולית. אם נפח הבקשות עלה ב-25% ומחיר ממוצע לבקשה נשאר קבוע, זה סימן טוב — המוצר צומח וקנה המידה עובד כמצופה. אבל אם נפח הבקשות עלה רק ב-5% ומחיר ממוצע לבקשה עלה ב-19%, זה סימן לבעיה אמיתית — אולי budget חשיבה שהוגדל בטעות, אולי לולאת retry חדשה, אולי context שהתנפח עם הזמן. בלי פירוק ברור בין נפח למחיר יחידה, שני המצבים נראים זהים בדוח החודשי הפשוט, למרות שהם דורשים תגובה הפוכה לגמרי.

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

chargeback פנימי ומה שהוא חושף

הצעד הבשל ביותר הוא chargeback אמיתי — כל צוות רואה חשבונית פנימית משלו, לא רק שורה בדוח כללי. זה משנה התנהגות בצורה מיידית: צוותים שרואים שהם משלמים ישירות על כל בקשה מתחילים לשאול שאלות שלא שאלו קודם — האם באמת צריך context כה מקיף בכל קריאה, האם budget החשיבה מוגזם למשימה, האם אפשר לנתב חלק מהבקשות למודל זול יותר. chargeback לא רק מודד עלות — הוא יוצר תמריץ ארגוני לייעול שלא קיים כשהעלות "נבלעת" בתקציב IT כללי. הצעד הזה גם חושף לעיתים קרובות פיצ'רים שמעולם לא היו כדאיים כלכלית — שימוש AI שנוסף "כי אפשר" בלי חישוב עלות/תועלת אמיתי מראש, ורק כשהוא מקבל תג מחיר ברור מתגלה שהעלות שלו גבוהה בהרבה מהערך שהוא מייצר ללקוח או לעסק.

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

תגיות: Cost Attribution · Chargeback · FinOps · Token Tracking · Model Economics

← חזרה לבלוג · צור קשר