המודלים משתפרים. העסק שמסביבם מסתבך.

מישהו משלם על כל הצמיחה הזאת

מיקרוסופט דיווחה ב-28 באוקטובר על צמיחה של 48% ב-Azure ועל תזרים חופשי של 18.6 מיליארד דולר לחברה כולה. אצל Alphabet, הכנסות Google Cloud צמחו ב-103% לכ-30.7 מיליארד דולר. במקביל, השקעות הוניות של כ-51.4 מיליארד דולר עלו על התזרים התפעולי, כ-42.3 מיליארד. אפשר לראות כאן ביקוש חזק מאוד וחשבונית כבדה מאוד באותו רבעון. [1] [2] [3]

הנתונים אינם מאפשרים לקבוע מי מצאה את הנוסחה לרווחיות AI. הכנסות הענן כוללות שירותים אחרים; התזרים שייך לחברות שלמות, עם עסקים ותיקים שמייצרים מזומנים. אבל הם מחדדים את ההבדל בין שלוש כלכלות: יצרני התשתית, ספקי המודלים והיישומים, והלקוח שמשתמש בהם. צמיחה בשכבה אחת אינה מבטיחה רווח בשכבה שמתחתיה או מעליה.

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

הספק רוצה יותר שימוש. הלקוח רוצה פחות עבודה.

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

ניקח מספרים להמחשה. ארגון מעבד 10,000 מסמכים בחודש. הרצת המודל עולה שקל למסמך, וכל מסמך עובר שלוש דקות בדיקה אנושית בעלות עבודה של 120 שקל לשעה. חשבון המודל יהיה 10,000 שקל; הבדיקה תעלה עוד 60,000. הורדה של 50% במחיר המודל תחסוך 5,000 שקל. קיצור הבדיקה משלוש דקות לדקה ישחרר זמן עבודה ששוויו 40,000 שקל.

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

מיקרוסופט סיפקה בשיחת המשקיעים פרט שמתחבר לכך: חלק מהצמיחה נתמך בניצול טוב יותר של צי ה-CPU וה-GPU. השקעות נמוכות מהצפי נבעו גם מדחיית אספקה. [1] הראשון הוא שיפור תפעולי אפשרי; השני הוא עניין של עיתוי. עבור ספק תשתית, הפקת יותר הכנסה מאותו ציוד יכולה להיות חשובה כמעט כמו רכישת ציוד חדש. אצל הלקוח המקבילה היא להפיק יותר תוצאות מאותו תהליך, במקום למדוד כמה אנשים נכנסו לכלי.

למי יש זמן לחכות לתשואה

תוכנית המימון של Meta מוסיפה ממד אחר. ההיקף של כ-97.5 מיליארד דולר מורכב מ-25 מיליארד במניות רגילות באמצעות הסכמי מכירה עתידיים, 12.5 מיליארד בניירות המירים ותוכנית עתידית של עד 60 מיליארד. זה אינו סכום שכבר נכנס לקופה, והתוכנית העתידית עדיין כפופה לתנאים. [4] [5]

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

יש כאן בעיית תזמון: ההתחייבות למרכז נתונים מתקבלת הרבה לפני שיודעים אילו מודלים ירוצו בו ומה לקוחות יסכימו לשלם עליהם. חומרה יכולה להמשיך לעבוד היטב ובכל זאת לאבד יתרון כלכלי מול דור חדש. לכן צריך לשאול במשך כמה משנות פעילותה היא תצליח להרוויח בתנאי התחרות שיהיו אז.

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

העבודה הזולה החדשה, והעבודה היקרה שנשארת

Google הציגה ב-28 באוקטובר את Gemini 4 Carbon, עם דגש על משימות הנדסיות ממושכות וסייבר. לפי החברה, המודל מסוגל להתמיד בחקירות לאורך ימים; הגישה הראשונית מוגבלת למגיני סייבר נבחרים. אלה דיווחי הספק, לא הבטחה לביצועים בכל ארגון. מה שמעניין אותי כאן הוא האפשרות הכלכלית: חקירה שעד היום היה קשה להצדיק את עלותה עשויה להפוך לעבודה שאפשר לבצע באופן שוטף. [6]

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

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

מה המודל צריך לדעת כדי לעבוד כאן

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

כאן אני רואה חיבור ישיר ל-Company Brain. מאגר מסמכים שניתן לחפש בו יכול לעזור למצוא תשובה; עבודה עצמאית דורשת גם לדעת איזו תשובה בתוקף, מה הייתה ההחלטה, על מי היא חלה ומי רשאי לשנות אותה. שתי הנחיות סותרות אינן רק בעיית חיפוש. אדם יכול להרים טלפון ולהכריע. סוכן שפועל אלפי פעמים צריך דרך מוסדרת להתמודד עם הסתירה.

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

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

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

תפקיד המומחה נעשה פחות ממוקד בניסוח כל שינוי ויותר בהגדרת מה נחשב שינוי נכון. זה דורש הבנה עמוקה של המערכת ושל העסק. ארגון שימדוד רק כמה קוד נכתב עלול להחליש את האנשים שבזכותם אפשר לסמוך על הקוד הזה.

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

האפשרות המעניינת היא לייצר ניסיון

קל להסתכל על Genie 4 ולראות עוד קפיצה באיכות התמונה. Google הציגה אותו ב-27 באוקטובר כמודל המייצר סביבה אינטראקטיבית בזמן אמת, עם קול ויכולת לשנות את הסצנה בשפה טבעית. הוא פתוח לקבוצת בודקים מוגבלת. [7] בעיניי, ההבטחה המעניינת נמצאת במקום אחר: היכולת לייצר הרבה יותר מצבים שאפשר להתנסות בהם.

ניסיון בעולם האמיתי הוא חומר גלם יקר. צריך אתר, ציוד, אנשים וזמן. אירועים מסוכנים או נדירים קשה לשחזר, ולפעמים אסור. אם אפשר לבנות מגוון סביבות בעלות נמוכה, ניתן לחשוב על תרגול עשיר יותר לעובדים ועל סביבות אימון לסוכנים ולרובוטים. זהו פוטנציאל, לא תוצאה שכבר הוכחה עבור Genie 4, אבל יש בו יותר משמעות כלכלית מאשר ״וידאו מרשים שאפשר להסתובב בו״.

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

אבל מי בודק את העולם שמלמד את הסוכן?

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

Google מציינת מגבלות של עקביות לאורך זמן, אינטראקציות בין סוכנים, שחזור מקומות אמיתיים ומשך התנסות של דקות אחדות. [8] בסרט, חפץ שזז מעט בין רגעים עלול להיות פגם אסתטי; בתרגיל שבו לומדים כיצד לנוע סביב מכשול, אותו שינוי עלול ללמד התנהגות לא נכונה.

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

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

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

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

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