ایجاد تعادل بین تأخیر بسیار کم و اقتصاد ابری در عامل‌های صوتی مجازی

Devin Reimer

به «ایجاد توازن بین تأخیر بسیار کم و اقتصاد ابری در عوامل صوتی مجازی» خوش آمدید.

من دِوین رایمر هستم.

من بنیان‌گذار و مدیرعامل AstroBeam هستم.

پیش‌از این، مدیرعامل و هم‌بنیان‌گذار Owlchemy Labs بودم که احتمالاً بیشتر به‌خاطر Job Simulator شناخته می‌شود.

بنابراین، ما در AstroBeam بر ساخت هوش مصنوعی هم‌زمان در بازی‌ها تمرکز کرده‌ایم.

به‌طور خاص، ما واقعاً روی صدا به‌عنوان ورودی تمرکز کرده‌ایم.

تاکنون دو عنوان منتشر کرده‌ایم، Stellar Cafe که برای واقعیت مجازی و رایانه است.

این بازی‌ای است که در آن با ربات‌ها در کافه ایستگاه فضایی صحبت می‌کنید و به حل مشکلات آن‌ها کمک می‌کنید.

این ویژگی کاملاً با صدا کنترل می‌شود.

همه چیز را، ازجمله منوها و پیمایش، فقط با صدایتان پخش می‌کنید.

بازی بعدی ما که امروز آن را اعلام کردیم، Robo Detective، برای Android XR و به‌طور خاص برای Project Aura از XREAL ساخته شده است.

در این بازی، شما نقش کارآگاهی را بازی می‌کنید که با یک شریک ربات کار می‌کند تا به مصاحبه با ربات‌ها برای حل جرایم رباتیک کمک کند، و باز هم، ۱۰۰٪ با صدا هدایت می‌شود.

بنابراین، صداپیشگان واقعاً کار سختی دارند و در بازی‌ها، کارشان حتی سخت‌تر است.

دلیلش این است که بازی‌ها چیزهای بسیار کم‌هزینه‌ای هستند و عامل صوتی اکنون هزینه جدیدی است که باید به آن خط لوله اضافه شود.

به‌علاوه، ما با دیگر صداپیشگان رقابت نمی‌کنیم، ما با کیفیت هر بازی‌ای که تاکنون ساخته شده است رقابت می‌کنیم، درست است؟

بنابراین، باید با کیفیت بسیار بالایی وارد شویم.

این بدان معنا نیست که موارد استفاده خاصی از عامل صوتی وجود ندارد که در آن چالش‌های منحصربه‌فردی وجود داشته باشد، یا جایی که ریسک بسیار بالاتر باشد، اما بازی‌ها قطعاً از نظر فنی در این فضا بسیار چالش‌برانگیز هستند.

اما، همچنین چون این‌ها بازی هستند، فضای زیادی برای آزمایش نحوه حل برخی‌از این مشکلات سخت باقی می‌ماند.

بنابراین، معتقدم اگر عامل‌های صوتی بتوانند در بازی‌ها کار کنند، تقریباً در هر جایی می‌توانند کار کنند.

بنابراین، برنامه‌هایی که در این گفتگو درباره آن‌ها صحبت می‌کنم، نه تنها برای بازی‌ها، بلکه برای هر برنامه صوتی که بخواهید بسازید، قابل استفاده هستند.

بنابراین، وقتی به عوامل صوتی فکر می‌کنید، فکر می‌کنم سه چالش اصلی وجود دارد.

بنابراین، تأخیر، هوش، و هزینه را داریم.

بنابراین، چیزی که می‌خواهم روشن کنم این است که وقتی درباره عامل‌های صوتی صحبت می‌کنم، منظورم عامل‌های صوتی به‌عنوان یک مکالمه است، نه به‌عنوان یک پیام‌واره.

منظورم یک پوشش میکروفون نیست که چیزی را به مدل زبانی بزرگ ارسال می‌کند و سپس منتظر پاسخ می‌ماند.

منظورم یک گفتگوی رفت‌وبرگشتی هم‌زمان در دنیای واقعی است، و این درواقع همان چیزی است که ساختنش بسیار دشوار می‌شود.

بنابراین، بیایید با تأخیر شروع کنیم.

چقدر باید سریع باشد؟

معلوم می‌شود که باید سریع باشد، خیلی سریع، اما بسته به آنچه خوانده‌اید، ممکن است آن‌قدر که فکر می‌کنید سریع نباشد، یا ممکن است خیلی سریع‌تر از آنچه فکر می‌کنید باشد.

بنابراین، بیایید درباره برخی‌از اعدادی که در بسیاری از آزمایش‌هایمان کشف کرده‌ایم صحبت کنیم.

بنابراین، وقتی درباره تأخیر سرتاسر صحبت می‌کنم، منظورم زمان بین آخرین گفته کاربر، یعنی آخرین صدایی که کاربر تولید کرده، تا زمانی است که صدای برگشتی را می‌شنود.

چیزی که در آزمایش‌هایمان متوجه شدیم این است که وقتی بازخورد آزمایش بازی را از کاربران دریافت می‌کنیم، حدود ۱٫۵ ثانیه نقطه‌ای است که دیگر به سرعت یا کندی یا چیزهایی از این قبیل اشاره نمی‌کنند.

به‌نظر می‌رسد این نقطه‌ای است که افراد واقعاً با آن احساس راحتی می‌کنند.

به‌محض اینکه سرعت ما از این مقدار کمتر می‌شود، افراد معمولاً این موضوع را مطرح می‌کنند که «این عالی است، اما...» و بنابراین به‌نظر می‌رسد این سرعت نقطه مطلوب باشد.

سپس وقتی سرعت را بیشتر می‌کنید، متوجه شدیم که در حدود ۱٫۲ ثانیه، اتفاقات فوق‌العاده طبیعی‌تری مثل مکالمه رفت‌وبرگشتی شروع می‌شود.

مثلاً من چیزی می‌گویم و در این مورد ربات خیلی سریع چیزی می‌گوید و شما به‌نوعی با هم گفتگو می‌کنید.

به‌نظر می‌رسد که یک نقطه مطلوب در آنجا وجود دارد که قفل آن باز شده است.

بااین‌حال، ۱٫۲ ثانیه واقعاً زمان کمی برای انجام این کار در پشته است.

و سپس، یافته جالب دیگر این است که ما آزمایش‌های زیادی انجام دادیم و درنهایت به سناریوهایی رسیدیم که به زیر یک ثانیه برسیم.

