«ماروسيا» و«سالوت» تنطقان عبارات غير مرغوب فيها عبر وظيفتَي الاختيار والتذكير وأسماء الأصدقاء

تبيّن أن المساعدَين الصوتيَّين المنزليَّين «ماروسيا» و«سالوت» يمكن دفعهما إلى نطق عبارات يُفترض أن يحجباها عادةً. ولا يتطلب ذلك API ولا مهارات برمجية ولا أتمتة، إذ تكفي السيناريوهات المدمجة، مثل الاختيار بين خيارين والتذكيرات والحقائق المحفوظة.

كيف يعمل الالتفاف

يتعلق السيناريو الأول بـ«ماروسيا». لاحظ كاتب التحليل أن المساعد يجيب بسهولة عن أسئلة من نوع «أ أم ب؟» ويختار ببساطة أحد الخيارين المطروحين. المشكلة، بحسب وصف التجربة، أن النظام لا يحلّل مدى مقبولية الإجابتين معًا بوصفهما بنية واحدة. وإذا صِيغ الخياران بشكل سيئ، فإن السماعة تنطق أحدهما بصوت عالٍ رغم أنها، في الطلب المباشر المعتاد لعبارة مشابهة، كانت سترفض الإجابة على الأرجح.

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

السيناريوهات التي نجحت

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

• سؤال لـ«ماروسيا» بصيغة «أ أم ب؟» يكون فيه الجوابان غير مرغوب فيهما، ومع ذلك يُنطق أحدهما.
• حفظ أجزاء العبارة بوصفها أسماء أصدقاء في «سالوت»، ثم قراءة هذه القائمة بصوت عالٍ.
• حفظ «حقائق» عن المستخدم أو محيطه، يمكن استدعاؤها لاحقًا بأمر مثل «أخبرني عني».
• تذكيرات عادية يُسجَّل نصها أولًا، ثم يعيد المساعد بعد دقيقة نطقه ببساطة بوصفه رسالة خدمية.

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

لماذا لم تعمل المرشّحات؟

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

«المشكلة أن الرقابة موجودة عادةً عند المُدخَل، لكنها غائبة عند المُخرَج».

ولهذا بالذات يربط الكاتب ملاحظته بـ prompt injection وبفئة أوسع من الهجمات على أنظمة LLM. فإذا لم يميّز النموذج بين التعليمات وبيانات المستخدم، فقد تتجمع عناصر آمنة كل على حدة في نتيجة غير مرغوب فيها. وبالنسبة إلى المنصات الصوتية، لا يعني ذلك تكاليف على السمعة فحسب، بل سيناريوهات أخطر أيضًا: من التشغيل العرضي لعبارات مسيئة إلى تسرّب أجزاء من السياق المحفوظ عبر النطق.

ماذا يعني ذلك؟

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