مسألة التمثيل: نحو توليد الأكواد المجردة القائمة على الرسوم البيانية

المعلومات الأساسية

• معرّف الورقة: 2510.13163
• العنوان: A Matter of Representation: Towards Graph-Based Abstract Code Generation
• المؤلفون: Nyx Iskandar (جامعة بيركلي)، Hisham Bedri (Ramen VR)، Andy Tsen (Ramen VR)
• التصنيف: cs.CL (اللسانيات الحسابية)
• المؤتمر: المؤتمر الـ 39 لأنظمة معالجة المعلومات العصبية (NeurIPS 2025) - ورشة عمل: التعلم العميق للأكواد
• رابط الورقة: https://arxiv.org/abs/2510.13163v1

الملخص

تتفوق نماذج اللغة الكبيرة (LLMs) الحالية في توليد الأكواد الخام والمتسلسلة، لكن هناك بحث قليل جداً حول توليد الأكواد المجردة القائمة على الرسوم البيانية. يقوم الكود المجرد القائم على الرسوم البيانية بتغليف المنطق المهم في عقد معرّفة مسبقاً، مع تحديد تدفق التنفيذ من خلال الحواف. يشيع هذا الشكل من الأكواد في لغات البرمجة البصرية، وهو مهم أيضاً عندما لا يكون الكود المصدري الخام متاحاً للمستخدمين ومجموعات بيانات تدريب LLMs. تقترح هذه الورقة وتقيّم طرق التمثيل بصيغة JSON للرسوم البيانية لتحقيق توليد دقيق للأكواد المجردة القائمة على الرسوم البيانية. يقيّم المؤلفون هذه الطرق على ScratchTest، وهي مجموعة معايير صغيرة تعتمد على إعادة تطبيق Scratch بلغة Python. تكتشف الدراسة أنه تحت التمثيل الصحيح للرسوم البيانية، يمكن لـ LLMs فعلاً إكمال المهمة المذكورة أعلاه في جيل واحد، دون الاعتماد على خطوط أنابيب متخصصة أو معقدة. تؤدي طرق التمثيل المختلفة إلى دقة مختلفة بشكل كبير، مما يبرز الدور الحاسم للتمثيل في مهمة التوليد هذه.

السياق البحثي والدافع

تعريف المشكلة

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

• لغات البرمجة البصرية: Scratch و Unreal Engine Blueprints و n8n وغيرها
• المكتبات والأطر عالية المستوى من التجريد: يتم تغليف تفاصيل التطبيق، ويمكن للمستخدمين فقط التعامل من خلال واجهات معرّفة مسبقاً

تحليل الأهمية

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

قيود الطرق الموجودة

• طرق توليد الرسوم البيانية: تركز GraphRNN و GraphGAN على توليد الرسوم البيانية العامة، وغير مناسبة للرسوم البيانية الوظيفية للأكواد
• نماذج الأساس القائمة على الرسوم البيانية (GFMs): تتمتع الطرق القائمة على GNN بقابلية توسع ضعيفة، والطرق القائمة على LLM تعتمد بشكل مفرط على لغة طبيعية هشة
• نماذج توليد الأكواد: موجهة بشكل أساسي للأكواد المتسلسلة، مع اختلاف كبير في قدرة الدعم لأنواع لغات وأطر مختلفة

المساهمات الأساسية

1. اقتراح طريقة تمثيل JSON للعقد: تمكّن LLMs الحالية من توليد رسوم بيانية أكواد بأعلى دقة نحوية ومنطقية
2. اقتراح طريقة تمثيل JSON لرسوم الأكواد البيانية: تعزز دقة إخراج تمثيل الرسوم البيانية من LLMs بشكل أكبر
3. بناء معيار ScratchTest: مجموعة معايير تعتمد على إعادة تطبيق Scratch بلغة Python، مخصصة لتقييم قدرة توليد الأكواد المجردة القائمة على الرسوم البيانية
4. التحقق من أهمية التمثيل: إثبات أنه تحت إطار عمل LLM أحادي الوكيل، يمكن للتمثيل الصحيح أن يعزز بشكل كبير دقة التوليد

شرح الطريقة

تعريف المهمة

• الإدخال: وصف باللغة الطبيعية للمتطلبات الوظيفية
• الإخراج: رسم بياني متصل يفي بالمتطلبات، يتضمن عقد معرّفة مسبقاً وعلاقات الاتصال بين الحواف
• القيود: يجب أن يكون الرسم البياني موجهاً بدون دورات (DAG)، مما يضمن تسلسل تنفيذ صحيح

تصميم معيار ScratchTest

خصائص المعيار

• عدد العقد: 53 كتلة Scratch مدمجة (من أصل 107 أجزاء قابلة للتطبيق في واجهة سطر الأوامر)
• أنواع العقد: الحركة والمظهر والصوت والأحداث والتحكم والاستشعار والعوامل والمتغيرات وغيرها (8 فئات)
• التطبيق المبسط: لا يتعامل مباشرة مع الكائنات، بل يقيّم الوظيفة من خلال سجلات السلوك
• استمرارية الحالة: الحفاظ على قاموس خصائص الكائن (الموضع والاتجاه وما إلى ذلك)

