💬 NLP

StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs

يقدم البحث StructEval، وهو معيار شامل يضم 18 تنسيقاً و44 نوعاً من المهام التي تقيم قدرة النماذج اللغوية الكبيرة على توليد وتحويل المخرجات المهيكلة غير القابلة للعرض والقابلة للعرض على حد سواء، مما يكشف عن فجوات كبيرة في الأداء حيث تعاني حتى النماذج الأكثر تطوراً من دقة الهيكلية، لا سيما في مهام التوليد والمحتوى المرئي.

المؤلفون الأصليون: Jialin Yang, Dongfu Jiang, Lipeng He, Sherman Siu, Yuxuan Zhang, Disen Liao, Zhuofeng Li, Huaye Zeng, Yiming Jia, Haozhe Wang, Benjamin Schneider, Chi Ruan, Wentao Ma, Zhiheng Lyu, Yifei Wang, Yi Lu

نُشر 2026-04-06

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Jialin Yang, Dongfu Jiang, Lipeng He, Sherman Siu, Yuxuan Zhang, Disen Liao, Zhuofeng Li, Huaye Zeng, Yiming Jia, Haozhe Wang, Benjamin Schneider, Chi Ruan, Wentao Ma, Zhiheng Lyu, Yifei Wang, Yi Lu, Quy Duc Do, Ziyan Jiang, Ping Nie, Wenhu Chen

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك تقوم بتوظيف طباخ موهوب للغاية وسريع جداً (نموذج لغوي كبير، أو LLM) لمساعدتك في إدارة مطعم.

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

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

هذا هو بالضبط ما يدور حوله بحث StructEval. إنه اختبار جديد وصعب لمعرفة ما إذا كان بإمكان هؤلاء الطهاة الآليين بناء أشياء مهيكلة بالفعل، وليس مجرد التحدث عنها.

إليك تفصيل اختبارهم الجديد، مشروحاً ببعض استعارات المطبخ:

1. نوعا "الطهي"

أدرك الباحثون أن "البناء" يأتي بنوعين، لذا قسموا الاختبار إلى قسمين:

"منظم المخزن" (نص فقط):
تخيل أن الطباخ يحتاج إلى تنظيم جدول بيانات للمكونات. يجب عليه التأكد من أن البيانات في تنسيق صارم مثل JSON (خزانة ملفات رقمية)، أو YAML (قائمة تعليمات)، أو CSV (قائمة تسوق).
- الاختبار: "إليك قائمة فوضوية بالمكونات. يرجى وضعها في ملف JSON مثالي."
- لماذا يهم هذا: إذا كان الملف معطلاً ولو قليلاً، فإن البرنامج الحاسوبي الذي يحاول قراءته سينهار.
"المهندس المعماري" (الرسم المرئي):
الآن، تخيل أن الطباخ يحتاج إلى بناء واجهة عرض أو موقع إلكتروني. يجب عليه كتابة كود لـ HTML (هيكل صفحة الويب)، أو React (أزرار تفاعلية)، أو SVG (فن رقمي).
- الاختبار: "إليك وصف لبرنامج رحلة سياحية. يرجى بناء صفحة ويب تعرض هذه الرحلة، مع عنوان كبير، وجدول مكون من 3 صفوف، وزر في الأسفل."
- لماذا يهم هذا: يجب ألا يبدو الكود صحيحاً على الورق فحسب، بل يجب أن يعمل فعلياً عند فتحه في المتصفح.

2. الطريقتان لخوض الاختبار

قدم البحث طريقتين مختلفتين لتحدي الذكاء الاصطناعي:

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

3. كيف قاموا بتقييم الطهاة؟

في الماضي، كان البشر يقرؤون المخرجات ويقولون "تبدو جيدة!"، لكن ذلك ذاتي للغاية. يستخدم StructEval "حكماً آلياً" بأدوات ثلاث محددة:

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

4. النتائج الصادمة

اختبر الباحثون أفضل الطهاة (أفضل نماذج الذكاء الاصطناعي المتاحة اليوم، مثل GPT-4o، وo1-mini، والنماذج مفتوحة المصدر مثل Llama). إليكم ما وجدوه:

الفجوة حقيقية: حتى "الطهاة النجوم" (الأكثر تكلفة، وهي النماذج التجارية) حصلوا فقط على حوالي 75 من 100. إنهم جيدون، لكنهم بعيدون عن المثالية.
معاناة المصادر المفتوحة: النماذج المجانية المبنية من المجتمع (مثل Llama) سجلت حوالي 10 نقاط أقل من العمالقة المدفوعين. إنهم يقتربون من ذلك، لكنهم لا يزالون يتعثرون في القواعد المعقدة.
الأمر أصعب مما يبدو:
- الترجمة أسهل من الابتكار: من الأسهل للذكاء الاصطناعي تحويل ملف JSON إلى ملف YAML من ابتكار ملف JSON من فقرة نصية.
- المرئيات هي الأصعب: جعل صفحة ويب تبدو صحيحة أصعب بكثير من مجرد كتابة قائمة نصية. غالباً ما ينسى الذكاء الاصطناعي توسيط النص أو يفتقد زراً معيناً.
- "كابوس التخصص": نماذج الذكاء الاصطناعي بارعة في الأشياء الشائعة مثل HTML أو JSON. ولكن إذا طلبت منهم صنع مخطط باستخدام Mermaid أو ملف تنسيق TikZ (تنسيقات متخصصة)، فإنهم غالباً ما يفشلون فشلاً ذريعاً، حيث يسجلون أقل من 50%.

