Habr يشرح كيف تجعل نماذج LLM تحسب دون أخطاء عبر توليد شيفرة Python

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

لماذا تخطئ نماذج LLM

المشكلة ليست في أن روبوت دردشة معينًا «تدهور». فالمحوّل (Transformer) يتنبأ بالرمز (token) التالي بناءً على الاحتمالات، ولا يستدعي آلة حاسبة. لذلك قد يقدّم النموذج، عند الضرب أو إعادة حساب مقادير وصفة أو احتساب فواتير الخدمات، إجابة تبدو مقنعة لكنها تختلف عن الصحيحة بنسبة تصل إلى عدة بالمئة أو حتى إلى عشرات بالمئة. يبدو ذلك للمستخدم تراجعًا في الأداء، لكنه في الواقع قيد جوهري في البنية: يجيد LLM محاكاة نمط الحساب، لكنه لا ينفّذ العملية نفسها.

«النموذج لا يحسب. النموذج يبرمج. والبرنامج هو الذي يحسب.»

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

كيف يعمل المخطط

يقوم المخطط العملي على فصل الأدوار. يرسل المستخدم المهمة عبر تطبيق مراسلة، ويتلقى LLM موجّهًا نظاميًا (system prompt) يتضمن السياق والبيانات اللازمة، ثم يولّد شيفرة Python. تُشغَّل هذه الشيفرة داخل بيئة Docker معزولة، وفي النهاية تعيد الخدمة نصًا مفصّلًا بحسب البنود، إضافة إلى ملف Excel جاهز. في هذا السيناريو يتولى النموذج فهم الطلب وبناء بنية البرنامج، بينما تُترك دقة الحساب كليًا لمفسّر Python.

• قد تكون المدخلات قراءات عدادات أو جدولًا أو تقدير تكاليف
• تُمرَّر التعرفات والمراجع إلى الموجّه من ملف الإعدادات
• يجب على النموذج أن يعيد شيفرة Python تحديدًا، لا إجابة جاهزة
• يُنفَّذ السكربت في حاوية معزولة مع مهلة زمنية
• يحصل المستخدم في النهاية على حساب نصي وملف Excel

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

أين كانت العقبات

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

المشكلة الثانية أن بعض النماذج تحاول، حتى بعد التعليمات، أن «تحسب في الذهن» وتقدّم إجابة جاهزة. والحل بسيط: التحقق من وجود شيفرة Python في الرد، وإرسال طلب ثانٍ بصياغة صارمة عند الحاجة. وظهرت عمليًا مشكلات تقنية أكثر: فقد تعطّل عرض الأحرف الكيريلية في Excel دون تحديد UTF-8 صراحةً، وكان النموذج يستدعي مكتبات زائدة مثل pandas، ولم يكن قادرًا على تصحيح أخطائه بعد انهيار السكربت ما لم يتلقَّ stderr كاملًا. ولكن حين بدأت الخدمة تعيد traceback إلى النموذج، انخفض عدد التكرارات غير المجدية، بحسب المؤلف، خمسة أضعاف. وطُبّق النهج نفسه على مهمة أكثر تعقيدًا، هي تحليل تقديرات أعمال الترميم، حيث أظهر أحد الاختبارات مبالغة قدرها 54 168 روبلًا، وثمانية بنود أغلى من السوق بأكثر من 50%.

ماذا يعني ذلك

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