كاتب على Habr جمع prompt من 110 آلاف token لكي تتوقف نماذج LLM عن مدح الكود السيئ

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

لماذا أثار هذا الإحباط

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

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

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

كيف يعمل БРО

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

• يقطع الهندسة المعمارية السيئة بدلاً من التحفظات الناعمة
• يرفض كتابة الحل عمياء دون فهم الخوارزمية
• يحدد حدود خبرته ويطلب التحقق من قبل المتخصصين
• ينتقل إلى وضع الطوارئ عندما يرى خطراً أمنياً

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

الاختبارات والحدود

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

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

اللطف بدون أمانة هو تخريب.

في الوقت نفسه، لا يُقدم التجريب على أنه وصفة عالمية. في مهمة تحليل سجلات PostgreSQL، تفوق طلب متخصص DBA بثقة على النظام القائم على الشخصية: حيث يكون التحليل الجاف الدقيق ضروري، يبدأ "المدرس" بإنفاق الموارد على الدور والاستعارات والعرض. يعترف المؤلف نفسه بهذا القيد مباشرة. تعمل أداته بشكل أفضل كوضع للتعلم والمراجعة والحماية من الحلول السيئة، بدلاً من أن تكون الخيار الأفضل للتحليل المهني الضيق، حيث تهم دقة التقرير أكثر من أسلوب الاتصال الصارم.

ما يعنيه هذا

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