الموازنة بين وقت الاستجابة الفائق السرعة واقتصاديات السحابة الإلكترونية في برامج وكلاء الصوت الافتراضية

ديفين رايمر

مرحبًا بك في دورة "الموازنة بين وقت الاستجابة الفائق السرعة واقتصاديات السحابة الإلكترونية في الوكلاء الصوتيين الافتراضيين".

اسمي "ديفين رايمر".

أنا مؤسِّس شركة AstroBeam ورئيسها التنفيذي.

في السابق، كنتُ الرئيس التنفيذي والمؤسس المشارك لشركة Owlchemy Labs، التي تشتهر على الأرجح بلعبة Job Simulator.

لذلك، نركّز في AstroBeam على إنشاء ذكاء اصطناعي في الوقت الفعلي في الألعاب.

نركّز بشكل خاص على الصوت كطريقة إدخال.

لقد أصدرنا لعبتَين حتى الآن، وهما Stellar Cafe، وهي لعبة واقع افتراضي ولعبة كمبيوتر.

إنّها لعبة تتحدّث فيها إلى روبوتات في مقهى بمحطة فضائية وتساعدها في حلّ مشاكلها.

ويتم التحكّم بها بالكامل من خلال الصوت.

يمكنك تشغيل اللعبة بالكامل، بما في ذلك القوائم والتنقّل، باستخدام صوتك فقط.

لعبتنا التالية التي أعلنّا عنها اليوم، Robo Detective، مصمَّمة لنظام Android XR، وتحديدًا لنظارات Project Aura من XREAL.

في هذه اللعبة، تلعب دور محقق يعمل مع شريك آلي للمساعدة في مقابلة الروبوتات لحل جرائم الروبوتات، ومرة أخرى، يتم التحكم فيها بالصوت بنسبة 100%.

لذا، فإنّ الوكلاء الصوتيين صعبون حقًا، وفي الألعاب، هم في الواقع أكثر صعوبة.

والسبب هو أنّ الألعاب منخفضة التكلفة للغاية، والوكيل الصوتي يمثّل الآن تكلفة جديدة تُضاف إلى هذا المسار.

بالإضافة إلى ذلك، نحن لا نتنافس مع وكلاء صوتيين آخرين، بل نتنافس مع جودة كل لعبة تم إنشاؤها على الإطلاق، أليس كذلك؟

لذلك، علينا تقديم محتوى بجودة عالية جدًا.

هذا لا يعني أنّه لا توجد حالات استخدام محدّدة للوكيل الصوتي تنطوي على تحديات فريدة أو تكون فيها المخاطر أعلى بكثير، ولكن الألعاب بالتأكيد تمثّل تحديًا تقنيًا كبيرًا في هذا المجال.

ولكن، لأنّها ألعاب، يتيح ذلك مجالاً واسعًا لتجربة كيفية حلّ بعض هذه المشاكل الصعبة.

لذلك، أعتقد أنّه إذا كان بإمكان وكلاء الصوت العمل ضمن الألعاب، فيمكنهم العمل في أي مكان تقريبًا.

وبالتالي، فإنّ التطبيقات التي أتحدث عنها في هذه المحاضرة لا تنطبق على الألعاب فحسب، بل على أي تطبيق يعتمد على الصوت أولاً تريد إنشاءه.

لذلك، عند التفكير في الوكلاء الصوتيين، أعتقد أنّ هناك ثلاثة تحديات أساسية.

لدينا وقت الاستجابة والذكاء والتكلفة.

أريد توضيح نقطة مهمة، وهي أنّني عندما أتحدث عن برامج المساعد الصوتي، أقصد تلك التي تتيح إجراء محادثة، وليس تلك التي تستجيب للطلبات فقط.

لا أقصد برنامجًا وسيطًا للميكروفون يرسل شيئًا إلى نموذج لغوي كبير ثم ينتظر الرد.

أقصد بذلك محادثة واقعية في الوقت الفعلي، وهذا ما يصعب إنشاؤه.

لنبدأ بوقت الاستجابة.

ما مدى السرعة التي يجب أن تكون عليها؟

اتّضح أنّها يجب أن تكون سريعة، بل سريعة جدًا، ولكن استنادًا إلى ما قرأته، قد لا تكون بالسرعة التي تتخيّلها، أو قد تكون أسرع بكثير مما تتخيّل.

لنتحدّث عن بعض الأرقام التي اكتشفناها في الكثير من اختباراتنا.

لذا، عندما أتحدث عن وقت الاستجابة من البداية إلى النهاية، ما أتحدث عنه هو الوقت من آخر كلام للمستخدم، وآخر صوت أصدره المستخدم، إلى الوقت الذي يسمع فيه الصوت يعود إليه.

ما اكتشفناه في اختباراتنا هو أنّ مدة 1.5 ثانية تقريبًا هي النقطة التي نبدأ عندها في تلقّي ملاحظات من المستخدمين حول اختبار اللعب، ولا يذكرون فيها السرعة أو البطء أو أي شيء من هذا القبيل.

يبدو أنّ هذه هي النقطة التي يبدأ فيها المستخدمون بالشعور بالراحة في استخدامها.

وعندما نقدّم إجابات أبطأ من ذلك، غالبًا ما يلاحظ المستخدمون ذلك ويقولون "هذا رائع، ولكن"، لذا يبدو أنّ هذه هي المدة المثالية.

وعندما تصبح الاستجابة أسرع، أي في غضون 1.2 ثانية تقريبًا، لاحظنا أنّ المحادثة تصبح طبيعية أكثر، وكأنّها محادثة بين شخصَين.

مثلاً، أقول شيئًا، وفي هذه الحالة، سيقول الروبوت شيئًا سريعًا جدًا، ويحدث نوع من التفاعل المتبادل.

يبدو أنّ هناك فرصة جيدة يمكن الاستفادة منها.

ومع ذلك، من الصعب جدًا تحقيق 1.2 ثانية في مجموعة.