و بنابراین، ممکن است بگویید: «اوه، این عالی خواهد بود!»

و گاهی اوقات اینطور بود، و گاهی اوقات احساس وحشتناکی بود، بسیار عجیب و غریب.

بنابراین، ممکن است بشنوید که مردم می‌گویند زمان پاسخ ۸۰۰ میلی‌ثانیه عدد مناسبی است، یا ۵۰۰.

من حتی چند مقاله درباره ۳۰۰ خواندم چون واقعاً درک انسان به آنجا می‌رسد.

واقعیت این است که این موضوع بسیار به بافتار بستگی دارد.

بنابراین، برای مثال، اگر از شما بپرسم نامتان چیست، انتظار دارم که در مدت زمان مشخصی پاسخ دهید.

اگر از شما بپرسم معنای زندگی چیست، انتظار دارم زمان پاسخ‌گویی بسیار متفاوتی داشته باشید.

وقتی واقعاً آزمایش کردیم و از افراد خواستیم رتبه‌بندی کنند که آیا این پاسخ سریع یا کند است، وقتی واقعاً به اعداد نگاه کردید، درواقع همه جا بود.

پاسخ‌هایی که زمان زیادی بردند، مردم گفتند سریع بودند و برعکس، چون معلوم شد که این موضوع بسیار وابسته به زمینه است.

و همچنین اینکه در کجای مکالمه بوده‌اند.

به‌طور کلی، افراد انتظار دارند که اولین پاسخ سریع‌تر از پاسخ‌های بعدی باشد زیرا زمان فکر کردن وجود دارد.

اما گاهی اوقات درنهایت مکالمه‌ای بسیار کوتاه خواهید داشت، بنابراین انتظارتان بالا می‌رود.

بنابراین، این یک علم کامل نیست که در آن یک عدد کامل وجود داشته باشد، اما ما حدود ۱.۵ را کشف کردیم، اگر در آن نقطه باشید، شما شما شما دارید خیلی خوب می‌شوید.

بنابراین، وقتی به این یک و نیم ثانیه می‌رسید، حالا واقعاً به ثبات اهمیت می‌دهید، درست است؟

چون اگر درنهایت این اتفاق در ۹۰٪ مواقع رخ دهد، اما در ۱۰٪ مواقع ۳ ثانیه طول بکشد، تجربه شما خراب به‌نظر می‌رسد، نه بد، بلکه خراب.

و بنابراین، ما در نهایت وقتی به اندازه کافی سریع می‌شوید، فقط به ثبات اهمیت می‌دهید، بنابراین همیشه سریع هستید، نه بیشتر اوقات.

Devin Reimer

بنابراین، این یک معماری خط لوله صوتی استاندارد است.

بنابراین، ما «گفتار به نوشتار» خود را می‌گیریم، آن را به یک «مدل زبانی بزرگ» ارسال می‌کنیم، و سپس نتیجه را از «مدل زبانی بزرگ» به «نوشتار به گفتار» برمی‌گردانیم.

منظورم این است که در «تبدیل گفتار به نوشتار»، صدا را به سرور ارسال می‌کنیم و سپس آن را به نوشتار تبدیل می‌کنیم.

در بخش مدل زبانی بزرگ، ما آن نوشتار، آن گفتگوی پاسخ را می‌گیریم یا آن را به گفتگوی پاسخ تبدیل می‌کنیم، و سپس مشخص می‌کنیم که چه کنش‌هایی از آن شخصیت انجام خواهد شد.

ما این‌ها را به‌طور تنگاتنگی با هم جفت می‌کنیم چون واقعاً فکر می‌کنیم که این کار بسیار مهم است.

و سپس در بخش «نوشتار به گفتار»، آن نوشتار را می‌گیریم، به «نوشتار به گفتار» خودمان ارسال می‌کنیم، و آن را برای کاربر جاری‌سازی می‌کنیم، همچنین با کنش‌هایی که نماینده می‌خواهد انجام دهد زمان‌بندی می‌کنیم.

یکی از مشکلات این است که اجرای متوالی این کار می‌تواند بسیار کند باشد زیرا درنهایت باید هریک از این موارد را مرحله‌به‌مرحله انجام دهید.

بنابراین، یک سؤال رایج که در نهایت از من پرسیده می‌شود این است که، خب، اگر این فرایند کند است و باید سه مرحله را انجام دهید، چرا به‌جای آن از یک مدل گفتار به گفتار استفاده نمی‌کنید؟

چون این‌طوری سریع‌تر است، درست است؟

و بله، مثلاً، بیشتر اوقات این کار سریع‌تر خواهد بود چون شما یک چیز را اجرا می‌کنید.

اما این کار با چند معاوضه بزرگ همراه است.

بنابراین، با اینکه سریع است، چند مشکل بزرگ برای ما دارد و بزرگ‌ترین آن هزینه است.

بنابراین، به‌طور کلی متوجه شدیم که اجرای مدل «گفتار به گفتار» حدود ۳ تا ۵ برابر گران‌تر از این رویکرد موازی است.

بنابراین، برای ما، اقتصاد به‌سادگی کار نمی‌کند.

ازنظر ایمنی، درواقع کمی پیچیده‌تر است زیرا تا زمانی که نماینده پاسخ را نگوید، اعتبارسنجی آن دشوارتر است.

اما درعین‌حال، اگر رویکرد خط لوله‌ای داشته باشید، می‌توانید پاسخ مدل زبانی بزرگ را بگیرید و درست همان‌جا، حتی قبل‌از اینکه به ارسال چیزها به کاربر نزدیک شوید، آن را اعتبارسنجی و بررسی ایمنی کنید.

در سبک‌بندی صدا، شما به‌نوعی به پیش‌تنظیمات موجود در آن مدل «گفتار به گفتار» محدود هستید.

نمی‌توانید بگویید: «اوه، می‌دانی چیست؟

برای این مورد، واقعاً می‌خواهم از این نوع صدا استفاده کنم.»

به‌نوعی با آن مورد خاص گیر کرده‌اید.

در رویکرد خط لوله‌ای، می‌توانید بگویید: «اوه، می‌خواهم آن را تغییر دهم.

من این مدل را انتخاب می‌کنم چون این مدل برای این مورد استفاده خاص واقعاً خوب کار می‌کند.»

و همین موضوع برای هوش هم صادق است، درست است؟

