Self-Healing JSON Generation in Small Language Models: A Systematic Evaluation of Syntax Repair, Schema Coercion, and Validator Feedback
تقدم هذه الورقة إطار عمل للشفاء الذاتي لنماذج اللغات الصغيرة يجمع بين إصلاح البنية النحوية، والتحويل الموجه بالمخطط، وتغذية المصحح الراجعة لتحسين صلاحية تنسيق JSON بشكل كبير من 16.7% إلى 78.1% دون تعديل أوزان النموذج، مع الكشف عن أن مثل هذه التصحيحات النحوية لا تضمن الدقة الدلالية.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلف ولم يصادق عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل عالماً تستطيع فيه الحواسيب قراءة ملاحظة مكتوبة بخط اليد بشكل فوضوي، أو بريد إلكتروني مبعثر، أو قصة مروية، لتستخرج منها فوراً الحقائق الرئيسية وتملأ بها نموذجاً منظماً وأنيقاً. هذا هو الوعد الذي يقدمه تحويل اللغة الحرة إلى بيانات مهيكلة، وهي مهمة تدعم كل شيء من التقويمات الرقمية إلى أنظمة المخزون. وللقيام بذلك، غالباً ما تستخدم الحواسيب نسخاً صغيرة وفعالة من الذكاء الاصطناعي يمكنها العمل على الأجهزة العادية دون الحاجة إلى خوادم ضخمة. هذه النماذج الصغيرة رخيصة وتحافظ على الخصوصية، لكن بها عيباً: عندما يُطلب منها كتابة إجاباتها بتنسيق صارم يسمى (JSON)، فإنها غالباً ما ترتكب أخطاء. قد تنسى فاصلة، أو تغلف الإجابة برموز إضافية، أو تخترع رقم هاتف لا وجود له. وإذا حاول برنامج حاسوبي قراءة هذه الإجابة المعطلة، فإنه يتوقف عن العمل (ينهار). لسنوات، كان الحل هو إجبار الحاسوب على التفكير بطريقة صارمة للغاية أثناء الكتابة، ولكن هذا أمر صعب الإعداد ويمكن أن يجعل الحاسوب أقل ذكاءً في بعض الأحيان. يسأل بحث جديد سؤالاً أبسط: ماذا لو تركنا الحاسوب يكتب إجابته بحرية، ثم قمنا بإصلاح الأخطاء بلطف لاحقاً؟
وضع الباحثون هدفهم لاختبار عملية مكونة من ثلاث خطوات تعمل بمثابة طاقم إصلاح لهذه الإجابات الرقمية. لقد أخذوا ثلاثة نماذج مختلفة من الذكاء الاصطناعي الصغير وطلبوا منها تحويل 120 وصفاً نصياً مختلفاً إلى سجلات مهيكلة، مثل تفاصيل الاتصال أو جداول المواعيد. كانت الخطوة الأولى لطاقم الإصلاح الخاص بهم هي "مصلح الصيغة" (syntax fixer). بحثت هذه الأداة في النص الخام وأزالت أخطاء التنسيق الشائعة، مثل علامات الاقتباس الزائدة أو الأقواس المفقودة، دون الحاجة إلى طلب التفكير مرة أخرى من الحاسوب. أما الخطوة الثانية فكانت "دليل المخطط" (schema guide). قامت هذه الأداة بالتحقق من المحتوى مقابل قواعد النموذج؛ فإذا كتب الحاسوب تاريخاً مثل "أكتوبر 8، 2025" بينما يتطلب النموذج "2025-10-08"، يقوم الدليل بتحويله. وإذا كتب الحاسوب "نعم" بدلاً من "true"، يقوم الدليل بتغييرها. ومن الأهمية بمكان أن هذه الخطوة لم تخترع معلومات جديدة أبداً، بل قامت فقط بإعادة تشكيل ما كان موجوداً بالفعل. أما الخطوة الثالثة فكانت "حلقة التغذية الراجعة" (feedback loop)؛ فإذا لم تكن الإجابة لا تزال تتوافق مع القواعد، يعرض النظام الأخطاء المحددة على الحاسوب ويطلب منه المحاولة مرة أخرى.
أظهرت النتتائج أن الخطوتين الأوليين قاما بالعمل الشاق. قبل أي إصلاح، كان حوالي واحد من كل ست إجابات من النماذج قابلاً للاستخدام فعلياً. وبعد أن قام مصلح الصيغة ودليل المخطط بعملهما، قفز عدد الإجابات القابلة للاستخدام إلى ما يقرب من اثنتين من كل ثلاث إجابات، وكل ذلك دون طلب توليد استجابة واحدة جديدة من الحاسوب. وبالنسبة للنموذج الأكثر قدرة في الدراسة، جعل هذا التنظيف البسيط كل إجابة تقريباً مثالية. وجد الباحثون أن أكبر مشكلة للحاسوب كانت غالباً مجرد عادة تغليف إجاباته برموز برمجية، مثل سياج العلامات الثلاثية (triple-backtick fence)، مما يربك المحللات الصارمة ولكنه يسهل إزالته بواسطة أداة الإصلاح. أما بالنسبة للنموذج الأصغر والأقل قدرة، فقد كانت المشكلة أعمق؛ إذ كان غالباً ما يسيء فهم هيكل الطلب أو ينسخ قواعد النموذج نفسه بدلاً من البيانات. وفي هذه الحالات، ساعدت مجرد مطالبة الحاسوب بالمحاولة مرة أخرى بعد رؤية أخطائه، ولكن فقط إذا كانت أدوات الإصلاح قد قامت بالفعل بتنظيف التنسيق الأساسي أولاً.
ومع ذلك، كشفت الدراسة عن حقيقة مفاجئة ومهمة: مجرد كون الإجابة منسقة بشكل صحيح لا يعني أنها صحيحة. فحتى بعد أن قام طاقم الإصلاح بإصلاح الصيغة والهيكل، كانت نصف الإجابات الصالحة تقريباً تحتوي على معلومات خاطئة. فقد تترك النماذج حقلاً فارغاً، أو تخترع رقم هاتف يبدو منطقياً، أو تختار الخيار الأول من قائمة خيارات دون التحقق مما إذا كان صحيحاً. حدث هذا حتى عندما طُلب من الحاسوب المحاولة مرة أخرى. لاحظ الباحثون أن الحاسوب يمكنه تلبية قواعد النموذج تماماً مع الفشل في مهمة قول الحقيقة. على سبيل المثال، قد ينسق نموذج بطاقة اتصال بشكل صحيح ولكنه يملأ رقم الهاتف برقم وهمي مثل "123-456-7890" لأنه لا يعرف الرقم الحقيقي.
تشير الدراسة إلى أن الاعتماد فقط على ما إذا كانت الإجابة تناسب تنسيقاً معيناً ليس كافياً. وللثقة حقاً في هذه النماذج الصغيرة، تحتاج الأنظمة إلى التحقق مما إذا كانت المعلومات داخل الإجابة تطابق النص الأصلي. وخلص الباحثون إلى أن أفضل نهج هو استخدام أدوات بسيطة وتلقائية لإصلاح التنسيق والهيكل أولاً، حيث يحل هذا معظم المشاكل مجاناً. وفقط بعد ذلك يجب على النظام أن يطلب من الحاسوب المحاولة مرة أخرى، وحتى حينها، يجب التحقق من أن الإجابة الجديدة تحتوي على حقائق حقيقية، وليس مجرد غلاف يبدو مثالياً. يظهر هذا العمل أنه بينما يمكن جعل النماذج الصغيرة أكثر موثوقية من خلال القليل من المعالجة اللاحقة، فإن الهدف المتمثل في استخراج معلومات دقيقة يظل تحدياً يتطلب التحقق من المحتوى، وليس فقط من الشكل.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.