الدردشة مع قواعد البيانات (Text-to-SQL): جعل الذكاء الاصطناعي يكتب استعلامات SQL بنفسه

ما هو Text-to-SQL ولماذا يُعد طبقة حاسمة في التطبيقات الذكية؟

فكرة Text-to-SQL تقوم على تحويل سؤال بشري عادي مثل: “ما أكثر 5 منتجات مبيعاً هذا الشهر؟” إلى استعلام SQL صحيح وقابل للتنفيذ. هذا يعني أن نموذج اللغة الكبير LLM لا يجيب بالنص فقط، بل يعمل كطبقة ترجمة دلالية بين اللغة الطبيعية وبنية قاعدة البيانات.

تقنياً، هذا النمط لا يتعلق بإنتاج جملة ذكية فحسب، بل ببناء نظام موثوق يقرأ schema الجداول، يفهم العلاقات بين الأعمدة، يستنتج نية المستخدم، ثم يكتب استعلاماً آمناً. لذلك يُستخدم بكثافة في لوحات التحليل الداخلية، أنظمة BI، أدوات خدمة العملاء، وتطبيقات الدردشة مع البيانات المؤسسية.

إذا كنت قد قرأت سابقاً مقال مدخل إلى هندسة الذكاء الاصطناعي التوليدي: كيف تعمل نماذج اللغة الكبيرة (LLMs) برمجياً؟ فستدرك هنا أن النموذج لا “يعرف” قاعدة بياناتك مسبقاً، بل يحتاج إلى سياق منظم حول الجداول والحقول والقواعد المسموحة قبل أن ينتج استعلاماً قابلاً للتنفيذ.

المعمارية الهندسية لنظام الدردشة مع قواعد البيانات

أفضل تصميم عملي لـ Text-to-SQL لا يرسل سؤال المستخدم مباشرة إلى قاعدة البيانات. بل يمر عبر خط أنابيب منظم يقلل الأخطاء والهلاوس ويرفع الأمان.

مكوّنات النظام الأساسية

• واجهة مستخدم تستقبل السؤال باللغة الطبيعية.
• طبقة تحليل نية المستخدم Intent Layer.
• وحدة تزويد النموذج بمخطط الجداول Schema Injection.
• نموذج LLM يولد الاستعلام.
• طبقة تحقق Validation Layer تمنع الأوامر الخطرة.
• منفذ استعلامات Read-Only Executor.
• طبقة تفسير النتائج وإعادتها للمستخدم بصيغة مفهومة.

تدفق البيانات خطوة بخطوة

1. المستخدم يكتب سؤالاً مثل: ما إجمالي الطلبات في الربع الأول؟
2. النظام يجلب الجداول والأعمدة المرتبطة بالمبيعات والفواتير فقط، بدلاً من إرسال schema كامل.
3. يُبنى prompt يشرح أسماء الجداول، أنواع الأعمدة، والممنوعات الأمنية.
4. النموذج يولد استعلام SELECT فقط.
5. طبقة تحقق تفحص وجود كلمات مثل DROP أو DELETE.
6. يُنفذ الاستعلام على مستخدم قاعدة بيانات محدود الصلاحيات.
7. ترجع النتائج إلى النموذج ليحوّلها إلى جواب بشري واضح.

لماذا يفشل النموذج أحياناً في كتابة SQL صحيح؟

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

كما أن حجم tokens مهم جداً، لأن إرسال مخطط قاعدة بيانات ضخم بالكامل يزيد التكلفة ويشتت النموذج. ويمكنك ربط هذه الفكرة بمقال حساب التكلفة وإدارة الرموز (Tokens): سكربت لمعرفة حجم استهلاك الـ API قبل الإرسال.

هندسة Prompt لإنتاج استعلامات موثوقة

في أنظمة Text-to-SQL لا يكفي أن تقول للنموذج “اكتب استعلاماً”. يجب أن تحدد له نوع قاعدة البيانات، أسماء الجداول، الأعمدة المتاحة، شكل الخرج، وما إذا كان مسموحاً له فقط بإنشاء read-only queries. هذا امتداد عملي لمفهوم هندسة الأوامر (Prompt Engineering) داخل الكود: قوالب النصوص المتغيرة (F-Strings).