اگر مدل «گفتار به گفتار» واقعاً خوبی داشته باشید که صدای خوبی تولید می‌کند، اما هوش آن کاملاً آن چیزی نباشد که می‌خواهید، نمی‌توانید به‌راحتی آن را عوض کنید، درست است؟

به‌نوعی در آن گیر افتاده‌اید.

در رویکرد خط لوله‌ای، شما می‌گویید: «اوه، برای این مورد استفاده، می‌خواهم از یک مدل خاص استفاده کنم.»

یکی از حوزه‌هایی که «گفتار به گفتار» قطعاً در آن برنده است، درک لحن کاربر است.

بنابراین، چیزهایی مثل کنایه و چیزهایی از این قبیل.

درحال‌حاضر، ترانویسی‌های گفتار به نوشتار معمولاً اطلاعات زیادی ندارند، اما فکر می‌کنم این موضوع با گذشت زمان تغییر خواهد کرد.

این قطعاً یکی از مزایای «گفتار به گفتار» است.

بنابراین، «گفتار به گفتار» قطعاً ازنظر سرعت مزیت دارد، اما ازنظر پیکربندی چالش‌هایی دارد و هزینه بالا، به‌ویژه برای ما، مانع بزرگی بود.

پس راه دیگری وجود دارد؟

بله.

کاری که باید انجام دهیم این است که تمام تلاش خود را برای موازی‌سازی خط لوله انجام دهیم.

بنابراین، برخی‌از کارهایی که انجام می‌دهیم این است که درنهایت مدل زبانی بزرگ را قبل‌از اینکه گفتار به نوشتار اطمینان کامل داشته باشد اجرا می‌کنیم.

و منظورم از اطمینان، اطمینان به کلماتی است که در ترانویسی تولید می‌شوند و سپس اطمینان به پایان نوبت.

بنابراین، به‌محض اینکه فکر کنیم احتمال دارد این همان لحظه‌ای باشد که کاربر صحبت کردن را متوقف کرده است و این همان چیزی است که گفته است، پیش‌دستی می‌کنیم.

و بنابراین، بدترین سناریو برای آن این است که ما اشتباه می‌کنیم، درست است؟

کاربر به صحبت کردن ادامه می‌دهد.

اما حتی در آن سناریو، تنها کاری که می‌کنیم این است که LLM را لغو می‌کنیم و سپس آن را دوباره اجرا می‌کنیم.

و چون بافت احتمالاً ذخیره موقت خواهد شد و ما آن تعداد زیاد از تراشه‌ها را تولید نکرده‌ایم، درواقع هزینه زیادی برای انجام این کار ندارد، و مزیت آن این است که کاربر درنهایت چیزها را سریع‌تر از زمانی می‌شنود که شما منتظر اطمینان کامل بودید.

همچنین منتظر نمی‌مانیم تا مدل زبانی بزرگ تولید کل پاسخ خود را به‌پایان برساند و سپس آن را به «نوشتار به گفتار» ارسال کنیم.

چیزی که منتظرش هستیم نوعی اولین بخش قابل‌بیان است.

در اکثر سناریوها، این متن یک جمله است.

گاهی اوقات ممکن است پیکربندی‌های دیگری باشد، اما به‌محض اینکه اولین بخش جمله را دریافت کنیم، آن را به «نوشتار به گفتار» ارسال می‌کنیم.

و سپس، اگر «نوشتار به گفتار» خوبی داشته باشیم که جاری‌سازی کند، به‌محض اینکه برای جاری‌سازی آماده شود، می‌تواند به کاربر ارائه شود.

همچنین درباره تعداد نشانه‌هایی که باید تولید شود بسیار دقت می‌کنیم.

بنابراین از چیزهایی مانند پوشاننده‌های JSON و موارد مشابه که ممکن است داده‌واحدهای اضافی اضافه کنند استفاده نمی‌کنیم.

ما سعی می‌کنیم بفهمیم ساده‌ترین ساختار برای دریافت سریع‌ترین پاسخ ممکن چیست.

همچنین اگر ازقبل بدانیم که اولین بخش از نشانه‌ها قرار است ازسوی نماینده چه باشد، از مواردی مثل پیش‌پر کردن دستیار استفاده می‌کنیم.

و بنابراین برای نوشتار به گفتار، درنهایت این دو بخش شد، درست است؟

بنابراین، ابتدا آن بخش قابل‌خواندن می‌آید و سپس بقیه موارد را اجرا می‌کنیم.

اما چون شنیدن پخش صدا بیشتر از تولید آن طول می‌کشد، تقریباً همیشه پخش آن بخش اول برای کاربر تا زمانی که بخش دوم آماده شود تمام خواهد شد.

بنابراین درواقع برای کاربر نامرئی است.

اینجا با حداکثر سرعت ممکن می‌آید.

بنابراین وقتی به انتخاب سرویس‌های مختلف فکر می‌کنید، در اینجا چند قانون سرانگشتی ما آورده شده است.

وقتی نوبت به انتخاب نوع مناسب چارچوب صوتی و عاملی می‌رسد، آنچه برای شما اهمیت دارد کمترین تأخیر در ورودی و خروجی است.

پس با چه سرعتی می‌توانم چیزها را ارسال و دریافت کنم؟

در بخش گفتار به نوشتار، زمان رسیدن به اطمینان برای ما مهم است.

بنابراین این اطمینان در ترانویسی و اطمینان در پایان نوبت است.

آن‌ها با هم جفت شده‌اند، درست است؟

اگر سریع به یکی اعتماد نکنید، به همان اندازه کند خواهد بود، درست است؟

بنابراین سرعت آن فقط به‌اندازه کندترین دستگاه در آن گروه است.

در بخش LLM، زمان رسیدن به اولین جمله، یعنی اولین بخش قابل‌بیان، برای ما مهم است.

و این دو بخش است، درست است؟

این معیار ترکیبی از زمان تا اولین داده‌واحد و داده‌واحد در ثانیه است.

بنابراین اگر ناگهان مدل بسیار خوبی پیدا کنید که زمان بسیار خوبی برای اولین کد به شما می‌دهد، اما ازنظر کد در ثانیه کند است، این می‌تواند بدتر از گزینه جایگزین باشد.

بنابراین ترکیب مناسب برای آن را پیدا کنید.

و سپس در بخش نوشتار به گفتار، زمان اولین صدا برایتان مهم است.