ومن النتائج الأخرى المثيرة للاهتمام أنّنا أجرينا الكثير من الاختبارات، وانتهى بنا الأمر إلى الحصول على بعض السيناريوهات التي تستغرق أقل من ثانية.

وقد تقولون لأنفسكم: "سيكون ذلك رائعًا".

وأحيانًا كان كذلك، وأحيانًا كان يبدو فظيعًا وغريبًا جدًا.

لذلك، قد ينتهي بك الأمر إلى سماع أشخاص يتحدثون عن وقت استجابة يبلغ 800 مللي ثانية باعتباره الرقم الصحيح، أو 500.

حتى أنني قرأت مجموعة من المقالات حول 300 لأن هذا هو المكان الذي يهبط فيه الإدراك البشري حقًا.

في الواقع، يعتمد ذلك على السياق.

على سبيل المثال، إذا سألتك عن اسمك، أتوقع أن يستغرق الرد وقتًا معينًا.

إذا سألتك عن معنى الحياة، أتوقع وقتًا مختلفًا تمامًا للرد.

عندما أجرينا الاختبارات وطلبنا من المستخدمين تقييم ما إذا كان هذا الردّ سريعًا أم بطيئًا، كانت النتائج متفاوتة بشكل كبير.

الردود التي استغرقت وقتًا طويلاً، قال الناس إنها كانت سريعة والعكس صحيح لأنها اتضح أنها تعتمد بشكل كبير على السياق.

وأيضًا مكانهم في المحادثة.

يتوقّع المستخدمون عادةً أن يكون الردّ الأول أسرع من الردود اللاحقة لأنّ هناك وقتًا للتفكير.

ولكن في بعض الأحيان، قد ينتهي بك الأمر إلى إجراء محادثات قصيرة جدًا، وبالتالي تزداد توقعاتك.

لذا، ليس هذا علمًا مثاليًا حيث يوجد رقم مثالي، ولكننا اكتشفنا حوالي 1.5، إذا كنت في هذا المكان، فأنت تحصل على نتائج جيدة جدًا.

لذا، بمجرد أن تصل إلى هذه النقطة التي تبلغ 1.5 ثانية، تبدأ الآن في الاهتمام حقًا بالاتساق، أليس كذلك؟

لأنه إذا انتهى بك الأمر إلى حدوث ذلك في 90٪ من الوقت، ولكن في 10٪ من الوقت يستغرق الأمر 3 ثوانٍ، فستشعر أن تجربتك معطلة، وليست سيئة، ولكنها معطلة.

وعندما تصبح السرعة كافية، يصبح التركيز على الاتساق، أي السرعة طوال الوقت، وليس معظم الوقت.

ديفين رايمر

إليكم بنية نموذجية لتدفق الصوت.

لذا، نأخذ تحويل الكلام إلى نص، ونرسله إلى نموذج لغوي كبير، ثم نرسل النتيجة من النموذج اللغوي الكبير إلى تحويل النص إلى كلام.

ما أعنيه بذلك هو أنّ ميزة "تحويل الكلام إلى نص" ترسل الصوت إلى الخادم ثم تحوّله إلى نص.

في ما يتعلق بالنموذج اللغوي الكبير، نأخذ هذا النص، أي حوار الرد، أو نحوّله إلى حوار رد، ثم نحدّد الإجراءات التي ستتخذها هذه الشخصية.

نحن نربط بينهما بشكل وثيق لأنّنا نعتقد أنّ ذلك مهم جدًا.

وفي ما يتعلق بميزة "تحويل النص إلى كلام"، نأخذ هذا النص ونرسله إلى ميزة "تحويل النص إلى كلام"، ونبثّه للمستخدم، مع تحديد وقت الإجراءات التي يريد الوكيل تنفيذها.

إحدى المشكلات في ذلك هي أن تشغيل هذا بشكل تسلسلي يمكن أن يكون بطيئًا للغاية لأنك ينتهي بك الأمر إلى الاضطرار إلى المرور بكل من هذه الأشياء.

لذا، من الأسئلة الشائعة التي أتلقاها: إذا كانت هذه الطريقة بطيئة وتتطلّب ثلاث خطوات، لِمَ لا نستخدم نموذجًا يحوّل الكلام إلى كلام؟

لأنّ ذلك سيكون أسرع، أليس كذلك؟

نعم، في معظم الأحيان، سيكون ذلك أسرع لأنّك تشغّل شيئًا واحدًا.

ولكنه يأتي مع بعض المقايضات الكبيرة.

لذا، على الرغم من سرعته، هناك بعض العيوب الكبيرة بالنسبة إلينا، وأكبرها هو التكلفة.

لذلك، وجدنا بشكل عام أنّ تشغيل نموذج "تحويل الكلام إلى كلام" أعلى تكلفة بنحو 3 إلى 5 مرات من هذا النهج الموازي.

وبالتالي، لا يمكننا تحمّل هذه التكاليف.

أما في ما يتعلق بالأمان، فالأمر أكثر صعوبة لأنّه من الصعب التحقّق من ردّ الوكيل قبل أن يقوله.

ولكن في الوقت نفسه، إذا كان لديك نهج متسلسل، يمكنك أخذ الردّ الذي يقدّمه النموذج اللغوي الكبير والتحقّق منه ومن أمانه قبل إرساله إلى المستخدم.

بالنسبة إلى أسلوب الصوت، أنت مقيّد بالإعدادات المسبقة ضمن نموذج "تحويل الكلام إلى كلام".

لا يمكنك أن تقول: "أتعلم؟

في هذه الحالة، أريد حقًا استخدام هذا النوع من الصوت".

ستكون عالقًا في هذا الخيار تحديدًا.

في نهج المسار، يمكنك أن تقول: "سأغيّر ذلك.

سأختار هذا النموذج لأنّه يعمل بشكل جيد جدًا في حالة الاستخدام هذه".

وينطبق الشيء نفسه على الذكاء، أليس كذلك؟

إذا كان لديك نموذج جيد جدًا لتحويل الكلام إلى كلام ينتج صوتًا جيدًا، ولكن الذكاء ليس تمامًا ما تريده، حسنًا، لا يمكنك حقًا تبديل ذلك، أليس كذلك؟

