تضمين قواعد العمل خارج الموجّه (Prompt): التدوير الموزون، والملكية، والاستثناءات

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

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

لماذا لا يمكن للنموذج ببساطة اتباع قواعد التوجيه الموجودة في الموجّه؟

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

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

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

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

لا يوجد مصدر حقيقة مقروء. يمكن لقائد العمليات مراجعة تغيير في قاعدة من سطرين. لكن موجّهاً مكوناً من 2000 كلمة هو أمر مختلف تماماً، خاصة عندما يعتمد معنى منطق التوجيه على الصياغة.

النماذج اللغوية تجيب أيضاً على أسئلة محددة بطلاقة حتى عندما تكون مخطئة. وجدت دراسة لجامعة ستانفورد (RegLab و HAI) عام 2024 معدلات هلوسة تتراوح بين 69% إلى 88% في الاستفسارات القانونية المحددة للنماذج الرائدة في تلك الفترة. كانت تلك الدراسة عن القانون، وليس التوجيه، والنماذج الحالية تؤدي بشكل أفضل. لكن الدرس المستفاد ينطبق في كل الأحوال: يبدو النموذج واثقاً بنفس القدر سواء أصاب التفاصيل الدقيقة أم أخطأ فيها.

ماذا يجب أن يقرر النموذج، وماذا يجب أن تقرر القواعد؟

قسّم العمل بناءً على نوع التقييم الذي يتطلبه.

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

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

نقطة التسليم بين الاثنين هي قائمة قصيرة من الحقول المسماة. إذا انخفضت ثقة النموذج في حقل تعتمد عليه القواعد عن حد معين، يتم توجيه العميل المحتمل إلى بوابة موافقة تتضمن تدخلاً بشرياً (human-in-the-loop) بدلاً من الاعتماد على أفضل تخمين. في هذا التصميم، لا يختار النموذج شخصاً بالاسم أبداً. بل يقتصر دوره على وصف العميل المحتمل.

كيف يبدو ملف القواعد الذي يمكن لقائد العمليات قراءته؟

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

إليك مثال توضيحي. الأسماء والحدود هي مجرد أمثلة (placeholders) وليست توصيات.

version: 14
approved_by: ops-lead
rules:                      # evaluated top to bottom
  - id: R1-licensing
    filter: rep.licensed_for(lead.product, lead.state)
  - id: R2-ownership
    when: crm.active_owner(lead.account) exists
    assign: crm.active_owner(lead.account)
    window_days: 180
  - id: R3-away
    when: assignee.status == "away"
    assign: assignee.backup
  - id: R4-capacity
    filter: rep.open_leads < 25
  - id: R5-rotation
    method: smooth_weighted
    weights: {amira: 3, james: 2, priya: 1}
    skipped_turns: forfeit   # or: owed
fallback: human_review_queue

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

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

كيف يعمل التدوير الموزون عندما يتم بشكل صحيح؟

استخدم طريقة حتمية (deterministic)، وليس السحوبات العشوائية. الخيار المعتاد هو التدوير الدوري الموزون السلس (smooth weighted round-robin)، وهو نفس الأسلوب الذي تستخدمه خوادم الويب لتوزيع حركة المرور عبر الأجهزة. إليك كيف يعمل:

1. ▸قبل كل عميل محتمل، أضف وزن كل مندوب إلى رصيده الجاري.
2. ▸قم بتعيين العميل المحتمل للمندوب صاحب الرصيد الأعلى.
3. ▸اطرح إجمالي الوزن من رصيد الفائز.

بأوزان 3 و 2 و 1 يكون الإجمالي 6. ستة عملاء محتملين سيتم توزيعهم كالتالي:

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

قارن ذلك بالاختيار الموزون العشوائي، وهو تقريباً أفضل ما يمكن لنموذج عديم الحالة (stateless) القيام به. خذ مندوباً بحصة 50% من 30 عميلاً محتملاً في الأسبوع. يتبع عدده الأسبوعي توزيعاً ثنائي الحدين، Bin(30, 0.5). فرصة الحصول على 12 أو أقل، أو 18 أو أكثر، تبلغ حوالي 36%. لذا في حوالي أسبوع واحد من كل ثلاثة أسابيع، يكون هذا المندوب بعيداً عن الهدف بثلاثة عملاء على الأقل. على مدار ربع سنة، تتحول هذه الفجوات إلى نقاشات حول العدالة.

أين تخطئ الملكية والاستثناءات؟

تتركز معظم تكلفة نظام التوجيه في حالاته الاستثنائية (edge cases). هذه هي الحالات التي يجب التصميم لها بشكل صريح:

• ▸نطاقات البريد الإلكتروني المجانية. مطابقة الملكية بناءً على نطاق البريد الإلكتروني يعامل كل مرسل من gmail.com كحساب واحد. قم بالمطابقة بناءً على معرّف الحساب (account ID) أو سجل جهة اتصال تم التحقق منه بدلاً من ذلك.
• ▸المالكون المغادرون. لا يزال نظام CRM يدرج اسم مندوب غادر في شهر مارس. يجب أن تعني عبارة "المالك النشط" مستخدماً نشطاً، وإلا فلن يذهب العميل المحتمل إلى أي مكان.
• ▸الحسابات الأم والفرعية. قرر ما إذا كانت الملكية تنتقل إلى الشركات الفرعية. ثم اكتب هذا القرار كقاعدة.
• ▸الملكية القديمة. بدون فترة زمنية محددة، فإن الحساب الذي تم التواصل معه مرة واحدة في 2023 سيظل مملوكاً للأبد. فترة زمنية مثل 180 يوماً، تحددها الشركة، تسد هذه الفجوة.
• ▸قوائم الانتظار الاحتياطية غير المراقبة. يكون الخيار الاحتياطي آمناً فقط إذا كان هناك من يملكه. قوائم الانتظار لها حدود أيضاً. توثق Salesforce حداً يبلغ 200,000 سجل لقائمة الانتظار في Omni-Channel والذي يظهر للوكلاء كخطأ. امنح قائمة الانتظار الاحتياطية مالكاً محدداً بالاسم وتنبيهاً بناءً على مدة الانتظار.

ماذا يجب أن يسجل سجل القرارات؟

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

• ▸الحقول التي استخرجها النموذج، مع درجات الثقة الخاصة بها
• ▸إصدار ملف القواعد المعمول به في تلك اللحظة
• ▸كل قاعدة تم تقييمها، وما إذا كانت قد طابقت، أو فلترت، أو تم تجاوزها
• ▸مجموعة المؤهلين وأرصدة التدوير وقت اتخاذ القرار
• ▸المعيَّن النهائي، أو سبب تحويل العميل المحتمل للمراجعة

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

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

الأسئلة الشائعة

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

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

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