كيف تربط الذكاء الاصطناعي بموقعك أو نظامك؟

لنفترض أن لديك موقعًا، وتريد أن يكتب العميل سؤالًا مثل:

«أي منتج يناسب احتياجي؟»

ثم يحصل على إجابة من نظام ذكاء اصطناعي.

من الخارج تبدو العملية كأن الموقع «تحدث مع AI». لكن خلف هذا الزر توجد عدة أجزاء تعمل معًا، وفهم هذه الأجزاء هو ما يجعل الربط آمنًا وقابلًا للتطوير بدل أن يكون مجرد تجربة تعمل على جهاز المطور.

لنرسم الرحلة أولًا

المستخدم
   ↓
الموقع
   ↓
Backend
   ↓
AI API
   ↓
Backend
   ↓
المستخدم

هذا أبسط شكل ممكن للتكامل.

المستخدم يرسل النص، Backend يستقبله، يرسل Request إلى مزود الذكاء الاصطناعي، يستقبل Response ثم يعيد النتيجة إلى الموقع.

لكن لماذا لا نرسل الطلب مباشرة من Browser إلى AI API؟

API Key لا يجب أن تكون داخل JavaScript العامة

معظم خدمات AI التي تستخدم API تحتاج إلى Credential مثل API Key.

إذا وضعت المفتاح داخل JavaScript التي تصل إلى Browser، يستطيع الزائر الاطلاع عليه من Developer Tools أو Network Requests.

بعدها قد يستخدم المفتاح على حسابك ويستهلك الرصيد أو يصل إلى وظائف لم تقصد إتاحتها.

إذًا ما وظيفة Backend؟

Backend ليست مجرد وسيط يمرر النص.

هي المكان الذي تستطيع فيه التحكم في العملية.

مثلًا تستطيع:

• التحقق من أن المستخدم مسجل.
• تحديد عدد الطلبات المسموحة.
• إخفاء API Keys.
• تنظيف Input قبل إرسالها.
• إضافة تعليمات للنموذج.
• حفظ سجل العملية.
• منع بعض أنواع الاستخدام.
• حساب التكلفة أو الاستخدام.

وهذا يجعل Backend الطبقة التي تفصل بين المستخدم ومزود AI.

الطلب إلى AI ليس «سؤالًا» فقط

في أبسط صورة، أنت ترسل Input وتستقبل Output.

لكن النظام الحقيقي قد يرسل معها Context وتعليمات ومعلومات عن العملية الحالية.

مثلًا إذا كان لديك متجر، قد تكون البيانات المرسلة:

{
  "question": "أريد لابتوب مناسب للتصميم",
  "budget": 500,
  "currency": "OMR",
  "available_products": [...]
}

هنا لا تطلب من النموذج أن يعرف مخزون متجرك من تلقاء نفسه؛ أنت تعطيه المعلومات التي يحتاجها لاتخاذ القرار.

AI لا تعرف بيانات موقعك تلقائيًا

هذه نقطة تسبب كثيرًا من الالتباس.

إذا ربطت نموذجًا بموقعك اليوم، فهذا لا يعني أنه أصبح يعرف:

• منتجاتك الحالية.
• طلبات العملاء.
• أسعارك.
• مواعيد الموظفين.
• المخزون.
• سياسات شركتك الداخلية.

يجب أن توصل هذه البيانات إليه بالطريقة المناسبة.

أحيانًا تكون البيانات جزءًا من Request نفسها، وأحيانًا يتم جلبها من Database أو API أخرى قبل سؤال النموذج.

مثال: مساعد يجيب عن المنتجات

العميل يسأل:

«هل عندكم شاشة 4K أقل من 150 ريال؟»

الطريقة الضعيفة هي إرسال السؤال إلى AI وحدها وانتظار أن تخمن.

الطريقة الأفضل:

1. يستقبل النظام سؤال العميل.
2. يبحث في Catalog الحقيقي.
3. يجلب المنتجات المتوفرة التي تطابق الشروط.
4. يرسل النتائج مع السؤال إلى AI.
5. تقوم AI بصياغة جواب مفهوم.

هنا Database هي مصدر الحقيقة، والذكاء الاصطناعي يساعد في فهم السؤال وصياغة الرد.

وماذا عن معلومات كثيرة جدًا؟

لنفترض أن لديك مئات صفحات الوثائق أو آلاف المقالات أو ملفات داخلية.

إرسالها كلها مع كل سؤال سيكون مكلفًا وغير عملي.

هنا تظهر فكرة RAG.

RAG اختصار لـ Retrieval-Augmented Generation.

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

المسار يصبح مثلًا:

سؤال المستخدم
      ↓
البحث في المعرفة
      ↓
أكثر النتائج ارتباطًا بالسؤال
      ↓
AI
      ↓
الإجابة

Embeddings ليست الإجابة نفسها

عند بناء بحث دلالي، قد تستخدم Embeddings لتحويل المحتوى إلى تمثيل رقمي يساعد النظام على قياس التشابه بين المعاني.

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

بعد استرجاع المحتوى المناسب يأتي دور نموذج اللغة في صياغة الجواب.

هل تحتاج Vector Database دائمًا؟

لا.

إذا كانت لديك عشر صفحات فقط ويمكن جلب المعلومات المطلوبة بطريقة مباشرة، فقد يكون بناء Vector Database كاملة تعقيدًا غير ضروري.

ابدأ بأبسط طريقة تحل المشكلة.

عندما تكبر كمية المعرفة ويصبح Search العادي غير كافٍ، يمكن الانتقال إلى بحث دلالي أكثر تقدمًا.

ربط AI لا يعني Chatbot فقط

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

يمكن استخدام AI داخل النظام دون أن يرى المستخدم Chat أصلًا.

مثلًا:

• تصنيف رسائل العملاء.
• استخراج معلومات من مستند.
• تلخيص Ticket طويلة.
• اقتراح رد لموظف الدعم.
• تحليل Feedback.
• توليد وصف أولي لمنتج.
• ترجمة محتوى.
• تحويل نص غير منظم إلى بيانات منظمة.

مثال آخر: رسالة دعم تدخل النظام

بدل أن تصل كل الرسائل إلى Queue واحدة، يمكن أن يحدث التالي:

رسالة جديدة
   ↓
AI تصنف الموضوع
   ↓
Billing ─────→ فريق الفواتير
Technical ───→ الدعم الفني
Sales ───────→ المبيعات

هنا AI لا تتحدث مع العميل بالضرورة. هي تعمل في الخلفية كجزء من Workflow.

هنا يأتي دور Webhook

Webhook طريقة تجعل نظامًا يخبر نظامًا آخر بأن حدثًا حصل.

بدل أن تسأل كل دقيقة:

«هل وصل طلب جديد؟»

يرسل المتجر Request فور وصول الطلب.

يمكن أن يكون المسار:

طلب جديد
   ↓
Webhook
   ↓
Workflow
   ↓
AI
   ↓
تصنيف أو استخراج بيانات
   ↓
CRM / Email / Database

وهذه الطريقة مناسبة عندما تريد إدخال AI ضمن عمليات موجودة أصلًا.

API وWebhook يؤديان وظيفتين مختلفتين

API تستخدم عادة عندما يريد نظام أن يطلب شيئًا من نظام آخر.

Webhook تستخدم عندما يريد نظام أن يخبرك بأن حدثًا وقع.

مثلًا:

موقعك يستخدم API ليسأل نموذج AI عن تحليل نص.

وبوابة الدفع تستخدم Webhook لتخبر موقعك بأن عملية الدفع اكتملت.

لا تجعل كل شيء يمر بالذكاء الاصطناعي

إذا كان لديك Rule واضحة مثل:

إذا كان المبلغ أكبر من 100 ريال أرسل الطلب للمدير.

فلا تحتاج AI لتقرر ذلك.

استخدم Logic عادية.

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

Structured Output توفر عليك مشاكل كثيرة

أحيانًا لا تريد جوابًا بشريًا مثل:

«يبدو أن الرسالة تتعلق بالفواتير.»

بل تريد نتيجة يستطيع البرنامج قراءتها:

{
  "department": "billing",
  "priority": "high",
  "language": "ar"
}

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

لا تثق في Output دون تحقق

حتى عندما تطلب بيانات منظمة، يجب أن يتحقق Backend من النتيجة.

مثلًا:

• هل الحقل المطلوب موجود؟
• هل القيمة ضمن الخيارات المسموحة؟
• هل الرقم ضمن نطاق منطقي؟
• هل AI اقترحت Action يملك المستخدم صلاحية تنفيذها؟

النموذج جزء من النظام، وليس بديلًا عن Validation.

أخطر تكامل هو الذي يعطي AI صلاحيات أكثر من حاجتها

تخيل Agent تستطيع قراءة البريد وحذف الملفات وإرسال الأموال وتعديل Database.

كلما زادت الأدوات، زادت النتائج التي يمكن أن تترتب على قرار خاطئ.

لذلك استخدم مبدأ Least Privilege.

أعطِ التكامل أقل صلاحيات يحتاجها لإنجاز المهمة.