أنت محصور نوعًا ما.

في النهج المتسلسل، يمكنك أن تقول: "أريد استخدام نموذج معيّن لحالة الاستخدام هذه".

من المجالات التي تتفوّق فيها ميزة "تحويل الكلام إلى كلام" بالتأكيد هي فهم نبرة المستخدم.

مثل السخرية وما شابه ذلك.

في الوقت الحالي، لا تتضمّن عمليات تحويل الكلام إلى نص الكثير من هذه المعلومات، ولكن أعتقد أنّ ذلك سيتغيّر بمرور الوقت.

هذه بالتأكيد ميزة إيجابية في ميزة "تحويل الكلام إلى كلام".

لذا، تتميز ميزة "تحويل الكلام إلى كلام" بالتأكيد بالسرعة، ولكنّها تواجه بعض التحديات في ما يتعلق بإمكانية الضبط، كما أنّ تكلفتها العالية كانت عائقًا كبيرًا بالنسبة إلينا.

إذًا، هل هناك طريقة أخرى؟

نعم.

ما يجب أن نفعله هو بذل قصارى جهدنا لموازاة المسار.

لذلك، من بين الإجراءات التي نتّخذها هي تشغيل نموذج لغوي كبير قبل أن يكون نموذج تحويل الكلام إلى نص واثقًا تمامًا من النتيجة.

وأقصد بالثقة هنا الثقة في الكلمات التي يتم إنشاؤها في النص، ثم الثقة في نهاية الدور.

لذلك، عندما نعتقد أنّ المستخدم توقّف عن الكلام وأنّ هذا ما قاله، ننتقل إلى الخطوة التالية.

وبالتالي، فإنّ أسوأ سيناريو هو أن نكون مخطئين، أليس كذلك؟

يواصل المستخدم التحدّث.

ولكن حتى في هذا السيناريو، كل ما نفعله هو إلغاء النموذج اللغوي الكبير ثم تشغيله مرة أخرى.

وبما أنّه من المحتمل أن يتم تخزين السياق مؤقتًا ولم ننشئ هذا العدد الكبير من الرموز المميّزة، لن تكون تكلفة ذلك كبيرة، والفائدة من ذلك هي أنّ المستخدم سيسمع الردود بشكل أسرع مما لو انتظرت حتى تتأكد من صحتها تمامًا.

لا ننتظر أيضًا أن ينتهي النموذج اللغوي الكبير من إنشاء ردّه بالكامل قبل أن نبدأ في إرساله إلى ميزة "تحويل النص إلى كلام".

ما ننتظره هو نوع من الجزء الأول القابل للتحدث.

في معظم الحالات، تكون هذه القيمة جملة.

في بعض الأحيان، قد تكون هناك بعض الإعدادات الأخرى، ولكن بمجرد حصولنا على الجزء الأول من الجملة، نرسله إلى ميزة تحويل النص إلى كلام.

بعد ذلك، إذا كان لدينا نموذج جيد لتحويل النص إلى كلام، سيتم بثه فورًا للمستخدم.

نحرص أيضًا على توخّي الحذر الشديد بشأن عدد الرموز المميّزة التي يجب إنشاؤها.

لذلك، لا نستخدم عناصر مثل برامج تضمين JSON وغيرها من العناصر التي قد تضيف رموزًا مميّزة إضافية.

نحاول معرفة البنية الأكثر بساطة للحصول على أسرع استجابة ممكنة.

نستخدم أيضًا ميزات مثل "الملء التلقائي للمساعد" إذا كنا نعرف مسبقًا ما ستكون عليه المجموعة الأولى من الرموز المميّزة من الوكيل.

وبالنسبة إلى ميزة "تحويل النص إلى كلام"، تم تقسيم النص إلى هذين الجزأين، أليس كذلك؟

لذا، يتم إدخال الجزء الأول القابل للقراءة، ثم يتم تشغيل كل شيء آخر بعد ذلك.

ولكن بما أنّ تشغيل الصوت يستغرق وقتًا أطول من إنشائه، فسيتم الانتهاء من تشغيل الجزء الأول للمستخدم في الوقت الذي يتم فيه الانتهاء من الجزء الثاني.

لذا فإنّ ذلك غير مرئي للمستخدم.

ويتم إرسالها بأسرع ما يمكن.

لذا، عندما تفكّر في اختيار خدمات مختلفة، إليك بعض القواعد الأساسية التي نتبعها.

عند اختيار إطار عمل جيد للصوت والوكيل، ما يهمّك هو أقل وقت استجابة في الإدخال والإخراج.

إذًا، ما هي سرعة إرسال البيانات وتنزيلها؟

في ما يتعلق بتحويل الكلام إلى نص، نهتم بالوقت المستغرَق للوصول إلى مستوى الثقة.

لذا، هذه هي الثقة في النص والثقة في نهاية الدور.

هذان مقترنان معًا، أليس كذلك؟

إذا لم تكن لديك ثقة سريعة في أحدهما، فسيكون الأمر بطيئًا مثل ذلك، أليس كذلك؟

لذا، فإنّ سرعة الاتصال تعتمد على أبطأ جهاز متصل.

في ما يتعلق بالنماذج اللغوية الكبيرة، نهتم بالوقت المستغرَق لإنشاء الجملة الأولى، أي أول جزء يمكن قراءته.

وهذا يتألف من جزأين، أليس كذلك؟

وهو الوقت حتى ظهور الرمز المميّز الأول بالإضافة إلى عدد الرموز المميّزة في الثانية.

لذا، إذا عثرت فجأة على نموذج جيد جدًا يمنحك وقتًا جيدًا جدًا للرمز المميز الأول، ولكنه بطيء في الرموز المميزة في الثانية، فقد يكون ذلك أسوأ من البديل.

لذا، عليك تحديد المزيج المناسب لذلك.

وفي ما يتعلّق بتحويل النص إلى كلام، يهمّك الوقت المستغرَق لتشغيل أول ملف صوتي.