طريقة التقييم

• مجموعة الاختبار: 20 موجهة وصفية وظيفية فريدة
• عدد التقييمات: تشغيل مستقل 5 مرات لكل موجهة
• معايير التقييم: تقييم يدوي لسجلات السلوك وملفات Python من حيث الصحة المنطقية

تصميم طرق التمثيل

تمثيل العقدة المرجعية

[NODENAME]: {
    inPorts: [{id: string, type: string}],
    fields: [{id: string, type: string}],
    outPorts: [{id: string, type: string}]
}

المكونات الرئيسية:

• NODENAME: يتوافق مع اسم كتلة Scratch
• inPorts: منافذ الإدخال، بما في ذلك المعاملات ومنافذ EXEC (تدفق التنفيذ)
• fields: معاملات الخيارات المعرّفة مسبقاً
• outPorts: منافذ الإخراج، بما في ذلك القيم المرجعة ومنافذ THEN (التنفيذ اللاحق) ومنافذ SUBSTACK (الحلقات/التحكم)
• type: نوع المنفذ، لمنع الاتصالات غير المتوافقة

تمثيل الرسم البياني للإخراج

{
    nodes: {
        [key: string]: {
            name: string,
            value: any | null
        }
    },
    edges: [{
        outNodeID: string,
        outPortID: string,
        inNodeID: string,
        inPortID: string
    }]
}

مزايا التصميم:

• فصل الاهتمامات: تُعرّف العقد والحواف بشكل منفصل، مما يقلل الأخطاء
• التوليد الخطي: تعريف العقد أولاً، ثم تعريف العلاقات
• تجنب التكرار: يتم تعريف كل حافة مرة واحدة فقط

عملية المعالجة اللاحقة

1. الترتيب الطوبولوجي: ضمان خاصية الرسم البياني الموجه بدون دورات
2. التحويل إلى Python: تحويل تمثيل الرسم البياني إلى تطبيق Scratch متوافق مع Python
3. إنشاء الكائنات: إنشاء كائنات كتل Scratch وربط المتغيرات
4. إنشاء الاتصالات: إنشاء تدفق التنفيذ بناءً على منافذ THEN و EXEC

إعداد التجربة

مجموعة البيانات

• ScratchTest: 20 موجهة وصفية وظيفية
• موجهات مثالية:
  • "عند النقر على العلم الأخضر، تحرك بشكل مستمر في نمط مربع حتى يضغط المستخدم على مفتاح المسافة"
  • "عند الضغط على مفتاح 's'، قل كلمة مرور سرية تتكون من حرفين عشوائيين وثلاثة أرقام عشوائية"

مؤشرات التقييم

• الدقة: نسبة الوظائف المنفذة بشكل صحيح
• معايير التقييم:
  • إخراج سجل سلوك معقول
  • ملف Python منطقي صحيح
  • بدون أخطاء معالجة لاحقة أو تنفيذ

طرق المقارنة

استبدال تمثيل العقدة المرجعية

1. بدون أنواع: الخط الأساسي الأدنى مع إزالة معلومات نوع المنفذ
2. وصف إضافي: إضافة وصف باللغة الطبيعية للعقد والمنافذ
3. المقترح: تمثيل كامل مقترح

استبدال تمثيل الرسم البياني للإخراج

1. بديل: تمثيل بديل مع معلومات الحواف المدمجة في العقد
2. المقترح: تمثيل مقترح يفصل بين العقد والحواف

تفاصيل التطبيق

• النموذج الرئيسي: OpenAI gpt-oss-120b (منصة Groq)
• نماذج أخرى: qwen3-32b و deepseek-r1-distill-llama-70b و llama-3.3-70b-versatile
• الإعدادات: Temperature=1، Max Tokens=8192، Top P=1
• الإطار: أحادي الوكيل، بدون ضبط دقيق، بدون تعلم سياقي، بدون تفاعل متعدد الجولات

نتائج التجربة

النتائج الرئيسية

نتائج استبدال تمثيل العقدة المرجعية

الدلالة الإحصائية:

• المقترح مقابل بدون أنواع: p=0.036 ≤ 0.05 (دال إحصائياً)
• المقترح مقابل وصف إضافي: p=0.82 > 0.05 (غير دال إحصائياً)

نتائج استبدال تمثيل الرسم البياني للإخراج

الدلالة الإحصائية: p=0.000024 ≤ 0.05، تحسن المقترح بنسبة 23-29% مقابل البديل

النتائج الرئيسية

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

أنواع الأخطاء الشائعة

1. DAG غير صحيح: توليد رسم بياني يحتوي على دورات
2. مراجع متغيرات غير معلنة: الإشارة إلى متغيرات غير معرّفة
3. أخطاء اتصال المنافذ: توصيل منافذ من نفس الاتجاه أو نسيان تعريف المنافذ

أداء النماذج الأخرى

تُظهر النماذج الثلاثة الأخرى (qwen3-32b و deepseek-r1-distill-llama-70b و llama-3.3-70b-versatile) أداءً أقل بكثير من gpt-oss-120b، مع دقة أقل وأخطاء أعلى في معظم الحالات.

