لا تزال الشبكات العصبية ضعيفة في الضرب: لماذا يكتب AI الكود لكنه يخطئ في الحساب

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

لماذا يحدث هذا

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

"إنها لا تحسب بالطريقة التي نفهمها، بل تتذكر وتقرب الإجابات."

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

أين تفشل النماذج

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

• ضرب الأرقام متعددة الأرقام مع عمليات نقل متعددة
• التجميعات النادرة التي كانت غائبة تقريباً عن بيانات التدريب
• المهام حيث تختلط الأرقام مع النص والوحدات أو الشروط
• سلاسل الحسابات حيث يفسد الخطأ المبكر الإجابة كاملة
• التحقق من النتيجة الخاصة به دون أداة خارجية

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

كيف يتم تجاوز هذا

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

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

ماذا يعني هذا

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