Quel est le site Web ?

https://www.youtube.com/playlist?list=PLfVdvKscEioMSVPWYUW0XD3CKKohUYMEG

Abdelali Zekiri, 19 Rue saint leger, Saint-Germain-en-Laye (2026)

29/10/2026

الدولة مش تعلب مادام قلت حضر المخفضة فمعناها هناك خطر قادم
من سيحضر نفسه مثلي ?
الله خير الحافظين

29/10/2026

س ج برمجة #مبرمج #ذكاء اصطناعي #مطور

29/10/2026

السلام عليكم
مقال او كتاب جدا رايع

مقدمة: لماذا ما زلنا نطلب من المبرمج استخراج البيانات؟

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

ومع مرور السنوات، لم تختفِ هذه المشكلة، رغم التطور الكبير في أدوات ذكاء الأعمال (Business Intelligence)، ومستودعات البيانات (Data Warehouses)، ومنصات التحليل.

ما زالت الطلبات تصل إلى فرق التطوير وقواعد البيانات لأسباب مختلفة، منها:

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

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

هنا يظهر سؤال مهم: ماذا لو استطاع المسؤول طرح سؤاله بلغته الطبيعية، والحصول على الإجابة مباشرة من البيانات، دون الحاجة إلى معرفة SQL؟

1 مقدمة: لماذا ما زلنا نطلب من المبرمج استخراج البيانات
https://www.facebook.com/share/p/1EdvYXuA5L/?mibextid=wwXIfr

2 لماذا لا نمنح المسؤول القدرة على كتابة SQL بنفسه؟
https://www.facebook.com/share/p/1eS1hbx8n9/?mibextid=wwXIfr

3 ظهور النماذج اللغوية الكبيرة: هل أصبح Text-to-SQL ممكنًا؟
4 لماذا لا نربط LLM مباشرة بقاعدة البيانات
https://www.facebook.com/share/p/1MuvCS7u9S/?mibextid=wwXIfr

5 التحدي الحقيقي: كيف نراقب SQL الذي يتغير باستمرار؟
6 قبل كتابة SQL، يجب أن نفهم السؤال
https://www.facebook.com/share/p/1HsahmsuQt/?mibextid=wwXIfr

7 لماذا لا يكفي أن نعطي النموذج مخطط قاعدة البيانات؟
8 بناء طبقة وسيطة باستخدام Views
9 من الـ Schema إلى الطبقة الدلالية (Semantic Layer)
https://www.facebook.com/share/p/19z89MhyRg/?mibextid=wwXIfr

10 كيف نبني منهجية متكاملة لوكيل Text-to-SQL؟
11 أين يأتي دور Rules وSkills وAgents؟
https://www.facebook.com/share/p/19z89MhyRg/?mibextid=wwXIfr

12 كيف نجعل المراقبة ديناميكية وآلية؟
13 كيف نختبر النظام ونختار الأدوات المناسبة؟
https://www.facebook.com/share/p/1FHuvnXTtY/?mibextid=wwXIfr

14 الخاتمة: من توليد SQL إلى بناء نظام موثوق للوصول إلى البيانات
15 المراجع والمصادر
https://www.facebook.com/share/p/1Cp1gBTMpU/?mibextid=wwXIfr

29/10/2026

. النقطة 14-15
خارطة طريق عملية للشركات الصغيرة والمتوسطة

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

المرحلة الأولى: تحديد نطاق واضح

اختيار مجال واحد، مثل المبيعات، وتحديد مجموعة من الأسئلة المتكررة التي يطلبها المسؤولون باستمرار.

الهدف هو اختيار مشكلة متكررة ومحددة يمكن قياس نجاح الحل فيها.

المرحلة الثانية: توثيق البيانات

حصر الجداول والأعمدة والعلاقات المتعلقة بهذا المجال، وتوثيق تعريفات المؤشرات التجارية، وتحديد قواعد احتسابها.

المرحلة الثالثة: إنشاء Views معتمدة

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

المرحلة الرابعة: بناء نموذج أولي لـ Text-to-SQL

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

المرحلة الخامسة: إضافة طبقة التحقق

فرض القراءة فقط، والتحقق من SQL، وتطبيق الصلاحيات والحدود التشغيلية، وتسجيل الطلبات والأخطاء.

المرحلة السادسة: إجراء تقييم واقعي

