هلوسة وكلاء البرمجة بالذكاء الاصطناعي وكيف تكتشفها

بقلم فريق تقني ·8 يوليو 2026 (آخر تحديث: 1 سبتمبر 2026)· أدوات المطورين

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

الأخطر: كود «صحيح تقريباً»

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

صورة نموذجية لذلك: دالّة تعالج مدخلات المستخدم وتعمل بلا مشكلة ما دام المدخل بالشكل المتوقع، لكنها لم تحسب حساب النص الفارغ أو الرقم السالب أو الحروف غير اللاتينية. القراءة السريعة لا تلتقط هذا الصنف؛ الاختبار الذي يتعمّد كسر الدالّة هو الذي يلتقطه.

استطلاع 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 تنزيل حقيقي في ثلاثة أشهر، لمجرد أن أدوات ومطوّرين افترضوا وجوده. والمفارقة أن الأداة الحقيقية موجودة فعلاً، لكنها تُثبَّت عبر حزمة باسم آخر هو huggingface_hub؛ فارق صغير كهذا بين الاسم المتداول واسم الحزمة الرسمي هو كل ما يحتاجه المهاجم.

لماذا يحدث هذا أصلاً

النموذج لا يبحث عن الأصحّ منطقياً، بل يتنبّأ بالرمز الأرجح إحصائياً. اسم مثل data-utils-async «يبدو معقولاً»، فيولّده النموذج بلا تحقّق من وجوده الفعلي. الوكيل لا يستعلم من سجلّ npm أو PyPI وقت التوليد؛ إنه يركّب اسم الحزمة كما يركّب أي جملة أخرى. ولهذا لا يكفي أن تسأله «هل أنت متأكد؟»، فمصدر التأكد هو السجلّ الرسمي لا النموذج نفسه.

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

كيف تكتشف الهلوسة في الكود نفسه

أربع خطوات تصنع الفرق بين مراجعة شكلية ومراجعة تمسك الاختلاق:

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

وانتبه إلى فخّ شائع: أدوات linting وفحص الأنواع قد تمرّ على كود مهلوس دون اعتراض لأنه سليم نحوياً بالكامل. السلامة النحوية ليست دليلاً على وجود ما استُدعي.

قبل تثبيت أي حزمة اقترحها الوكيل: فحص الدقائق الثلاث

كل حزمة جديدة يقترحها الوكيل تستحق هذا الفحص القصير قبل أن تلمس سطر التثبيت:

افتح صفحة الحزمة بنفسك على npmjs.com أو pypi.org بكتابة الاسم كاملاً. إن لم توجد صفحة أصلاً فقد انتهت القصة: الحزمة مهلوسة، ولا تثبّتها لتجرب.
انظر إلى تاريخ أول نشر وسجلّ الإصدارات. حزمة يقدّمها الوكيل كأنها معروفة ومستقرة، لكن عمرها على السجلّ أسابيع ولها إصدار يتيم، علامة إنذار صريحة؛ فهذا بالضبط شكل الحزمة التي سجّلها مهاجم على اسم مهلوس متكرر.
راجع عدد التنزيلات والمشاريع المعتمدة عليها. المكتبات الراسخة أرقامها واضحة ومستقرة، والحزمة التي بلا تنزيلات تُذكر وبلا مشاريع تعتمد عليها لا تستحق مكاناً في مشروعك بناء على اقتراح آلي.
افتح رابط المستودع المرفق. تأكد أن المستودع يخص الجهة المتوقعة فعلاً، وأن اسم الحزمة المكتوب في توثيقه مطابق حرفياً لما تنوي تثبيته؛ فالفرق بين شرطة وشرطة سفلية قد يعني حزمة مختلفة تماماً، كما في قصة huggingface-cli وhuggingface_hub أعلاه.
عند الشك في بيئة npm، ثبّت مع تعطيل السكربتات بالأمر npm install --ignore-scripts ثم افحص ما نزل قبل السماح لأي سكربت تثبيت بالعمل، فهذا يعطّل تحديداً قناة post-install التي تمرّ منها الحمولات الخبيثة.

هذه الدقائق ليست ترفاً؛ إنها الفاصل بين اعتماد مكتبة والتصريح لكود مجهول بالتنفيذ على جهازك.

متى تثق بكود الوكيل ومتى توقفه

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

ثم درّج ثقتك حسب ما يلمسه الكود:

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

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