Reef TRH2%. זה בערך החלק שחשבון ה-API, המספר היחיד שכולם מציגים במצגת, מייצג מתוך עלות התפעול האמיתית של פיצ'ר AI. קחו למשל צוות תמיכה בגודל בינוני שמטפל בשמונת אלפים אימיילים בחודש. עלות הטוקנים של ניתוח ראשוני של כל המיילים האלה דרך המודל היא כל כך נמוכה, שהיא נראית כמו שגיאת עיגול לעומת משכורת בודדת. זו בדיוק הסיבה שמציגים אותה, כי במצגת, המספר הזה סוגר את העסקה.
זהו גם המספר המטעה ביותר בתחשיב. הוא לא שגוי, הרי הטוקנים באמת זולים מאוד. הם פשוט זניחים, אך מציגים אותם כאילו הם מייצגים את החשבון כולו. ההוצאה על טוקנים היא רק קצה הקרחון. רוב העלויות הנדרשות כדי להחזיק את הפיצ'ר באוויר נמצאות מתחת לפני המים, ואף אחת מהן לא תצוף עד שכבר תהיו מחויבים לפרויקט.
חשבון הטוקנים הוא בסך הכל שגיאת עיגול
הקריאה למודל היא הרכיב היחיד בפיצ'ר AI שהוא זול, מדיד וצפוי. התמחור שלו גלוי וניתן לבדיקה תוך דקה. מה שאי אפשר לבדוק בקלות הוא כמה עולה להפוך את הפלט הזה לבטוח מספיק לשימוש עסקי, וזה בדיוק הרכיב שעליו אתם באמת משלמים.
בואו ניקח את הפיצ'ר של שמונת אלפים האימיילים ונתמחר אותו בצורה ריאלית, ולא מתוך אופטימיות יתר.
גם לאחר שקלול של ניסיונות חוזרים ופרומפטים ארוכים בהרבה מההערכות הראשוניות, עלות הטוקנים נשארת הסעיף הקטן ביותר בגיליון התקציב. בקרה אנושית על פלח הפניות שהמודל אינו יכול לשלוח בעצמו בבטחה (כ-40% מהנפח, תשעים שניות לפריט) עולה פי כמה מחשבון הטוקנים כולו. עלויות מערך ההערכה, לוחות הבקרה והתראות הסחף גבוהות אף יותר בפריסה על פני השנה הראשונה. guardrails והאינטגרציות שנשברות בכל פעם שהספק מעדכן endpoint מוסיפים עוד סעיף הוצאה באותו סדר גודל. כשמציגים את הגיליון המלא, עלות הטוקנים מהווה בערך חלק אחד מתוך חמישים מהסכום הכולל.
במילים אחרות, המספר שמוצג במצגת מהווה רק כ-2% מעלות התפעול האמיתית של פיצ'ר AI. מצגת המכירה פשוט מציגה את הסעיף הזול ביותר ומציגה אותו כמחיר המלא.
לחבר את כל העלויות שאף אחד לא מתמחר
אם תפרקו את הפיצ'ר לגורמים, תגלו שאתם משלמים על חמישה רכיבים שהדמו שלכם מעולם לא נזקק להם:
- הערכה, מערך בדיקות מתויג ותשתית שמוכיחה שהמערכת עדיין עובדת בצורה תקינה לאחר כל שינוי בפרומפט או עדכון מודל.
- guardrails, תהליכי הוולידציה שמזהים תשובות שגויות שנשמעות משכנעות ורהוטות, לפני שהן מגיעות ללקוח.
- בקרה אנושית, פלח הפעילות שהמודל אינו מסוגל לפתור באופן עצמאי, המתומחר בשעות עבודה חודשיות שוטפות.
- ניטור וזיהוי סחף, כדי לדעת שאיכות הפלט ירדה לפני שהלקוחות שלכם יתחילו להתלונן.
- תחלופת מודלים, בדיקה מחדש של הפיצ'ר כולו בכל פעם שהספק משנה את התמחור, מוציא מודל משימוש או "משפר" בשקט את המודל שבו אתם משתמשים.
אף אחד מהסעיפים האלה אינו בגדר רשות. הם ההבדל בין פיצ'ר יציב שעובד באופן שוטף, לבין פיצ'ר שרץ בהצלחה רק פעם אחת, בדמו, ביום טוב.
העלויות שצצות בחודש השלישי
החלק המאתגר באמת הוא התזמון. העלויות שקל לחזות מראש (כמו טוקנים וסבב הבדיקות הראשוני) הן הנמוכות ביותר ומגיעות מוקדם. העלויות הכבדות נוחתות מאוחר יותר, אחרי שההתלהבות הראשונית שוככת ומתחילים להגיע נתונים מהעולם האמיתי.
בפיצ'ר שהצגנו למעלה, עלות התפעול החודשית כמעט שולשה בין שלב ההשקה לחודש השלישי, כשרצף של ניסיונות חוזרים, עומס בדיקות ותורי אסקלציה הפכו לחלק מהשגרה.
איכות הפלט נשחקת ככל שהקלטים משתנים, ולכן נפח הבדיקות הולך וגדל במקום להצטמצם. ספק ה-API מוציא משימוש את המודל שעליו התבססתם ומותיר לכם תשעים יום לבצע הגירה ובדיקות מחדש. מקרי קצה שמעולם לא צצו בפיילוט מתחילים לייצר קריאות שירות דחופות, ומישהו מהצוות חייב להיות זמין לטפל בהם ב-2 בלילה. עלות התפעול האמיתית נחשפת רק כשהפיצ'ר מתמודד עם תעבורה אמיתית, וזו בדיוק המלכודת שמותירה את רוב פיילוטי ה-AI הרחק מפרודקשן.
תקצבו את המערכת, לא את הקריאה
תמחור של פתרון AI לפי קריאות API דומה לתמחור של חברת שליחויות לפי עלות הדלק: זהו נתון אמיתי וקל למדידה, אך הוא לא אומר כמעט כלום על העלות האמיתית של הפעלת הצי כולו. מדד העלות החשוב באמת אינו מחיר הטוקן, אלא קבלת תוצאה אמינה ויציבה לאורך זמן, גם כשהקלטים משתנים ומודלים מתחלפים ללא הרף.
המספר הזה אולי פחות אטרקטיבי מזה שמופיע בעמודי התמחור של הספקים, אך הוא שימושי בהרבה. הוא גם ניתן לחיזוי מראש, שכן סעיפי העלות הללו צפויים לחלוטין אם רק יודעים היכן לחפש אותם. אבחון מוכנות ל-AI נועד לספק הערכה ריאלית של עלויות הבקרה, הניטור והבדיקות החוזרות, עוד לפני שאתם מאשרים תקציב המבוסס על עלות הטוקנים בלבד.
שאלות נפוצות
כמה באמת עולה להריץ פיצ'ר AI בפרודקשן? עלות הטוקנים או ה-API מהווה בדרך כלל חלק קטן מאוד (לרוב פחות מ-5%) מההוצאה החודשית הכוללת. עיקר העלות נובע מבקרה אנושית על מקרים שהמודל אינו מסוגל לפתור בעצמו, תהליכי הערכה וניטור, guardrails, ובדיקות חוזרות בכל פעם שהמודל מתעדכן. פיצ'ר שעלות הטוקנים שלו נראית זניחה לחלוטין עלול להסתיר מאחוריו עלות תפעול כוללת הגבוהה פי חמישים.
למה עלות ה-API מהווה חלק קטן כל כך מההוצאה הכוללת? מכיוון שהקריאה למודל היא הרכיב היחיד שהוא זול וצפוי מראש. הפיכת הפלט לאמין (זיהוי תשובות שגויות שנשמעות משכנעות, ווידוא ששום דבר לא נשבר לאחר עדכון) דורשת עבודה של אנשי מקצוע ותהליכי פיתוח, ושם בדיוק מושקע עיקר התקציב.
כיצד מעריכים את העלות האמיתית לפני שמתחילים לפתח? מתמחרים את התוצאה הסופית, ולא את הקריאה למודל. יש להעריך את פלח הפעילות שעדיין דורש מעורבות אנושית, את עלויות מערך ההערכה והניטור שתצטרכו לתחזק, ואת הבדיקות החוזרות שכל עדכון מודל מחייב. רק בסוף מוסיפים לתחשיב את עלות הטוקנים, במקום הראוי לה.
אם תתמחרו רק את המודל, תטעו פי חמישים. תמחרו את המערכת המקיפה אותו (הבדיקות, הניטור והבדיקות החוזרות הבלתי נגמרות) ותקבלו הערכה קרובה למציאות. עלות הטוקנים מעולם לא הייתה השאלה הנכונה, היא פשוט הייתה הנתון שהכי קל לקבל.