لذلك، من المهم جدًا قياس هذه المدة، لأنّ الصوت قد يبدأ أحيانًا بصمت طويل لا يسمعه المستخدم.

لذا عليك فعليًا قياس النقطة التي يسمع فيها المستخدم الأشياء.

وبعد ذلك، كما ذكرت من قبل، قبل كل شيء، أنت تهتم بالاستقرار، وليس بالسرعات القصوى، وليس بأفضل سيناريو.

ما هو وقت الاستجابة الثابت لهذه المجموعة بأكملها؟

ديفين رايمر

لذلك، نستخدم حاليًا LiveKit في إطارات عمل وكلاء الصوت.

لتحويل الكلام إلى نص، نستخدم Deepgram.

بالنسبة إلى النماذج اللغوية الكبيرة، نستخدم نموذج Gemma 4 31B ونستضيفه على LiveKit.

في ما يتعلق بتحويل النص إلى كلام، نستخدم الإصدار الثاني من ميزة تحويل النص إلى كلام من Inworld AI.

بالإضافة إلى ذلك، أنشأنا نظام توجيه وكلاء الذكاء الاصطناعي AstroBeam بالكامل، والذي لا يربط كل هذه العناصر معًا فحسب، بل يضيف أيضًا كل ما يلزم للحصول على وكيل صوتي رائع، خاصةً إذا كان تفاعليًا للغاية مثل وكيلنا المخصّص للألعاب.

لم أتحدّث بعد عن نماذج الأمان.

عادةً ما تكون نماذج الأمان جزءًا من عملية معالجة النماذج اللغوية الكبيرة، ولكنّ ذلك يزيد من وقت الاستجابة ويضيف خطوة إضافية.

ماذا لو أنشأتَ أنت بنفسك هذه القناة؟

هذا هو شكل حزمة البيانات لدينا.

لذلك، عندما نتلقّى الجزء الأول من النص، أي الجزء الأول القابل للقراءة الذي سنرسله إلى ميزة تحويل النص إلى كلام، نرسله في الوقت نفسه إلى نموذج الأمان.

وبما أنّ نموذج الأمان أصغر حجمًا وسيعمل بشكل أسرع من جانب تحويل الكلام إلى نص، يتم تنفيذه دائمًا في وقت مبكر.

وهذا يعني أنّ إضافة نموذج أمان لا يضيف أي وقت استجابة إلى حزمتنا، والأفضل من ذلك أنّ هذا الجزء كبير بما يكفي ليتيح لنا تشغيل نموذج أمان أكبر بكثير مما يفكّر معظم الأشخاص في تشغيله.

وهذا أمر مهم جدًا بالنسبة إلينا، لا سيما أنّنا ننشئ ألعابًا.

هناك الكثير من السياق في هذا العالم الذي يُعدّ مهمًا للغاية.

على سبيل المثال، لنفترض أنّك تطوّر لعبة مستوحاة من العصور الوسطى، ولديك شخصية غير قابلة للّعب في هذه اللعبة تصرخ قائلة: "هجوم!

"اقطعوا رؤوسهم"، أليس كذلك؟

قد يكون نموذج الأمان التقليدي مثل، "هذا ليس جيدًا.

لا يجب أن تقول ذلك".

ولكن في سياق هذه اللعبة، هذا منطقي تمامًا.

ويمكننا تحقيق ذلك من خلال استخدام نموذج أمان أكثر فعالية مع سياق أكبر لما يحدث في العالم.

قد تلاحظون هنا أنّنا نشغّل نموذج الأمان مرّتين، فنشغّله على الجزء الأول ثم نشغّله مرة أخرى على النص بأكمله عندما نحصل على الجزء الأخير.

مرة أخرى، علينا تشغيله مرتين، لكنه لا يضيف أي وقت استجابة إلى الحزمة.

الآن، أصبحنا سريعين بما يكفي، ولكن للأسف لا يهم ذلك إذا لم نكن أذكياء بما يكفي.

ديفين رايمر

إذًا، ما مدى ذكاء هذه الأجهزة؟

يجب أن يكون ذكيًا بما يكفي للمستخدمين، ولكن الأهم من ذلك أن يكون ذكيًا بما يكفي لتطويره.

وهذا غالبًا ما لا يفكر فيه الأشخاص عندما يختارون نوعًا ما يحتاجون إليه من أجل الذكاء هنا.

نعمل على تطوير وكلاء صوتيين منذ حوالي ثلاث سنوات. في البداية، استخدمنا بعض نماذج LLaMA المبكرة، وعلى الرغم من أنّنا تمكّنا من تشغيلها بشكل مقبول للمستخدمين، كانت عملية التطوير مكلفة للغاية لأنّ كل شيء كان هشًا للغاية.

لم يتطلّب الأمر الكثير من النماذج لإنشاء ردود غير مرغوب فيها أو أشياء غير منطقية، ولذلك بذلنا الكثير من الجهد الهندسي لإنجاح ذلك.

لذلك، نمنح الأولوية لهذه المسألة، لأنّنا إذا لم نتمكّن من إنشاء هذه الميزات بسرعة، لن نتمكّن من طرحها للمستخدمين.

لذلك، من المهم جدًا التفكير في كليهما.

غالبًا ما يربط الناس الذكاء بالنماذج اللغوية الكبيرة، أليس كذلك؟

ولكن هذا مجرد جزء من الأمر.

علينا أن نفكر في كل جزء عندما يتعلق الأمر بالذكاء.

لنتحدّث الآن عن ذكاء ميزة "تحويل الكلام إلى نص".

لذا ما يهمنا هنا هو معدل خطأ منخفض في الكلمات.

بالإضافة إلى ذلك، لا يقتصر الأمر على أنّ معدّل الخطأ منخفض، بل إنّه عندما يحدث، ننشئ شيئًا قريبًا جدًا من الشيء الفعلي، لأنّه إذا كان قريبًا جدًا، يمكن للنموذج اللغوي الكبير في كثير من الأحيان، من خلال السياق، أن يؤدي مهمة جيدة جدًا في فهم ما هو عليه.

