بناء نظام جاهز للإنتاج لتحويل النصوص إلى SQL: تحقيق نسبة 88.15% على Spider 1.0

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

في هذه الدراسة، قمنا بتقييم أداء وكيل البيانات الخاص بنا على منصة Spider 1.0 وحققنا دقة تنفيذ بلغت 88.15% باستخدام نموذج Gemma 4 26B . وبدلاً من التركيز فقط على نتائج التقييم، تتناول هذه المقالة القرارات المعمارية والدروس الهندسية ورؤى التقييم التي تقف وراء هذه النتائج.

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

لتقييم هذه القدرات، قمنا باختبار أداء وكيل البيانات الخاص بنا على منصة Spider 1.0، وهي المنصة الأكثر استخدامًا في مجال تحويل النصوص إلى SQL. وباستخدام نموذج Gemma 4 26B ، حقق نظامنا دقة تنفيذ بلغت 88.15% ، مما يدل على أن إدارة البنية والسياق لا تقل أهمية عن اختيار النموذج.

يُعد اختيار المعيار المناسب بنفس أهمية اختيار النموذج المناسب. فبينما تُقدّم مجموعات البيانات الأحدث، مثل Spider 2.0 وBIRD، سيناريوهات مؤسسية أكثر تعقيدًا، يبقى Spider 1.0 المعيار الأكثر استخدامًا لتقييم أنظمة تحويل النصوص إلى SQL ومقارنة النتائج في مختلف الدراسات.

اخترنا برنامج Spider 1.0 لتقييمنا الأولي لأنه يوفر معيارًا أساسيًا موحدًا وموثوقًا. فهو يسمح لنا بقياس مدى فعالية برنامج Data Agent في فهم مخططات قواعد البيانات غير المألوفة وتوليد استعلامات SQL صحيحة في ظل ظروف واقعية.

يلخص الشكل 2 كيفية مقارنة Spider 1.0 مع معايير Text-to-SQL الأخرى الشائعة الاستخدام.

إن تحقيق دقة عالية في تحويل النصوص إلى لغة SQL لا يقتصر على استخدام نموذج لغوي أكبر. فقد وجدنا خلال عملية قياس الأداء أن بنية النظام وإدارة السياق لهما تأثير أكبر على الأداء من اختيار النموذج وحده.

صُمم وكيل البيانات لدينا كخط أنابيب متعدد المراحل يُضيّق نطاق المشكلة تدريجيًا قبل أن يطلب من نموذج التعلم المنطقي (LLM) إنشاء استعلام SQL. فبدلاً من عرض مخطط قاعدة البيانات بالكامل على النموذج، يسترجع النظام أولاً المخطط ذي الصلة والمعلومات السياقية فقط، ثم يُنشئ استعلام SQL، ويتحقق من صحة النتيجة، ويُصحح الأخطاء الشائعة تلقائيًا قبل التنفيذ.

كما هو موضح في الشكل 3 ، تتكون البنية من ثلاث مراحل رئيسية:

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

هذه البنية الموجهة نحو الإنتاج مستوحاة من الأفكار التي تم تقديمها في DIN-SQL و DAIL-SQL ، مع تكييفها لبيئات المؤسسات حيث تكون الموثوقية وقابلية التفسير والمتانة بنفس أهمية دقة القياس المعياري.

كان اختيار نموذج اللغة المناسب جزءًا مهمًا من عملية قياس الأداء لدينا. فبدلاً من تقييم نموذج واحد، قمنا بتجربة مجموعة واسعة من نماذج اللغة مفتوحة المصدر، بما في ذلك Llama 3.1 وQwen 2.5 وDeepSeek وSQLCoder وCodeGemma وMistral وGPT-OSS و Gemma 4.

لضمان مقارنة عادلة، قمنا بتقييم كل نموذج باستخدام دقة التنفيذ (EA) ، وهو المقياس القياسي لتقييم أداء تحويل النصوص إلى SQL. على عكس المقاييس القائمة على بناء الجملة، تقيس دقة التنفيذ ما إذا كان استعلام SQL المُولّد يُعيد نفس نتيجة الاستعلام المرجعي، مما يجعله مؤشرًا أفضل للأداء الفعلي.