أنت مساعد متخصص في تحويل الأسئلة إلى استعلامات SQL. استخدم فقط الجداول والأعمدة المذكورة. لا تكتب أي أوامر تعديل مثل INSERT أو UPDATE أو DELETE. أعد النتيجة بصيغة JSON تحتوي على المفتاحين: sql و explanation.

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

تنفيذ عملي باستخدام LangChain و SQLite

يمكن بناء نموذج أولي بسرعة عبر LangChain لأنه يوفر أدوات للاتصال بقواعد البيانات، تكوين السلاسل، وتمرير prompts. وإذا لم تكن جهزت البيئة بعد، فراجع مقال إعداد بيئة العمل الذكية: تثبيت مكتبات Python الأساسية للتعامل مع الذكاء الاصطناعي.

import os
from langchain_openai import ChatOpenAI
from langchain_community.utilities import SQLDatabase
from langchain_core.prompts import ChatPromptTemplate

db = SQLDatabase.from_uri("sqlite:///sales.db")

llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0
)

schema = db.get_table_info()

prompt = ChatPromptTemplate.from_template("""
You are a Text-to-SQL assistant.
Database dialect: SQLite

Schema:
{schema}

Rules:
- Only generate SELECT queries
- Never use INSERT, UPDATE, DELETE, DROP, ALTER
- Return valid JSON with keys: sql, explanation

User question:
{question}
""")

chain = prompt | llm

response = chain.invoke({
    "schema": schema,
    "question": "What are the top 5 customers by total order value?"
})

print(response.content)

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

import json
import re

def is_safe_select_query(sql: str) -> bool:
    forbidden = ["INSERT", "UPDATE", "DELETE", "DROP", "ALTER", "TRUNCATE", "CREATE"]
    sql_upper = sql.upper().strip()

    if not sql_upper.startswith("SELECT"):
        return False

    for word in forbidden:
        if re.search(rf"\b{word}\b", sql_upper):
            return False

    return True

data = json.loads(response.content)
generated_sql = data["sql"]

if is_safe_select_query(generated_sql):
    result = db.run(generated_sql)
    print(result)
else:
    print("Unsafe query blocked.")

استخدام RAG لتحسين فهم الجداول المعقدة

عندما تصبح قاعدة البيانات كبيرة، من غير العملي تمرير كل الجداول إلى النموذج في كل مرة. هنا يمكن الاستفادة من منطق قواعد البيانات المتجهة (Vector Databases) وEmbeddings لبناء فهرس دلالي لأوصاف الجداول والأعمدة. عند سؤال المستخدم، نسترجع فقط الأجزاء الأكثر صلة، ثم نرسلها إلى النموذج. هذه مقاربة هجينة بين SQL metadata retrieval ودمج المعلومات المسترجعة مع الـ LLM لتوليد إجابة دقيقة وبدون هلوسة.

أفضل الممارسات الأمنية والجودة الإنتاجية

• شغّل الاستعلامات عبر مستخدم read-only فقط.
• لا تسمح بتنفيذ أكثر من جملة في الطلب الواحد.
• استخدم قوائم سماح allowlist للجداول المصرح بها.
• سجّل كل سؤال، الاستعلام الناتج، وزمن التنفيذ لأغراض المراجعة.
• أضف أمثلة few-shot للاستعلامات الشائعة لتحسين الدقة.
• اضبط temperature=0 لأن المطلوب هنا دقة لا إبداع، وهي نقطة مرتبطة بمقال التحكم في إبداع الذكاء الاصطناعي: فهم وإعداد معاملات Temperature و Top-K برمجياً.

متى نلجأ إلى Fine-tuning بدلاً من الاكتفاء بالبرومبت؟

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

الخلاصة الهندسية

Text-to-SQL ليس خدعة عرضية، بل نظام هندسي متكامل يجمع بين فهم اللغة، توصيف قاعدة البيانات، التحقق الأمني، وإعادة صياغة النتائج. كلما كان schema context أوضح، والخرج أكثر تنظيماً، والتنفيذ أكثر تقييداً، أصبحت “الدردشة مع قاعدة البيانات” ميزة إنتاجية حقيقية لا مجرد تجربة مبهرة. وهذا بالضبط ما يميز تطبيقات الذكاء الاصطناعي الاحترافية: أنها لا تعتمد على ذكاء النموذج وحده، بل على بنية هندسية تحاصر الخطأ قبل أن يصل إلى البيانات.