ما هو NL2SQL وكيف يعمل؟

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

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

يتميز NL2SQL عن وكيل المحادثة المتصل بقاعدة البيانات بالمعنى الواسع. الأول ينتج استعلامًا قابلاً للقراءة والتدقيق؛ يمكن للثاني أن يتسلسل عدة استدعاءات للأدوات (البحث والحساب والكتابة) دون أن يؤدي بالضرورة إلى SQL فريد وقابل للفحص. يظل نظام NL2SQL المصمم بشكل صحيح ضمن هذا النطاق المقيد عمدًا: الترجمة والتحقق من الصحة والتنفيذ وإرجاع النتيجة.

يتبع خط أنابيب NL2SQL الموثوق دائمًا نفس التسلسل، بغض النظر عن الموفر: يمر السؤال عبر نموذج لغة، ثم يتم التحقق من صحة SQL المنتج قبل التنفيذ، وليس بعده أبدًا. يوضح تطبيق Aurabase، الذي تم التحقق منه في كود الخدمة aura-ai، كل خطوة من هذه الخطوات بقواعد محددة بدلاً من الوصف المجرد.

1. يتم استلام السؤال بالمخطط الفعلي للقاعدة

يقوم النظام بربط السؤال باللغة الطبيعية بمخطط قاعدة البيانات التي تم الاستعلام عنها: أسماء الجداول والأعمدة والأنواع. وهذا النمط يجب أن يأتي من الاستبطان للأساس الفعلي، وليس من الوصف الذي يقدمه المتصل. إن التنفيذ الذي يقبل المخطط المعلن من قبل العميل من شأنه أن يفتح الباب لطرح أسئلة حول الجداول غير الموجودة، أو لتجاوز العزل بين المشاريع. يرفض محرك Aurabase صراحةً (خطأ 400) أي حقل schema مرسل في الطلب، بدلاً من تجاهله بصمت.

2. يقوم LLM بإنشاء SQL مرشح

يتلقى نموذج اللغة السؤال والمخطط في موجهه، ثم ينتج استعلام SQL مرشحًا مع شرح قصير. تعامل Aurabase ثلاثة مقدمي خدمات على قدم المساواة مع عميل أصلي مخصص: OpenAI وAnthropic (Claude) وGemini. SQL المرشح هذا هو في هذه المرحلة مجرد اقتراح، ولم يتم تنفيذه بشكل مباشر.

3. يتم التحقق من صحة SQL المرشح قبل التنفيذ، وليس بعده

هذه هي الخطوة التي تميز نظام NL2SQL الجاد عن استدعاء LLM بسيط يتبعه تنفيذ ساذج. يتم تحليل SQL الذي تم إنشاؤه إلى شجرة بناء الجملة (AST) بدلاً من فحصه من خلال البحث عن الكلمات الرئيسية، والذي يمكن تجاوزه بسهولة. يسمح تطبيق Aurabase، مع مكتبة sqlparser، فقط باستعلامات SELECT البسيطة: يتم رفض CTE/WITH والاستعلامات الفرعية وUNONs ووظائف النافذة وعبارات القفل (FOR UPDATE) بشكل صريح، وكذلك أي وظائف SQL خارج القائمة البيضاء المكونة من عشر وظائف (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. يتم تشغيل الاستعلام الملتزم باستخدام حد أقصى للصف

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

-- السؤال: "كم عدد الطلبات هذا الشهر للعملاء المميزين؟"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- تمت إضافته بواسطة الخادم، وهو مفقود من SQL الذي تم إنشاؤه

تمت تغطية التفاصيل الكاملة لخط الأنابيب هذا، مع كل استدعاء HTTP وكل استجابة JSON، في برنامجنا التعليمي خطوة بخطوة لإنشاء نقطة نهاية NL2SQL على Postgres.

ليس المقصود من NL2SQL أن تحل محل لغة SQL المكتوبة بخط اليد في كل مكان. وهو يغطي نطاقًا محددًا: أسئلة مخصصة لمرة واحدة يطرحها شخص لا يعرف SQL أو يريد ببساطة توفير الوقت في استعلام بسيط.

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

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

تتكرر ثلاثة مخاطر بشكل منهجي في تنفيذ NL2SQL، مع استجابات مختلفة اعتمادًا على نضج النظام.

حقن SQL عبر المطالبة أو السؤال

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

هلوسة عدم وجود الجداول أو الأعمدة

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

التكلفة وزمن الوصول للمكالمات النموذجية

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

ينتج عن بنايتين نتيجة واضحة مماثلة، ولكن بضمانات مختلفة تمامًا. يدمج NL2SQL الأصلي عملية الإنشاء والتحقق والتنفيذ مباشرة في طبقة الواجهة الخلفية التي تعرف بالفعل مخطط المشروع وحقوق الوصول: هذا هو المنطق الموضح أعلاه لـ Aurabase، حيث تشارك خدمة aura-ai البنية التحتية وعزل المخطط مع بقية الواجهة الخلفية.

يجمع NL2SQL المجمع بين خدمة LLM عامة وموصل لقاعدة البيانات وطبقة التحقق من الصحة التي يمكنك إنشاؤها بنفسك. لا شيء يمنع أن يكون هذا النهج آمنًا، ولكن كل ضمان، ومخطط الاستبطان من جانب الخادم، والتحقق من صحة AST، وسقف الصف، ومستأجر العزل، يجب تنفيذه وصيانته بواسطة الفريق الذي يجمع هذه الوحدات معًا، بدلاً من توفيرها بواسطة النظام الأساسي.

تتم مقارنة مشهد أدوات NL2SQL، الأصلية والمجمعة، مفتوحة المصدر والتجارية، بالتفصيل في مقارنة أدوات NL2SQL 2026.

يجيب NL2SQL وRAG (جيل الاسترجاع المعزز) على عائلتين مختلفتين من الأسئلة، وغالبًا ما يتم الخلط بينهما لأن كلاهما يعتمد على LLM متصل بقاعدة بيانات.

يستهدف NL2SQL البيانات المنظمة والعلائقية: كم، ومتى، وما النسبة، من الأسئلة التي تترجم بشكل طبيعي إلى SELECT، GROUP BY، مجموعات. يستهدف RAG المحتوى غير المنظم: المستندات، والملاحظات، وتذاكر الدعم، حيث لا تتناسب الإجابة مع صف الجدول ولكنها تتطلب العثور على مقطع ذي صلة عن طريق التشابه الدلالي، والبحث المتجهي على pgvector، وفهرس HNSW، قبل إعطائه في سياق النموذج.

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