أردت أن أرى ما إذا كان طرح السؤال نفسه 51 مرة سيجعل الإجابة أكثر موثوقية. أخذت نموذج لغة كبير (LLM) محلي، وغذيته بقطعة من كود برمجي فعلي (production code)، وطلبت منه مراجعته. ثم كررت ذلك مرة أخرى، ومرة أخرى. إجمالي 51 مرة، مستخدماً نظام "تصويت الأغلبية" (majority voting) لاختيار الاستجابة "الأفضل". كانت الفكرة بسيطة: إذا تعثر النموذج في إحدى المرات، فربما تؤدي "حكمة الحشود" عبر 51 عملية توليد إلى إلغاء الضجيج وإظهار التحليل الصحيح. لكن هذا لم يحدث. أظهرت التجربة أن تصويت الأغلبية لا يختار الإجابة الصحيحة، بل يختار ما يصر عليه النموذج بشدة.
هذا التمييز مهم لأن تصويت الأغلبية أصبح "حيلة" (hack) شائعة في مسارات عمل نماذج اللغة الكبيرة (LLM pipelines). النمط بسيط: تقوم بتشغيل النموذج عدة مرات على نفس المطالبة (prompt)، وتجمع المخرجات، وتحتفظ بالإجابة التي تظهر بشكل متكرر. في مجالات مثل التصوير الطبي أو اكتشاف الرسائل غير المرغوب فيها (spam detection)، تعمل أساليب التجميع (ensemble methods) لأن النماذج المختلفة، أو الرؤى المختلفة للبيانات، تنتج أخطاءً مستقلة تلغي بعضها البعض بالفعل. أما نماذج اللغة الكبيرة فليست مصوتين مستقلين؛ إنها نظام واحد بتاريخ تدريب واحد، ومجموعة واحدة من الأوزان (weights)، وكون واحد من الانحيازات. عندما تسأل النموذج نفسه السؤال نفسه 51 مرة، فأنت لا تعقد لجنة، بل تجري استطلاع رأي لنفس الشخص تحت حالات مزاجية مختلفة قليلاً.
مشكلة الإصرار
المشكلة الأساسية هي أن أخطاء نماذج اللغة الكبيرة نادراً ما تكون عشوائية، بل هي أنماط متجذرة في بيانات التدريب وفي البنية البرمجية (architecture). فالنموذج الذي يسيء قراءة "decorator" معين في لغة Python في إحدى المرات، من المرجح أن يسيء قراءته في المرة التالية. والنموذج الذي "يهلوس" بوجود ثغرة أمنية لأن اسم المتغير يشبه كلمة مرور، سيقوم على الأرجح بالهلوسة بها مرة أخرى في المرة السابعة والأربعين. الضجيج الذي تحاول تقليله عبر المتوسط الحسابي هو عادةً تباين سطحي في الصياغة أو التنسيق، بينما يظل المنطق الأساسي ثابتاً في مكانه.
لنأخذ مثالاً ملموساً. تخيل دالة تقوم بتحليل ملفات السجل (log files) باستخدام تعبير نمطي (regular expression). التعبير النمطي (regex) صارم وآمن، لكن السلسلة النصية r'...' تحتوي على رموز قد تؤدي إلى هجوم حقن (injection) في سياق مختلف. اطلب من نموذج لغة كبير مراجعة هذا. إذا كان النموذج قد رأى آلاف المنشورات على Stack Overflow تحذر من حقن التعبيرات النمطية في محللات السجلات، فقد يصنف هذه القطعة البرمجية الآمنة على أنها خطر. إذا قمت بتشغيله مرة واحدة، ستحصل على نتيجة إيجابية خاطئة (false positive). وإذا قمت بتشغيله 51 مرة، فهناك احتمال كبير أن تحصل على 51 نتيجة إيجابية خاطئة، أو على الأقل أغلبية ساحقة. هنا، يعمل تصويت الأغلبية على ترسيخ الهلوسة؛ فالنموذج مصرّ، وبالتالي فإن "الإجماع" مصرّ أيضاً.
يحدث هذا لأن حيل "درجة الحرارة" (temperature) وأساليب أخذ العينات (sampling) لا تغير ما يعرفه النموذج، بل تعيد فقط ترتيب طريقة حديثه. قد تجعل درجة الحرارة العالية الشرح ثرثاراً أو مقتضباً، وقد تستبدل المرادفات، لكنها لن تعلم النموذج فجأة أن التعبير النمطي غير ضار في الواقع. الاختلافات التي تصوت عليها هي اختلافات شكلية، أما الخطأ فهو هيكلي.
ما تكشفه الـ 51 عملية تشغيل
عندما نشرت تلك المخرجات الـ 51 على مكتبي، كان النمط واضحاً. لم يستكشف النموذج 51 تفسيراً مختلفاً للكود، بل كان يكرر التفسير نفسه بأصوات مختلفة قليلاً. خرجت حفنة من عمليات التشغيل عن النص، مقترحةً إصلاحات لحالات استثنائية (edge-cases) أو ملاحظة مشكلات تتعلق بأسلوب الكتابة لا علاقة لها بالموضوع. لكن الكتلة المهيمنة، وهي الأغلبية الواضحة، استمرت في العودة إلى نفس الادعاء المركزي الخاطئ. لم يكن ذلك الادعاء صحيحاً، بل كان مألوفاً فحسب.
تفترض رياضيات تصويت الأغلبية وجود تجارب "برنولي" (Bernoulli trials) مستقلة. أنت بحاجة إلى أخطاء غير مترابطة لكي تتفوق الأغلبية على الفرد. في تجربتي، كانت الأخطاء مترابطة بعمق، حيث تشاركت في نفس السبب الجذري: توزيع تدريب النموذج يعطي وزناً زائداً لبعض الأنماط البرمجية الشائعة (coding tropes). لذلك، لم يقلل تصويت الأغلبية من الخطأ، بل ضخم انحياز الأغلبية، وأعطى شعوراً زائفاً باليقين لتحليل معيب.
هذا الأمر خطير بشكل خاص في مراجعة الكود، لأن المطورين يتعاملون مع مخرجات الذكاء الاصطناعي المتفق عليها بالإجماع أو شبه الإجماع على أنها مرجع موثوق. من السهل تجاهل اقتراح واحد متردد، لكن التوصية التي تظل ثابتة عبر 51 عملية تشغيل تبدو وكأنها حقيقة مطلقة (ground truth). لكنها ليست كذلك؛ إنها مجرد "حلقة أرضية" (ground loop).
أين ينجح التصويت فعلياً
لا يعني أي مما سبق أنه لا ينبغي لك تشغيل النموذج أكثر من مرة واحدة أبداً. يمكن أن يساعد التصويت بالأغلبية في حالات ضيقة تكون فيها المهمة سطحية والأخطاء عشوائية تماماً. إن طلب الاختيار بين تنسيقين نحويين من نموذج ما، أو اختيار اصطلاح لتسمية المتغيرات، أو استخراج سلسلة تاريخ من سطر سجل (log line) — هذه المهام منخفضة المخاطر قد تستفيد أحياناً من أخذ العينات المتكرر. التباين هنا هو ضجيج حقيقي، والتصويت السريع كفيل بتنقيته.
تبدأ المشكلة عندما تتطلب المهمة الاستنتاج حول القصد. هل ينتمي فحص المصادقة (auth check) هذا إلى هنا؟ هل استدعاء الـ async هذا آمن؟ هل تصادم مفتاح التخزين المؤقت (cache key collision) هذا قابل للاستغلال فعلياً؟ تتطلب هذه الأسئلة فهماً للسياق، وليس مجرد مطابقة الأنماط. إن أداة مطابقة الأنماط في النموذج حتمية في انحيازها؛ فهي ستلجأ إلى الإجابة الأكثر شيوعاً من بيانات التدريب الخاصة بها، وليس الإجابة الأكثر دقة لمجموعة الأكواد (codebase) الخاصة بك.
طرق أذكى لاستغلال قدرات الحوسبة لديك
إن تشغيل نموذج محلي إحدى وخمسين مرة يكلف وقتاً وطاقة كهربائية حقيقية. هناك طرق أفضل لاستثمار تلك القدرات الحوسبية. إذا كنت ترغب في تحسين الموثوقية، فإن التنوع يتفوق على الكمية. قم بتشغيل نموذجين مختلفين بـ