هلوسة وكلاء البرمجة بالذكاء الاصطناعي وكيف تكتشفها
وكيل البرمجة يكتب لك دالّة غير موجودة، يستدعي مكتبة لم تُنشر قط، يمرّر معاملاً ليس في التوثيق، ثم يقدّم ذلك كله بثقة تامة وصياغة سليمة. هذه هي «الهلوسة»، وهي أخطر من الخطأ العادي. الخطأ المنطقي سوء استخدام لشيء موجود، أما الهلوسة فاختلاق شيء من العدم. حين تسيء الأداة استخدام دالّة حقيقية تكشفها الوثائق بسرعة، أما حين تخترع اسماً لا سند له فقد يمرّ الكود أمام عينيك دون أن تنتبه، لأنه يبدو صحيحاً تماماً.
الأخطر: كود «صحيح تقريباً»
أسوأ ما ينتجه الوكيل ليس الكود المكسور بوضوح، بل الكود الذي يعمل في المسار المعتاد وينهار عند الحالة الحدّية. يمرّ في التجربة الأولى، يعبر المراجعة السريعة، ثم يسقط في الإنتاج على مدخل فارغ أو قيمة غير متوقعة.
استطلاع Stack Overflow لعام 2025، بمشاركة أكثر من 49000 مطوّر، يضع رقماً على هذا الإحباط: نحو 66% يحبطهم تحديداً هذا الصنف «الصحيح تقريباً»، ونحو 45% يرون تصحيح كود الذكاء الاصطناعي أكثر استهلاكاً للوقت، فيما لم تتجاوز الثقة القوية بدقّة هذه الأدوات 3.1% فقط. وهنا مكمن الخطر: الخطأ الفاضح يوقفه أول مبرمج يمرّ عليه، أما الاختلاق المصقول فيعبر المراجعة نفسها التي يُفترض أن تمسكه.
هلوسة الحزم وslopsquatting: حين تصبح الهلوسة ثغرة أمنية
الزاوية الأخطر أن يقترح النموذج اسم حزمة غير موجودة أصلاً. في دراسة كبرى فحصت 16 نموذجاً عبر مئات آلاف العيّنات، كان نحو 1 من كل 5 حزم مقترحة (~19.7%) غير موجود. النسبة أعلى في النماذج مفتوحة المصدر (~21.7%) وأقل بكثير في التجارية (~5.2%)، لكنها لم تختفِ.
المشكلة ليست في الاختلاق وحده، بل في ثباته. نحو 43% من الأسماء المهلوسة تكرّرت في كل محاولة، فتحوّلت إلى أهداف قابلة للتنبّؤ. يكفي أن يرصد مهاجم اسماً مهلوساً متكرراً ليسجّل حزمة خبيثة بالاسم نفسه على npm أو PyPI. وحين يثق مطوّر بالاقتراح ويثبّت الحزمة، تنفّذ حمولتها صامتة عبر سكربت post-install وقت التثبيت، قبل أن يكتب سطراً واحداً. هذا النمط اكتسب اسماً في 2025: slopsquatting.
الخطر ليس نظرياً. اسم حزمة مهلوس (huggingface-cli) سُجّل تجريبياً على PyPI فنال أكثر من 15000 تنزيل حقيقي في ثلاثة أشهر، لمجرد أن أدوات ومطوّرين افترضوا وجوده.
لماذا يحدث هذا أصلاً
النموذج لا يبحث عن الأصحّ منطقياً، بل يتنبّأ بالرمز الأرجح إحصائياً. اسم مثل data-utils-async «يبدو معقولاً»، فيولّده النموذج بلا تحقّق من وجوده الفعلي. وتزداد المشكلة كلما طالت المحادثة: تتدهور الدقّة ويناقض الوكيل قراراته السابقة، فيما يشبه تعفّن السياق. لهذا ابدأ جلسة جديدة لكل مهمة منفصلة بدل تكديس كل شيء في محادثة واحدة ممتدة.
كيف تكتشف الهلوسة
شغّل الكود فعلاً ولا تكتفِ بقراءته؛ الاختلاق يظهر عند التنفيذ لا عند التصفّح. اطلب اختبارات تغطّي الحالات الحدّية، لا المسار السعيد وحده. تحقّق من وجود كل حزمة ودالّة وAPI في التوثيق الرسمي قبل الاعتماد عليها، ولا تثبّت حزمة لا تعرفها لمجرد أن الوكيل اقترحها.
وانتبه إلى فخّ شائع: أدوات linting وفحص الأنواع قد تمرّ على كود مهلوس دون اعتراض لأنه سليم نحوياً بالكامل. السلامة النحوية ليست دليلاً على وجود ما استُدعي.
قرار عملي: كيف تقلّلها ومتى تثق
قلّل الهلوسة قبل أن تكتشفها. جزّئ المهمة إلى خطوات صغيرة قابلة للاختبار بدل طلب ميزة كاملة دفعة واحدة. زوّد الوكيل بسياق كافٍ وطلبٍ واضح؛ فكلما وضح ما تريده قلّ اختلاقه، وهذا أساس كتابة أوامر فعّالة لنماذج الذكاء الاصطناعي مثل كلود. وراجع الفروق ملفاً ملفاً، لا كتلة واحدة.
وتبقى قاعدة واحدة غير قابلة للتفاوض: لا تدمج كوداً لا تفهمه. النماذج الأحدث قلّصت نسبة الهلوسة كثيراً لكنها لم تُنهها، والأداة لا تعوّض المراجعة. ولا تثق حتى بشعور السرعة نفسه؛ فقد وجدت تجربة مضبوطة أن الوكيل قد يبطئ مطوّراً مخضرماً بينما يشعر بأنه أسرع. اختر أداتك على أساس واقعي لا انطباعي، كما في أفضل أدوات البرمجة بالذكاء الاصطناعي 2026. القرار الذي لا يملكه الوكيل — أن يدخل هذا الكود إنتاجك — يبقى قرارك أنت وحدك.