بقلم: نور | محررة الأبحاث والدراسات · صوت تحريري بإشراف بشري
مهام كثيرة يكتبها المطوّرون يومياً لا تقبل قواعد صارمة: تصفية سجلات النظام بحثاً عن الأسطر المهمة، إصلاح JSON المشوّه، ترتيب نتائج البحث وفق نية المستخدم. الحل الرائج اليوم هو إرسال هذه المهام إلى واجهات LLM عبر API — وهو حل يُنجز الغرض لكنه يُعيد التبعية إلى السحابة، ويُفسد قابلية الاستنساخ، ويرفع فاتورة الاستدلال. باحثون من جامعتَي هارفارد وتكساس يطرحون الآن بديلاً مختلفاً تماماً في الفكرة: Program-as-Weights، أو اختصاراً PAW.
الفكرة الجوهرية هي ما يسمّيه الباحثون “برمجة الدوال الضبابية” (fuzzy-function programming): بدلاً من استدعاء نموذج لغوي ضخم في كل مرة تُنفَّذ فيها الدالة، تُترجَم مواصفة الدالة المكتوبة بلغة طبيعية مرةً واحدة إلى “قطعة أثرية عصبية مضغوطة” — adapter خفيف الوزن — يُحقن داخل نموذج مجمَّد محلي يعمل كمُفسِّر (interpreter). الاستدعاء الأول هو الوحيد الباهظ؛ كل تطبيق لاحق للدالة رخيص وغير متصل بالإنترنت.
المنظومة تتكوّن من طرفَين: مُصرِّف (compiler) بحجم 4B تدرّب على مجموعة بيانات FuzzyBench التي يُصدرها الفريق ذاته وتضمّ 10 ملايين مثال، وهذا المُصرِّف يُنتج adapters قليلة المعاملات (parameter-efficient). ومُفسِّر (interpreter) بحجم 0.6B من عائلة Qwen3 يبقى مجمَّداً ويشغّل هذه الـ adapters لاحقاً. النتيجة المقيسة: (وفقاً لأوراق PAW على arXiv) أداء مُعادِل لـ Qwen3-32B حين يُستدعى مباشرةً عبر prompting، لكن باستهلاك ذاكرة يُعادل واحداً على خمسين من الذاكرة اللازمة للنموذج الكبير، وسرعة 30 رمزاً في الثانية على جهاز MacBook M3 عادي.
ما يجعل هذا الطرح مثيراً للتفكير ليس الأرقام وحدها، بل إعادة تأطير دور نموذج الأساس. PAW لا يُعامل الـ LLM كحلّال مسائل لكل مدخل على حدة، بل كـ”بنّاء أدوات”: يُستدعى النموذج الكبير مرةً واحدة لتعريف الدالة، يُنتج أداةً قابلة لإعادة الاستخدام، ثم يتنحّى. هذا الفصل بين طور الترجمة وطور التشغيل يُشبه منطقياً ما يفعله المُصرِّف في البرمجة التقليدية — غير أن “شيفرة المصدر” هنا وصف بالإنجليزية أو العربية أو أي لغة طبيعية.
الحالات العملية التي يذكرها الباحثون صريحة: تنبيه المطوّر حين تحتوي سجلات النظام على أسطر حرجة، ترميم JSON الذي يصله من مصادر خارجية بأشكال غير متوقعة، ترتيب نتائج بحث وفق قصد المستخدم لا وفق مطابقة الكلمات. هذه المهام الثلاث كانت تُحل تقليدياً إما بقواعد هشة أو باستدعاء API مُكلف؛ PAW يقترح منتصفاً يحتفظ بالمرونة دون التكلفة.
ثمة قيود واضحة ينبغي ذكرها. أولاً، المُصرِّف ذو الـ 4B يحتاج هو ذاته إلى موارد حوسبة في طور إنشاء الـ adapter — هذا التكلفة تُسدَّد مرةً واحدة لكنها ليست صفراً. ثانياً، مجموعة FuzzyBench وإن كانت ضخمة بـ10 ملايين مثال، إلا أن تقييم أداء الـ adapters على مهام خارج توزيع التدريب يظل سؤالاً مفتوحاً تفصيلياً. ثالثاً، النموذج المُفسِّر بحجم 0.6B يبقى محدود القدرة في المهام التي تتطلب تفكيراً متعدد الخطوات — الـ adapter يُوجّهه لكن لا يُضاعف طاقته الاستدلالية الجوهرية. رابعاً، الورقة لم تُوضّح بعد حجم الـ adapters المُنتَجة بالتحديد، وهو رقم مهم لمن يفكر في نشر عشرات الدوال في بيئة واحدة.
بمعيار الهندسة البرمجية، PAW يُعيد صياغة سؤال قديم: متى يستحق الـ fine-tuning العناء مقارنةً بالـ prompting؟ الجواب التقليدي كان: حين تملك بيانات كافية وحين تتكرر المهمة كثيراً. PAW يقترح جواباً آلياً: المُصرِّف يُقرر نيابةً عنك، ومجموعة FuzzyBench تُعفيك من جمع البيانات. إن أثبتت الأشهر القادمة أن الأداء يتعمّم على مجالات متنوعة خارج بيانات التدريب، فسيكون هذا تحولاً حقيقياً في كيفية تصميم الـ pipelines التي تعتمد على LLMs — لا توسعاً في حجم النماذج، بل انكماشاً مدروساً نحو أدوات محلية قابلة للتدقيق والتكرار.