And so it's really important to measure what it is, because sometimes audio can come back with leading silence and the user isn't going to hear that.

بنابراین باید تا نقطه‌ای که کاربر چیزها را می‌شنود اندازه‌گیری کنید.

و سپس، همان‌طور که قبلاً اشاره کردم، بیش از هر چیز به پایداری اهمیت می‌دهید، نه سرعت‌های اوج، نه بهترین سناریو.

تأخیر ثابت کل این پشته چقدر است؟

Devin Reimer

بنابراین، درحال‌حاضر برای چارچوب‌های عامل صوتی خود، از LiveKit استفاده می‌کنیم.

برای گفتار به نوشتار، از Deepgram استفاده می‌کنیم.

برای مدل‌های زبانی بزرگ، از Gemma 4 31B استفاده می‌کنیم و آن را در LiveKit میزبانی می‌کنیم.

در بخش نوشتار به گفتار، از Inworld AI text-to-speech 2 استفاده می‌کنیم.

و علاوه‌براین، ما کل زیرساخت عامل هوش مصنوعی AstroBeam را ساخته‌ایم که نه‌تنها همه این‌ها را به هم متصل می‌کند، بلکه تمام قطعاتی را که برای داشتن یک عامل صوتی واقعاً خوب نیاز دارید، به‌ویژه عاملی که مانند عامل ما برای بازی‌ها بسیار تعاملی است، اضافه می‌کند.

بنابراین، چیزی که درباره آن صحبت نکرده‌ام این است که مدل‌های ایمنی چه می‌شوند؟

بنابراین، به‌طور سنتی، مدل‌های ایمنی بخشی از گذر LLM هستند، اما این امر تأخیر را افزایش می‌دهد و یک مرحله اضافی به آن اضافه می‌کند.

پس، اگر به‌جای آن، خودتان آن را اجرا کنید چه؟

بنابراین، این درواقع بیشتر شبیه پشته ما است.

و بنابراین کاری که ما در اینجا انجام می‌دهیم این است که وقتی اولین بخش نوشتار را دریافت می‌کنیم، اولین بخش قابل‌گفتار که قرار است به نوشتار به گفتار ارسال کنیم، دقیقاً در همان زمان آن را به مدل ایمنی خود ارسال می‌کنیم.

و چون مدل ایمنی کوچک‌تر است و سریع‌تر از بخش گفتار به نوشتار اجرا می‌شود، تقریباً همیشه زودتر انجام می‌شود.

و بنابراین، معنای نهایی این است که افزودن مدل ایمنی هیچ تأخیری به پشته ما اضافه نمی‌کند، و حتی بهتر از آن، این بخش به‌اندازه کافی بزرگ است که درواقع می‌توانیم مدل ایمنی بسیار بزرگ‌تری را نسبت‌به آنچه اکثر مردم حتی فکر می‌کنند اجرا کنیم.

و این برای ما بسیار مهم است، به‌ویژه به این دلیل که ما درحال ساخت بازی هستیم.

بافتار آن دنیا بسیار مهم است.

بنابراین، برای مثال، فرض کنید درحال ساختن یک بازی قرون وسطایی هستید و یک NPC در این بازی قرون وسطایی دارید که فریاد می‌زند: «حمله!

سرشان را بزنید!»، درست است؟

یک مدل ایمنی سنتی ممکن است این‌طور باشد: «اوه، این خوب نیست.

نباید این را بگویی.»

اما در بافت این بازی، این موضوع کاملاً منطقی است.

و روشی که می‌توانیم این کار را انجام دهیم این است که از مدل ایمنی کمی قوی‌تر با بافت بسیار بیشتری از آنچه در جهان اتفاق می‌افتد استفاده می‌کنیم تا بتوانیم این کار را انجام دهیم.

ممکن است در اینجا متوجه شوید که ما درواقع مدل ایمنی را دو بار اجرا می‌کنیم، بنابراین درنهایت آن را روی بخش اول اجرا می‌کنیم و سپس وقتی بخش نهایی را به‌طور کامل دراختیار داریم، دوباره آن را روی کل محتوا اجرا می‌کنیم.

یک‌بار دیگر، باید آن را دو بار اجرا کنیم، اما این کار هیچ تأخیری به پشته اضافه نمی‌کند.

بنابراین، اکنون ما به اندازه کافی سریع هستیم، اما متأسفانه اگر به اندازه کافی هوشمند نباشیم، این موضوع اهمیتی ندارد.

Devin Reimer

بنابراین، چقدر باید هوشمند باشد؟

این مدل باید به‌اندازه کافی برای کاربران شما هوشمند باشد، اما مهم‌تر از آن، باید به‌اندازه کافی برای توسعه‌دهندگان هوشمند باشد.

و این اغلب چیزی است که مردم وقتی می‌خواهند آنچه را که برای هوش مصنوعی نیاز دارند انتخاب کنند، به آن فکر نمی‌کنند.

حدود سه سال است که روی عوامل صوتی کار می‌کنیم و مثلاً در روزهای اول از برخی مدل‌های اولیه LLaMA استفاده می‌کردیم و هرچند توانستیم آن‌ها را برای کاربران تاحدودی قابل‌استفاده کنیم، اما بخش توسعه بسیار پرهزینه بود چون همه‌چیز بسیار شکننده بود.

مدل‌ها به‌راحتی می‌توانستند پاسخ‌های نامطلوب یا چیزهایی تولید کنند که اصلاً منطقی نبودند، بنابراین تلاش مهندسی زیادی برای درست کردن این کار انجام دادیم.

و این چیزی است که ما آن را در اولویت قرار می‌دهیم، زیرا اگر نتوانیم در ساختن این چیزها سریع حرکت کنیم، نمی‌توانیم چیزها را به کاربران برسانیم.

بنابراین، خیلی مهم است که به هر دو فکر کنید.

بنابراین، اغلب وقتی مردم به هوش فکر می‌کنند، به مدل زبانی بزرگ فکر می‌کنند، درست است؟

اما این فقط بخشی از آن است.

وقتی صحبت از هوش مصنوعی می‌شود، باید به همه بخش‌ها فکر کنیم.

پس بیایید درباره هوش گفتار به نوشتار صحبت کنیم.

بنابراین آنچه در اینجا برای ما مهم است، نرخ پایین خطای کلمه است.

