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

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

لماذا تخطئ نماذج اللغة الكبيرة

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

"النموذج لا يحسب. النموذج يبرمج. والبرنامج يحسب."

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

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

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

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

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

أين ظهرت المشاكل

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

المشكلة الثانية: بعض النماذج تحاول حتى بعد التعليمات "الحساب عقلياً" وتقديم إجابة جاهزة. الحل بسيط: التحقق من وجود كود Python وإذا لزم الأمر، إرسال طلب متابعة بصيغة صارمة. في الممارسة العملية، ظهرت مشاكل أكثر تقنية: كانت السيريليكية في Excel تنكسر دون UTF-8 صريح، كان النموذج يسحب مكتبات غير ضرورية مثل pandas، وبدون stderr الكامل لم يستطع إصلاح أخطاؤه الخاصة بعد فشل البرنامج النصي.

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

ماذا يعني هذا

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