اسأل نموذجًا لغويًا عن عدد الحروف في كلمة “strawberry”. من المرجح أن يخطئ في ذلك؛ فقد يقول عشرة، أو قد يخمن أحد عشر. سيبدو واثقًا تمامًا من نفسه، ومع ذلك سيكون مخطئًا. اطلب من النموذج نفسه حساب الفائدة المركبة على قرض، أو جمع رقمين كبيرين، أو حساب أيام العمل بين تاريخين، وغالبًا ما ستحصل على إجابة تبدو منطقية ولكن بأرقام غير دقيقة بشكل طفيف وخطير.
يحدث هذا لأن النماذج اللغوية الكبيرة لا تستنتج الأرقام بالطريقة التي يفعلها البشر، بل تتنبأ بالوحدات النصية (tokens). قد تكون الوحدة النصية كلمة كاملة، أو جزءًا من كلمة، أو رقمًا واحدًا. عندما يرى النموذج كلمة “strawberry”، فإنه لا يرى ثمانية أحرف فردية مصطفة في صف واحد، بل يرى مجموعة من الكتل النصية. لم يتم تعليمه أبدًا كيفية عد الأحرف، بل فقط التنبؤ بالكتلة النصية التالية. ينطبق نفس القصور على الحساب؛ فالنموذج ليس لديه آلة حاسبة داخلية، ويفتقر إلى منطق الترحيل (carry logic)، ولا يملك فهمًا حقيقيًا للقيمة المنزلية. عندما يضرب 148 في 279، فهو لا يقوم بعملية الضرب، بل يقوم بمطابقة الأنماط مع تعبيرات مماثلة رآها أثناء التدريب، مخمنًا تسلسل الأرقام الذي يجب أن يتبعها. بالنسبة للمجاميع الصغيرة، يكون النمط قويًا بما يكفي ليعمل، ولكن بالنسبة لأي شيء يتطلب دقة حقيقية، فإن التخمين يفشل في النهاية.
وظيفتان، وروبوت واحد
تطلب طرق التلقين (prompting) القياسية من نظام واحد القيام بأمرين مختلفين تمامًا في وقت واحد: أولاً، فهم منطق المشكلة. ثانيًا، تنفيذ العملية الحسابية بدقة. النموذج مبهر حقًا في المهمة الأولى؛ إذ يمكنه قراءة مسألة لفظية، واستخراج المتغيرات، ورسم العلاقات، وتخطيط مسار الحل. ولكن بعد ذلك، يتعين عليه أن يعمل كآلة حاسبة خاصة به، وهنا تنهار السلسلة. فرقم واحد خاطئ في الخطوة الثالثة قد يفسد كل خطوة تليها. قد يكون المنطق نفسه مثاليًا، ومع ذلك تكون الإجابة النهائية خاطئة لأن النموذج أخطأ في الجمع.
تحل نماذج اللغة المعتمدة على البرمجة (Program-Aided Language Models، أو PAL) هذه المشكلة عن طريق تقسيم العمل. فبدلاً من طلب الإجابة من النموذج، تطلب منه كتابة برنامج.
إليك كيف يعمل التدفق فعليًا: أنت تقدم المشكلة، فيقوم النموذج باستنتاج المنطق، وتحديد المتغيرات، وهيكلة الخوارزمية. ثم، بدلاً من حساب النتيجة بنفسه، يكتب نصًا برمجيًا (script) قصيرًا، عادةً بلغة Python. يتم تسليم هذا النص إلى مفسر أكواد (code interpreter) حقيقي، والذي يقوم بتشغيل المنطق وإرجاع النتيجة الدقيقة والحتمية. النموذج يصف الرياضيات، وPython يقوم بالرياضيات.
الاستدلال القابل للتنفيذ في الممارسة العملية
فكر في PAL على أنه استدلال قابل للتنفيذ. إذا كان بإمكان نص برمجي حل مشكلة ما، فاجعل النموذج يكتب هذا النص.
لننظر في مثال ملموس. تحتاج إلى حساب مبلغ الاستحقاق لوديعة ثابتة بقيمة ₹50,000 بمعدل فائدة سنوي قدره 8.5 بالمائة، تُحسب مركبة ربع سنويًا، ولمدة سبع سنوات. إذا سألت نموذجًا لغويًا مباشرة، فقد يكتب معادلة، ويعوض بالقيم، ويحسب النتيجة عبر سلسلة من الأفكار. ولكن إذا نظرت عن كثب، فقد تجده قد أخطأ في حساب الفائدة المركبة ربع السنوية عن طريق قسمة المعدل بشكل غير صحيح، أو قام بتقريب خطوة وسيطة ونقل الخطأ إلى الخطوات التالية. تبدو الإجابة معقولة ولكنها تختلف بمئات الروبيات.
مع PAL، يتغير التفاعل. أنت توجه النموذج لإنشاء كود Python يحدد principal = 50000 و rate = 0.085 و time = 7 و n = 4 ، ثم يحسب amount = principal * (1 + rate/n) ** (n * time). يصدر النموذج الكود، وتقوم بيئة تشغيل Python بتنفيذه. تحصل على الرقم الدقيق، حتى آخر رقم عشري، في كل مرة. لا يوجد تخمين في عملية الضرب، ولا بقايا متخيلة، ولا أخطاء تقريب واثقة.
ينطبق هذا النمط نفسه على حساب التواريخ. اسأل النموذج عن التاريخ الذي يوافق تمامًا 120 يوم عمل من اليوم، باستثناء عطلات نهاية الأسبوع. قد يقوم النموذج النصي فقط بالعد للأمام ويخطئ في يوم سبت. أما نهج PAL فيجعل النموذج يكتب نصًا برمجيًا باستخدام منطق datetime و calendar ، ثم يترك المفسر يقوم بالتكرار بدقة. وتعمل معالجة البيانات بنفس الطريقة؛ فإذا كنت بحاجة إلى تحليل ملف CSV فوضوي، أو تصفية ملف JSON متداخل، أو إجراء تحويل إحصائي سريع، فيجب على النموذج صياغة المنطق بينما يتولى المفسر عملية التكرار.
لماذا يهم هذا حقًا
يوفر الانتقال من الإجابات النثرية إلى الكود القابل للتنفيذ ثلاث مزايا عملية.
الحتمية. قد يغير النموذج اللغوي صياغته أو يغير رقماً ما عند طرح نفس السؤال مرتين. بينما يعيد المفسر (interpreter) نفس المخرجات لنفس المدخلات في كل مرة. هذا الاستقرار أمر بالغ الأهمية في المحاسبة، والخدمات اللوجستية، والجدولة، وأي حسابات هندسية حيث لا يعد الاتساق أمراً اختيارياً.
القابلية للتحقق. عندما يقدم لك النموذج ثلاث فقرات من الاستنتاج، يجب عليك قراءة كل جملة للبحث عن الرقم الواحد الخاطئ. أما عندما يقدم لك نصاً برمجياً (script) مكوناً من عشرة أسطر، فيمكنك مراجعة الكود. يمكنك التحقق من صحة معادلة الفائدة المركبة قبل أن يقوم المفسر بتشغيلها. يمكنك فحص أسماء المتغيرات، ورصد أخطاء "الزيادة أو النقص بمقدار واحد" (off-by-one errors)، وحتى استخدام نظام التحكم في الإصدارات (version-control) للحل. وبذلك تتقلص مساحة الأخطاء الخفية بشكل كبير.
الموثوقية. يلتزم النموذج بنطاق عمله؛ فهو يقوم بما صُمم لأجله: الاستنتاج حول البنية، والدلالات (semantics)، وتفكيك المشكلات. وتقوم الآلة بما صُممت لأجله: الحساب بدقة. هذا "الفصل بين المهام" (separation of concerns) هو بالضبط الطريقة التي تُبنى بها البرمجيات الموثوقة. فالتركيب (Composition) يتفوق على التصميم المتجانس (monolithic design).
قم بتشغيله ككود غير موثوق
لا بد من توجيه كلمة تحذير؛ إذ يجب التعامل مع الكود المُنشأ كمدخلات غير موثوقة. قد يكتب النموذج نصاً برمجياً يحتوي على حلقة مفرغة (infinite loop)، أو طلباً غير ضروري للشبكة، أو عملية على نظام الملفات لم تطلبها. قم دائماً بتنفيذ هذه البرامج داخل بيئة معزولة (sandbox). استخدم الحاويات (containers) ذات الصلاحيات المقيدة، أو الوظائف عديمة الخادم (serverless functions) التي لا تملك وصولاً للشبكة، أو بيئات محكومة بدقة مع وقت محدود للمعالج (CPU) وبدون تخزين دائم. الأمن ليس مجرد ملاحظة هامشية هنا، بل هو جزء من تصميم النظام.
أين يتألق PAL، وأين يتوقف
يعمل PAL بشكل رائع في الرياضيات، والتواريخ، ومعالجة البيانات المهيكلة. فهو يزيل الأخطاء الميكانيكية التي تعيب الاستنتاج النصي فقط.
ومع ذلك، فهو لا يصلح المنطق السيئ. فإذا اختار النموذج المعادلة الخاطئة،