علاوه‌براین، فقط این نیست که نرخ خطا پایین است، بلکه وقتی خطا رخ می‌دهد، چیزی تولید می‌کنیم که بسیار نزدیک به واقعیت است، زیرا اگر واقعاً نزدیک باشد، مدل زبانی بزرگ اغلب می‌تواند بااستفاده از بافتار، به‌خوبی آن را درک کند.

اگر نرخ خطای شما پایین باشد اما اشتباهات بسیار زیاد باشد، مدل زبانی بزرگ برای فهمیدن قصد واقعی شما بسیار بیشتر دچار مشکل خواهد شد.

مورد دیگری که باید به آن فکر کنید پلاتفرم هدف شما است.

بنابراین، برای مثال، اگر من برای XR می‌سازم و میکروفون‌هایی دارم که واقعاً به دهان کاربر نزدیک هستند، داده‌های صوتی میکروفون با کیفیت بسیار خوب و بالایی خواهم داشت و این ممکن است برای مدل‌های خاصی بسیار خوب کار کند.

اما اگر ناگهان برنامه‌ای برای تلفن همراه بسازم که مردم قرار است در خیابانی شلوغ از آن استفاده کنند، این تأثیر بسیار متفاوتی دارد و مدل‌های مختلف رفتار متفاوتی خواهند داشت و می‌توانند به‌طور هوشمندانه آنچه را که به روش‌های مختلف گفته می‌شود درک کنند.

بنابراین باید به این موضوع فکر کنید و مطمئن شوید که پلاتفرم مناسبی را برای ساختن انتخاب می‌کنید.

بنابراین، سپس به سمت نوشتار به گفتار معادله هوش می‌رویم.

آیا طبیعی به‌نظر می‌رسد؟

هدف ما این است که به کاربر اطلاع دهیم که آیا کاربر می‌تواند آن را درک کند؟

اما این فقط بخشی از آن است، درست است؟

بیانگری آن عامل نیز بسیار بسیار مهم است زیرا در بیانگری اطلاعات وجود دارد، و همچنین در آزمایش‌های بازی‌مان متوجه شده‌ایم که هرچه عامل‌های ما بیانگرتر باشند، کاربران احساس می‌کنند که آن‌ها باهوش‌تر هستند، که این کاملاً منطقی است.

و سپس، آیا به‌اندازه کافی سریع است؟

و می‌دانم که در بخش قبلی درباره تأخیر صحبت می‌کردم، اما درواقع در اینجا هم برای هوش درک‌شده اهمیت دارد.

کاربران سرعت پاسخ را مستقیماً با میزان هوشمندی آن مرتبط می‌دانند.

اگر پاسخ سریعی داشته باشم، احتمالاً هوشمندانه‌تر به‌نظر می‌رسد.

بنابراین، این موارد واقعاً می‌توانند در نحوه درک کاربر از تجربه و همچنین میزان غوطه‌ور شدن او در تجربه تأثیرگذار باشند.

بنابراین، به بخش مدل زبانی بزرگ (LLM) هوش مصنوعی می‌رسیم.

این، تا حد زیادی، سخت‌ترین چیز برای متعادل کردن است چون الزامات مختلف زیادی در اینجا وجود دارد، درست است؟

بنابراین ما نوعی درک گفتار، بافت، و زمینه‌سازی داریم.

در بازی‌ها، این کار بسیار دشوار است، زیرا باید بر کل جهان و کیهان تکیه کنید، درست است؟

این یک چارگوش نوشتاری نیست که بتواند چیزهایی را که درحال رخ دادن است بسازد.

اگر نماینده شما در بازی بگوید «یک سیب روی میز است» و سیبی روی میز نباشد، این امر تجربه کاربر را خراب می‌کند.

همچنین به چیزهایی مثل پیروی قوی از قوانین نیاز داریم.

بازی‌ها بسیار قانون‌محور هستند.

آیا مدل زبانی بزرگ می‌تواند این کار را انجام دهد؟

آیا می‌توانیم نرخ کژپنداری پایینی داشته باشیم؟

آیا می‌توانیم وقتی بارها و بارها با همان نماینده تعامل برقرار می‌کنید، شخصیت‌های ثابتی داشته باشیم؟

آیا احساس می‌کنید با همان نماینده صحبت می‌کنید؟

و سپس، موردی که ممکن است شما را به اشتباه بیندازد، چون در شروع توسعه مشکلی نیست، این است که آیا مدل شما می‌تواند با افزایش اندازه پیام‌واره کنار بیاید؟

چون به‌طور اجتناب‌ناپذیری، با ادامه توسعه، چیزهای بیشتری را در پیام‌واره قرار خواهید داد.

اما بعد، همچنین، وقتی کاربران به بازی ادامه می‌دهند، سابقه گپ بیشتری در آن پیام‌واره وجود خواهد داشت.

بنابراین، آیا آن پیام‌واره می‌تواند این رشد را مدیریت کند؟

چون گاهی اوقات اتفاقی که می‌افتد این است که برای برخی مدل‌ها، با رشد پیام‌واره شما، کیفیت پاسخ کاهش می‌یابد، بنابراین باید به‌نوعی بفهمید که نیازهای واقعی شما برای مقداری که باید هربار در آن پیام‌واره وارد شود چیست.

اما این فقط نوک کوه یخ است و واقعاً به آنچه می‌سازید بستگی دارد.

بنابراین باید واقعاً درباره آنچه می‌سازید و آنچه می‌خواهید به‌دست آورید فکر کنید.

بنابراین اکنون ما به‌اندازه کافی سریع و هوشمند هستیم، اما اگر هزینه آن خیلی زیاد باشد، هیچ‌کدام از این‌ها اهمیتی ندارد.

Devin Reimer

پس چقدر باید ارزان باشد؟

متأسفانه، کمی پیچیده‌تر از این است.

بنابراین باید به اقتصاد برنامه یا بازی‌ای که می‌سازیم فکر کنیم، درست است؟

بنابراین، چند سؤال هست که باید بپرسید.

کاربر چه مدت با نماینده‌های صوتی شما تعامل خواهد داشت؟

به‌ازای هر کاربر چقدر درآمد دارید؟

و هزینه اجرای آن پشته صوتی در هر ساعت چقدر است؟

آن‌ها را کنار هم می‌گذاریم تا ببینیم منطقی هستند یا نه.

بنابراین، این اقتصاد اولین بازی ما، Stellar Cafe است.

بنابراین زمان بازی در Stellar Cafe چیزی بین ۱ و نیم تا ۳ و نیم ساعت است، پس بیایید میانگین آن را حدود ۲ ساعت درنظر بگیریم.