الخلاصة الكبرى

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

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

StructEval هو الأداة التي نحتاجها لإصلاح ذلك. إنه ميدان تدريب صارم لتعليم هذه الأنظمة أن في العالم الحقيقي، الهيكل يهم بقدر ما تهم الأسلوب. فإذا كان التنسيق خاطئاً، سيتعطل التطبيق بأكمله.

إليك ملخص تقني مفصل لورقة البحث "StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs".

1. بيان المشكلة

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

الفجوة: تركز الاختبارات المرجعية الحالية بشكل أساسي على الجودة الدلالية أو الاستنتاج (مثل MMLU، GSM8K) أو توليد الأكواد البرمجية المتخصص. وهي تفتقر إلى تقييم شامل عبر تنسيقات هيكلية متنوعة (سواء كانت غير قابلة للعرض مثل JSON/YAML أو قابلة للعرض مثل HTML/SVG).
التحدي: يتطلب توليد المخرجات الهيكلية ليس فقط التماسك الدلالي، بل أيضاً الالتزام الصارم بالقواعد النحوية، والمخططات الهرمية، والدقة البصرية. فالأخطاء في التنسيق يمكن أن تؤدي إلى فشل في التحليل (parsing)، أو تعطل خطوط الأنابيب، أو واجهات مستخدم غير صالحة للعمل.
القيود الحالية: تعتمد العديد من الاختبارات المرجعية السابقة على التحقق اليدوي، وتفتقر إلى مقاييس موحدة للمخرات النصية مقابل المخرات البصرية، أو تغطي مجموعة ضيقة فقط من التنسيقات، مما يترك أداء النماذج الحديثة (SOTA) في المهام الهيكلية المعقدة غير معروف إلى حد كبير.

2. المنهجية: إطار عمل StructEval

قدم المؤلفون StructEval، وهو اختبار مرجعي شامل مصمم لتقييم النماذج اللغوية الكبيرة بشكل منهجي عبر 18 تنسيقاً مختلفاً و 44 نوعاً من المهام.

أ. بناء مجموعة البيانات

تتكون مجموعة البيانات من 2,035 مثالاً منظمة في مجموعتين متكاملتين:

StructEval-T (النص فقط): تقيم توليد وتحويل التنسيقات غير القابلة للعرض (مثل JSON، XML، YAML، CSV، TOML، Markdown).
StructEval-V (البصري): تقيم توليد وتحويل الأكواد البرمجية القابلة للتنفيذ التي تُعرض بصرياً (مثل HTML، React، SVG، Mermaid، Matplotlib، LaTeX، TikZ، Vue، Angular).

أنواع المهام:

التوليد (Generation): تحويل المطالبات باللغة الطبيعية إلى مخرات هيكلية.
التحويل (Conversion): الترجمة بين تنسيقين هيكليين (على سبيل المثال، JSON $\to$ YAML، HTML $\to$ React).

خط أنابيب التوسيم (Annotation Pipeline):
لضمان الجودة العالية والقابلية للتوسع، استخدم المؤلفون خط أنابيب مكوناً من ثلاث مراحل:

تنسيق المهام: تحديد 44 نوعاً فريداً من المهام تغطي 18 تنسيقاً.
التخليق القائم على النماذج اللغوية (LLM-based Synthesis): استخدام النماذج اللغوية لتوليد أمثلة مرشحة أولية (الاستعلامات والمقاييس) لتقليل الجهد اليدوي.
المراجعة الخبيرة: عملية مراجعة بشرية من مرحلتين باستخدام LabelStudio للتحقق من وضوح المهمة، واكتمالها، وصحة المقاييس.

ب. مقاييس التقييم

يقدم StructEval إطار تقييم آلياً مبتكراً يجمع بين ثلاثة مقاييس أساسية:

درجة النحو (Syntax Score - $s_s$ ): تتحقق من الصلاحية الهيكلية.
- النص: يتم تحليلها باستخدام أدوات تحليل (parsers) خاصة بالتنسيق (مثل json.loads في Python).
- البصري: يتم عرضها باستخدام محركات بدون واجهة رسومية (headless engines) للتحقق من نجاح التنفيذ.
- الدرجة: 1 إذا كانت صالحة/ناجحة، و0 خلاف ذلك.
درجة مطابقة الكلمات المفتاحية (Keyword Matching Score - $s_k$ ): تقيم الدقة الهيكلية باستخدام مراجع المسار النقطي (dot-path references).
- تتحقق من وجود مفاتيح محددة، حقول متداخلة، فهارس القوائم، والسمات (مثل planet.moons[0].name).
- تدعم قواعد معقدة تشمل الرموز العامة (wildcards)، وعناوين CSV، وسمات XML.
درجة الإجابة على الأسئلة البصرية (VQA Score - $s_v$ ): حصرية لـ StructEval-V.
- تستخدم نموذج لغة رؤية (VLM، وتحديداً GPT-4.1-mini) للإجابة على أسئلة حول الصورة المعروضة (على سبيل المثال، "ما هو النص الموجود في الترويسة؟").
- تضمن مطابقة المخرج البصري للمتطلبات الدلالية.