مقارنة النتائج بإجابات معتمدة، وقياس الدقة، والتكلفة، وزمن الاستجابة، والأخطاء التي تتكرر.

المرحلة السابعة: التوسع التدريجي

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

والأهم هو ألا نقيس نجاح المشروع بعدد الأسئلة التي يستطيع النموذج الإجابة عنها، بل بنسبة الأسئلة التي يستطيع الإجابة عنها بشكل صحيح وآمن ومتكرر.

الخاتمة: الهدف ليس أن يكتب الذكاء الاصطناعي SQL، بل أن يجعل الوصول إلى البيانات موثوقًا

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

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

كما نحتاج إلى استخدام Rules وSkills وAgents بطريقة منظمة، بحيث تتولى النماذج المهام التي تجيدها، بينما تبقى القرارات الأمنية والتنفيذية الحاسمة تحت سيطرة آليات برمجية يمكن اختبارها والتحقق منها.

ولعل أهم تحول في طريقة التفكير هو الانتقال من سؤال:

«كيف نجعل LLM يكتب SQL أفضل؟»

إلى سؤال أعمق:

«كيف نبني نظامًا يسمح للذكاء الاصطناعي بكتابة SQL، لكنه لا يعتمد على صحة ما يكتبه دون تحقق مستقل؟»

هذا هو الفارق بين تجربة تقنية مبهرة ونظام مؤسسي يمكن الوثوق به.

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

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

29/10/2026

النقطة 12-13

؟

لا يكفي أن نجرب النظام على خمسة أسئلة ونقرر أنه يعمل.

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

ويُفضل أن يكون لكل سؤال مرجع معتمد، يحدد النتيجة المتوقعة أو قواعد الإجابة الصحيحة

ومن المهم عدم الاعتماد على تطابق نص SQL وحده في التقييم؛ فقد يختلف استعلامان في الصياغة ويعطيان النتيجة الصحيحة نفسها، كما قد يبدو استعلامان متشابهين بينما ينتج عنهما اختلاف تجاري مهم.

الأفضل الجمع بين اختبارات التنفيذ، والتحقق من النتائج، ومراجعة قواعد العمل، واختبارات الأمان.

كما يجب اختبار التغييرات في الـ Schema والـ Views وتعريفات المؤشرات قبل نشرها، لأن أي تعديل في مصادر البيانات قد يؤثر على الاستعلامات التي كان النظام ينفذها بنجاح سابقًا.

13. هل نحتاج إلى منصة مدفوعة أم يمكن بناء الحل باستخدام أدوات مفتوحة المصدر؟

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

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

ويمكن التفكير في ثلاثة مسارات رئيسية:

المسار الأول: بناء حل مخصص باستخدام أدوات مفتوحة المصدر.

يناسب الشركات التي تريد التحكم في البنية، وتملك فريقًا تقنيًا قادرًا على تطوير طبقة الاسترجاع والتحقق والأمان والاختبارات.

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

المسار الثاني: استخدام منصة جاهزة.

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

لكن يجب التحقق من دعم المنصة لمحرك قاعدة البيانات المستخدم، وصلاحيات الوصول، والخصوصية، والتدقيق، والتكلفة، وإمكانية اختبار النتائج، ومدى توافقها مع تعريفات العمل الداخلية.

المسار الثالث: بنية هجينة.

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

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

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

29/10/2026

النقطة 10-11

؟

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

Rules — القواعد: تحدد ما يجب على النظام فعله وما يُمنع عليه. مثل منع تنفيذ الاستعلامات التي تعدل البيانات، أو اشتراط تحديد الفترة الزمنية في أنواع معينة من الأسئلة، أو إلزام النظام باستخدام تعريف معتمد لمؤشر معين.

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

Agents — الوكلاء: ينسقون هذه المراحل، ويقررون متى يحتاج السؤال إلى توضيح، ومتى يجب استرجاع معلومات إضافية، ومتى ينبغي إعادة صياغة الاستعلام أو التوقف.

لكن هناك مبدأ أساسيًا: التعليمات النصية وحدها لا تكفي لتطبيق الضوابط الأمنية.

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

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

لهذا أقترح فصل النظام إلى طبقتين:

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

يمنحنا هذا التصميم مرونة النماذج اللغوية دون تحويلها إلى الجهة الوحيدة المسؤولة عن سلامة النظام.

11. كيف نجعل المراقبة ديناميكية وآلية؟

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

يمكن، على سبيل المثال، تصنيف الطلبات إلى مستويات:

المستوى الأول: استعلامات بسيطة منخفضة المخاطر.

مثل عدد الطلبات حسب الحالة، ضمن View معتمدة. يمكن السماح بتنفيذها بعد التحقق الآلي الأساسي.

المستوى الثاني: استعلامات تحليلية متعددة الجداول.

مثل مقارنة صافي المبيعات حسب الفرع والشهر. تحتاج إلى التحقق من تعريف المقاييس، وعلاقات الربط، ومستوى تفصيل البيانات، وتكلفة التنفيذ.

المستوى الثالث: استعلامات حساسة أو عالية التكلفة.

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

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

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

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

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

وهنا تصبح المراقبة عملية مستمرة: نرصد، ونصنف الأخطاء، ونحدد أسبابها، ونحسن مصادر المعرفة والضوابط، ثم نعيد التقييم

29/10/2026

النقطة 8-9
من الـ Schema إلى الطبقة الدلالية Semantic Layer

إذا كانت الـ Views تقدم واجهة مبسطة للبيانات، فإن الطبقة الدلالية (Semantic Layer) تذهب خطوة أبعد.

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

لنفترض أن ثلاثة أقسام داخل الشركة تستخدم مصطلح «المبيعات»، لكن كل قسم يحسبه بطريقة مختلفة:

* قسم المبيعات يحتسب قيمة الطلبات المؤكدة.
* قسم المالية يعتمد الفواتير الصادرة أو المدفوعات وفق السياسة المحاسبية.
* قسم التجارة الإلكترونية يحتسب قيمة الطلبات بعد خصم الإلغاءات والمرتجعات.

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

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

وتستطيع الطبقة الدلالية أن تتضمن:

* تعريفات موحدة للمؤشرات.
* الأبعاد التي يمكن تقسيم المؤشرات وفقها.
* العلاقات المسموح بها بين الكيانات.
* قواعد احتساب المقاييس.
* القيود الزمنية والتجارية.
* الأسماء البديلة والمصطلحات التي يستخدمها الموظفون.
* قواعد الصلاحيات على مستوى البيانات.

والأفضل في المؤشرات المعروفة أن يتولى النظام اختيار المقياس والأبعاد، بينما تتولى طبقة برمجية موثوقة توليد SQL من التعريفات المعتمدة.

بهذا الشكل، لا يضطر النموذج إلى إعادة اختراع طريقة حساب صافي المبيعات في كل طلب؛ بل يحدد أنه يريد مقياس «صافي المبيعات» حسب «الشهر»، ثم تُنفذ القواعد المعتمدة بصورة حتمية.

هذا لا يعني أن الطبقة الدلالية تغني دائمًا عن Text-to-SQL. فهي ممتازة للأسئلة التي تغطيها المقاييس والنماذج المعرفة مسبقًا، لكنها لا تستطيع الإجابة تلقائيًا عن كل سؤال جديد إذا كانت البيانات أو العلاقات المطلوبة خارج نطاقها.

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

9. كيف نبني منهجية متكاملة لوكيل Text-to-SQL؟

حتى هذه المرحلة، تحدثنا عن فهم السؤال، والـ Schema، والـ Views، والطبقة الدلالية. لكن كيف نجمع هذه العناصر في نظام متكامل؟

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

المرحلة الأولى: فهم نية المستخدم

يستقبل النظام السؤال باللغة الطبيعية، ثم يصنفه ويستخرج عناصره الأساسية.

على سبيل المثال:

«أريد معرفة صافي المبيعات لكل فرع خلال الربع الأخير».

يمكن تحويله إلى وصف منظم يتضمن:

* المؤشر: صافي المبيعات.
* البعد: الفرع.
* الفترة: الربع الأخير.
* نوع العملية: تجميع وتحليل.
* مستوى التفصيل: إجمالي لكل فرع.

إذا كانت الفترة الزمنية أو دلالة «الربع الأخير» غير واضحة وفق سياق الشركة، يطلب النظام التوضيح قبل الانتقال إلى الخطوة التالية.

المرحلة الثانية: استرجاع السياق المناسب

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

قد تشمل هذه المعلومات:

* تعريف المؤشر المطلوب.
* أسماء الـ Views المناسبة.
* أعمدة التاريخ والمبالغ.
* العلاقات المعتمدة.
* قواعد احتساب المرتجعات.
* أمثلة سابقة على أسئلة مشابهة.

