يمكن لوكيل الذكاء الاصطناعي أن ينجح في العرض التجريبي ويفشل بعد أسبوع من التشغيل. قد يجيب بسرعة لكنه يستخدم مصدراً قديماً، أو ينفذ أداة صحيحة في الوقت الخطأ، أو يرسل رسالة غير مناسبة، أو يكرر العملية عند فشل الشبكة. لذلك لا يكفي اختيار نموذج قوي أو كتابة برومبت طويل؛ تحتاج إلى تقييم وكلاء الذكاء الاصطناعي وحواجز الحماية بطريقة تشبه اختبار أي نظام إنتاج. هذا الدليل يشرح كيف تبني مجموعة اختبارات، تراقب التتبع، تضبط الصلاحيات، وتقرر متى يمر الوكيل ومتى يتوقف أو يطلب إنساناً.
الخلاصة التنفيذية
- تقييم الوكيل يقيس المهمة كاملة: فهم الطلب، اختيار الأداة، المدخلات، النتيجة، والسلامة، لا جودة نص منفرد فقط.
- ابدأ بمعايير قبول قابلة للملاحظة ومجموعة أمثلة حقيقية منقحة، ثم أضف حالات فشل وإساءة استخدام.
- حواجز الحماية تشمل الصلاحيات، التحقق من المخرجات، حدود التكلفة والوقت، الموافقة البشرية، وسجل التتبع.
- المقيّم الآلي يساعد على التوسع لكنه لا يلغي مراجعة الخبراء، خاصة في قرارات مالية أو قانونية أو تتعلق بالعملاء.
لماذا تفشل الوكلاء بعد نجاح النموذج الأولي؟
النموذج الأولي غالباً يختبر محادثة قصيرة ومهمة واضحة بمدخلات مثالية. أما التشغيل الحقيقي فيضيف طلبات غامضة، مستندات غير منظمة، صلاحيات مختلفة، خدمات تتوقف، وتغيرات في البيانات. الوكيل لا يكتفي بكتابة جواب؛ قد يقرر استخدام أداة، يمرر حججاً إليها، يقرأ نتيجة، ثم يكرر الدورة. كل خطوة تضيف احتمالاً للخطأ أو للاستخدام غير المقصود.
قد يكون الجواب اللغوي ممتازاً لكنه مبني على نتيجة بحث خاطئة. وقد تستدعي الأداة الصحيحة لكن بمدخل غير كامل. وقد ينجح التدفق عشر مرات ثم يكرر إنشاء سجل بسبب إعادة محاولة بعد انقطاع. لذلك ينبغي أن يجيب التقييم عن أسئلة تشغيلية: هل اختار الوكيل المصدر الصحيح؟ هل احترم الصلاحية؟ هل توقف عندما لم يجد دليلاً؟ هل قدّم نتيجة يمكن للمستخدم مراجعتها؟
هذا هو الفرق بين تقييم نموذج وتقييم وكيل. في النموذج تقارن إجابة بإجابة مرجعية. في الوكيل تفحص سلسلة أفعال وقرارات ونتائج. اقرأ أيضاً شرح MCP لفهم طبقة الأدوات، ودليل RAG لفهم مشكلات الاسترجاع؛ كلاهما يدخل في سجل التقييم عندما يبني الوكيل جواباً من مصادر أو يستدعي نظاماً.
ما المقصود بالتقييم والـGuardrails؟
التقييم هو عملية قياس منظمة تسأل: هل حقق النظام المطلوب بدرجة مقبولة؟ قد يكون القياس يدوياً أو آلياً أو مزيجاً. أما حواجز الحماية فهي قواعد وتصميمات تمنع الأفعال غير المرغوبة أو تحد آثارها، مثل منع الوصول إلى ملف لا يحق للمستخدم رؤيته، أو وضع سقف لعدد استدعاءات الأداة، أو طلب موافقة قبل إرسال رسالة.
لا تضع الحاجز داخل النص فقط. عبارة «لا ترسل معلومات حساسة» لا تحميك إذا كانت الأداة نفسها تقبل قاعدة بيانات كاملة. طبّق الحماية في طبقة الهوية والصلاحية، وفي مخطط المدخلات، وفي بوابة التنفيذ، وفي المراقبة. لا تجعل النموذج الحكم الوحيد على سلامة قراره؛ أعطه مساحة ضيقة وأدوات محددة ثم تحقق من النتيجة خارج النموذج.
ابدأ بمواصفة مهمة لا بجدول درجات عام
اكتب وصفاً دقيقاً للمهمة: من المستخدم؟ ما المدخل؟ ما المصادر المسموحة؟ ما الإخراج المطلوب؟ ما الحالات التي يجب أن يرفضها الوكيل؟ ما الذي يغير نظاماً خارجياً؟ مثال: «صنف تذاكر المنتج وأعد مسودة ملخص، ولا ترسل أو تغلق التذكرة، واستشهد بمصدر الحل إن وجد». هذه المواصفة تساعدك على بناء اختبار يمكن لفريق العمل فهمه.
بعد ذلك عرّف معايير القبول. قد تشمل: صحة تصنيف، اكتمال الحقول، دقة الاقتباس، عدم كشف بيانات، عدم استدعاء أداة غير مصرح بها، زمن أقصى، وتكلفة لكل مهمة. لا تضع كل شيء في درجة واحدة. قد يقبل مدير خدمة العملاء خطأ أسلوبياً بسيطاً، لكنه لا يقبل كشف اسم عميل أو إغلاق طلب بلا مراجعة.
أضف أمثلة إيجابية وسلبية وحدّية. الإيجابي يملك معلومات مكتملة. السلبي يطلب فعلاً خارج صلاحية الوكيل. والحدّي يحتوي لغة مبهمة أو نصاً متضارباً أو تعليمات خفية. التقييم الذي لا يضم الفشل سيعطيك ثقة زائفة.
| المعيار | سؤال الاختبار | مثال فشل |
|---|---|---|
| صحة المهمة | هل نفذ الهدف المطلوب؟ | صنف التذكرة في منتج خاطئ |
| اختيار الأداة | هل استدعى الأداة المناسبة؟ | بحث في ملف غير معتمد |
| سلامة المدخل | هل أرسل أقل بيانات لازمة؟ | تمرير نص عميل كامل لخدمة غير لازمة |
| النتيجة | هل الحقول صحيحة ومكتملة؟ | JSON ناقص أو قيمة مختلقة |
| المصدر | هل الاستشهاد يثبت الجملة؟ | رابط صحيح لكن لا علاقة له بالادعاء |
| السلوك | هل توقف عند الخطر؟ | إرسال رسالة بلا موافقة |
| التشغيل | هل يتعامل مع الفشل؟ | تكرار الإجراء بعد انقطاع |
تتبع الوكيل: لا تكتف بالسجل النهائي
التتبع أو tracing يسجل الرحلة التي أدت إلى النتيجة: طلب المستخدم، نسخة التعليمات، النموذج، الأدوات التي ظهرت، الأداة المختارة، المدخلات المنقحة، النتائج، عدد التكرارات، الزمن، والتكلفة. لا يعني ذلك حفظ كل البيانات بلا حدود؛ اخفِ الأسرار وقلل المحتوى الحساس وحدد مدة الاحتفاظ. لكنه يعني أن مراجعاً يستطيع فهم سبب فشل حالة معينة.
من دون التتبع قد ترى أن الوكيل كتب «لا يمكنني المساعدة»، ولا تعرف أنه فشل في المصادقة أو استرجع مقطعاً فارغاً أو رفض أداة بسبب مخطط غير صحيح. مع التتبع تستطيع فصل خطأ النموذج عن خطأ التكامل وعن خطأ البيانات. هذه المعرفة تمنع تبديل النموذج عشوائياً عندما يكون الخلل في خدمة المصدر.
اجعل لكل تشغيل معرفاً، واربطه بالمستخدم والمهمة والإصدار، لكن لا تستخدم معرفاً يكشف معلومات شخصية في عنوان عام. إذا كان المشروع يشمل عملاء أو مستندات حساسة، ضع سياسة وصول لسجلات التتبع نفسها؛ السجل قد يكون أكثر حساسية من الجواب.
المقيّم الآلي والمراجعة البشرية
يمكن لمقيّم آلي أن يفحص مخرجات كثيرة بسرعة وفق Rubric، مثل وجود المصدر، تطابق الحقول، أو ملاءمة النبرة. وتوفر مشاريع مثل OpenAI Evals ومراجع Graders أفكاراً لتقييم واسع بالمقاييس أو الحكام الآليين. لكن المقيّم الآلي نفسه قد يخطئ أو يتأثر بصياغة الإجابة. لا تستخدمه ليمنح نظاماً حساساً شهادة نهائية بلا عينات بشرية.
قسّم الأدوار: الآلة تفرز الحالات وتكشف الأنماط، والخبراء يراجعون عينة مركزة والحالات العالية المخاطر. إذا كان الوكيل يقترح قيداً مالياً، اجعل محاسباً يراجع. إذا كان يفرز محتوى طبي أو قانوني، اجعل المختص يحدد معيار القبول. سجّل اختلافات المقيّم الآلي والبشري؛ إنها فرصة لتحسين المعيار أو الأمثلة.
حواجز حماية عملية قبل أي أداة تنفيذ
أقل صلاحية
أنشئ أداة قراءة محددة بدلاً من اتصال شامل. افصل قراءة العميل عن تعديل سجله، واجعل كل فعل يحتاج صلاحية مستقلة. لا يمنح الوكيل صلاحية المدير لأن النموذج قد يحتاج الوصول إلى سجل واحد.
المعاينة قبل التنفيذ
اعرض للمستخدم ما ينوي الوكيل فعله: الرسالة، المستلم، السجل، والقيم التي ستتغير. اطلب تأكيداً صريحاً. في العمليات غير القابلة للعكس، اجعل المعاينة مساراً إلزامياً لا خياراً تجميلياً.
حدود الكلفة والتكرار
حدد أقصى عدد خطوات وزمن واستدعاءات وأدوات. استخدم معرفات idempotency كي لا يؤدي إعادة المحاولة إلى إنشاء طلب أو دفع مرتين. أوقف التشغيل عند حلقة أو نتيجة غير متوقعة.
تحقق من المخرجات
افحص البنية والأنواع والقيم المسموحة خارج النموذج. لا تمرر نصاً حراً إلى SQL أو بريد أو API تنفيذية. استخدم قائمة سماح ورفض الحالات الناقصة.
عزل التعليمات غير الموثوقة
المستند أو رسالة العميل بيانات للقراءة، وليست تعليمات للنظام. افصلها في مدخل واضح، واختبر prompt injection وطلبات استخراج الأسرار. لا تضع الأسرار في السياق إذا لم تكن لازمة.
تقييم الاسترجاع والأداة قبل تقييم البلاغة
في وكيل يعتمد على RAG، سجّل المقاطع التي استُرجعت وقارنها بالمقطع المرجعي. إذا لم يصل الدليل الصحيح، فلن ينقذك تحسين صياغة الجواب. وفي وكيل يستخدم CRM أو نظام تذاكر، تحقق من أن الأداة أعادت السجل الصحيح قبل أن تحكم على النص. ابنِ اختباراً لكل طبقة: بحث، اختيار أداة، مخطط مدخل، تنفيذ، ثم صياغة. هذا التقسيم يجعل الإصلاح أسرع ويمنع إلقاء اللوم على النموذج في كل مشكلة.
قيّم كذلك القرارات السلبية. أحياناً أفضل نتيجة هي «لا أملك صلاحية» أو «لا يوجد مصدر كافٍ». ضع أمثلة يجب أن يرفضها الوكيل، وأمثلة يستطيع فيها طلب معلومة ناقصة. إذا أجاب دائماً، فهذا ليس ذكاءً؛ قد يكون نقصاً في الحاجز. راقب صياغة الرفض حتى لا تكشف اسم ملف أو قيمة لم يكن للمستخدم حق رؤيتها.
التكلفة والزمن جزء من الجودة
وكيل يحقق دقة عالية لكنه يستدعي خمسة نماذج وأربع أدوات لكل سؤال قد لا يصلح في مركز اتصال أو متجر. سجّل زمن أول استجابة، الزمن الكامل، عدد الخطوات، حجم السياق، والتكلفة التقريبية. ضع حدّاً للمهمة، ثم صمم مساراً سريعاً للحالات البسيطة ومساراً أعمق للحالات المعقدة. لا تستخدم نموذجاً كبيراً لتصنيف كلمة يمكن لقاعدة ثابتة معالجتها.
اقطع الحلقة عندما يكرر الوكيل السؤال أو الأداة، وحدد سياسة لإعادة المحاولة عند فشل الشبكة. استخدم طابوراً للحالات التي تحتاج وقتاً بدلاً من إبقاء المستخدم منتظراً. وإذا كانت التكلفة تختلف بحسب المزود أو النموذج، خزّن الإصدار في سجل التشغيل. هذه المعلومات تساعد الإدارة على فهم العائد، وتمنع مفاجآت الفاتورة بعد إطلاق واسع.
تقييم متعدد اللغات والسياقات الخليجية
اختبر العربية الفصحى واللهجات والصياغة المختلطة مع الإنجليزية، لأن المستخدمين لا يكتبون بالطريقة نفسها في نموذج أو مكالمة أو بريد. أضف أسماء شركات ومنتجات خليجية، عملات وتواريخ، ومصطلحات قطاعية مثل المشتريات والضريبة والشحن. لا تنقل مجموعة اختبار إنجليزية ثم تعتبرها كافية؛ قد تتغير نتيجة الاسترجاع أو استخراج الحقول بسبب اتجاه النص ونوع الأرقام.
قسّم النتائج حسب لغة المستخدم ودوره وحساسية المهمة. إذا كانت الجودة ممتازة للمستخدم التقني وضعيفة لموظف خدمة العملاء، فربما تحتاج تبسيط التعليمات أو تحسين قاعدة المعرفة. لا تخفِ الفرق في متوسط واحد. هذا التحليل يساعدك على اتخاذ قرار نشر تدريجي وتحديد أين يحتاج الإنسان إلى التدخل.
الفرق بين الاختبار الوظيفي واختبار السلامة
الاختبار الوظيفي يسأل هل أنجز الوكيل المهمة، مثل استخراج حقول فاتورة أو تلخيص تذكرة. اختبار السلامة يسأل هل امتنع عن الكشف والتنفيذ عندما لا يملك الصلاحية، وهل تعامل مع مدخل خبيث أو خدمة متوقفة. افصل التقريرين حتى لا تعوض درجة وظيفية مرتفعة عن حادث سلامة خطير. قد يكون الوكيل ممتازاً في التلخيص لكنه غير جاهز لفتح تذكرة أو إرسال بريد.
أنشئ حالات سلامة خاصة بكل أداة: قراءة سجل خارج الدور، تمرير تعليمات داخل ملف، طلب إعادة محاولة متكرر، وإدخال نص يحاول استدعاء وظيفة غير معلنة. نفّذها في بيئة اختبار، وسجل ما حدث، ثم ضع حاجزاً خارج النموذج عندما يكون ذلك ممكناً. القاعدة التي تمنع الإرسال أقوى من نص يطلب من الوكيل أن يتذكر عدم الإرسال.
كيف تقنع الإدارة بميزانية التقييم؟
اربط التقييم بخسارة يمكن فهمها: وقت مراجعة، رسالة خاطئة، كشف بيانات، أو تكرار معاملة. اعرض عينة قبل وبعد إضافة الحواجز، ووضح تكلفة الاختبار مقابل تكلفة الحادث. لا تقدم رقم دقة واحداً بلا سياق؛ بيّن عدد الحالات، درجة الخطورة، ومتى يحتاج الإنسان إلى التدخل. الإدارة لا تحتاج جدولاً مختبرياً فقط، بل قراراً واضحاً حول النطاق المقبول للمخاطر.
استجابة الحوادث والرجوع إلى إصدار سابق
اكتب خطة لما يحدث إذا كشف الوكيل معلومة أو نفذ فعلاً خطأ. من يوقفه؟ من يراجع السجلات؟ كيف تحجب الأداة أو تغير المفتاح؟ كيف تبلغ المتأثرين؟ وكيف تعيد النظام إلى إصدار سابق؟ نفّذ تمريناً محدوداً قبل الإنتاج، لأن معرفة الزر لا تكفي عندما يقع الحادث تحت ضغط.
احتفظ بإصدارات التعليمات والنماذج وقوائم الأدوات. لا تستبدل نسخة تعمل من دون علامة واضحة. إذا حدث تدهور بعد تحديث مزود، تستطيع المقارنة والرجوع. وبعد معالجة الحادث، أضف الحالة إلى مجموعة الاختبار حتى لا تعود المشكلة في الإصدار التالي.
اختبارات يجب ألا تغيب عن الوكيل العربي
اختبر اختلاف اللهجات والصياغة المختصرة والخلط بين العربية والإنجليزية والأرقام العربية. استخدم أسماء منتجات متشابهة وتواريخ متنوعة وعناوين طويلة. اختبر رسالة غاضبة، طلباً لا يملك النظام مصدره، ومستخدمين بصلاحيات مختلفة. لا تعتمد على ترجمة اختبار إنجليزي؛ قد تفشل العربية في التقسيم أو استخراج الحقول أو الاستشهاد.
أضف حالات البيانات الناقصة والتناقض. إذا قال المصدر إن المدة خمسة أيام وقال مستند آخر سبعة، يجب أن يذكر الوكيل التعارض أو يطلب تحديد النسخة. وإذا طلب المستخدم كشف معلومات موظف لا يملك صلاحيتها، يجب أن يرفض بوضوح ولا يلمح إلى وجود الملف. راقب ما يقوله في الرفض؛ الرفض الآمن لا يكشف تفاصيل داخلية.
اختبارات هجوم آمنة وRed Teaming
أنشئ تمارين داخلية لاختبار حدود النظام: تعليمات داخل ملف، طلب أن يتجاهل قواعده، اسم أداة مشبوه، مرفق يحاول تغيير المهمة، أو سلسلة طلبات تستنزف الكلفة. لا تجرب هذه الهجمات على أنظمة خارجية بلا إذن. الهدف فهم أين يحتاج الوكيل إلى عزل وموافقة وسجل.
صنف النتائج إلى خطأ جودة، تسريب بيانات، تجاوز صلاحية، تكرار إجراء، وكلفة أو أداء. أعط كل حالة أولوية ومالكاً وموعد إصلاح. أعد تشغيل الاختبارات بعد كل تغيير كبير؛ إصلاح مشكلة قد يضعف حالة أخرى، خصوصاً عند تغيير نموذج أو تعليمات.
بطاقة إطلاق الوكيل
قبل الإنتاج، أنشئ بطاقة تحتوي الغرض والنطاق، المستخدمين، المصادر، الأدوات، البيانات المحظورة، نموذج الفشل، معايير القبول، الإصدار، المالك، وسجل الاختبارات. اذكر ما لا يفعله النظام صراحة. هذا المستند يسرع التحقيق عندما يتغير الموظفون أو الموردون، ويمنع الاعتماد على ذاكرة الشخص الذي بناه.
بعد الإطلاق، حدد فترة مراقبة مكثفة. راجع عينة يومية أو أسبوعية، حسب المخاطر، وقارن النتائج بخط الأساس. إذا انخفضت الجودة أو تغيرت خدمة خارجية، أوقف الأداة التنفيذية أو ارجع إلى إصدار سابق. الإيقاف الآمن علامة نضج، وليس اعترافاً بالفشل.
خطة تقييم خلال 30 يوماً
الأسبوع الأول: اكتب مواصفة المهمة ومعايير القبول واجمع 50 مثالاً منقحاً. الأسبوع الثاني: أضف 25 حالة فشل وإساءة استخدام، وسجل رحلة الوكيل كاملة. الأسبوع الثالث: قارن نسختين أو إعدادين، واجعل مراجعاً تجارياً وتقنياً يقيمان عينات مختلفة. الأسبوع الرابع: طبق الحواجز، اختبر التكرار والانقطاع، وأطلق لمجموعة صغيرة مع خطة إيقاف.
بعد الشهر الأول، لا تترك مجموعة التقييم ثابتة. أضف الحالات التي فشل فيها النظام، وراجع توزيعها حتى لا تصبح كل الاختبارات سهلة. إذا تغيرت نية المستخدم أو النظام المصدر، حدّث المعيار. التقييم مستمر لأن العمل مستمر.
الخلاصة
الوكيل الموثوق ليس الذي يتصرف أكثر، بل الذي يعرف حدوده ويشرح ما فعل ويمكن إيقافه. ابنِ مواصفة مهمة، اختبر النجاح والفشل، سجل الرحلة، افصل الصلاحيات، واحتفظ بالإنسان عند الأثر الحقيقي. استخدم المقيّم الآلي لتوسيع التغطية، لكن اجعل الحكم المهني جزءاً من النظام. بهذه الطريقة يصبح الذكاء الاصطناعي أداة قابلة للمساءلة في الشركة الخليجية، لا تجربة سريعة يصعب تفسيرها بعد أول خطأ.
تذكّر أن كل نتيجة تقييم مرتبطة بسياقها: نموذج محدد، بيانات محددة، أدوات محددة، وإصدار محدد. وثّق هذه الحدود حتى لا تعرض الإدارة رقماً قديماً كأنه وعد دائم، وراجع الاختبارات عندما تتغير اللغة أو العملية أو المورد.
واحتفظ بمسار مراجعة بسيط يستطيع أعضاء الفريق قراءته، مع أمثلة للنجاح والفشل وقرار واضح بشأن كل حالة. التوثيق الجيد يقلل وقت التشخيص ويجعل نقل ملكية الوكيل بين الفرق أقل خطراً، خصوصاً عندما يتوسع الاستخدام من تجربة صغيرة إلى عملية يومية.
إذا لم تستطع شرح سبب قبول الوكيل للطلب أو رفضه، فالمشكلة ليست في واجهة العرض فقط؛ عد إلى الصلاحيات والمصادر والتتبع. الوضوح شرط أساسي للاستمرار.
لا تنتظر حادثاً حتى تبدأ التقييم. اطلب من فريق العمل تسجيل الحالات التي صححها يدوياً، ثم حولها إلى أمثلة اختبار. راجع الأخطاء المتكررة كل أسبوعين، وابحث عن أصلها: سؤال غامض، مصدر قديم، صلاحية زائدة، أو تعليمات غير واضحة. عندما تتراكم هذه الأمثلة، يصبح لديك معيار خاص بسياقك العربي والخليجي أفضل من اختبار عام لا يشبه عملك. عيّن مالكاً لهذه المجموعة، وضع تاريخ مراجعة، واحتفظ بنتيجة كل إصدار حتى ترى التحسن أو التراجع بوضوح.
أشرك أصحاب العملية في تفسير النتائج، لأن درجة آلية لا تعرف تكلفة الخطأ أو حساسية العميل. اجتماع قصير بعد كل دورة قد يكشف حاجزاً ضرورياً لا يظهر في الرسم التقني.
وعندما تتوسع المهمة، أعد حساب المخاطر بدلاً من نسخ الإعدادات. اختلاف المستخدمين والبيانات قد يحتاج صلاحيات ومعايير مختلفة، حتى لو بقي اسم الوكيل نفسه.
التوسع المنضبط يحافظ على الثقة ويجعل الكلفة والمراجعة قابلتين للإدارة.
أسئلة شائعة
هل يكفي اختبار الإجابة النهائية؟
لا. راقب اختيار الأداة، المدخلات، المصادر، التكرار، الصلاحيات والنتيجة، لأن الخطأ قد يحدث قبل الجملة الأخيرة.
هل يمكن الاعتماد على LLM كحَكَم؟
يساعد في الفرز والتوسع، لكنه يحتاج معايرة ومراجعة بشرية، خاصة في الحالات القانونية والمالية وحماية البيانات.
متى أضيف تنفيذات للوكيل؟
بعد إثبات جودة القراءة والاقتراح، وإضافة معاينة وموافقة وحدود وصلاحيات وسجل، وليس في أول نموذج تجريبي.
ما أهم مؤشر مبكر؟
نسبة المهام التي حققت الهدف من أول مرة من دون تجاوز الصلاحية أو تصحيح مكلف، مع معرفة سبب كل فشل.
روابط مكملة لتشغيل الوكلاء
اقرأ أيضاً شرح MCP بالعربي، ودليل RAG وقواعد المعرفة، وأتمتة سير العمل مع n8n قبل إطلاق وكيل في بيئة الإنتاج.