يوضح الشكل 4 رحلة قياس الأداء التي قمنا بها. بدأنا بالتجربة على محطة عمل محلية مزودة ببطاقة رسومات RTX 4060 (ذاكرة فيديو 8 جيجابايت) ، حيث سمحت لنا النماذج الأصغر بالتكرار السريع والتحقق من صحة مسار العمل الخاص بنا. بعد إنشاء خط أساس مستقر باستخدام مجموعة فرعية من 233 سؤالًا من أسئلة Spider 1.0، انتقلنا إلى وحدات معالجة الرسومات السحابية لتقييم نماذج أكبر على معيار الأداء الكامل المكون من 2,147 سؤالًا . مكّننا هذا النهج التدريجي من تحسين البنية بكفاءة قبل الاستثمار في عمليات قياس أداء واسعة النطاق.

قمنا بتقييم النماذج النهائية على مجموعة اختبار Spider 1.0 الكاملة التي تضم 2,147 سؤالًا. وكما هو موضح في الجدول 1، حقق نموذج Gemma 4 26B أعلى نتيجة (88.15%)، يليه نموذج GPT-OSS 20B (86.63%). تُظهر هذه النتائج أن نماذج اللغة المفتوحة المصدر الحديثة، عند دمجها مع آلية فعّالة للاسترجاع والتحقق، قادرة على تحقيق أداء تنافسي للغاية في تحويل النصوص إلى لغة SQL. 

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

الجدول 2: معدلات دقة النماذج ذات المصادر المغلقة التي تم الإبلاغ عنها في دراسة SQL-of-Thought على مجموعة فرعية من مجموعة بيانات العنكبوت؛ يوضح الجدول، من حيث المقارنة، أن النتيجة 88.15% التي تم الحصول عليها في هذا العمل تقع فوق GPT-4o Mini (87%) وعلى مستوى قريب من GPT-5 (89%).

تشير دراسات حديثة، مثل دراسة SQL-of-Thought [1]، إلى أن نماذج المصادر المغلقة الرائدة - بما في ذلك Claude Opus 3 وGPT-5 و GPT-4 Mini - تحقق دقة عالية في مجموعات بيانات Spider المعيارية. وبينما ينبغي تفسير المقارنات المباشرة بحذر نظراً لاختلاف إعدادات التقييم والمطالبات ومجموعات البيانات المعيارية، فإن دقة التنفيذ التي حققناها والبالغة 88.15% تُظهر أن نماذج المصادر المفتوحة قادرة على تحقيق أداء ضمن النطاق التنافسي نفسه.

على الرغم من أن هذه النتائج مستمدة من بيئات تقييم مختلفة، ولا ينبغي مقارنتها مباشرةً، إلا أنها توفر سياقًا مفيدًا لفهم الوضع الحالي لأداء أنظمة تحويل النصوص إلى SQL. ويُظهر معيارنا أن النماذج مفتوحة المصدر قادرة الآن على منافسة البدائل الرائدة مغلقة المصدر عند دمجها مع بنية مصممة جيدًا.

لقد قمنا أيضًا بمقارنة نتائجنا مع أطر عمل تحويل النص إلى SQL الموجهة للإنتاج مثل DIN-SQL [3] و DAIL-SQL ، والتي تجمع بين نماذج اللغة الكبيرة والتقنيات التي تشمل ربط المخططات، وهندسة المطالبات، والاتساق الذاتي، وتصحيح الأخطاء.

الجدول 3: نتائج دقة التنفيذ لطرق مختلفة على Spider 1.0 في دراسة "Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation" [2]؛ يكشف عن تأثير اختيار النموذج على الدقة، وكذلك التقنيات مثل الهندسة الفورية، وربط المخططات، والاتساق الذاتي.

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

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

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

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

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

لا تُعدّ الدقة العالية سوى جانب واحد من جوانب نظام تحويل النصوص إلى SQL الجاهز للاستخدام في بيئات الإنتاج. ففي بيئات المؤسسات، تُعتبر تكلفة البنية التحتية، وخصوصية البيانات، ومرونة النشر من الاعتبارات بالغة الأهمية أيضاً.