إذا كان معدل الخطأ منخفضًا، ولكن الأخطاء كبيرة جدًا، سيواجه النموذج اللغوي الكبير صعوبة أكبر في محاولة معرفة القصد الفعلي.

هناك شيء آخر يجب التفكير فيه وهو ما هي المنصة المستهدفة.

على سبيل المثال، إذا كنت أطوّر نموذجًا للواقع الممتد، ولديّ ميكروفونات قريبة جدًا من فم المستخدم، سأحصل على بيانات صوتية عالية الجودة من الميكروفون، وقد يعمل ذلك بشكل جيد مع نماذج معيّنة.

ولكن إذا كنتُ فجأةً أعمل على إنشاء تطبيق لهاتف جوّال سيستخدمه الأشخاص في شارع مزدحم، سيكون لذلك تأثير مختلف تمامًا، وستعمل النماذج المختلفة بشكل مختلف وستكون قادرة على فهم ما يُقال بطرق مختلفة.

لذا عليك التفكير في ذلك، والتأكّد من اختيار المنصة المناسبة التي تصمّم لها.

لننتقل الآن إلى جانب "تحويل النص إلى كلام" في معادلة الذكاء.

هل يبدو ذلك طبيعيًا؟

هدفنا هو إبلاغ المستخدم بما يمكنه فهمه؟

ولكن هذا جزء فقط من الأمر، أليس كذلك؟

تعبيرية الوكيل مهمة للغاية أيضًا لأنّ هناك معلومات في التعبير، وفي اختبارات اللعب، اكتشفنا أنّه كلما زادت قدرة الوكلاء على التعبير، زاد شعور المستخدمين بذكائهم، وهذا أمر منطقي للغاية.

وهل هو سريع بما يكفي؟

في القسم السابق، تحدّثتُ عن وقت الاستجابة، ولكنّه مهم أيضًا هنا في ما يتعلّق بالذكاء المتصوَّر.

يربط المستخدمون سرعة الاستجابة مباشرةً بمدى ذكاء النموذج.

إذا كان لدي رد سريع، فمن المحتمل أن يبدو أكثر ذكاءً.

لذا، يمكن أن تكون هذه الأمور مهمة حقًا عندما يتعلق الأمر بكيفية إدراك المستخدم للتجربة، وكذلك مدى اندماجه في التجربة.

لننتقل الآن إلى الجانب المتعلّق بالنموذج اللغوي الكبير في الذكاء الاصطناعي.

هذا هو، إلى حد بعيد، أصعب ما يمكن تحقيقه لأن هناك العديد من المتطلبات المختلفة هنا، أليس كذلك؟

لدينا إذًا فهم الكلام والسياق والربط بالواقع.

في الألعاب، هذا أمر صعب للغاية، لأن عليك أن ترتكز على عالم كامل، أليس كذلك؟

هذا ليس مربّع نص يمكنه اختلاق أحداث.

إذا قال وكيلك في لعبة ما: "هناك تفاحة على الطاولة"، ولم تكن هناك تفاحة على الطاولة، فسيؤدي ذلك إلى إفساد تجربة المستخدم.

نحتاج أيضًا إلى أشياء مثل اتباع القواعد الصارمة.

تعتمد الألعاب بشكل كبير على القواعد.

هل يمكن للنموذج اللغوي الكبير التعامل مع ذلك؟

هل يمكننا الحصول على معدّل هلوسة منخفض؟

هل يمكننا الحصول على شخصيات متسقة عند التفاعل مع هذا الوكيل نفسه مرارًا وتكرارًا؟

هل يبدو أنّه الوكيل نفسه؟

بعد ذلك، قد تواجه مشكلة، لأنّها ليست مشكلة في بداية التطوير، وهي: هل يمكن لنموذجك التعامل مع حجم الطلب المتزايد؟

لأنّه مع استمرار التطوير، ستضيف حتمًا المزيد من المعلومات إلى الطلب.

ومع استمرار المستخدمين في اللعب، سيزداد سجلّ المحادثات في هذا الطلب.

إذًا، هل سيتعامل هذا الطلب مع هذا النمو؟

لأنّه في بعض الأحيان، مع بعض النماذج، كلما زاد طول الطلب، انخفضت جودة الردّ، لذا عليك معرفة احتياجاتك الفعلية من حيث كمية المعلومات التي يجب إدخالها في الطلب في كل مرة.

ولكن هذا مجرد غيض من فيض، ويعتمد أيضًا على ما تقوم بإنشائه.

لذلك عليك التفكير مليًا في ما تبنيه وما تحاول تحقيقه.

الآن، أصبحنا سريعين وأذكياء بما يكفي، ولكن لا يهمّ أي من ذلك إذا كانت التكلفة مرتفعة جدًا.

ديفين رايمر

إذًا، ما هو السعر المناسب؟

للأسف، الأمر أكثر تعقيدًا من ذلك.

لذلك علينا التفكير في الجوانب الاقتصادية للتطبيق أو اللعبة التي ننشئها، أليس كذلك؟

لذا، هناك بعض الأسئلة التي تحتاج إلى طرحها.

ما هي مدة تفاعل المستخدم مع الوكلاء الصوتيين؟

ما هي الأرباح التي تحققها من كل مستخدم؟

وكم تبلغ تكلفة تشغيل حزمة الصوت هذه في الساعة؟

نجمعها معًا لمحاولة فهمها، ومعرفة ما إذا كانت منطقية.

إليكم الجوانب الاقتصادية للعبتنا الأولى، Stellar Cafe.

لذا فإن وقت اللعب في Stellar Cafe يتراوح بين ساعة ونصف و3 ساعات ونصف، لذا دعنا نصل إلى متوسط ​​حوالي ساعتين.

تبلغ تكلفة تشغيل الوكلاء الصوتيين حوالي 1.20 دولار أمريكي في الساعة لكل مستخدم، ويتفاعل المستخدمون معهم طوال الوقت.