الأعمال ذات الصلة

فهم وتوليد الرسوم البيانية

• توليد الرسوم البيانية العامة: يركز GraphRNN و GraphGAN على تعلم توزيع الرسوم البيانية، غير مناسب للرسوم البيانية الوظيفية للأكواد
• نماذج الأساس القائمة على الرسوم البيانية: تتمتع الطرق القائمة على GNN بقابلية توسع ضعيفة، والطرق القائمة على LLM تعتمد على لغة طبيعية هشة
• فهم الرسوم البيانية بواسطة LLM: يركز البحث الموجود بشكل أساسي على فهم الرسوم البيانية الرياضية، وليس الرسوم البيانية المشفرة منطقياً

وكلاء LLM للأكواد

• قدرات توليد الأكواد: يتفوق LLMs الحالي في توليد الأكواد التقليدية
• طرق التحسين: التعلم المعزز والتفكير السلسلي والتدريب على الملء والفك المقيد وغيرها
• اختلافات الأداء: يوجد اختلاف كبير في قدرة التوليد لأنواع لغات وأطر مختلفة، يرجع بشكل أساسي إلى توفر بيانات التدريب

الخلاصة والمناقشة

الاستنتاجات الرئيسية

1. التحقق من الجدوى: يمكن لـ LLMs إكمال توليد الأكواد المجردة القائمة على الرسوم البيانية في جيل واحد
2. الدور الحاسم للتمثيل: التمثيل الصحيح بصيغة JSON حاسم لدقة التوليد
3. مبادئ التصميم: معلومات النوع وفصل الاهتمامات وتدفق التوليد الخطي هي عناصر رئيسية للتمثيل الفعال
4. إنشاء المعيار: يوفر ScratchTest معيار تقييم لتوليد الأكواد البصرية

القيود

1. حد الدقة: حتى مع أفضل تمثيل، لم يتم الوصول إلى دقة 100%
2. الاعتماد على النموذج: الأداء تعتمد بشكل كبير على قدرات LLM المحددة
3. حد الحجم: التحقق الحالي فقط في مجال Scratch نسبياً بسيط
4. طريقة التقييم: تعتمد على التقييم اليدوي، تفتقر إلى معايير التقييم الآلي

الاتجاهات المستقبلية

1. تحسين التمثيل: استكشاف طرق تمثيل أفضل غير JSON
2. نماذج متخصصة: تطوير نماذج توليد متخصصة لمساحة رسوم الأكواد البيانية
3. إطار عمل متعدد الوكلاء: دمج التخطيط وتصحيح الأخطاء في طرق متعددة الجولات
4. التحقق على نطاق واسع: التحقق في بيئات برمجة بصرية أكثر تعقيداً

التقييم المتعمق

المزايا

1. جدة المشكلة: أول دراسة منهجية لمشكلة توليد الأكواد المجردة القائمة على الرسوم البيانية
2. بساطة الطريقة: طريقة تمثيل JSON المقترحة بسيطة وفعالة وسهلة التطبيق والتوسع
3. صرامة التجربة: ضمان موثوقية النتائج من خلال عمليات تشغيل متعددة واختبارات إحصائية
4. القيمة العملية: توفير أساس للتطوير المساعد بواسطة الذكاء الاصطناعي للغات البرمجة البصرية

أوجه القصور

1. قيود التقييم: طريقة التقييم اليدوي غير موضوعية بما يكفي، يصعب تطبيقها على نطاق واسع
2. حجم المعيار: 20 حالة اختبار نسبياً قليلة، قد لا تكون شاملة بما يكفي
3. تغطية النموذج: النتائج تعتمد بشكل أساسي على نموذج واحد، أداء النماذج الأخرى أضعف
4. التحليل النظري: نقص التحليل النظري المتعمق حول سبب فعالية بعض التمثيلات

التأثير

1. مساهمة رائدة: إنشاء خط أساس بحثي لتوليد الأكواد البصرية
2. التطبيق العملي: يمكن تطبيقه مباشرة على أدوات مثل Scratch
3. قابلية التوسع: يمكن توسيع الطريقة إلى بيئات برمجة بصرية أخرى
4. الدلالة الإرشادية: تؤكد على أهمية تعلم التمثيل في توليد الأكواد

السيناريوهات المطبقة

1. مجال التعليم: مساعدة أدوات التدريس مثل Scratch في توليد الأكواد
2. النماذج الأولية السريعة: أتمتة أنظمة المخططات في تطوير الألعاب
3. أتمتة سير العمل: تكوين ذكي للأدوات مثل n8n
4. تكيف المكتبات الجديدة: توليد أكواد للأطر الجديدة التي تفتقر إلى بيانات التدريب

المراجع

تستشهد الورقة بـ 54 مرجعاً ذا صلة، تغطي توليد أكواد LLM والشبكات العصبية الرسومية ولغات البرمجة البصرية وغيرها من المجالات المهمة، مما يوفر أساساً نظرياً قوياً للبحث.

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