כלכלת טוקנים בארגונים: מה Meta ו-Google מלמדות על שימוש נכון ב-AI
מונח Tokenmaxxing הוא מונח חדש-ישן ומאחוריו גישה שגויה שאומצה בצורה עיוורת. על פי דיווח של Financial Times מהיום, Google נאלצה להגביל את צריכת Gemini של Meta לאחר שהחברה הפכה לאחת מצרכניות טוקני AI הגדולות בעולם. אני מנסה ללא הצלחה להבין את הגישה, אבל אין בה היגיון, בטח בעידן אג'נטי. מעבר לכך ששימוש בסוכנים אוטונומיים ללא תכנון הוא בעייתי ולא יעיל בצד העסקי, הדבר העיקרי שהוא תורם הוא שריפת טוקנים עיוורת. שימוש עיוור בסוכני AI עבור פעולות פשוטות, שצורכות כמויות טוקנים אדירות, אינו אימוץ AI אלא דגרדציה תפעולית. אין בעיה לבנות סוכן אוטונומי, הבעיה היא לבנות אותו בלי להבין תהליך, בלי להבין טכנולוגיה ובלי להתאים פתרון עסקי.
כלכלת טוקנים אינה מדד לפרודוקטיביות
ארגונים רבים התבלבלו בין שימוש גבוה ב-AI לבין ערך עסקי. מדידה לפי מספר קריאות למודל, נפח טוקנים או כמות סוכנים פעילים מייצרת תמריץ שגוי: יותר צריכה במקום יותר תפוקה. כאשר פעולה פשוטה כמו סיווג טופס, חילוץ שדה או בדיקת סטטוס נשלחת שוב ושוב למודל שפה גדול, הארגון משלם על חישוב לא דטרמיניסטי במקום להשתמש בתחנה דטרמיניסטית זולה, יציבה ומהירה. תהליך AI חכם צריך להיות חסכוני יותר, לא יקר יותר. ברוב המקרים, רק חלק קטן מהתהליך באמת דורש שיקול דעת של מודל שפה, בעוד שרוב הזרימה צריכה להתבסס על חוקים, אינטגרציות, ולידציה, תורים, הרשאות ומעקב.
ניהול סוכנים דורש ארכיטקטורה ולא שריפת משאבים
הסיפור של Meta ו-Google חשוב כי הוא מציף מגבלה שרבים מעדיפים להתעלם ממנה: גם ענני AI של ענקיות הטכנולוגיה אינם אינסופיים. הדיווח מציין ש-Google הגבילה את Meta לאחר חריגות משמעותיות, ובמקביל חתמה על הסכם לרכישת קיבולת מחשוב בהיקף של 920 מיליון דולר בחודש מ-SpaceX. עבור ארגון עסקי זו נורת אזהרה. אם ספק מרכזי יכול להציב תקרה ללקוח ענק, גם מוצר ישראלי שנשען על Gemini, Claude או GPT-4 חייב להחזיק תוכנית צריכה, חלופות מודלים, מדיניות קאשינג, מנגנוני Rate Limit, ותיעדוף עומסים לפי חשיבות עסקית.
כאשר בונים סוכני AI נכון, הסוכן אינו אמור להחליף ארכיטקטורה. הוא אמור לפעול מעל תשתית ארגונית שמגדירה הרשאות, כלים מותרים, זיכרון, תיעוד החלטות, מסלולי הסלמה ואדם בלולאה בנקודות שבהן יש סיכון עסקי אמיתי. אדם בלולאה אינו אומר שאדם מאשר כל פעולה. המטרה היא שאדם שפיקח בעבר על תהליך אחד יפקח כעת על מאות תהליכים באמצעות חריגים, ספים, דוחות ובקרות. כאן נדרשת הבנה משולבת של AI, תהליך עסקי וניהול תפעולי, ולא רק יכולת לחבר מודל ל-API.
יישום AI ארגוני מתחיל בממשל צריכה
מנהלים צריכים להפסיק לשאול כמה טוקנים הארגון שרף ולהתחיל לשאול מה שיעור הפעולות שהושלמו, מה עלות הפעולה העסקית, כמה חריגים נוצרו, ומה רמת הדיוק לאחר בקרת איכות. מדד טוב יכול להיות עלות לכל תיק שטופל, זמן טיפול ממוצע, שיעור השלמות ללא התערבות, ושיעור הסלמה מוצדקת לאדם. אם סוכן מייצר חיסכון של 40 אחוז בזמן טיפול אבל מגדיל פי שלושה את עלות התשתית ויוצר עומס בקרה, הוא לא פתרון מוצלח.
ארגון רציני צריך לבנות שכבת FinOps ל-AI: תקציב טוקנים לפי יחידה עסקית, בחירת מודל לפי מורכבות משימה, שימוש במודלים קטנים למשימות צרות, שמירת תשובות חוזרות, בדיקות איכות, וניהול ספקים עם יכולת מעבר. כלים כמו Claude, Copilot Studio או N8N יכולים להיות יעילים מאוד, אבל רק כאשר הם מחוברים למתודולוגיה, לאופרטיביקה ולידע מקצועי עמוק. המסקנה ברורה: אימוץ AI אינו תחרות צריכה. אימוץ AI הוא תכנון תהליכים חכמים שבהם מודלים, סוכנים ואנשים עובדים יחד באופן מדוד, יציב וחסכוני.