إنّها لعبة تعتمد على الصوت بالكامل.

نفرض رسومًا ثابتة بقيمة 10 دولارات أمريكية مقابل اللعبة، وهو أمر تقليدي.

لا نعتمد على الاشتراكات لأنّها صعبة جدًا في الألعاب، وأنا أؤمن بشدة بأنّنا يجب أن نعتمد على تكلفة ثابتة، وإلا لن ينجح ذلك ولن يتوسّع نطاق العمل.

في السابق، كنا نتقاضى 15 دولارًا، ولكننا عملنا على خفض تكاليف الخادم هذه، لذا فقد خفضناها الآن إلى 10 دولارات.

وهذا المبلغ البالغ 1.20 دولار أمريكي هو ما وصلنا إليه.

هذه ليست تكلفة عالمية.

لقد رأيت هذه الأشياء تكلف مجموعة متنوعة من الأشياء، وأكثر تكلفة في بعض الأحيان.

لذلك، عليك أيضًا معرفة موقفك من جانب التكلفة.

يمكننا خفض السعر، ولكننا نحاول الحفاظ على مستوى الجودة قدر الإمكان.

لذا، من خلال العمل على كل هذا، يعني هذا أنه في وقت اللعب الذي يبلغ ساعتين، يبلغ حوالي 2.40 دولارًا أمريكيًا لمجموعة الصوت لكل مستخدم.

وبما أنّنا نتقاضى 10 دولارات أمريكية، ويفرض المتجر رسومًا، يعني ذلك أنّنا نحقّق حوالي 4.59 دولار أمريكي لكل مستخدم، أليس كذلك؟

وبالتالي، فإنّ الجانب الاقتصادي من ذلك يعمل، أليس كذلك؟

الصوت هو ما يجذب الجمهور، وهو ما نريد إنفاق المال عليه، وهذا ما ينجح.

هذه لعبة صغيرة جدًا.

لنتحدّث عن موضوع أكبر قليلاً.

لنتحدّث عن لعبة افتراضية، لعبة سردية، تستغرق ما بين 5 و9 ساعات، أي في المتوسط 7 ساعات.

في الواقع، معظم الأشخاص - الكثير من الأشخاص لا ينهون الألعاب، فهم يلعبون قليلاً من اللعبة، ويتخلون عنها نوعًا ما، لكنني أريد اختيار شيء أعلى قليلاً للتأكد من أن الاقتصاد لا يزال يعمل.

لذا، سنحافظ على سعر 1.20 دولار في الساعة، ولكن التغيير الذي سنقوم به هو أن المكون الصوتي سيتم استخدامه بنسبة 60% من الوقت، لأن اللعبة الأكبر ستحتوي على آليات أكثر بكثير من مجرد الصوت.

لذا، ستظل اللعبة تعتمد بشكل كبير على الصوت، ولكنها ستتضمّن ميزات أخرى.

لذا، إذا فرضنا 20 دولارًا، نوعًا ما من العمل على كل هذا مرة أخرى، فإنه يكلفنا حوالي - سيكلفنا حوالي 5 دولارات لكل مستخدم، مما يعني أنه في نهاية اليوم، نحقق حوالي 9 دولارات لكل مستخدم.

لذا، مرة أخرى، مع هذا، تعمل الاقتصاديات.

هذا لا يعني أنّ الجوانب الاقتصادية ستكون مناسبة لكل شيء.

على سبيل المثال، من الأخطاء الشائعة أن تقول: "أريد إنشاء لعبة بمحتوى مجاني، ومن المحتمل أن يلعبها المستخدمون لمدة تتراوح بين ساعة وأكثر من 100 ساعة".

لنفترض أنّ متوسط المدة هو 10 ساعات.

إنّها لعبة تعتمد على الصوت بنسبة %100، ولكن لنفترض أنّها حقّقت نجاحًا كبيرًا، وأنّها تحقّق حوالي 3 دولارات لكل مستخدم، وهو أمر رائع بالنسبة إلى لعبة بمحتوى مجاني.

ستخسر 10 دولار أمريكي من كل مشترك.

لذلك، لا تعمل هذه الميزة بعد في كل هذه الحالات، وعليك التفكير في ما تنشئه حاليًا، وهل هو منطقي؟

لا تنتظر حتى النهاية لمحاولة معرفة الجوانب الاقتصادية.

ديفين رايمر

والسؤال التالي الذي يُطرح هو: ماذا عن النماذج المحلية؟

لأنّه إذا كان لديك هذا التحدي الكبير المتمثل في التكلفة، ألن تقضي النماذج المحلية عليه؟

نعم، هذا صحيح.

ولكن هناك بعض المفاضلات هنا التي يجب أن نفكر فيها.

لذا، من ناحية التكلفة، نعم، سنلغي فاتورة الخادم، وهو ما سيكون فائدة كبيرة، ويفتح الكثير من الفرص.

ولكن هناك الكثير من المشاكل التي يمكن للسحابة حلّها الآن والتي يصعب على الأجهزة المحلية التعامل معها.

على سبيل المثال، الحوسبة.

غالبًا ما يقول المستخدمون: "لقد وجدتُ نموذجًا جيدًا جدًا لتحويل الكلام إلى نص، وهو يعمل محليًا على هذا الجهاز، أليس كذلك؟"

رائع، ولكن ما علينا التفكير فيه هو أنّه لا يشغّل نموذجًا واحدًا، بل يشغّل نماذج متعدّدة، أليس كذلك؟

في حالتنا، أربعة، من المحتمل في نفس الوقت، وبالتالي، لا يكفي تشغيل شيء ما مرة واحدة، بل يجب تشغيله عدة مرات في نفس الوقت.

وبعد ذلك، إذا أنجزت ذلك، فهل تركت أي شيء متبقيًا لتشغيل لعبتك أو تطبيقك؟

إذا استهلكت وحدة معالجة الرسومات بالكامل، لن تتمكّن من عرض الكثير من ألعاب الفيديو.

لنفترض أنّك تغلّبت على هذه التحديات.