التسجيل النهائي:
الدرجة النهائية هي مزيج مرجح من هذه المقاييس:

المهام النصية: $s = 0.2 \cdot s_s + 0.8 \cdot s_k$
المهام البصرية: $s = 0.2 \cdot s_s + 0.1 \cdot s_k + 0.7 \cdot s_v$

3. المساهمات الرئيسية

اختبار مرجعي شامل: أول اختبار مرجعي يغطي 18 تنسيقاً متنوعاً (سواء كانت برمجية أو غير برمجية) و44 نوعاً من المهام، مما يسد الفجوة بين التوليد الهيكلي النصي والبصري.
إطار تقييم موحد: نظام مقاييس مبتكر يوحد التحليل النحوي، ومطابقة الكلمات المفتاحية القائمة على المسار، وVQA القائم على الرؤية في خط تسلسل تسجيل واحد.
مجموعة بيانات عالية الجودة: مجموعة بيانات منسقة بدقة تضم 2,035 مثالاً مع أزواج VQA تم التحقق منها بشرياً (معدل عدالة 88.92%) وتعريفات كلمات مفتاحية قوية.
تحليل منهجي: دراسة تجريبية مفصلة تكشف عن فجوات الأداء بين النماذج التجارية ومفتوحة المصدر، وبين مهام التوليد مقابل مهام التحويل.

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

قام المؤلفون بتقييم 12 نموذجاً (6 مفتوحة المصدر، 6 تجارية) في إعداد الصفر (zero-shot).

الأداء العام:
- أداء النماذج الرائدة (SOTA): حتى أفضل نموذج تجاري، GPT-4o، حقق متوسط درجة قدره 76.02%.
- فجوة المصادر المفتوحة: أفضل نموذج مفتوح المصدر، Qwen3-4B، سجل 67.04%، متأخراً عن النماذج التجارية بنحو 9 نقاط.
- أفضل مؤدٍ: نموذج o1-mini (من OpenAI) سجل 75.58%، مما أظهر قدرات استنتاج قوية ولكنه لا يزال يتخلف عن GPT-4o.
تحليل صعوبة المهام:
- التوليد مقابل التحويل: تؤدي النماذج عموماً بشكل أفضل في مهام التحويل مقارنة بمهام التوليد. ومع ذلك، تتفوق النماذج التجارية في التوليد في StructEval-T، بينما تتفوق النماذج مفتوحة المصدر أحياناً في التحويل.
- البصري مقابل النصي: توليد كود للـ عرض البصري (StructEval-V) أصعب بكثير من توليد الهياكل النصية فقط.
- خصوصية التنسيقات:
  - سهل: النص $\to$ Markdown، النص $\to$ HTML، YAML $\to$ JSON (الدرجات > 90%).
  - صعب: النص $\to$ Mermaid، النص $\to$ SVG، Matplotlib $\to$ TikZ (الدرجات < 50% للعديد من النماذج).
التفاوت بين النماذج:
- أدى نموذج Phi-3-mini أداءً ضعيفاً (متوسط 40.79%)، وفشل بشكل خاص في التحويلات الهيكلية (مثل TOML $\to$ YAML) بسبب الوسوم المشوهة والعلاقات الهرمية المفقودة.
- التجارية مقابل مفتوحة المصدر: الفجوة في الأداء تتسع في مهام توليد StructEval-T (خاصة TOML)، مما يشير إلى أن النماذج التجارية لديها تدريب متفوق على الالتزام بالمخططات المعقدة.

5. الأهمية والتوجهات المستقبلية

الأثر في العالم الحقيقي: يسلط StructEval الضوء على أنه بينما تتمتع النماذج اللغوية بالطلاقة، إلا أنها ليست موثوقة بعد لإنتاج المخرات الهيكلية القابلة للاستخدام في الإنتاج، وهو أمر ضريد لواجهات برمجة التطبيقات (APIs)، وخطوط أنابيب البيانات، وتوليد واجهات المستخدم.
الاتجاه البحثي: تشير النتائج إلى أن النماذج المستقبلية تحتاج إلى التحسين في الاستنتاج الهيكلي والالتزام بالمخططات (schema adherence)، وليس فقط الطلاقة الدلالية.
القيود: يركز الاختبار المرجعي الحالي على العرض الثابت غير التفاعلي. يجب أن يمتد العمل المستقبلي ليشمل السلوكيات الديناميكية (الرسوم المتحركة، التفاعلات) ويتضمن عمليات تدقيق أوسع للتحيز في إنشاء مجموعة البيانات.

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