تتمثل إحدى المزايا الرئيسية لنهجنا في اعتماده الكامل على نماذج لغوية مفتوحة المصدر. خلال عملية التطوير، تمكّنا من إجراء معظم التجارب محليًا باستخدام بطاقة رسومات RTX 4060 (بذاكرة 8 جيجابايت) من الفئة الاستهلاكية ، مما سمح لنا بالتكرار السريع دون تكبّد أي تكاليف متعلقة بواجهات برمجة التطبيقات أو الرموز. بعد ذلك، تم تنفيذ عمليات قياس الأداء الأكبر على وحدات معالجة رسومية مخصصة للحوسبة السحابية فقط بعد التحقق من صحة البنية.

استخدمنا منصة RunPod Secure Cloud لإجراء التقييم الكامل لبرنامج Spider 1.0. تم تنفيذ اختبار Gemma 4 26B على وحدة معالجة رسومية A100 PCIe بسعة 80 جيجابايت، بينما تم تشغيل اختبار GPT-OSS 20B على وحدة معالجة رسومية RTX 6000 بسعة 48 جيجابايت.

تم تلخيص تكاليف البنية التحتية في الجدول 4.

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

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

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

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

تُبرهن دقة التنفيذ التي حققناها بنسبة 88.15% على منصة Spider 1.0 أن النماذج مفتوحة المصدر، إلى جانب بنية مصممة جيدًا، قادرة على تقديم أداء تنافسي للغاية لمهام تحويل النصوص إلى SQL في المؤسسات. والأهم من ذلك، أنها تُؤكد صحة مبادئ التصميم التي يقوم عليها وكيل البيانات الخاص بنا ، والذي صُمم ليعمل بكفاءة عالية على قواعد بيانات المؤسسات المعقدة، وليس فقط على مجموعات البيانات المعيارية.

يمثل Spider 1.0 علامة فارقة مهمة، ولكنه ليس سوى بداية رحلتنا. تشمل خطواتنا التالية تقييم وكيل البيانات على Spider 2.0 ، وإجراء اختبارات معيارية أوسع نطاقًا على مستوى المؤسسات، والأهم من ذلك، بيئات عملاء حقيقية حيث تكون مخططات قواعد البيانات أكبر بكثير وتكون أسئلة الأعمال أكثر تعقيدًا.

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

لا يقتصر التقييم المعياري على قياس الدقة فحسب، بل يتعلق أيضاً بفهم سبب نجاح النظام أو فشله.

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

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

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

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

ينصب تركيزنا التالي على تقييم البنية على معايير أكثر تحديًا مثل Spider 2.0 ، والأهم من ذلك، على قواعد بيانات المؤسسات الحقيقية حيث تكون المخططات أكبر بكثير، والوثائق غالبًا ما تكون غير مكتملة، والأسئلة التجارية أكثر تعقيدًا.

هدفنا ليس مجرد بناء نظام آخر لتحويل النصوص إلى لغة SQL. بل إننا نبني وكلاء بيانات أذكياء يجمعون بين الاسترجاع والاستدلال والتحقق والتفسير لمساعدة المؤسسات على التفاعل مع بياناتها المؤسسية بشكل طبيعي وموثوق.

مراجع حسابات

[1] سوميا تشاتورفيدي، أمان تشادها، لوران بيندشيدلر، arXiv. "SQL-of-Thought: تحويل النص إلى SQL متعدد الوكلاء مع تصحيح الأخطاء الموجه." arXiv. يونيو 2026 https://arxiv.org/abs/2509.00581

[2] داوي جاو، هايبين وانج، ياليانج لي، شيويو صن، ييتشين تشيان، بولين دينج، جينجرين تشو "تحويل النص إلى SQL مدعومًا بنماذج اللغة الكبيرة: تقييم مرجعي" arXiv. يونيو 2026

https://arxiv.org/pdf/2308.15363 

[3] محمد رضا بور رضا، داوود رفيعي. "DIN-SQL: التعلم السياقي المُجزأ لتحويل النص إلى SQL مع التصحيح الذاتي" arXiv. يونيو 2026

https://arxiv.org/pdf/2304.11015

Dilşen YILDAR HAVAYLAR, 

مهندس برمجيات أول، حاصل على درجة الماجستير.