LLM-Based SQL Generation: Prompting, Self-Refinement, and Adaptive Weighted Majority Voting
تقترح هذه الورقة إطار عمل جديداً لتوليد استعلامات SQL من النصوص استناداً إلى النماذج اللغوية الكبيرة، يجمع بين مسار "التحسين الذاتي للوكيل المنفرد مع التصويت بالتجميع" (SSEV) ونظام تعاوني متعدد الوكلاء (ReCAPAgent-SQL)، وذلك لتحقيق دقة تنفيذ تنافسية في اختبارات معيارية مثل Spider وBIRD، مع معالجة تعقيدات قواعد بيانات المؤسسات في العالم الحقيقي بفعالية دون الاعتماد على بيانات الحقيقة الأرضية.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تريد طرح سؤال على مكتبة ضخمة من المعلومات (قاعدة بيانات)، لكن أمناء المكتبة لا يتحدثون سوى لغة آلية صارمة للغاية تسمى SQL. أنت تتحدث الإنجليزية الطبيعية. الهدف من هذا البحث هو بناء مترجم يمكنه تحويل أسئلتك بالإنجليزية إلى أوامر SQL مثالية لكي تتمكن المكتبة من الإجابة عليك.
قام المؤلفان، يو-جي يانغ وزملاؤه، بمعالجة مشكلة أن هؤلاء المترجمين غالباً ما يصابون بالارتباك، أو يرتكبون الأخطاء، أو لا يفهمون مخطط المكتبة. لقد بنوا نظامين رئيسيين لإصلاح ذلك: نهج "فريق الخبراء" ونهج "فريق الوكلاء المتخصصين".
إليك كيف فعلوا ذلك، باستخدام تشبيهات بسيطة:
1. المشكلة: فشل المترجم الذي "يصلح لكل زمان ومكان"
تخيل أنك تطلب من شخص واحد ترجمة وثيقة قانونية معقدة إلى لغة أخرى. قد يفتقد إلى التفاصيل الدقيقة، أو يخطئ في اسم، أو يستخدم قواعد لغوية خاطئة. في عالم قواعد البيانات، يحدث هذا عندما يحاول نموذج ذكاء اصطناعي واحد تخمين كود SQL. فغالباً ما يضيع في "المخطط" (خريطة المكتبة) أو يسيء فهم سؤالك.
2. الحل الأول: "فريق الخبراء" (مسار SSEV)
أنشأ المؤلفون نظاماً يسمى SSEV (التنقيح الذاتي لعميل واحد مع التصويت الجماعي). فكر في هذا ليس كمترجم واحد، بل كـ لجنة من خمسة خبراء مختلفين يجلسون حول طاولة.
- مرحلة الصياغة (PreSQL): تكتب اللجنة تخميناتها الأولية للإجابة.
- التحقق من الخريطة (ربط المخطط): يدركون أنهم ينظرون إلى خريطة ضخمة للمكتبة. وبدلاً من محاولة قراءة الخريطة بأكملها، يستخدمون تخميناتها الأولى لتحديد فقط الممرات والأرفف ذات الصلة. هذا يقلل من الضوضاء.
- المسودة الثانية (PostSQL): مع تضييق نطاق الخريطة، يكتبون مسودة ثانية أكثر نظافة وتركيزاً.
- حلقة "التصحيح الذاتي": إذا كانت المسودة تحتوي على خطأ مطبعي أو لم تعمل عند تجربتها، فهم لا يلقون بها فحداً. بل ينظرون إلى رسالة الخطأ، ويصلحونها، ثم يحاولون مجدداً. يشبه الأمر كاتباً يراجع عمله حتى يصبح منطقياً.
- نظام التصويت (WMA): هذا هو السر الحقيقي. بدلاً من مجرد أخذ تصويت حيث يحصل الجميع على نقطة متساوية، يستخدمون خوارزمية الأغلبية الموزونة.
- تخيل برنامج مسابقات حيث لدى الحكام مستويات مختلفة من الثقة. إذا كان "القاضي أ" قد أصاب 10 مرات متتالية، فإن صوته يُحتسب أكثر. إذا كان "القاضي ب" يستمر في ارتكاب الأخطاء، فإن صوته يُحتسب أقل.
- يقوم النظام باستمرار بتحديث "درجات الثقة" هذه بناءً على من أصاب الإجابة في الماضي. ومع مرور الوقت، يتعلم النظام الاستماع في الغالب إلى الخبير الأكثر ذكاءً في الغرفة.
النتيجة: في الاختبارات القياسية (مثل Spider 1.0 و BIRD)، حصل نهج "فريق الخبراء" هذا على الإجابة الصحيحة حوالي 86% من المرات، وهو أفضل بكثير من أي خبير واحد يعمل بمفرده.
3. الحل الثاني: "فريق الوكلاء المتخصصين" (ReCAPAgent-SQL)
بالنسبة للمشكلات الأكثر صعوبة (مثل مجموعة بيانات Spider 2.0 الجديدة، التي تحاكي قواعد بيانات الشركات الفوضوية في العالم الحقيقي)، فإن لجنة بسيطة ليست كافية. بنى المؤلفون ReCAPAgent-SQL، وهو يشبه توظيف فرقة مهام متخصصة حيث لكل عضو وظيفة محددة.
- المخطط (The Planner): يقسم سؤالك الكبير إلى خطوات صغيرة ومنطقية (مثل مدير المشروع).
- المسترجع (The Retriever): يخرج للبحث عن أدلة أو وثائق إضافية إذا لم تكن لدى الفريق قواعد محددة (مثل الباحث).
- الناقد (The Critic): يراجع العمل ويقول: "مهلاً، هذا المنطق لا يبدو منطقياً"، أو "لقد فاتتك خطوة".
- رابط المخطط (The Schema Linker): يتعامل خصيصاً مع خريطة المكتبة، ويتأكد من أنهم ينظرون إلى الجداول والأعمدة الصحيحة.
- المُنقّح الذاتي (The Self-Refiner): إذا تعطل الكود، يقوم هذا الوكيل بإصلاحه.
- المُدقق (The Validator): مراقب الجودة النهائي الذي يتحقق مما إذا كانت هذه الإجابة تحل مشكلة المستخدم بالفعل.
يتواصل هؤلاء الوكلاء مع بعضهم البعض في حلقة. يخططون، ينفذون، يتلقون النقد، يصلحون الخطأ، ويحاولون مجدداً حتى ينجحوا.
النتيجة: عندما اختبروا هذا على أصعب الأسئلة وأكثرها واقعية (Spider 2.0-lite)، قاموا برفع نظام أساسي لم يكن يحصل إلا على 6% من الإجابات الصحيحة، ورفعوه إلى 31%. هذه قفزة هائلة في مجال تُقاس فيه التقدم عادةً بأجزاء ضئيلة جداً.
4. لماذا يهم هذا؟
يدعي البحث أنه من خلال الجمع بين التنقيح الذاتي (إصلاح أخطائك الخاصة)، والتصويت الذكي (الاستماع لأفضل الخبراء)، والوكلاء المتخصصين (امتلاك فريق بأدوار محددة)، يمكننا بناء أنظمة تتعامل مع أسئلة البيانات المعقدة في العالم الحقيقي بشكل أفضل بكثير من ذي قبل.
لم يكتفوا بالتخمين؛ بل اختبروا هذه الأساليب على معايير قياسية وأثبتوا أن:
- التصويت الموزون يعمل بشكل أفضل من التصويت بالأغلبية البسيطة لأنه يتكيف مع من هو بارع فعلياً في المهمة.
- التنقيح الذاتي يساعد في إصلاح الأخطاء التي تحدث عندما تقول قاعدة البيانات "لا، هذا الأمر خاطئ".
- الأنظمة متعددة الوكلاء ضرورية لقواعد البيانات المعقدة والفوضوية الموجودة في الشركات الحقيقية.
باختصاف، لقد بنوا مترجماً أكثر ذكاءً ومرونة، يتعلم من أخطائه ويستمع إلى أفضل خبرائه، مما يجعل من السهل جداً على الأشخاص العاديين طرح أسئلة معقدة على قواعد بيانات ضخمة.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.