إذًا، الميزة التالية هي السرعة، أليس كذلك؟

يمكنك في كثير من الأحيان تشغيلها، ولكنّها ستكون بطيئة جدًا، وستبدو وكأنّها مجرد طلبات بدلاً من محادثة فعلية في الوقت الفعلي.

لذا، من الناحية النظرية، فإنّ الحصول على البيانات محليًا يحقّق مكاسب مستقبلية، لأنّك لست بحاجة إلى إجراء عملية الذهاب والعودة من الإنترنت.

يتمثّل التحدي حاليًا في الحصول على نماذج تعمل بالسرعة المناسبة لإنجاح هذه العملية.

لنفترض أنّنا نجحنا في تحسين قدرات الحوسبة والسرعة، علينا الآن التفكير في الجودة، أليس كذلك؟

بشكل عام، لأنّك تشغّل النموذج على جهاز محلي، فأنت تستخدم نموذجًا لغويًا كبيرًا أصغر حجمًا، مثل نموذج تحويل النص إلى كلام أكثر بدائية، وقد يمثّل ذلك بعض التحديات في ما يتعلق بالمحتوى الذي تنشئه.

وكما ذكرت سابقًا، عند التفكير في النموذج اللغوي الكبير، لا يقتصر الأمر على ما إذا كان جيدًا بما يكفي للمستخدمين، بل ما إذا كان جيدًا بما يكفي لتطويره.

لذا، إذا أصبح هذا النموذج صعبًا للغاية لإنشاء شيء ما، فهذا بالتأكيد شيء يجب التفكير فيه.

لنفترض أنّكم حقّقتم نجاحًا في مجال الحوسبة والسرعة والجودة، الخطوة التالية هي قابلية النقل.

إذا فزت وأكملت هذه العملية بأكملها، وتمكّنت من تشغيل هذه اللعبة على بطاقة RTX 5070 مثلاً، قد يكون هذا هو المكان الوحيد الذي يمكن تشغيلها فيه.

لذلك، إذا سنحت فرصة لنقلها إلى منصة جديدة، فقد تكون عالقًا.

في ما يتعلق بالسحابة الإلكترونية، كل ما تحتاج إليه هو الإنترنت.

وهذا إنجاز كبير.

يتيح لك هذا الإجراء البث على منصات متعدّدة.

لنتحدث الآن عن النهج المختلط.

لذا، لنشغّل بعض المهام في السحابة الإلكترونية وبعضها على الجهاز.

نوعًا ما، هل يمكن أن ينجح ذلك؟

حسنًا، ليس هذا فوزًا كبيرًا كما تعتقد.

لذا، إذا حصلت على نموذج صغير بما يكفي لتشغيله على معظم المنصات المحلية، وإذا شغّلت هذا النموذج نفسه في السحابة الإلكترونية، فمن المحتمل أن يكلّفك ذلك مبالغ زهيدة.

لذلك، لا يمكنك تحقيق أكبر انتصاراتك إلا بعد حلّ المشاكل في جميع المستويات.

بعد ذلك، السؤال الذي يطرح نفسه هو: ماذا لو قمت بتشغيله محليًا إذا كان ذلك ممكنًا، أليس كذلك؟

لديهم الأجهزة المناسبة، وفي السحابة الإلكترونية إذا لم يكن لديك، أليس كذلك؟

يمكنك تشغيل شيء أكثر قوة في السحابة.

وهذا يطرح تحديات جديدة، أليس كذلك؟

إذا انتهى بك الأمر إلى تشغيل نموذج مختلف، فقد يؤثر ذلك على التطوير قليلاً.

وينتهي بك الأمر إلى قضاء الكثير من الوقت في العمل على الحد الأدنى من المواصفات على أي حال.

ويمكن أن تكون لديك نماذج تعمل بشكل مختلف تمامًا.

لذلك، ما لم تستخدموا النماذج نفسها، قد ينتهي بكم الأمر إلى إضافة الكثير من الوقت والتكلفة في عملية التطوير.

لذا، من المهم التفكير في ما تحاول تحقيقه، لأنّه لنفترض أنّك توصّلت إلى حلّ وحصلت على نموذج محلي جيد إذا لزم الأمر، أو نموذج سحابي إذا لم يكن الأمر كذلك، لا تزال الجوانب الاقتصادية يجب أن تعمل مع النموذج السحابي.

لأنّه إذا أصبح جميع المستخدمين فجأةً يستخدمون السحابة الإلكترونية، ستخسر إذا لم تفكّر في ذلك من وجهة نظر اقتصادية.

لذا، عندما يتعلق الأمر بالنماذج المحلية، فإنّها بالتأكيد تمثّل مكسبًا اقتصاديًا كبيرًا، ولكن لا يزال الوقت مبكرًا.

بالنسبة إلى التطبيقات التي تتأثر بالأسعار، مثل الألعاب، أعتقد أنّها ستفوز في النهاية على الأرجح.

في الوقت الحالي، من الصعب استخدامها خارج حالات الاستخدام الأكثر تحديدًا، لا سيما الأمور المتعلقة بالأوامر.

لذا، نريد الآن، اليوم، أفضل تجربة ممكنة.

لهذا السبب نستخدم السحابة الإلكترونية.

ومع ذلك، يتطوّر هذا المجال بسرعة كبيرة، وتتغيّر الأمور بسرعة فائقة.

لذا، الجزء التالي هو التفكير في النماذج التي نستخدمها، أليس كذلك؟

السؤال التالي هو: ما الفرق بين الأوزان المفتوحة والأوزان المغلقة؟

ما الذي يجب أن نفعله هنا؟

أريد التركيز على النماذج اللغوية الكبيرة عند الحديث عن هذا الموضوع لأنّنا وجدنا أنّ هذا هو المجال الأكثر تأثرًا بمسألة المصادر المفتوحة مقابل المصادر المغلقة.

لذا، هناك بالتأكيد بعض الإيجابيات والسلبيات هنا.