يمكن استخدام الاسترجاع المعزز بالتوليد (RAG) أو البحث الدلالي أو فهرسة بيانات الـ Schema والوثائق لتحقيق ذلك.

لكن الاسترجاع وحده لا يضمن صحة الإجابة؛ فجودة النتائج تعتمد على جودة المعلومات المفهرسة، وآلية اختيارها، ومدى تحديثها.

المرحلة الثالثة: اختيار مسار التنفيذ

قبل توليد SQL، يقرر النظام أي المسارات أنسب للسؤال.

إذا كان السؤال يتعلق بمؤشر معروف ومتاح في الطبقة الدلالية، فيُفضل استخدام المسار المحدد مسبقًا.

أما إذا كان السؤال استكشافيًا ويتطلب تفاصيل غير مغطاة، فيمكن السماح للنموذج بتوليد SQL فوق مجموعة محددة من الـ Views والجداول المسموح بها.

وإذا كان السؤال غامضًا، أو كانت البيانات المطلوبة غير متاحة، فلا ينبغي للنظام أن يخترع إجابة أو يولد استعلامًا تخمينيًا؛ بل يطلب التوضيح أو يشرح حدود البيانات المتاحة.

المرحلة الرابعة: إنشاء خطة للاستعلام

بدلًا من مطالبة النموذج بكتابة استعلام طويل مباشرة، يمكن أن نطلب منه تحديد خطة الاستعلام أولًا.

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

ثم تتحقق طبقة برمجية من أن هذه العناصر مسموح بها ومتوافقة مع تعريفات البيانات.

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

المرحلة الخامسة: توليد SQL والتحقق منه

يُولد الاستعلام باستخدام سياق محدود وموثوق، ثم يمر بمجموعة من الفحوص الآلية.

يمكن أن تشمل هذه الفحوص:

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

من المهم أن تكون هذه الضوابط مستقلة عن النموذج. فلا ينبغي اعتبار قول النموذج إن استعلامه آمن دليلًا على أنه آمن فعلًا.

المرحلة السادسة: تنفيذ الاستعلام في بيئة مقيدة

بعد اجتياز التحقق، ينفذ الاستعلام باستخدام حساب قاعدة بيانات محدود الصلاحيات.

يُفضل استخدام اتصال للقراءة فقط، مع تطبيق صلاحيات المستخدم الفعلية، والحد من عدد الصفوف والمدة الزمنية واستهلاك الموارد وفق الإمكانات المتاحة.

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

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

المرحلة السابعة: التحقق من النتائج وعرضها

بعد التنفيذ، لا ينتهي دور النظام.

يجب التحقق من أن النتيجة قابلة للعرض، وأنها تتوافق مع نوع السؤال، وأن أي حدود أو افتراضات مهمة واضحة للمستخدم.

فإذا كانت النتيجة فارغة، ينبغي التمييز بين عدم وجود سجلات وبين وجود خطأ في تعريف الفترة أو المرشحات.

وإذا كانت الأرقام غير متاحة بسبب الصلاحيات، يجب إظهار ذلك بدلًا من تقديم إجابة ناقصة وكأنها كاملة.

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

المرحلة الثامنة: التسجيل والتقييم المستمر

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

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

بهذا الشكل، يتحول النظام من تجربة تعتمد على جودة الإجابة في محادثة واحدة إلى منتج يمكن قياس أدائه وتحسينه مع مرور الوقت

29/10/2026

النقطة 6-7
لماذا لا يكفي أن نعطي النموذج مخطط قاعدة البيانات؟

بعد فهم السؤال، يحتاج النموذج إلى معرفة بنية البيانات التي سيعمل عليها.

وهنا تظهر أهمية مخطط قاعدة البيانات (Database Schema)، الذي يصف الجداول والأعمدة وأنواع البيانات والعلاقات بينها.

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

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

على سبيل المثال، قد نجد جدولًا باسم orders وآخر باسم order_items وثالثًا باسم payments. يستطيع النموذج استنتاج بعض العلاقات من الأسماء، لكنه لا يستطيع ضمان أن هذا الاستنتاج يطابق قواعد العمل الفعلية.

كما أن اسم العمود status لا يوضح وحده جميع الحالات الممكنة، ولا معنى كل حالة، ولا الحالات التي ينبغي احتسابها ضمن المبيعات.

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

هذه الطبقة ينبغي أن تتضمن:

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

