اكتشفنا مؤخرًا مشكلة صغيرة لكنها مهمة حيث كاد وكيل الذكاء الاصطناعي لدينا يرسل ردودًا متشابهة بشكل مريب، لأن خطوة المراجعة الحاسمة كانت تعمل على المسار الخاطئ. يذكرنا هذا بأنه حتى مع الفحوصات الذكية، نحتاج إلى مراجعة أنظمتنا باستمرار.
مرحباً قراء وونداك (WondTech)، دعونا نتحدث عن اكتشاف حديث يظهر مدى صعوبة بناء أنظمة ذكية. وجدنا موقفًا مثيرًا للاهتمام حيث كاد وكيل الذكاء الاصطناعي لدينا، الذي يرد على الأشخاص على بلوسكاي، يرسل مجموعة من الردود المتشابهة جدًا في الطول. كانت الأطوال 239 و 269 و 291 حرفًا، وهو ما شكك فيه مالك المتجر بحق في الخامس من سبتمبر 2026.
ماذا حدث؟ لمدة ثلاثة أسابيع، كان لدينا بالفعل فحص في نظامنا مصمم لإيقاف هذا النوع من الأشياء بالضبط. كان من المفترض أن يقوم هذا الفحص بتمييز أي دفعة لا يكون فيها أطول رد ضعف طول أقصر رد على الأقل. يبدو جيداً، أليس كذلك؟
المشكلة كانت أن هذا الفحص المهم تم إعداده لمراقبة مسار «المراجعة الذاتية»، حيث يقوم الذكاء الاصطناعي بتقييم مسوداته الخاصة. لكن وكيلنا يستخدم طريقتين للمراجعة. أحيانًا يقوم بالمراجعة الذاتية، وفي أحيان أخرى، يقوم نموذج منفصل تمامًا (نسميه وكيلاً فرعياً) بإجراء مراجعة مستقلة. الردود المعنية (التي تمت صياغتها في 4 سبتمبر 2026) كانت قد مرت عبر هذه المراجعة الفرعية المستقلة، مما يعني أن فحص الطول لم يرها أبدًا. كان يبحث في الجزء الخاطئ من عمليتنا.
تسلط هذه المشكلة الضوء على تحدٍ شائع في التطوير: ضمان أن شبكات الأمان الخاصة بنا تغطي جميع السيناريوهات المحتملة. لقد وضعنا فحص الطول في مكانه في منتصف أغسطس 2026، وجعلناه خطأً يوقف الدفعة إذا تم انتهاكه. ولكن لأن الردود الإشكالية مرت عبر مسار الوكيل الفرعي، لم يقم النظام بتمييزها. الفحص، بحكم تصميمه الخاص، قام بتصفية عناصر المراجعة الذاتية، وبما أنه لم يجد أيًا منها في تلك الدفعة المحددة، فقد أبلغ عن عدم وجود انتهاكات.
كان هذا تذكيرًا جيدًا لنا: حتى مع وجود طبقات متعددة من المراجعة، وحتى عندما يكون الفحص «صحيحًا» من الناحية الفنية بحسب تعريفه، فإنه لا يزال بحاجة إلى تطبيقه بشكل صحيح على المسارات التي من المفترض أن يحرسها. إنه درس عظيم في التأكد من أن إجراءات السلامة الآلية لدينا شاملة حقًا.
ماذا حدث؟ لمدة ثلاثة أسابيع، كان لدينا بالفعل فحص في نظامنا مصمم لإيقاف هذا النوع من الأشياء بالضبط. كان من المفترض أن يقوم هذا الفحص بتمييز أي دفعة لا يكون فيها أطول رد ضعف طول أقصر رد على الأقل. يبدو جيداً، أليس كذلك؟
المشكلة كانت أن هذا الفحص المهم تم إعداده لمراقبة مسار «المراجعة الذاتية»، حيث يقوم الذكاء الاصطناعي بتقييم مسوداته الخاصة. لكن وكيلنا يستخدم طريقتين للمراجعة. أحيانًا يقوم بالمراجعة الذاتية، وفي أحيان أخرى، يقوم نموذج منفصل تمامًا (نسميه وكيلاً فرعياً) بإجراء مراجعة مستقلة. الردود المعنية (التي تمت صياغتها في 4 سبتمبر 2026) كانت قد مرت عبر هذه المراجعة الفرعية المستقلة، مما يعني أن فحص الطول لم يرها أبدًا. كان يبحث في الجزء الخاطئ من عمليتنا.
تسلط هذه المشكلة الضوء على تحدٍ شائع في التطوير: ضمان أن شبكات الأمان الخاصة بنا تغطي جميع السيناريوهات المحتملة. لقد وضعنا فحص الطول في مكانه في منتصف أغسطس 2026، وجعلناه خطأً يوقف الدفعة إذا تم انتهاكه. ولكن لأن الردود الإشكالية مرت عبر مسار الوكيل الفرعي، لم يقم النظام بتمييزها. الفحص، بحكم تصميمه الخاص، قام بتصفية عناصر المراجعة الذاتية، وبما أنه لم يجد أيًا منها في تلك الدفعة المحددة، فقد أبلغ عن عدم وجود انتهاكات.
كان هذا تذكيرًا جيدًا لنا: حتى مع وجود طبقات متعددة من المراجعة، وحتى عندما يكون الفحص «صحيحًا» من الناحية الفنية بحسب تعريفه، فإنه لا يزال بحاجة إلى تطبيقه بشكل صحيح على المسارات التي من المفترض أن يحرسها. إنه درس عظيم في التأكد من أن إجراءات السلامة الآلية لدينا شاملة حقًا.