لذا، عندما يتعلق الأمر بالنماذج المغلقة، فإنّها تمثّل بشكل عام الذكاء الاصطناعي المتقدم، أليس كذلك؟

لذا، إذا كنت بحاجة إلى أكبر قدر من المعلومات، فهذا هو المكان الذي عليك الذهاب إليه غالبًا.

وفي الوقت نفسه، في الجانب المفتوح، غالبًا ما يكونون متأخرين بجيل.

لذا، يمكن أن يكون هذا بمثابة مقايضة حقيقية.

في ما يتعلق بالسرعة، ذكرت أنّني أهتم كثيرًا بالوقت المستغرَق لإنشاء الجملة الأولى.

ما اكتشفناه هو أنّه على مدار عمر النماذج المغلقة، غالبًا ما تنخفض السرعة.

ويمكن أن يكون هناك العديد من الأسباب لذلك.

ربما يستخدم المزيد من الأشخاص النموذج، وربما تم نقل الأجهزة إلى نموذج أحدث.

ولكن هذا أمر لاحظناه.

لذلك، عليك توخي الحذر لأنّ ذلك قد يسبّب مشكلة، فإذا شحنت منتجًا رائعًا، قد يصبح بمرور الوقت غير صالح للاستخدام.

التالي هو الارتفاعات المفاجئة.

يهمّك كثيرًا هذا النوع من الاتساق، لذا غالبًا ما يتم إنشاء النماذج المغلقة حول نوع من التجميع في المهام غير المتزامنة، وليس نوعًا من زمن انتقال P99، حيث يمكنك، في الجانب المفتوح، اختيار مقدّم خدمة يهتم بهذا الشيء المحدّد الذي يهمّك، لمنحك نوعًا من الثقة والسرعة وزمن الانتقال الذي تحتاج إليه في النهاية.

التالي هو عمر النموذج نفسه.

لذلك، غالبًا ما يتم إيقاف النماذج المغلقة بعد عام تقريبًا.

هذا يعني أنّه إذا طوّرت نموذجًا لمدة عام، وتوقّعت أن يبقى في مرحلة الإنتاج لمدة 3 أعوام، قد تجري أكثر من 3 تغييرات عليه.

ومجرّد أنّ النموذج أفضل لا يعني أنّه سيناسبك أكثر.

لقد أجرينا الكثير من التغييرات على النماذج في السنوات الثلاث الماضية، وغالبًا ما يستغرق الأمر أسابيع، وأحيانًا أشهر من العمل لإعادة تجهيز كل شيء، وهو ما يمكنك الاستمرار في تشغيل هذا النموذج على الجانب المفتوح طالما أن شخصًا ما على استعداد لاستضافته، أو أنك على استعداد لاستضافته بنفسك.

أخيرًا، التكلفة.

غالبًا ما تصبح هذه النماذج المغلقة، بمرور الوقت، أكثر تكلفة من الإصدارات السابقة مع إصدار إصدارات جديدة.

لذلك، يجب الانتباه إلى هذا الأمر في ما يتعلق بالاقتصاد، وهو أنّ اقتصادك قد يكون ناجحًا عند الإطلاق ثم يفشل عند الانتقال إلى نماذج أخرى.

في ما يتعلق بالجانب المفتوح، لديك المرونة لتتمكّن من نقله، ومن المرجّح ألا يزيد بشكل كبير لأنّه النموذج نفسه بالضبط.

لذلك، نستخدم Gemma 4 31B، وقد شكّل ذلك إنجازًا كبيرًا بالنسبة إلينا لأنّه يوفّر أفضل مزيج من السرعة والذكاء والتكلفة.

وقد سمح لنا أيضًا بالتحرّك بسرعة كبيرة.

إنّ تطوير التطبيقات باستخدام هذه المنصة أسهل بكثير من بعض الأدوات التي استخدمناها في السابق.

هذا لا يعني أنّنا نستخدم هذه الطريقة فقط.

نستخدم الكثير من المجموعات من النماذج المفتوحة والمغلقة المختلفة.

على سبيل المثال، ميزات مثل إنشاء الذكريات والأمان والتخصيص.

من المهم اختيار النموذج الأفضل لاحتياجاتك المحددة في تلك المهمة.

أما نموذج Gemma 4 31B، فهو الأفضل في ما يتعلّق بالوكلاء الصوتيين.

لذا، عندما يتعلق الأمر بهذا النوع من الاختلافات بين الاثنين، فإن النماذج المفتوحة تمنحك بالتأكيد تحكمًا أكبر وتسمح لك بالاحتفاظ بالنماذج طالما يمكن استضافتها بتكلفة يمكن التنبؤ بها.

ولن يتأثر جدولك الزمني بإيقاف نموذج معيّن.

ديفين رايمر

لذا، لتلخيص هذا الأمر، يتعلق الأمر بموازنة كل هذه الأشياء الثلاثة، أليس كذلك؟

نحاول تحقيق التوازن بين وقت الاستجابة وجوانب البث والتوازي والسرعة والاتساق.

وعلى صعيد الذكاء، إنّها ذكية بما يكفي للمستخدمين، وذكية بما يكفي لإنشاء المحتوى باستخدامها.

بالنسبة إلى التكلفة، علينا معرفة التكلفة لكل مستخدم ومقدار الأرباح التي يمكننا تحقيقها من كل مستخدم لضمان نجاح الجانب الاقتصادي.

لا تبدأ بالبناء ثم تفكّر في الجوانب الاقتصادية لاحقًا.

فكِّر في ذلك منذ البداية.

لا يزال الوقت مبكرًا، ولكن بدأت تظهر بوادر نجاح هذا النموذج الاقتصادي.

لذلك، ستكون النماذج الأرخص والأكثر ذكاءً أفضل بالتأكيد.

ولكن الآن، يمكننا البدء في العمل على التحديات الصعبة التي نحتاج إلى العمل عليها لجعل برامج الصوت متاحة في كل مكان.

لذلك، يسرّني جدًا أن أقدّم للجميع هذه الميزات الفعّالة التي توفّرها برامج الصوت الآلية.

شكرًا لك.