Android XR

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

רמקולים

מידע כללי

מידע על ההרצאה

השילוב של AI בממשק שיחה בחוויות סוחפות פותח אפשרויות עצומות, אבל יש מתח מתמיד בין זמן אחזור קצר של תגובות לבין עלויות ענן סבירות. במפגש הזה, דווין ריימר (מייסד ומנכ "ל AstroBeam) מסביר איך הצוות של Stellar Cafe הצליח להגיע לזמני תגובה מובילים בתחום לאינטראקציה קולית (1.15-1.4 שניות), תוך שמירה על מודל עסקי רווחי.

נבחן את הארכיטקטורה ההיברידית שמאחורי צינורות עיבוד הנתונים האלה עם זמן אחזור קצר, ונתמקד בתזמור חכם בין מודלים במכשיר לבין הסקת מסקנות בענן שעברה אופטימיזציה, כדי לצמצם קריאות יקרות ל-API בלי לפגוע בשיחה. בסיום הסדנה תהיה לכם תוכנית מעשית שכוללת אופטימיזציה של הזמן עד לקבלת הטוקן הראשון (TTFT) בתהליכים של המרת דיבור לטקסט (STT) והמרת טקסט לדיבור (TTS) בסטרימינג, אמצעי הגנה מקבילים שעוקפים את זמן האחזור וכלכלת יחידות לכל סשן של משתמש פעיל.

סיכום

  • זמן אחזור מקצה לקצה של כ-1.5 שניות מאפשר למשתמשים להרגיש בנוח עם סוכני קול לשיחות, בלי תלונות על איטיות. העקביות חשובה אפילו יותר ממהירות השיא, כדי שהשיחות לא ירגישו מקוטעות.
  • הפעלה מקבילה של צינורות עיבוד נתונים של דיבור מקצרת את זמני התגובה, והיא זולה פי 3 עד 5 ממודלים של דיבור לדיבור. הפעלת בדיקות בטיחות במקביל לחלקים הראשונים של המרת הטקסט לדיבור לא מוסיפה זמן אחזור.
  • כדי שהסוכן יהיה חכם, הוא צריך שיעורי שגיאות נמוכים בתמלול ודיבור אקספרסיבי. חשוב גם שהמודלים יהיו קלים לפיתוח, כדי שהמפתחים לא יצטרכו להתמודד עם עומס עבודה מיותר.
  • צריך למדל את הכלכלה של הענן מראש על ידי השוואה בין עלויות השרת לכל משתמש לבין ההכנסה הצפויה. ב-Stellar Cafe השיגו שולי רווח סבירים של כ-1.20 $לשעה לכל משתמש עם תמחור אחיד.
  • מודלים עם משקלים פתוחים לא מוצאים משימוש לעיתים קרובות, והעמלות שלהם לא עולות כמו במודלים סגורים. אירוח עצמי של המודלים מאפשר עלויות צפויות ומגן על לוחות הזמנים של הייצור מפני העברות כפויות.

משאבים

Gemini Notebook

נושאים

  • סוכנים קוליים
  • המרת דיבור לטקסט (STT)
  • המרת טקסט לדיבור (TTS)
  • large-language-models
  • זמן אחזור קצר
  • cloud-economics
  • game-development

תמליל

הורדת התמליל

מבוא לסוכנים קוליים ולאתגרים המרכזיים

  • Devin Reimer

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

  • אז אני דווין ריימר.

  • אני המייסד והמנכ"ל של AstroBeam.

  • לפני כן הייתי המנכ"ל והמייסד השותף של Owlchemy Labs, שמוכרת בעיקר בזכות Job Simulator.

  • לכן, ב-AstroBeam אנחנו מתמקדים בפיתוח AI בזמן אמת במשחקים.

  • באופן ספציפי, אנחנו מתמקדים בקול כקלט.

  • עד עכשיו הוצאנו שני משחקים, Stellar Cafe, שהוא משחק VR ו-PC.

  • זה משחק שבו מדברים עם רובוטים בבית קפה בתחנת חלל ועוזרים להם לפתור את הבעיות שלהם.

  • הוא מופעל באמצעות הקול בלבד.

  • אתם יכולים לשחק במשחק כולו, כולל התפריטים והניווט, רק באמצעות הקול.

  • המשחק הבא שלנו, Robo Detective, שהכרזנו עליו היום, מיועד ל-Android XR ובמיוחד ל-Project Aura של XREAL.

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

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

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

  • בנוסף, אנחנו לא מתחרים בסוכנים קוליים אחרים, אנחנו מתחרים באיכות של כל משחק שנוצר אי פעם, נכון?

  • לכן, אנחנו צריכים להציע איכות גבוהה מאוד.

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

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

  • לכן, אני מאמין שאם סוכנים קוליים יכולים לעבוד בתוך משחקים, הם יכולים לעבוד כמעט בכל מקום.

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

  • אז כשחושבים על סוכנים קוליים, יש שלושה אתגרים עיקריים.

  • אז יש לנו זמן אחזור, אינטליגנציה ועלות.

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

  • אני לא מדבר על מעטפת של מיקרופון ששולחת משהו למודל LLM ואז מחכה לתשובה.

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

  • נתחיל עם זמן האחזור.

  • כמה מהר צריך לעשות את זה?

  • מסתבר שהיא צריכה להיות מהירה, מהירה מאוד, אבל בהתאם למה שקראתם, יכול להיות שהיא לא מהירה כמו שאתם חושבים, או שהיא הרבה יותר מהירה ממה שאתם חושבים.

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

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

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

  • נראה שזה השלב שבו אנשים מתחילים להרגיש ממש בנוח עם זה.

  • ברגע שהתגובה איטית יותר, אנשים אומרים "זה נהדר, אבל", אז נראה שזה פחות או יותר הזמן האידיאלי.

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

  • למשל, אני אומר משהו, ובמקרה הזה הרובוט אומר משהו ממש מהר, ואז ממשיכים לדבר ככה.

  • נראה שיש שם נקודה מתוקה שפתוחה.

  • עם זאת, קשה מאוד להגיע ל-1.2 שניות בתוך ערימה.

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

  • ואז אתם חושבים לעצמכם, "וואו, זה הולך להיות מדהים!"

  • ולפעמים זה היה, ולפעמים זה הרגיש נורא, מאוד מוזר.

  • לכן, יכול להיות שתשמעו אנשים אומרים שזמן תגובה של 800 מילישניות הוא המספר הנכון, או 500.

  • אפילו קראתי כמה מאמרים על 300 כי זה באמת המקום שבו התפיסה האנושית נוחתת.

  • בפועל, זה תלוי מאוד בהקשר.

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

  • אם אשאל אותך מה משמעות החיים, אצפה לזמן תגובה שונה מאוד.

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

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

  • וגם איפה הם היו בשיחה.

  • בדרך כלל אנשים מצפים שהתשובה הראשונה תהיה מהירה יותר מהתשובות הבאות, כי יש זמן חשיבה.

  • אבל לפעמים יש שיחה קצרה, ואז הציפיות עולות.

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

  • אז ברגע שמגיעים ל-1.5 שניות, עכשיו באמת מתחילים לדאוג לגבי עקביות, נכון?

  • כי אם זה קורה ב-90% מהמקרים, אבל ב-10% מהמקרים זה לוקח 3 שניות, החוויה תרגיש מקולקלת, לא רעה, אלא מקולקלת.

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

ארכיטקטורה ואופטימיזציה של צינור עיבוד נתונים קולי

  • Devin Reimer

    אז הנה ארכיטקטורה סטנדרטית של צינור עיבוד נתונים קולי.

  • אז אנחנו לוקחים את המרת הדיבור לטקסט, שולחים אותה ל-LLM, ואז שולחים את התוצאה מה-LLM בחזרה להמרת הטקסט לדיבור.

  • כלומר, בהמרת דיבור לטקסט, אנחנו שולחים אודיו לשרת ואז ממירים אותו לטקסט.

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

  • אנחנו מצמידים אותם בצימוד חזק כי אנחנו חושבים שזה מאוד חשוב.

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

  • אחת הבעיות היא שהרצה רציפה יכולה להיות איטית, כי צריך לעבור על כל אחד מהדברים האלה.

  • אז שאלה נפוצה שאני מקבל היא, אם זה איטי וצריך לעשות שלושה שלבים, למה לא להשתמש במודל דיבור לדיבור במקום?

  • כי זה יהיה מהיר יותר, נכון?

  • וכן, ברוב המקרים זה יהיה מהיר יותר כי מריצים רק דבר אחד.

  • אבל יש לזה מחיר.

  • אז למרות שהיא מהירה, יש כמה דברים שמונעים מאיתנו להשתמש בה, והגדול שבהם הוא העלות.

  • לכן, באופן כללי גילינו שהפעלת מודל דיבור לדיבור יקרה פי 3 עד 5 מהגישה המקבילה הזו.

  • ולכן, מבחינתנו, המודל הכלכלי פשוט לא עובד.

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

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

  • בסגנון הקול, אתם די מוגבלים להגדרות הקבועות מראש במודל הדיבור לדיבור.

  • אי אפשר להגיד, "אה, אתם יודעים מה?

  • במקרה הזה, אני ממש רוצה להשתמש בסוג הקול הזה".

  • אתם תקועים עם השם הזה.

  • בגישה של צינור עיבוד הנתונים, אפשר להגיד "אני הולך לשנות את זה.

  • אני אבחר במודל הזה כי הוא מתאים מאוד לתרחיש הספציפי הזה".

  • אותו דבר לגבי אינטליגנציה, נכון?

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

  • אתם קצת נעולים.

  • בגישה של צינור עיבוד נתונים, אתם אומרים לעצמכם: "אה, לתרחיש הזה אני רוצה להשתמש במודל מסוים".

  • תחום אחד שבו Speech-to-Speech בהחלט מנצח הוא הבנת הטון של המשתמש.

  • למשל, דברים כמו סרקזם.

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

  • זה בהחלט יתרון של המודל Speech-to-Speech.

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

  • אז יש דרך אחרת?

  • כן.

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

  • לכן, חלק מהדברים שאנחנו עושים זה להפעיל את ה-LLM לפני שהמרת הדיבור לטקסט (STT) בטוחה לחלוטין.

  • כשאני אומר "רמת סמך", אני מתכוון לרמת הסמך של המילים שנוצרות בתמליל, ואז לרמת הסמך של סוף התור.

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

  • אז התרחיש הכי גרוע הוא שטעינו, נכון?

  • המשתמש ממשיך לדבר.

  • אבל גם במקרה כזה, כל מה שאנחנו עושים זה לבטל את ה-LLM ואז להפעיל אותו שוב.

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

  • בנוסף, אנחנו לא מחכים שה-LLM יסיים ליצור את כל התשובה לפני שאנחנו מתחילים לשלוח אותה להמרת טקסט לדיבור.

  • אנחנו מחכים לחלק הראשון שאפשר להקריא.

  • ברוב המקרים, מדובר במשפט.

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

  • ואז, אם יש לנו המרת טקסט לדיבור (TTS) טובה שמועברת בסטרימינג, ברגע שהיא מוכנה לסטרימינג, היא יכולה להגיע למשתמש.

  • אנחנו גם מקפידים מאוד על מספר הטוקנים שצריך ליצור.

  • לכן אנחנו לא משתמשים בדברים כמו מעטפות JSON ודברים דומים שעשויים להוסיף עוד טוקנים.

  • אנחנו מנסים להבין מהו המבנה הפשוט ביותר שיאפשר לקבל את התשובה המהירה ביותר.

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

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

  • אז הקטע הראשון שניתן להקראה נכנס ואז אנחנו מריצים את כל השאר אחריו.

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

  • אז למעשה, המשתמש לא רואה את זה.

  • הוא מגיע לשם הכי מהר שאפשר.

  • אז כשאתם חושבים על בחירה של שירותים שונים, הנה כמה כללי אצבע.

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

  • אז כמה מהר אפשר להעלות ולהוריד דברים?

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

  • אז זהו מדד המהימנות בתמליל ובסיום התור.

  • הם מותאמים, נכון?

  • אם לא בוטחים במודל מהר, הוא פשוט יהיה איטי, נכון?

  • לכן, המהירות של המודל כולו תלויה במהירות של המודל הכי איטי.

  • בצד של ה-LLM, חשוב לנו הזמן עד למשפט הראשון, החלק הראשון שאפשר להקריא.

  • אז יש שני חלקים, נכון?

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

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

  • לכן, צריך להבין מהו השילוב הנכון.

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

  • לכן חשוב מאוד למדוד את זה, כי לפעמים האודיו יכול לחזור עם שתיקה בהתחלה והמשתמש לא ישמע את זה.

  • לכן, צריך למדוד עד לנקודה שבה המשתמש שומע דברים.

  • וכמו שציינתי קודם, הדבר הכי חשוב הוא היציבות, לא מהירויות שיא, לא התרחיש הכי טוב.

  • מהו זמן האחזור העקבי של כל המערכת הזו?

מחסנית סוכני הקול של Astrobeam

  • Devin Reimer

    לכן, כרגע אנחנו משתמשים ב-LiveKit בתור מסגרת לסוכני האודיו שלנו.

  • להמרת דיבור לטקסט, אנחנו משתמשים ב-Deepgram.

  • אנחנו משתמשים במודל Gemma 4 31B, ומארחים אותו ב-LiveKit.

  • בכל מה שקשור להמרת טקסט לדיבור, אנחנו משתמשים ב-Inworld AI text-to-speech 2.

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

  • אז דבר אחד שלא דיברתי עליו הוא מה לגבי מודלים של בטיחות?

  • באופן מסורתי, מודלים של בטיחות הם חלק מהמעבר של מודל ה-LLM, אבל זה מוסיף זמן אחזור ושלב נוסף בתהליך.

  • אז מה אם במקום זאת תפעילו אתר משלכם?

  • אז ככה נראה המחסנית שלנו.

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

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

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

  • וזה חשוב לנו מאוד, במיוחד כי אנחנו מפתחים משחקים.

  • יש כל כך הרבה הקשר בעולם הזה, וזה חשוב מאוד.

  • לדוגמה, נניח שאתם מפתחים משחק על ימי הביניים, ויש לכם דמות NPC במשחק שצועקת "הסתערות!

  • "תערפו את הראשים שלהם!", נכון?

  • מודל בטיחות מסורתי עשוי להגיב בצורה כזו: "וואו, זה לא בסדר.

  • אתה לא צריך להגיד את זה".

  • אבל בהקשר של המשחק הזה, זה הגיוני לחלוטין.

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

  • אולי שמתם לב שאנחנו מפעילים את מודל הבטיחות פעמיים: פעם אחת על החלק הראשון, ופעם שנייה על כל התוכן כשהחלק האחרון מוכן.

  • שוב, אנחנו צריכים להריץ את זה פעמיים, אבל זה לא מוסיף זמן אחזור למחסנית.

  • אז עכשיו אנחנו מהירים מספיק, אבל לצערנו זה לא משנה אם אנחנו לא חכמים מספיק.

הגדרה והערכה של אינטליגנציה של סוכנים

  • Devin Reimer

    אז עד כמה חכם הוא צריך להיות?

  • הוא צריך להיות חכם מספיק בשביל המשתמשים, אבל חשוב לא פחות – חכם מספיק בשבילכם, כדי שתוכלו לפתח איתו.

  • וזה משהו שאנשים לא תמיד חושבים עליו כשהם בוחרים את מה שהם צריכים בשביל המודיעין.

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

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

  • זה משהו שאנחנו נותנים לו עדיפות, כי אם אנחנו לא יכולים לפעול מהר בפיתוח הדברים האלה, אנחנו לא יכולים להוציא דברים למשתמשים.

  • לכן, חשוב מאוד לחשוב על שני ההיבטים האלה.

  • אז לעיתים קרובות כשאנשים חושבים על בינה, הם חושבים על מודל ה-LLM, נכון?

  • אבל זה רק חלק מהעניין.

  • אנחנו צריכים לחשוב על כל חלק כשמדובר בבינה.

  • אז בואו נדבר על המרת דיבור לטקסט (STT) חכמה.

  • לכן, מה שחשוב לנו כאן הוא שיעור שגיאות נמוך במילים.

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

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

  • דבר נוסף שצריך לחשוב עליו הוא מהי פלטפורמת היעד שלכם.

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

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

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

  • אז בואו נעבור לצד של המרת הטקסט לדיבור במשוואת הבינה.

  • נשמע טבעי, נכון?

  • המטרה שלנו היא להעביר למשתמש את המידע בצורה שהוא יוכל להבין.

  • אבל זה רק חלק מהעניין, נכון?

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

  • ואז, האם הוא מהיר מספיק?

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

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

  • אם אני עונה מהר, כנראה שהתשובה שלי נשמעת חכמה יותר.

  • לכן, לדברים האלה יכולה להיות השפעה משמעותית על האופן שבו המשתמש תופס את החוויה, וגם על מידת המעורבות שלו בחוויה.

  • אז עכשיו נעבור לחלק של ה-LLM.

  • זה, ללא ספק, החלק שהכי קשה לאזן כי יש כל כך הרבה דרישות שונות כאן, נכון?

  • אז יש לנו סוג של הבנת דיבור, הקשר ועיגון.

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

  • זה לא תיבת טקסט שבה הוא יכול להמציא דברים שקורים.

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

  • אנחנו צריכים גם דברים כמו ציות קפדני לכללים.

  • משחקים מבוססים מאוד על כללים.

  • האם מודל ה-LLM יכול להתמודד עם זה?

  • Can we have a low hallucination rate?

  • האם אפשר ליצור דמויות עקביות כשמקיימים אינטראקציה עם אותו סוכן שוב ושוב?

  • האם זה מרגיש כמו אותו נציג?

  • ואז, משהו שיכול להכשיל אתכם, כי זו לא בעיה בתחילת הפיתוח, הוא: האם המודל שלכם יכול להתמודד עם גודל ההנחיה שגדל?

  • כי באופן בלתי נמנע, ככל שתמשיכו לפתח, אתם תוסיפו עוד דברים להנחיה.

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

  • אז האם ההנחיה הזו תטפל בצמיחה הזו?

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

  • אבל זה רק קצה הקרחון, והכול תלוי במה שאתם בונים.

  • לכן צריך לחשוב טוב טוב מה אתם בונים ומה אתם מנסים להשיג.

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

מודלים של עלויות וכלכלה של סוכני קול

  • Devin Reimer

    אז כמה זול זה צריך להיות?

  • לצערנו, זה קצת יותר מורכב מזה.

  • אז אנחנו צריכים לחשוב על הכלכלה של האפליקציה או המשחק שאנחנו בונים, נכון?

  • אז יש כמה שאלות שצריך לשאול.

  • כמה זמן המשתמשים יתקשרו עם הנציגים הקוליים?

  • כמה כסף אתם מרוויחים מכל משתמש?

  • וכמה עולה להפעיל את מערכת הקול הזו לשעה?

  • אנחנו מחברים אותם כדי לנסות להבין את התמונה הכוללת, לראות אם הדברים הגיוניים.

  • אז הנה הכלכלה של המשחק הראשון שלנו, Stellar Cafe.

  • אז זמן המשחק ב-Stellar Cafe הוא בין שעה וחצי ל-3 שעות וחצי, אז נניח שהממוצע הוא בערך שעתיים.

  • עלות ההפעלה של סוכני הקול שלנו היא בערך 1.20 $לשעה לכל משתמש, והמשתמשים מקיימים איתם אינטראקציה 100% מהזמן.

  • המשחק מופעל באמצעות הקול בלבד.

  • אנחנו גובים תשלום קבוע של 10 $על המשחק, שזה מחיר מקובל.

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

  • בעבר גבינו 15$, אבל פעלנו כדי להוזיל את עלויות השרתים, ועכשיו הצלחנו להוריד את המחיר ל-10$.

  • והסכום הזה של 1.20 $הוא המקום שבו אנחנו נמצאים.

  • זה לא מחיר אוניברסלי.

  • ראיתי שהדברים האלה עולים במגוון רחב של דברים, ולפעמים הרבה יותר יקרים.

  • ולכן, צריך גם להבין איפה אתם נמצאים מבחינת העלויות.

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

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

  • אז בגלל שאנחנו גובים 10 דולר, והחנות גובה עמלה, זה אומר שאנחנו מרוויחים בערך 4.59 דולר לכל משתמש, נכון?

  • אז מבחינה כלכלית זה עובד, נכון?

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

  • אז זה משחק ממש קטן.

  • בואו נדבר על משהו קצת יותר גדול.

  • אז בואו נדבר על משחק היפותטי, משחק עלילתי, שאורך בין 5 ל-9 שעות, נניח 7 שעות בממוצע.

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

  • אז נשמור על 1.20 $לשעה, אבל השינוי שנעשה הוא שרכיב הקול ישמש ב-60% מהזמן, כי למשחק גדול יותר יהיו הרבה יותר מכניקות מאשר רק קול.

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

  • אז אם אנחנו גובים 20 דולר, ונעבור על כל זה שוב, זה עולה לנו בערך, זה יעלה לנו בערך 5 דולר למשתמש, מה שאומר שבסופו של דבר, אנחנו מרוויחים בערך 9 דולר למשתמש.

  • אז שוב, עם זה, הכלכלה עובדת.

  • זה לא אומר שהמודל הכלכלי הזה יעבוד לכל דבר.

  • לדוגמה, אם אתם רוצים ליצור משחק בחינם, וסביר להניח שהמשתמשים ישחקו בו בין שעה אחת ליותר מ-100 שעות.

  • אז נניח שהממוצע הוא 10 שעות.

  • הוא מופעל ב-100% באמצעות הקול, אבל נניח שיש לנו להיט, והמשחק מניב בערך 3 דולר למשתמש, נכון, וזה יהיה די נהדר למשחק בחינם.

  • ההפסד יהיה 10 $למשתמש.

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

  • אל תחכו עד הסוף כדי לנסות להבין את ההיבטים הכלכליים.

מודלים מקומיים לעומת פריסה בענן

  • Devin Reimer

    אז השאלה הבאה היא, מה לגבי מודלים מקומיים?

  • כי אם יש את האתגר הגדול הזה של העלות, האם מודלים מקומיים לא יבטלו אותו?

  • וכן, זה אפשרי.

  • אבל יש כאן כמה פשרות שאנחנו צריכים לחשוב עליהן.

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

  • אבל יש הרבה דברים שהענן יכול לפתור כרגע, וקשה יותר לפתור באופן מקומי.

  • לדוגמה, compute.

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

  • מעולה, אבל צריך לזכור שלא מדובר במודל אחד, אלא בכמה מודלים, נכון?

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

  • ואם תעשו את זה, האם יישארו מספיק משאבים כדי להפעיל את המשחק או האפליקציה?

  • אם ה-GPU מגיע למקסימום, לא באמת תוכלו לעבד הרבה ממשחק וידאו.

  • נניח שהתגברתם על האתגרים האלה.

  • אז הבא הוא מהירות, נכון?

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

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

  • האתגר כרגע הוא למצוא מודלים שיפעלו במהירות הנכונה כדי שזה יעבוד.

  • אז נניח שהתגברתם על בעיות המחשוב והמהירות, עכשיו צריך לחשוב על האיכות, נכון?

  • באופן כללי, כשמריצים את המודל במכשיר מקומי, משתמשים במודל LLM קטן יותר, למשל, המרת טקסט לדיבור (TTS) פרימיטיבית יותר. זה יכול להציב אתגרים מסוימים כשמדובר בתוכן שאתם יוצרים.

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

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

  • אז נניח שכבשתם את תחום המחשוב, כבשתם את תחום המהירות, כבשתם את תחום האיכות, השלב הבא הוא ניידות.

  • אם זכיתם ועברתם את כל התהליך הזה, והפעלתם את הדבר הזה, נניח, ב-RTX 5070, יכול להיות שזה המקום היחיד שבו הוא יכול לפעול.

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

  • בצד של הענן, כל מה שצריך זה חיבור לאינטרנט.

  • וזה סוג של פריצת דרך.

  • מאפשרת לשדר לכמה פלטפורמות.

  • אז עכשיו נדבר על גישה היברידית, נכון?

  • אז בואו נריץ חלק מהדברים בענן וחלק מהדברים באופן מקומי.

  • בערך, זה יכול לעבוד?

  • טוב, זה לא ניצחון גדול כמו שאתם חושבים.

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

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

  • הדבר הבא שעולה הוא, מה אם במקום זאת תפעילו אותו באופן מקומי אם זה אפשרי, נכון?

  • יש להם את החומרה המתאימה, ובענן אם אין לכם, נכון?

  • אפשר להריץ משהו חזק יותר בענן.

  • זה מביא איתו אתגרים חדשים, נכון?

  • אם בסופו של דבר תשתמשו במודל אחר, זה יכול להשפיע מאוד על הפיתוח.

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

  • ויכולים להיות מודלים שמתנהגים בצורה שונה לגמרי.

  • אז אם לא משתמשים בדיוק באותם מודלים, יכול להיות שזמן הפיתוח והעלות יגדלו משמעותית.

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

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

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

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

  • היום זה קצת מסובך, חוץ ממקרים ספציפיים, במיוחד דברים שקשורים לפקודות.

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

  • לכן אנחנו משתמשים בענן.

  • אבל זה תחום שמתפתח במהירות, והדברים משתנים כל הזמן.

  • החלק הבא הוא לחשוב על המודלים שבהם אנחנו משתמשים, נכון?

  • אז השאלה הבאה היא משקלים פתוחים לעומת משקלים סגורים.

  • מה אנחנו צריכים לעשות כאן?

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

  • אז בהחלט יש כאן יתרונות וחסרונות.

  • אז כשמדובר במודלים סגורים, אלה בדרך כלל המודלים המתקדמים ביותר, נכון?

  • לכן, אם אתם צריכים את המידע הכי מקיף, בדרך כלל זה המקום שבו תמצאו אותו.

  • במקביל, בצד של הקוד הפתוח, הם בדרך כלל דור אחד מאחור.

  • לכן, יכול להיות שיהיה כאן שיקול של עלות מול תועלת.

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

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

  • יכולות להיות לכך הרבה סיבות.

  • יכול להיות שיותר אנשים משתמשים במודל, או שהחומרה הוחלפה בדגם חדש יותר.

  • אבל זה משהו ששמנו לב אליו.

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

  • השלב הבא הוא קוצים.

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

  • השלב הבא הוא משך החיים של המודל עצמו.

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

  • זה אומר שאם אתם מפתחים משהו במשך שנה, ואתם מצפים שהוא יהיה בייצור במשך 3 שנים, יכול להיות שתעברו יותר מ-3 שינויים במודל.

  • וגם אם מודל מסוים נחשב לטוב יותר, זה לא אומר שהוא יתאים לכם יותר.

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

  • הגורם האחרון הוא העלות.

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

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

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

  • אנחנו משתמשים ב-Gemma 4 31B, וזה היה פתרון מצוין בשבילנו כי זה השילוב הכי טוב של מהירות, אינטליגנציה ועלות.

  • הוא גם אפשר לנו להתקדם מהר מאוד.

  • הרבה יותר קל לפתח איתו מאשר עם דברים אחרים שהשתמשנו בהם בעבר.

  • זה לא אומר שאנחנו משתמשים רק בזה.

  • אנחנו משתמשים בהרבה שילובים של מודלים פתוחים וסגורים שונים.

  • לדוגמה, דברים כמו תהליך יצירת זיכרון, בטיחות והתאמה אישית.

  • חשוב לבחור את המודל שהכי מתאים לצרכים הספציפיים שלכם במשימה.

  • אבל Gemma 4 31B הוא המודל העיקרי שלנו לסוכנים קוליים.

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

  • כך לא תהיה השפעה על לוח הזמנים שלכם כתוצאה מהוצאה משימוש של מודל.

איזון בין זמן אחזור, אינטליגנציה ועלות

  • Devin Reimer

    אז לסיכום, צריך לאזן בין שלושת הדברים האלה, נכון?

  • אנחנו מנסים לאזן בין זמן האחזור, היבט הסטרימינג, ההיבט המקביל, המהירות והעקביות.

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

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

  • אל תפתחו את האפליקציה ורק אז תחשבו על ההיבט הכלכלי.

  • כדאי לחשוב על זה כבר מההתחלה.

  • אז זה עדיין בשלב מוקדם מאוד, אבל המודל הכלכלי כאן מתחיל לעבוד.

  • ולכן, מודלים זולים יותר בהחלט יהיו טובים יותר, מודלים חכמים יותר בהחלט יהיו טובים יותר.

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

  • לכן, אני מאוד מתרגש להביא את היכולות של הסוכנים הקוליים האלה לכולם.

  • תודה.