في السنوات الأخيرة أصبح بناء واجهة محادثة فوق نموذج لغوي أمرًا سهلًا نسبيًا. تضع مربعًا للرسائل، تربطه بـ API لنموذج لغوي، ثم تعرض الإجابة للمستخدم. لكن هذا ليس ما كنت أريده من Sadeem AI. الفكرة الأساسية كانت مختلفة: ماذا لو كان الذكاء الاصطناعي قادرًا على فهم النظام الذي يعمل داخله، بدل أن يكون مجرد نموذج منفصل عنه؟ من هنا بدأ Sadeem AI. من Chatbot إلى System-Aware AI Sadeem AI هو مساعد محادثي مدمج داخل شبكة سديم، ومهمته لا تقتصر على توليد النصوص. المساعد يمكنه التعامل مع المعرفة الموجودة داخل المنصة، مثل المكتبة والمقالات والخدمات، بحيث تصبح المحادثة وسيلة للوصول إلى النظام نفسه. بدل أن يسأل المستخدم: أين أجد هذا الكتاب؟ ثم يبحث بنفسه في عشرات الصفحات، يستطيع أن يسأل المساعد مباشرة. وبدل أن يحتاج إلى معرفة بنية المنصة أو أسماء الأقسام، يتعامل معها من خلال لغة طبيعية. وهنا يظهر الفرق بين: LLM + Chat UI وبين: LLM + Application Context + Data + Tools الأول مجرد محادثة. الثاني يمكن أن يصبح جزءًا من النظام. النموذج اللغوي ليس النظام من الأخطاء المعمارية الشائعة التعامل مع النموذج اللغوي وكأنه التطبيق بأكمله. لكن النموذج لا يعرف تلقائيًا بيانات منصتك، ولا ينبغي أن تمنحه وصولًا مباشرًا وغير محدود إلى كل شيء. لذلك يصبح دور الـBackend أساسيًا. يمكن تصور البنية بشكل مبسط: User ↓ Sadeem AI ↓ AI Orchestration ↓ Context / Tools ↓ Sadeem Backend ↓ Database / Services النموذج مسؤول عن فهم اللغة والاستدلال وتوليد الإجابة. أما التطبيق فهو المسؤول عن: * البيانات الحقيقية. * الصلاحيات. * تنفيذ العمليات. * التحقق من المدخلات. * تسجيل الأحداث. * حماية الموارد. * تحديد ما يستطيع المساعد الوصول إليه. وهذا الفصل مهم جدًا. لا ينبغي أن يكون الـLLM هو مصدر الحقيقة. مصدر الحقيقة هو النظام وبياناته. لماذا نحتاج إلى Context؟ إذا سألت نموذجًا لغويًا سؤالًا عامًا، يمكنه الإجابة اعتمادًا على المعرفة التي تدرب عليها. لكن إذا سألت: ما الكتب الموجودة في مكتبة سديم؟ فهذا سؤال يعتمد على بيانات متغيرة. النموذج لا يستطيع تخمين قاعدة البيانات الحالية. لذلك يحتاج إلى Context من التطبيق. مثلًا: User Question ↓ Understand Intent ↓ Retrieve Relevant Data ↓ Provide Context to Model ↓ Generate Response بهذه الطريقة يصبح النموذج طبقة ذكاء فوق البيانات، وليس بديلًا عنها. الأدوات أهم من الكلام المرحلة الأكثر أهمية في تطوير المساعد ليست أن نجعله يتحدث بطريقة أكثر طبيعية. بل أن نجعله يفعل أشياء مفيدة. يمكن للمساعد، بحسب الصلاحيات والأدوات المتاحة له، أن يتعامل مع وظائف مختلفة داخل النظام. وهنا ننتقل من مفهوم: Question → Answer إلى: Intent → Tool → Result → Response وهذا التحول هو أحد أهم الأفكار في بناء تطبيقات الذكاء الاصطناعي الحديثة. المستخدم لا يريد دائمًا نصًا. أحيانًا يريد نتيجة. التحدي الحقيقي: التحكم كلما زادت صلاحيات المساعد، زادت المخاطر. إذا أصبح قادرًا على الوصول إلى البيانات وتنفيذ العمليات، فلا يكفي أن نقول: “النموذج ذكي، وسيفهم ماذا يفعل.” هذا ليس تصميمًا هندسيًا. يجب أن تكون هناك حدود واضحة لما يمكن للمساعد فعله. مثلًا: AI ↓ Allowed Tool ↓ Validation ↓ Authorization ↓ Execution النموذج يقترح العملية. لكن الـBackend هو الذي يقرر إن كانت العملية مسموحة أصلًا. وهذه نقطة جوهرية: الذكاء الاصطناعي يقترح، والنظام يتحقق وينفذ. Sadeem AI كتجربة هندسية بناء Sadeem AI لم يكن بالنسبة لي مجرد إضافة ميزة AI إلى منصة موجودة. كان تجربة لفهم سؤال أكبر: كيف ندمج نموذجًا لغويًا داخل نظام برمجي حقيقي دون أن نفقد السيطرة على النظام؟ هذا السؤال يقود إلى مجموعة واسعة من المفاهيم: Context Engineering، Tool Calling، Authentication، Authorization، Retrieval، Caching، Rate Limiting، Observability، وAI Security. وهنا تصبح هندسة الذكاء الاصطناعي امتدادًا طبيعيًا لهندسة الـBackend، وليست مجالًا منفصلًا عنها تمامًا. الخلاصة Sadeem AI ليس مجرد Chatbot يجيب عن الأسئلة. الفكرة هي بناء طبقة ذكاء تستطيع فهم طلب المستخدم، الوصول إلى السياق المناسب، استخدام الأدوات المتاحة، ثم إنتاج نتيجة مرتبطة بالنظام الحقيقي. وهذا يقودنا إلى مبدأ بسيط: لا تجعل الذكاء الاصطناعي هو النظام. اجعله طبقة ذكية فوق النظام. وهذا، في رأيي، هو أحد الفروق الأساسية بين إضافة نموذج لغوي إلى تطبيق، وبين هندسة تطبيق يعمل بالذكاء الاصطناعي.