مراقبة الذكاء الاصطناعي في الإنتاج: عبدالله عبدالرحيم سنكر وسجلات ما تكذب

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

ليش المراقبة هنا غير مراقبة موقع عادي؟

الموقع العادي لما يتعطل، يتعطل بصوت عالي: صفحة خطأ، رمز 500، تنبيه يرن. نظام الذكاء الاصطناعي يقدر يفشل وهو يرجع استجابة ناجحة تماماً. الطلب نجح تقنياً، بس الجواب غلط، أو فاضي، أو طويل بلا داعي، أو جاء من نموذج احتياطي أضعف بدون ما يدري أحد. عشان كذا تحتاج تراقب ثلاث طبقات: هل اشتغل؟ كم كلّف؟ وهل كان الجواب زين؟

السجل: وش تكتب عن كل استدعاء

لو ما سجّلت الشي، ما تقدر تسأل عنه بعدين. هذي الحقول اللي تستاهل تنحفظ مع كل استدعاء للنموذج:

• معرّف الطلب ومعرّف المحادثة، عشان تربط كل الاستدعاءات اللي صارت في محادثة وحدة.
• النموذج اللي جاوب فعلاً، مو النموذج اللي طلبته. الفرق مهم لو عندك نظام احتياطي.
• عدد التوكنز الداخلة والخارجة، والتوكنز المقروءة من الكاش إن وُجد.
• زمن الاستجابة الكلي، وزمن أول توكن لو تعرض الجواب متدفقاً.
• سبب انتهاء الجواب: اكتمل طبيعياً، أو انقطع لأنه وصل حد الطول، أو توقف لاستدعاء أداة.
• الأدوات اللي انطلبت ومدخلاتها ونتيجتها، وعدد الخطوات في المهمة.
• إصدار التعليمات (البرومبت) المستخدم، عشان لما تعدّل تعرف مين قبل ومين بعد.
• تقييم المستخدم لو عندك زر إعجاب أو عدم إعجاب.

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

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

التنبيهات: اللي يستاهل يوقظك فقط

أسرع طريقة تخلي فريقك يتجاهل التنبيهات إنك تكثّرها. ركّز على اللي يعني مشكلة حقيقية:

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

التكلفة: قسّمها لين تفهمها

رقم «صرفنا كذا هالشهر» ما يساعدك تقرر شي. قسّمه: كم تكلف المحادثة الواحدة في المتوسط؟ وأي ميزة في منتجك تاكل أكثر الميزانية؟ وأي نوع من الأسئلة يطوّل المحادثة؟ لما تقسم، تلقى غالباً إن جزءاً صغيراً من المحادثات يستهلك جزءاً كبيراً من المصروف، مثل محادثات طويلة جداً يتراكم فيها السياق، أو مهمة بسيطة تروح لنموذج كبير وهي تقدر تنحل بنموذج أرخص.

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

الجودة: المراقبة اللي ما يسويها جهاز لحاله

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

ولما يكون عندك تحويل احتياطي بين نماذج، يصير سؤال «مين جاوب؟» جزءاً من الجودة نفسها. محادثة موقع azhal.io مثلاً تستدعي النماذج عبر OpenRouter مع انتقال احتياطي بين أكثر من نموذج، والفكرة من هالتصميم إن المستخدم ما ينقطع لو تعطّل نموذج. لكن أي نظام بهالشكل يحتاج يسجل النموذج اللي جاوب فعلاً، وإلا ممكن تقرأ جواباً ضعيفاً وتلوم التعليمات وهي بريئة، والسبب إن الجواب جاء من البديل.

النظام اللي ما تشوفه، ما تقدر تحسّنه ولا تحسب تكلفته. على هالمبدأ يبني عبدالله عبدالرحيم بن سنكر الكندي أنظمته، وفي منصة أزهل الرقمية، أول لوحة نبنيها مع أي مشروع ذكاء اصطناعي فيها ثلاثة أرقام بس: كم محادثة، كم كلفت، وكم واحدة منها انتهت بتحويل أو تقييم سلبي. الباقي يجي مع الوقت.