هزینه ما برای اجرای عامل‌های صوتی حدود ۱٫۲ دلار در ساعت برای هر کاربر است و کاربران ۱۰۰٪ مواقع با آن تعامل دارند.

این بازی کاملاً صوتی است.

ما برای بازی هزینه ثابت ۱۰ دلاری دریافت می‌کنیم که سنتی است.

ما اشتراک ارائه نمی‌دهیم چون در بازی‌ها بسیار دشوار است و من قویاً معتقدم که باید آن را با هزینه ثابت ارائه دهیم، درغیراین‌صورت، این کار نتیجه نخواهد داد و مقیاس‌پذیر نخواهد بود.

قبلاً ۱۵ دلار دریافت می‌کردیم، اما تلاش کردیم این هزینه‌های سرور را کاهش دهیم، بنابراین اکنون آن را به ۱۰ دلار کاهش داده‌ایم.

و این ۱٫۲۰ دلار، این جایی است که ما هستیم.

این یک هزینه جهانی نیست.

دیده‌ام که این چیزها قیمت‌های بسیار متنوعی دارند و گاهی‌اوقات بسیار گران‌تر هستند.

و بنابراین، شما همچنین باید به نوعی بفهمید که در بخش هزینه چیزها کجا هستید.

می‌توانستیم ارزان‌تر عرضه کنیم، اما تلاش می‌کنیم سطح کیفیت را تا جایی که ممکن است بالا نگه داریم.

بنابراین، با درنظر گرفتن همه این موارد، این یعنی برای آن ۲ ساعت زمان بازی، هزینه پشته صوتی ما حدود ۲٫۴۰ دلار برای هر کاربر است.

و بنابراین، چون ما ۱۰ دلار دریافت می‌کنیم و فروشگاه کارمزد می‌گیرد، یعنی ما حدود ۴٫۵۹ دلار برای هر کاربر درآمد داریم، درست است؟

و بنابراین، اقتصاد آن کار می‌کند، درست است؟

صدا قلاب ما است، این همان چیزی است که می‌خواهیم برایش پول خرج کنیم، این کارساز است.

بنابراین، این بازی واقعاً کوچکی است.

بیایید درباره موضوعی کمی بزرگ‌تر صحبت کنیم.

بنابراین، بیایید درباره یک بازی فرضی، یک بازی روایی، صحبت کنیم که مدت آن چیزی بین ۵ تا ۹ ساعت است، پس بیایید میانگین ۷ ساعت را درنظر بگیریم.

در واقعیت، اکثر مردم-- خیلی از مردم بازی‌ها را تمام نمی‌کنند، کمی بازی می‌کنند و بعد آن را رها می‌کنند، اما من می‌خواهم چیزی کمی بالاتر را انتخاب کنم تا مطمئن شوم که اقتصاد همچنان کار می‌کند.

بنابراین، ما همان ۱٫۲ دلار در ساعت را حفظ می‌کنیم، اما تغییری که ایجاد می‌کنیم این است که مؤلفه صوتی آن ۶۰٪ از زمان استفاده خواهد شد، زیرا یک بازی بزرگ‌تر مکانیک‌های بسیار بیشتری نسبت‌به فقط صدا خواهد داشت.

بنابراین، این بازی همچنان بسیار مبتنی بر صدا خواهد بود، اما ویژگی‌های دیگری نیز در آن وجود خواهد داشت.

بنابراین، اگر ۲۰ دلار دریافت کنیم، با درنظر گرفتن دوباره همه این موارد، هزینه ما حدود ۵ دلار برای هر کاربر خواهد بود، یعنی در پایان روز، حدود ۹ دلار برای هر کاربر درآمد خواهیم داشت.

بنابراین، یک بار دیگر، با این، اقتصاد کار می‌کند.

این بدان معنا نیست که اقتصاد برای همه چیز کارساز خواهد بود.

بنابراین، برای مثال، کاری که نباید انجام دهید این است که بگویید: «اوه، من می‌خواهم یک بازی رایگان بسازم و احتمالاً کاربران این بازی را بین ۱ ساعت تا بیش‌از ۱۰۰ ساعت بازی خواهند کرد.»

بنابراین، بیایید میانگین آن را ۱۰ ساعت درنظر بگیریم.

این بازی کاملاً صوتی است، اما فرض کنید که بازی موفقی باشد و حدود ۳ دلار برای هر کاربر درآمد داشته باشد، که برای یک بازی رایگان بسیار عالی است.

به‌ازای هر کاربر ۱۰ دلار ازدست می‌دهید.

بنابراین، هنوز در همه این موارد کار نمی‌کند، و باید به نوعی به آنچه درحال‌حاضر می‌سازید فکر کنید، و آیا منطقی است؟

تا پایان ویدیو صبر نکنید تا بخواهید مسائل اقتصادی را توضیح دهید.

Devin Reimer

بنابراین، سؤال بعدی که مطرح می‌شود این است که مدل‌های محلی چطور؟

چون اگر این چالش بزرگ هزینه را دارید، آیا مدل‌های محلی آن را برطرف نمی‌کنند؟

و بله، همین‌طور است.

اما در اینجا برخی مبادلات وجود دارد که باید به نوعی درباره آن‌ها فکر کنیم.

بنابراین، از نظر هزینه، بله، ما صورت‌حساب سرور را حذف می‌کنیم، که مزیت بزرگی خواهد بود و فرصت‌های بسیار بیشتری را باز می‌کند.

اما درحال‌حاضر چیزهای زیادی وجود دارد که فضای ابری می‌تواند حل کند ولی پردازش محلی با آن‌ها مشکل دارد.

بنابراین، برای مثال، compute.

اغلب مردم می‌گویند: «ببینید، من این مدل گفتار به نوشتار واقعاً خوب را پیدا کردم و به‌صورت محلی در این دستگاه اجرا می‌شود، درست است؟»

عالی است، اما چیزی که باید به آن فکر کنیم این است که این سیستم یک مدل را اجرا نمی‌کند، بلکه چندین مدل را اجرا می‌کند، درست است؟

در مورد ما، چهار، احتمالاً هم‌زمان، و بنابراین، کافی نیست که چیزی یک بار اجرا شود، باید چندین بار هم‌زمان اجرا شود.

و سپس، اگر این کار را انجام دهید، آیا چیزی برای اجرای بازی یا برنامه‌تان باقی گذاشته‌اید؟