بمعنى آخر، لا نريد أن يعرف النموذج أين توجد البيانات فحسب، بل نريده أن يعرف ماذا تعني، وكيف ترتبط ببعضها، وما القواعد التي يجب احترامها عند استخدامها.

وهذا أحد الأسباب التي تجعل Text-to-SQL في المؤسسات أكثر صعوبة من كتابة استعلامات على قواعد بيانات تجريبية.

7. بناء طبقة وسيطة باستخدام Views: هل نحتاج إلى إعادة تصميم قاعدة البيانات؟

بعد أن أدركنا أهمية فهم بنية البيانات، تظهر خطوة عملية يمكن أن تحدث فرقًا كبيرًا: إنشاء مجموعة من الـ Views المخصصة لتسهيل وصول النظام إلى المعلومات التي يحتاج إليها.

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

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

يمكننا بدلًا من ذلك إنشاء View مخصصة للتحليل، مثل vw_sales_analysis، تعرض البيانات اللازمة وفق تعريف تجاري متفق عليه، مع توثيق أعمدتها ومعانيها.

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

وتحقق هذه المقاربة عدة فوائد:

1. تقليل مساحة البحث: لا يحتاج النموذج إلى استكشاف جميع الجداول في قاعدة البيانات.
2. تقليل أخطاء الربط: يمكن تثبيت العلاقات المعقدة داخل Views واختبارها مسبقًا.
3. توحيد تعريفات البيانات: يمكن استخدام المنطق نفسه في أكثر من استعلام.
4. تبسيط الصلاحيات: يمكن منح المستخدم أو النظام حق القراءة من Views محددة بدلًا من إتاحة الجداول الأساسية.
5. تحسين قابلية الصيانة: يمكن تعديل بعض تفاصيل التنفيذ الداخلية دون تغيير الواجهة التي يعتمد عليها النظام، بشرط الحفاظ على عقد الـ View وتوافقه.

لكن يجب الانتباه إلى نقطة مهمة: إنشاء Views لا يحل المشكلة بالكامل.

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

لذلك، يجب التعامل معها باعتبارها مكونات معمارية تخضع للتوثيق والاختبار والإصدارات، لا مجرد وسيلة لتقليل عدد الجداول التي يراها النموذج.

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

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

29/10/2026

النقطة 4-5
التحدي الحقيقي: كيف نراقب SQL الذي يتغير باستمرار؟

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

الحل هو بناء منظومة من الضوابط المستقلة، بحيث لا يُسمح للاستعلام بالوصول إلى قاعدة البيانات إلا بعد اجتياز الاختبارات المطلوبة.

ومن المهم التمييز بين أربعة أنواع من التحقق:

أولًا: التحقق النحوي. هل الاستعلام مكتوب وفق قواعد SQL التي يدعمها محرك قاعدة البيانات؟

ثانيًا: التحقق البنيوي. هل الجداول والأعمدة موجودة؟ وهل العلاقات المستخدمة معروفة ومسموح بها؟

ثالثًا: التحقق الدلالي والتجاري. هل يعكس الاستعلام تعريف المؤشر المطلوب، وطريقة احتساب المبالغ، والفترة الزمنية، وحالة السجلات التي ينبغي تضمينها؟

رابعًا: التحقق الأمني والتشغيلي. هل يملك المستخدم صلاحية الوصول إلى البيانات؟ وهل الاستعلام للقراءة فقط؟ وهل تكلفته المتوقعة ضمن الحدود المسموح بها؟

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

والأهم أن هذه الضوابط يجب أن تعمل تلقائيًا مع كل طلب، لا أن تنتظر مراجعة يدوية بعد كل عملية توليد.

5. قبل كتابة SQL، يجب أن نفهم السؤال

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

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

«كم حققنا من المبيعات هذا الشهر؟»

هذا السؤال يبدو واضحًا، لكنه قد يخفي عدة احتمالات:

* هل المقصود المبيعات الإجمالية أم الصافية؟
* هل نعتمد تاريخ إنشاء الطلب أم تاريخ الدفع أم تاريخ الفاتورة؟
* هل نحتسب الطلبات الملغاة أو المرتجعات؟
* هل الشهر الحالي يعني الشهر التقويمي أم آخر ثلاثين يومًا؟
* هل المقصود جميع الفروع أم فرع محدد؟
* هل الأرقام تشمل الضرائب أم تستبعدها؟