ويمكن وضع Approval بشري قبل العمليات الحساسة.

مثال: AI تكتب الرسالة والإنسان يرسلها

ليس ضروريًا أن تقوم Automation بكل شيء.

يمكن أن يكون المسار:

رسالة العميل
   ↓
AI تفهم الموضوع
   ↓
AI تقترح الرد
   ↓
الموظف يراجع
   ↓
Approve
   ↓
إرسال

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

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

كثير من AI APIs تحاسب بحسب الاستخدام.

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

راقب:

• عدد Requests.
• حجم Input.
• حجم Output.
• النموذج المستخدم.
• العمليات التي يمكن تنفيذها دون AI.

ولا ترسل عشر صفحات من Context عندما يحتاج السؤال إلى فقرتين فقط.

Rate Limiting تحمي الميزانية والنظام

إذا كان Endpoint متاحًا دون حدود، يستطيع User أو Bot إرسال عدد ضخم من الطلبات.

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

ضع حدودًا مناسبة بحسب المستخدم أو الحساب أو IP وطبيعة الخدمة.

بعض العمليات لا يجب أن تجعل المستخدم ينتظرها

إذا كانت المهمة تحتاج عشرات الثواني أو عدة خطوات، لا تجعل HTTP Request مفتوحة بلا نهاية.

يمكن تحويلها إلى Background Job:

المستخدم يرسل المهمة
        ↓
النظام يقبلها
        ↓
Queue
        ↓
Worker
        ↓
AI Processing
        ↓
حفظ النتيجة
        ↓
إشعار المستخدم

هذه البنية تصبح مهمة أكثر عندما يزداد الاستخدام.

ماذا يحدث عندما تفشل AI API؟

المزود قد يكون بطيئًا أو يعيد Error أو يتوقف الاتصال مؤقتًا.

لا تجعل التطبيق كله يتوقف لأن خدمة خارجية لم تستجب.

حدد مسبقًا:

• Timeout.
• عدد Retries.
• متى لا يجب إعادة المحاولة.
• ماذا يرى المستخدم عند الفشل.
• كيف تسجل Error.

Logs مهمة لكن لا تسجل كل شيء بلا تفكير

Logs تساعدك على معرفة لماذا فشل Request أو كم استغرق.

لكن Prompt قد تحتوي معلومات شخصية أو بيانات حساسة.

لذلك لا تجعل Debug Logs مستودعًا دائمًا لكل ما يكتبه المستخدمون.

سجل ما تحتاجه للتشخيص مع مراعاة نوع البيانات ومدة الاحتفاظ بها ومن يستطيع الوصول إليها.

احمِ نفسك من Prompt Injection

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

قد يحتوي المحتوى على نص يحاول دفع النموذج إلى تجاهل التعليمات أو تنفيذ Action غير مقصودة.

الحماية لا تعتمد على Prompt تقول «لا تستمع للمستخدم» فقط.

الأهم هو أن Backend نفسها تتحكم في الأدوات والصلاحيات وتتحقق من أي عملية حساسة قبل تنفيذها.

ابدأ بتكامل صغير له نتيجة قابلة للقياس

لا تبدأ مشروعك بعنوان:

«سنضيف الذكاء الاصطناعي إلى الشركة.»

ابدأ بمهمة واضحة مثل:

• تصنيف Tickets الواردة.
• استخراج رقم الفاتورة من PDF.
• اقتراح رد للدعم.
• البحث داخل Documentation.
• تلخيص طلب طويل قبل وصوله للموظف.

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

ثم وسّع المسار بدل إعادة بنائه

إذا نجح أول Workflow، يمكن إضافة الخطوات تدريجيًا.

مثلًا يبدأ النظام هكذا:

Form
 ↓
AI Classification
 ↓
Email

وبعد فترة يصبح:

Form
 ↓
Validation
 ↓
AI Classification
 ↓
CRM
 ↓
Assign Employee
 ↓
Generate Draft
 ↓
Human Approval
 ↓
Send
 ↓
Analytics

وهنا يتحول «ربط AI بالموقع» من زر تجريبي إلى جزء حقيقي من عملية العمل.

قبل إطلاق التكامل

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

• نص فارغ.
• رسالة طويلة جدًا.
• لغة مختلفة.
• طلب غير متعلق بالخدمة.
• محاولة إدخال تعليمات ضارة.
• انقطاع AI API.
• Output ناقصة.
• نفس الطلب يتكرر مرتين.

إذا عرفت ماذا سيفعل النظام في هذه الحالات، فأنت لا تملك Demo فقط؛ لديك تكامل تستطيع تشغيله أمام مستخدمين حقيقيين.