اگر از حداکثر توان واحد پردازش گرافیکی استفاده کرده باشید، واقعاً نمی‌توانید بازی ویدیویی را به‌خوبی پرداز کنید.

بنابراین، فرض کنید که رفته‌اید و بر آن چالش‌ها غلبه کرده‌اید.

پس، مورد بعدی سرعت است، درست است؟

اغلب می‌توانید آن‌ها را اجرا کنید، اما بسیار کند خواهند بود و بیشتر شبیه به پیام‌واره دادن خواهد بود تا مکالمه هم‌زمان واقعی.

بنابراین، از نظر تئوری، دریافت محلی آن در آینده مزیت دارد، زیرا مجبور نیستید آن رفت‌وبرگشت را از اینترنت انجام دهید.

درحال‌حاضر، دریافت مدل‌هایی که با سرعت مناسب اجرا شوند تا این کار انجام شود، یک چالش است.

بنابراین، فرض کنیم که شما به نوعی بر محاسبات و سرعت غلبه کرده‌اید، حالا باید به کیفیت فکر کنیم، درست است؟

بنابراین، به‌طور کلی چون آن را روی دستگاه محلی اجرا می‌کنید، از مدل زبانی بزرگ کوچک‌تری استفاده می‌کنید، مثلاً نوشتار به گفتار ابتدایی‌تر، این درواقع می‌تواند چالش‌هایی را دررابطه‌با محتوایی که می‌سازید ایجاد کند.

و همان‌طور که قبلاً اشاره کردم، وقتی به مدل زبانی بزرگ فکر می‌کنید، فقط این نیست که آیا برای کاربران شما به‌اندازه کافی خوب است، بلکه آیا برای توسعه دادن شما هم به‌اندازه کافی خوب است؟

And so, if that model becomes quite challenging to build something with, that's definitely something to think about.

بنابراین، فرض کنید که بر محاسبات، سرعت، و کیفیت غلبه کرده‌اید، مرحله بعدی قابلیت حمل است.

اگر برنده شوید و کل این فرایند را طی کنید و این چیز را مثلاً روی RTX 5070 اجرا کنید، ممکن است این تنها جایی باشد که می‌تواند اجرا شود.

بنابراین، اگر فرصتی برای آوردن آن به پلاتفرم جدیدی پیش بیاید، ممکن است گیر کنید.

در بخش ابری، تنها چیزی که نیاز دارید اینترنت است.

و بنابراین، این یک نوع باز کردن قفل بزرگ در اینجا است.

امکان رفتن به چندین پلاتفرم را فراهم می‌کند.

بنابراین، در ادامه، بیایید درباره رویکرد ترکیبی صحبت کنیم، درست است؟

بنابراین، بیایید برخی‌از چیزها را در فضای ابری و برخی‌از چیزها را به‌صورت محلی اجرا کنیم.

یک جورهایی، آیا این کار می‌کند؟

خب، این برد آن‌قدرها هم که فکر می‌کنید بزرگ نیست.

بنابراین، اگر مدلی داشته باشید که به‌اندازه کافی کوچک باشد تا روی اکثر پلتفرم‌های محلی اجرا شود، اگر همان مدل را در فضای ابری اجرا کنید، احتمالاً هزینه بسیار کمی برای شما خواهد داشت.

و بنابراین، معمولاً تا زمانی که کل پشته را حل نکرده باشید، بزرگترین بردهای خود را به‌دست نمی‌آورید.

سپس، موضوع بعدی که مطرح می‌شود این است که اگر به‌جای آن، آن را به‌صورت محلی اجرا کنید، چه می‌شود، اگر ممکن باشد، درست است؟

آن‌ها سخت‌افزار مناسب را دارند و اگر شما نداشته باشید، در فضای ابری است، درست است؟

می‌توانید چیز قدرتمندتری را در فضای ابری اجرا کنید.

این چالش‌های جدیدی دارد، درست است؟

اگر درنهایت مدل دیگری را اجرا کنید، این امر می‌تواند تأثیر زیادی بر توسعه داشته باشد.

و درنهایت مجبور می‌شوید زمان زیادی را صرف کار روی حداقل مشخصات کنید.

و شما می‌توانید مدل‌هایی داشته باشید که کاملاً متفاوت رفتار می‌کنند.

بنابراین، اگر از مدل‌های دقیقاً یکسان استفاده نکنید، ممکن است درنهایت زمان و هزینه توسعه زیادی را اضافه کنید.

بنابراین، مهم است که به نوعی به آنچه که می‌خواهید به آن دست یابید فکر کنید، زیرا فرض کنید شما این را متوجه شده‌اید و یک محلی خوب دریافت کرده‌اید اگر نیاز باشد، ابری اگر نباشد، هنوز هم اقتصاد باید برای مدل ابری کار کند.

چون اگر ناگهان همه کاربران شما در سمت ابری باشند، درست است، اگر از دیدگاه اقتصادی به آن فکر نکرده باشید، ضرر خواهید کرد.

بنابراین، وقتی صحبت از مدل‌های محلی می‌شود، قطعاً یک پیروزی بزرگ اقتصادی است، اما هنوز در مراحل اولیه است.

برای برنامه‌های حساس به قیمت مانند بازی‌ها، معتقدم که احتمالاً درنهایت برنده خواهد شد.

امروزه، خارج از موارد استفاده خاص‌تر، به‌ویژه موارد مربوط به چیزهای مبتنی بر فرمان، کمی دشوار است.

بنابراین درحال‌حاضر، امروز، ما بهترین تجربه ممکن را می‌خواهیم.

به‌همین دلیل است که از فضای ابری استفاده می‌کنیم.

اما این فضا بسیار سریع درحال حرکت است و چیزها خیلی سریع تغییر می‌کنند.

بنابراین، بخش بعدی این است که بیایید درباره مدل‌هایی که استفاده می‌کنیم فکر کنیم، درست است؟

بنابراین، سؤال بعدی درباره وزن‌های باز در مقابل وزن‌های بسته است.

اینجا باید چه کار کنیم؟

وقتی درباره این موضوع صحبت می‌کنیم، می‌خواهم روی مدل‌های زبانی بزرگ تمرکز کنم چون متوجه شدیم این حوزه‌ای است که بیشترین تأثیر را از مسئله باز در مقابل بسته می‌گیرد.

بنابراین، قطعاً مزایا و معایبی در اینجا وجود دارد.

