איך מונעים מעלויות ה- AI לצמוח ללא שליטה?
התשובה המרכזית טמונה בניהול נכון של טוקנים. יחידת המידע שהמודל מעבד ומייצר בכל פנייה.
חשוב להבהיר, חיסכון בטוקנים אינו אומר בהכרח לכתוב פרומפטים קצרים יותר או לבחור תמיד במודל הזול ביותר. המטרה היא לייצר מקסום ערך. לתת למודל את כמות המידע המדויקת והמינימלית הדרושה כדי לקבל תוצאה מעולה.
מהם בכלל טוקנים?
מודל AI אינו קורא טקסט כפי שבני אדם קוראים אותו, אלא מפרק אותו ליחידות קטנות הנקראות Tokens (בממוצע, כ-4 תווים או 0.75 מילים באנגלית; בעברית החישוב מעט שונה).
בכל פנייה למודל (API Call) התמחור מתחלק לשני סוגים:
- טוקנים נכנסים (Input Tokens): הפרומפט, היסטוריית השיחה, המסמכים המצורפים וההוראות שניתנו למודל.
- טוקנים יוצאים (Output Tokens): התשובה והתוצר שהמודל מייצר בפועל.
איפה הבעיה?
- כאשר מערכת שולחת למודל בכל בקשה עשרות עמודים או את כל היסטוריית השיחה – הארגון משלם שוב ושוב על מידע שכבר נשלח בעבר.
- ברוב המודלים, טוקנים יוצאים יקרים פי 3 עד 4 שטוקנים נכנסים. תשובות ארוכות שלא לצורך מנפחות את החשבונית החודשית במהירות.
איפה "דולף" התקציב? 7 הסיבות המרכזיות לגידול בעלויות AI
ברוב הארגונים, החריגה בתקציב אינה נגרמת מפעולה אחת יקרה, אלא ממיליוני פעולות קטנות ולא יעילות:
- שליחת כל היסטוריית השיחה מחדש בכל בקשה.
- צירוף מסמכים שלמים כאשר נדרשים רק סעיפים בודדים.
- שימוש במודל הפרימיום היקר ביותר גם למשימות סיווג וטקסט פשוטות.
- בקשת תשובות ארוכות ומילוליות ללא הגדרת מבנה פלט קשיח.
- ריבוי ניסיונות חוזרים (Retries) כתוצאה מפרומפטים לא מדויקים.
- שליחת הנחיות קבועות (System Prompts) פעם אחר פעם מחדש.
- תהליכים אוטומטיים (Agents/Pipelines) שמורצים ברקע ללא ניטור ומעקב FinOps.
7 אסטרטגיות פרקטיות לחיסכון והתייעלות ב-AI
שליחת מידע ממוקד בלבד (ארכיטקטורת RAG)
אחת הטעויות הנפוצות היא להזין למודל קובץ שלם בתקווה ש"ימצא כבר לבד". אם עובד שואל: "מהי מדיניות החברה לגבי החזר הוצאות בחו"ל?", אין צורך לשלוח למודל ספר נהלים בן 200 עמודים.
ארכיטקטורת RAG (Retrieval-Augmented Generation) מציעה פתרון: המערכת מחפשת ומחלצת מראש רק את הפסקאות הרלוונטיות, ורק אותן היא שולחת למודל.
התוצאה: פיזית פחות טוקנים נכנסים, תשובות מהירות יותר, פחות "הזיות" של המודל ואבטחת מידע משופרת.
סיכום היסטוריית השיחה
בשיחות ארוכות מצטברת היסטוריה עמוסה בשאלות, ניסיונות והחלטות ישנות. במקום לשלוח בכל קריאה את כל ה-Log, מומלץ ליצר "תקציר מצב" תקופתי.
דוגמה לתקציר שמשתקף למודל:
- פרויקט: הקמת מערכת שירות לקוחות בעברית
- מקור מידע: SharePoint
- סטטוס: אושר מנגנון החזרי תשלום
- משימה נוכחית: כתיבת מענה ללקוח בנושא ביטול עסקה
התקציר שומר על המשכיות השיחה, מסיר את "הרעש" וחוסך אלפי טוקנים מיותרים.
ניצול מנגנוני מטמון (Prompt & Context Caching)
במערכות ארגוניות ישנו מידע קבוע שנשלח שוב ושוב: נהלים, System Prompts , מבנה בסיסי נתונים ודוגמאות.
ספקיות הענן והמודלים (OpenAI ,Anthropic ,Google Gemini) מציעות כיום מנגנוני Prompt Caching. מנגנונים אלו מאפשרים לאחסן את החלקים הקבועים בזיכרון המערכת ולשלם עליהם עד 50%-90% פחות בקריאות הבאות, לצד קיצור משמעותי בזמן התגובה.
התאמת המודל למשימה
לא כל משימה דורשת את המודל החזק והיקר ביותר בשוק.
| סוג המודל | משימות מתאימות | דוגמאות |
| מודלים קלים ומהירים (SLMs) | סיווג פניות, חילוץ שמות/תאריכים, תיוג מסמכים, שינוי פורמט (JSON). | GPT-4o-mini, Claude Haiku, Gemini Flash |
| מודלים מתקדמים (LLMs) | ניתוח עומק, לוגיקה מורכבת, ארכיטקטורה, כתיבת קוד סבוך, החלטות בסיכון גבוה. | GPT-4o, Claude Sonnet/Opus, Gemini Pro |
ניתן להגדיר כללים פשוטים: Routing – חילוץ נתונים מטופס יופנה למודל קל; ניסוח חוזה משפטי יופנה למודל מתקדם בליווי בקרת אדם.
שליטה קפדנית באורך התשובה
הנחיות כלליות כמו "תסביר לי לעומק" מניבות תשובות ארוכות שאינן נחוצות, המנפחות את בעיית הטוקנים היוצאים (היקרים יותר).
הגדירו בפורמט הפרומפט או בהגדרות ה- API מגבלות ברורות:
- "החזר תשובה של עד 100 מילים."
- "הצג 3 המלצות בלבד בפורמט בולטים."
- "החזר אובייקט JSON בלבד ללא טקסט נלווה."
עיבוד אסינכרוני מרוכז (Batch Processing)
משימות שאינן דורשות מענה מיידי בזמן אמת, כגון ניתוח לוגים לילי, סיכום משובים שבועי, סיווג ארכיון מסמכים או יצירת Embeddings , מומלץ לאגד ולשלוח לעיבוד מרוכז.
ספקים רבים מציעים Batch API המעניק 50% הנחה על המחיר הרגיל תמורת עיבוד המשימה בטווח של עד 24 שעות.
מדידת ROI ולא רק כמות טוקנים
דאשבורד שמראה "צרכנו 100 מיליון טוקנים" אינו מספק תמונה ניהולית. FinOps נכון בודק ערך עסקי:
- מהי העלות הכוללת לטיפול מוצלח בפניית לקוח?
- כמה ניסיונות נדרשו עד לקבלת תוצאה תקינה?
- מהו אחוז התשובות שהתקבלו ואושרו ללא תיקון אנושי?
מודל יקר שפותח בעיה מורכבת בניסיון ראשון עשוי להיות כלכלי בהרבה ממודל זול שדורש 4 ניסיונות חוזרים ותיקונים ידניים.
ממה להיזהר? (מה לא לעשות)
אופטימיזציה אגרסיבית מדי עלולה לפגוע באיכות התוצרים. הימנעו מ:
- הדילול מוגזם של הקונטקסט שהמודל באמת חייב כדי לענות נכון.
- מעבר אוטומטי למודל הזול ביותר מבלי לבדוק את אחוז השגיאות.
- סיבוך יתר של ארכיטקטורת התוכנה (מנגנוני ניתוב מורכבים שעולים יותר מהחיסכון עצמו).
- התעלמות מהיבטי אבטחת מידע והרשאות בדרך לחיסכון.
איך מתחילים?
- בוחרים תהליך אחד בלבד: למשל: צ'אטבוט שירות או תהליך סיכום מסמכים.
- ממפים את הצריכה: כמה טוקנים נשלחים? מהו אחוז המידע החוזר על עצמו?
- מיישמים שינוי אחד: הגבלת פלט, Caching, או מעבר ל-RAG ממוקד.
- משווים תוצאות: מודדים עלות, איכות וזמן תגובה לפני ואחרי.
- מרחיבים לשאר תהליכי ה-AI בארגון.
לסיכום, ניהול טוקנים אינו נושא טכני בלבד – הוא חלק קריטי מניהול אסטרטגי של מערכות AI. ארגון שרוצה לייצר Scale אמיתי ולהטמיע חדשנות בלי לשרוף את התקציב, חייב לייצר תרבות FinOps מבוקרת.
רוצים להפוך את כלי ה-AI בארגון שלכם ליעילים, מבוקרים וחסכוניים? בחברת כרמל הדרכה אנו מעבירים הכשרות AI מעשיות וסדנאות יישומיות המותאמות לתהליכי העבודה הארגוניים שלכם. מוזמנים ליצור איתנו קשר לבניית תוכנית הכשרה מותאמת אישית.