إذا انتقل النظام مباشرة إلى كتابة SQL، فقد يختار إجابة واحدة من بين هذه الاحتمالات دون أن يدرك المستخدم وجود اختلاف بينها.

لذلك، يجب أن تتضمن المنهجية مرحلة مستقلة لفهم السؤال، وتحديد المقصود منه، قبل توليد أي استعلام.

يمكن أن تبدأ هذه المرحلة بتصنيف الطلب: هل هو سؤال عن مؤشر تجاري معروف؟ أم تحليل استكشافي؟ أم مقارنة زمنية؟ أم طلب لتفاصيل سجلات؟ أم سؤال لا تتوفر بياناته أصلًا؟

بعد ذلك، يحدد النظام العناصر الأساسية للسؤال:

* المؤشر المطلوب.
* الأبعاد التي نريد تقسيم النتائج وفقها.
* الفترة الزمنية.
* المرشحات والشروط.
* مستوى التفصيل المطلوب.
* التعريفات التجارية ذات الصلة.
* المعلومات الناقصة التي تستدعي سؤال المستخدم.

على سبيل المثال، بدلًا من توليد SQL فورًا لسؤال «كم حققنا من المبيعات؟»، يمكن للنظام أن يكتشف أن تعريف المبيعات غير محدد، فيسأل المستخدم:

«هل تريد إجمالي قيمة الطلبات أم صافي المبيعات بعد خصم المرتجعات؟»

هذا السؤال الإضافي ليس عائقًا أمام تجربة المستخدم، بل آلية لتجنب إنتاج إجابة دقيقة حسابيًا وخاطئة تجاريًا

29/10/2026

النطقة 2-3
ظهور النماذج اللغوية الكبيرة: هل أصبح Text-to-SQL ممكنًا؟

مع التطور الكبير الذي شهدته النماذج اللغوية الكبيرة (Large Language Models — LLMs)، أصبحت كتابة SQL من اللغة الطبيعية أكثر واقعية.

يمكن للمستخدم أن يسأل مثلًا:

«أريد معرفة إجمالي المبيعات لكل شهر خلال السنة الحالية، مع مقارنة النتائج بالسنة الماضية».

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

هذا هو جوهر مفهوم Text-to-SQL: تحويل السؤال المكتوب بلغة طبيعية إلى استعلام SQL قابل للتنفيذ.

لكن علينا التمييز بين أمرين مختلفين تمامًا:

1. أن يكون النموذج قادرًا على كتابة استعلام SQL صحيح من الناحية التقنية.
2. أن يكون الاستعلام صحيحًا من الناحية التجارية، وأن تعكس نتائجه ما قصده المستخدم فعلًا.

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

نجاح الاستعلام في التنفيذ لا يعني بالضرورة صحة الإجابة.

وهذه هي النقطة التي تجعل بناء نظام Text-to-SQL مؤسسي أكثر تعقيدًا من مجرد ربط نموذج لغوي بقاعدة بيانات.

3. لماذا لا نربط LLM مباشرة بقاعدة البيانات؟

قد يبدو الحل بسيطًا:

* نربط النموذج بقاعدة البيانات.
* نرسل إليه سؤال المستخدم.
* نطلب منه إنشاء استعلام SQL.
* ننفذ الاستعلام.
* نعرض النتائج.

لكن هذه البنية تفتقر إلى طبقة حقيقية للتحقق والحوكمة.

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

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

في النموذج التقليدي، نراجع الكود ثم نعتمده. وإذا تغيرت متطلبات العمل، نعيد تطويره واختباره وفق دورة واضحة.

أما في نظام Text-to-SQL الديناميكي، فإن الكود نفسه يصبح ناتجًا متغيرًا لكل سؤال، ولذلك لا تكفي مراجعة استعلام واحد لضمان سلامة جميع الاستعلامات المستقبلية.

كل استعلام جديد قد يحمل خطأ مختلفًا، مثل:

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

وقد يكون الاستعلام صحيحًا نحويًا ومنطقيًا وفق تفسير النموذج، لكنه يجيب عن سؤال مختلف قليلًا عن السؤال الذي قصده المستخدم.

لهذا السبب، لا يمكن الاعتماد على مراجعة بشرية لمرة واحدة، ولا على الثقة في قدرة النموذج على توليد الكود.

نحتاج إلى نقل جزء كبير من عملية المراجعة إلى نظام آلي يعمل مع كل استعلام، قبل تنفيذه وبعده