بنابراین، وقتی صحبت از مدل‌های بسته و وزنی می‌شود، این‌ها عموماً هوش پیشرو شما هستند، درست است؟

بنابراین، اگر به بیشترین هوش نیاز دارید، اغلب باید به اینجا بروید.

درهمین‌حال، در بخش باز، آن‌ها اغلب یک نسل عقب‌تر هستند.

بنابراین، این می‌تواند یک معاوضه واقعی باشد.

درمورد سرعت، اشاره کردم که زمان رسیدن به اولین جمله برایم خیلی مهم است.

چیزی که ما متوجه شدیم این است که در طول عمر مدل‌های بسته، سرعت اغلب کاهش می‌یابد.

و دلایل زیادی برای این امر وجود دارد.

شاید افراد بیشتری از مدل استفاده می‌کنند، شاید سخت‌افزار به مدل جدیدتری تغییر کرده است.

اما این یکی از چیزهایی است که متوجه شده‌ایم.

بنابراین باید مراقب باشید چون می‌تواند مشکلی ایجاد کند که اگر چیزی را عرضه کنید و عالی باشد، ممکن است با گذشت زمان غیرقابل‌استفاده شود.

مورد بعدی میخ‌ها است.

شما به این نوع ثبات اهمیت زیادی می‌دهید، و بنابراین، اغلب، مدل‌های بسته حول نوعی دسته‌بندی در وظایف ناهمگام ساخته می‌شوند، نه نوعی تأخیر P99، درحالی‌که در سمت باز، می‌توانید ارائه‌دهنده‌ای را انتخاب کنید که به همان چیز خاصی که برای شما مهم است اهمیت می‌دهد، تا به شما نوعی اطمینان، سرعت، و تأخیری را بدهد که درنهایت به آن نیاز دارید.

مورد بعدی طول عمر خود مدل است.

بنابراین، مدل‌های بسته اغلب پس‌از حدود یک سال منسوخ می‌شوند.

بنابراین، این برای شما به این معنی است که اگر درنهایت چیزی را برای یک سال توسعه دهید و انتظار داشته باشید که برای ۳ سال در تولید باشد، ممکن است بیش‌از ۳ تغییر مدل را تجربه کنید.

و صرفاً به این دلیل که مدلی بهتر است، به این معنی نیست که برای شما بهتر کار خواهد کرد.

ما در ۳ سال گذشته تغییرات زیادی در مدل‌ها داشته‌ایم و اغلب هفته‌ها، گاهی ماه‌ها کار لازم است تا همه چیز را بازسازی کنیم، که در بخش متن‌باز، می‌توانید تا زمانی که کسی مایل به میزبانی آن باشد یا خودتان مایل به میزبانی آن باشید، به اجرای آن مدل ادامه دهید.

درنهایت، هزینه است.

اغلب، با گذشت زمان، این مدل‌های بسته، با انتشار نسخه‌های جدید، گران‌تر از نسخه قبلی می‌شوند.

بنابراین، این چیز دیگری است که باید درمورد اقتصاد مراقب آن بود، یعنی، یک بار دیگر، اقتصاد شما می‌توانست در زمان راه‌اندازی کار کند و سپس با مهاجرت مدل‌ها کار نکند.

در بخش باز، شما انعطاف‌پذیری لازم برای جابه‌جایی آن را دارید و احتمالاً هزینه آن به‌طور چشمگیری افزایش نخواهد یافت زیرا دقیقاً همان مدل است.

بنابراین، ما از Gemma 4 31B استفاده می‌کنیم و این یک گشایش بزرگ برای ما بود، زیرا برای ما، این بهترین ترکیب از سرعت، هوش، و هزینه بود.

این کار به ما اجازه داد تا خیلی سریع پیش برویم.

توسعه دادن با آن نسبت به چیزهایی که قبلاً استفاده کرده‌ایم خیلی آسان‌تر است.

این بدان معنا نیست که ما فقط از این استفاده می‌کنیم.

ما از ترکیب‌های زیادی از مدل‌های باز و بسته مختلف استفاده می‌کنیم.

بنابراین، برای مثال، چیزهایی مثل تولید حافظه و ایمنی و سفارشی‌سازی.

بسیار مهم است که بهترین مدل را برای نیازهای خاص خود در آن تکلیف انتخاب کنید.

اما Gemma 4 31B درزمینه عامل‌های صوتی، اسب کاری ما است.

بنابراین، وقتی صحبت از این نوع تفاوت‌ها بین این دو می‌شود، مدل‌های باز قطعاً کنترل بیشتری به شما می‌دهند و به شما اجازه می‌دهند تا زمانی که مدل‌ها می‌توانند با هزینه قابل‌پیش‌بینی‌تری میزبانی شوند، آن‌ها را نگه دارید.

و با منسوخ شدن مدل، تأثیری بر زمان‌بندی شما نخواهد داشت.

Devin Reimer

پس، برای جمع‌بندی، موضوع ایجاد تعادل بین این سه چیز است، درست است؟

تأخیر شما، ما در تلاشیم تا جنبه جاری‌سازی، جنبه موازی، سرعت، و ثبات آن را متعادل کنیم.

ازنظر هوش، به‌اندازه کافی برای کاربران هوشمند است، به‌اندازه کافی برای ساختن با آن هوشمند است.

درباره هزینه، باید بدانیم که هزینه به‌ازای هر کاربر چقدر خواهد بود و چقدر می‌توانیم به‌ازای هر کاربر درآمد داشته باشیم تا بتوانیم مطمئن شویم که ازنظر اقتصادی به‌صرفه است.

اول نسازید و بعداً به فکر اقتصاد آن باشید.

از همان ابتدا به این موضوع فکر کنید.

بنابراین، هنوز خیلی زود است، اما اقتصاد در اینجا شروع به کار کرده است.

بنابراین، مدل‌های ارزان‌تر قطعاً بهتر خواهند بود، مدل‌های هوشمندتر قطعاً بهتر خواهند بود.

اما همین حالا، امروز، می‌توانیم کار روی چالش‌های واقعاً سختی را شروع کنیم که باید روی آن‌ها کار کنیم تا عوامل صوتی را در همه‌جا به واقعیت تبدیل کنیم.

بنابراین، بسیار هیجان‌زده هستم که این قدرت صدا، قدرت عامل‌های صوتی را برای همه به ارمغان بیاورم.

متشکریم.