تقييم أنظمة الـ Multi-Agent: رصد هلوسات استخدام الأدوات في بيئة الإنتاج

هلوسة نموذج الذكاء الاصطناعي (AI model) حول حقيقة تاريخية أثناء جلسة دردشة هي أمر محرج. لكن هلوسة وكيل الذكاء الاصطناعي (AI agent) في معامل (parameter) مطلوب ضمن استدعاء API لنظام CRM، وفشله، ثم إعادة محاولة نفس الطلب المشوه عشرات المرات في حلقة مفرغة (loop)، هو فشل تشغيلي كارثي. هذا الفشل يستهلك بصمت حدود الاستخدام اليومية (rate limits)، ويرفع فاتورة الاستنتاج (inference)، ويتسبب في تدهور أداء النظام بالكامل.

مع انتقال بنيات الـ multi-agent من بيئات الاختبار التجريبية (sandboxes) إلى بيئات العمل الحية في عام 2026، تغير مفهوم "الهلوسة" جذرياً. الأنظمة القائمة على موجّه (prompt) واحد تولد نصوصاً؛ أما الوكلاء (agents) فينفذون إجراءات فعلية. إنهم يستعلمون قواعد البيانات، ويكتبون مسودات البريد الإلكتروني، ويحدثون السجلات، ويطلقون خطوط معالجة (workflows) لاحقة. عندما يخترع الوكيل أداة غير موجودة، أو يمرر بثقة وسائط JSON خاطئة لأداة موجودة فعلاً، فإن نطاق الضرر (blast radius) يتجاوز بكثير مجرد تجربة مستخدم سيئة.

على مستوى قطاع التكنولوجيا، تتعثر معظم مشاريع الذكاء الاصطناعي للمؤسسات في مرحلة "المشاريع التجريبية" (pilot purgatory) بسبب هذا الخطر تحديداً. تتراكم لدى الشركات ديون تقنية في مجال الذكاء الاصطناعي—سلاسل موجّهات (prompt chains) متشابكة، ووكلاء غير مراقبين، وبنيات هشة تعمل بشكل مثالي في العروض التوضيحية المتحكم بها ولكنها تنهار عند مواجهة الحالات الاستثنائية (edge cases). هذه الحالة من الركود تمثل تكلفة غارقة هائلة في رواتب المهندسين وتأخيراً في جداول التحول الرقمي. تقوم Verel Systems بنقل الذكاء الاصطناعي من هذه الحالة العشوائية (spaghetti state) إلى بيئة الإنتاج الفعلية. لبناء أنظمة multi-agent جاهزة للإنتاج (production-grade)، يجب أن تتخلى عن فكرة تقييم المخرجات النصية النهائية فقط، وتبدأ في تقييم مسار اتخاذ القرار (decision trajectory) بالكامل.

التكلفة المالية والتشغيلية للإخفاقات الصامتة

لفهم سبب حاجة تقييم أنظمة الـ multi-agent إلى نهج هندسي متميز، عليك النظر في كيفية فشل هذه الأنظمة فعلياً في بيئة الإنتاج. نادراً ما تفشل عن طريق إظهار رسالة خطأ للمستخدم. بدلاً من ذلك، تفشل بصمت، وبتكلفة باهظة، وبشكل تكراري متتالٍ.

لنفترض وجود نظام multi-agent مصمم لتأهيل عملاء المبيعات المحتملين الواردين (inbound sales leads). يتضمن مخطط التنسيق (orchestration graph) وكيل بحث يستكشف الويب لجمع معلومات عن الشركة، ووكيل بيانات يستعلم من نظام CRM الداخلي عبر API، ووكيل صياغة يكتب الملخص النهائي.

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

بدون قيود صارمة على النظام، يدخل الوكيل في حلقة تكرار عميقة (recursion loop) حتى يصل إلى الحد الأقصى لوقت التشغيل (timeout) الخاص بإطار العمل. يقوم بتعديل الاستعلام قليلاً، ويستدعي الـ API مرة أخرى، ويفشل، ويكرر العملية.

تكلفة هذا الفشل قابلة للقياس بدقة:

• ▸تكاليف الاستنتاج الإضافية (Inference Overhead): إذا كان وكيلك يعمل على عائلة من النماذج الرائدة (frontier models)، فإن كل تكرار للحلقة يتطلب من النموذج معالجة كامل سجل محاولاته الفاشلة السابقة. إذا كان متوسط نافذة السياق (context window) يبلغ 10,000 رمز (tokens) لكل محاولة إعادة، وتشغيل الحلقة 50 مرة قبل الوصول إلى المهلة المحددة، فإن استعلام مستخدم واحد يستهلك 500,000 رمز. بتكلفة توضيحية تبلغ 3.00 دولارات لكل مليون رمز إدخال، فإن هذا الاستعلام الفاشل الفردي يكلف 1.50 دولار من تكلفة الاستنتاج الصافية. اضرب ذلك في 100 جلسة متزامنة تواجه حالات استثنائية مشابهة، وستهدر 150 دولاراً في ساعة واحدة.
• ▸وقت تعطل المهندسين (Engineering Downtime): بدون تتبع (tracing) مناسب، تضيع الفرق الهندسية ما متوسطه 14 ساعة من وقت المطورين ذوي الأجور المرتفعة لكل حادثة، لمحاولة إعادة إنتاج وتشخيص حلقة وكيل واحدة غير متتبعة.
• ▸خسارة العملاء (Customer Churn): بالنسبة لمنصات الـ SaaS، فإن معدل خطأ API بنسبة 2% ناتج عن الحلقات التكرارية (recursive loops) يمكن أن يؤدي إلى قفزة بنسبة 15% في خسارة العملاء خلال 30 يوماً بسبب تدهور أداء المنصة ومشاكل قيود الاستخدام (rate-limiting).

إن تقييم أنظمة الـ multi-agent يدور حول كشف إخفاقات المسار (trajectory failures) هذه قبل وصولها إلى بيئة الإنتاج، وتتبعها فوراً عند حدوثها على أرض الواقع.

لماذا تفشل مقاييس الـ LLM القياسية مع الوكلاء (Agents)

إذا حاولت تقييم نظام multi-agent باستخدام الأدوات المصممة لروبوتات الدردشة (chatbots)، فستكون أعمى عن الأداء الفعلي لنظامك. يعتمد تقييم نماذج اللغة الكبيرة (LLM evaluation) التقليدي على مقاييس مرجعية (reference-based metrics) أو تقييم بسيط للمخرجات النهائية باستخدام نموذج كحَكَم (LLM-as-a-judge).

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

المقاييس المصممة لمقارنة تشابه النصوص ليست كافية عند تقييم عملية اتخاذ القرار لدى الوكيل. لا يهمك ما إذا كان الملخص النهائي للوكيل يحتوي على تداخل دلالي (semantic overlap) عالٍ مع ملخص بشري؛ ما يهمك هو ما إذا كان الوكيل قد استعلم بالفعل من قاعدة البيانات الحية أم أنه خمن الأرقام بناءً على أوزان التدريب المسبق الخاصة به.

يتطلب تقييم الوكيل قياس "الأمانة" (faithfulness) و"دقة اختيار الأدوات" (tool-selection accuracy).

تعني "الأمانة" (Faithfulness) في سياق الوكيل: هل اعتمد المخرج النهائي حصرياً على البيانات المسترجعة بواسطة الأدوات، أم أن النموذج أقحم معلومات خارجية؟ بينما تسأل "دقة اختيار الأدوات": بالنظر إلى موجّه (prompt) المستخدم والأدوات المتاحة، هل اختار الوكيل الأداة المثلى بالمعاملات (parameters) الصحيحة من المحاولة الأولى؟

لقياس ذلك، تقوم الفرق الهندسية بتكييف أطر عمل مثل RAGAS. ورغم أنه صُمم في الأصل لخطوط معالجة البحث (search pipelines)، إلا أن المبادئ الرياضية تنطبق مباشرة على الوكلاء. من خلال تسجيل حمولة الـ JSON (JSON payload) الدقيقة التي يحاول الوكيل تمريرها إلى الأداة، يمكنك كتابة اختبارات حتمية (deterministic tests) للتحقق مما إذا كانت المعاملات تطابق المخطط (schema) المطلوب. يمكنك بعد ذلك استخدام نموذج ثانوي أرخص لمراجعة مسار الوكيل وتقييم اختياره للأداة من 0 إلى 1 بناءً على الضرورة والصحة.

تقييم المسار وتتبع استخدام الأدوات (Tool-Use Tracing)

لا يمكنك تقييم ما لا يمكنك رؤيته. إن أساس تقييم أنظمة الـ multi-agent هو التتبع غير المتزامن (asynchronous tracing) الشامل. في كل مرة يفكر فيها الوكيل، أو يقرر، أو يتصرف، يجب تسجيل هذا الحدث كـ span منفصل داخل trace أكبر.

من منظور استراتيجي، فإن قابلية المراقبة (observability) ليست رفاهية هندسية؛ بل هي أداتك الأساسية للحد من المخاطر. إن تطبيق تتبع قوي يقلل من متوسط وقت الحل (MTTR) من ساعات إلى ثوانٍ، مما يحمي التزامات اتفاقية مستوى الخدمة (SLA) الخاصة بك في أسواق المؤسسات المتطلبة مثل الولايات المتحدة ومنطقة الخليج العربي.

عندما نعيد بناء مشاريع الذكاء الاصطناعي التجريبية الفاشلة وتحويلها إلى أنظمة جاهزة للإنتاج في Verel Systems، فإن أول ما نتخلص منه هو عبارات الطباعة الخام (print statements) وسجلات قواعد البيانات الأساسية. ونستبدلها بمنصات مراقبة مخصصة للذكاء الاصطناعي مثل Langfuse أو Weave لتتبع استخدام الأدوات والمسارات في الوقت الفعلي.

يلتقط تتبع الإنتاج (production trace) الحالة الدقيقة للنظام عند كل عقدة (node):

1. ▸مدخلات المستخدم الخام.
2. ▸الموجّه (prompt) الذي تم حقنه في وكيل التوجيه (routing agent).
3. ▸قرار وكيل التوجيه (مثال: استدعاء أداة search_crm).
4. ▸وسائط JSON الدقيقة التي تم إنشاؤها للأداة.
5. ▸وقت تنفيذ استدعاء الـ API الخارجي.
6. ▸الاستجابة الخام من الـ API.
7. ▸تفسير الوكيل لتلك الاستجابة.

غالباً ما يقلق قادة الأعمال من أن التقاط هذا المستوى من بيانات القياس عن بُعد (telemetry) قد يؤدي إلى إبطاء التطبيق. هذا مفهوم خاطئ نابع من ممارسات التسجيل المتزامن (synchronous logging) القديمة. تعمل مكتبات التتبع الحديثة بشكل غير متزامن (asynchronously). يتم إرسال بيانات القياس في الخلفية، مما يضيف زمن استجابة (latency) ضئيل جداً لا يكاد يذكر إلى دورة الطلب والاستجابة الخاصة بالمستخدم.

مع التقاط هذه البيانات، يمكنك تشغيل تقييمات ليلية. لست بحاجة إلى تقييم كل تتبع (trace) يدوياً. بدلاً من ذلك، تقوم بتصفية التتبعات؛ فتسحب كل تتبع أعاد فيه استدعاء الـ API خطأ من فئة 400، أو كل تتبع تجاوز فيه وقت التنفيذ 10 ثوانٍ. ثم تقوم بتشغيل LLM-as-a-judge على تلك المسارات الفاشلة فقط لتصنيف السبب الجذري: هل كان إدخالاً سيئاً من المستخدم، أم API خارجياً غير مستقر، أم هلوسة حقيقية في استخدام الأدوات من قبل الوكيل؟

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

تطبيق نقاط التوقف الصارمة والتدخل البشري (Human-in-the-Loop)

التقييم يخبرك بأن النظام يفشل؛ أما البنية التحتية (architecture) فتمنع هذا الفشل من التسبب في أضرار.

النمط البنيوي الأكثر أهمية لأنظمة الـ multi-agent هو التنسيق المعتمد على الحالة (stateful orchestration). تتيح أطر العمل مثل LangGraph للمهندسين تعريف الوكلاء ليس كصناديق سوداء لتوليد النصوص، بل كعقد (nodes) في مخطط دائري (cyclical graph) ذي حواف (edges) واضحة وإدارة دقيقة للحالة (state management).

يتيح هذا النهج المعتمد على الحالة وضع نقاط توقف صارمة (hard breakpoints). إذا أظهرت بيانات التقييم أن الوكيل يهلوس بالمعاملات بشكل متكرر عند التعامل مع حالة استثنائية معينة، فلا تكتفي بمطالبة الوكيل عبر الموجّه بأن "يكون أكثر حذراً". بل تقوم بتطبيق حافة شرطية (conditional edge) في المخطط.

إذا حاول الوكيل استدعاء أداة تخريبية أو ذات تأثير دائم (مثل delete_record أو send_client_email)، يوقف المخطط التنفيذ مؤقتاً. يتم حفظ الحالة الحالية في قاعدة البيانات، وينتظر النظام موافقة بشرية. هذا هو مفهوم التدخل البشري (human-in-the-loop - HITL)، ليس كميزة في واجهة المستخدم، بل كعنصر أساسي لإدارة المخاطر.

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

علاوة على ذلك، تتيح لك المخططات المعتمدة على الحالة (stateful graphs) تحديد حدود التكرار (recursion limits) برمجياً بشكل صارم. يمكنك فرض ألا يحاول الوكيل إصلاح استدعاء أداة معطل أكثر من ثلاث مرات. وعند الفشل الرابع، يفرض المخطط خروجاً آمناً (graceful exit)، ويعيد رسالة خطأ موحدة للمستخدم مع وضع علامة على التتبع (trace) لمراجعته هندسياً. هذا يحد بشكل صارم من مخاطر حلقات التكرار العميقة وما يرتبط بها من تجاوز لتكاليف الـ API، محولاً الفشل التشغيلي المكلف إلى استثناء روتيني مسجل.

إطار عمل تقييم الـ Multi-Agent في بيئة الإنتاج

يعتمد اختيار كيفية تقييم وكلائك بالكامل على ملف تعريف المخاطر (risk profile) للإجراءات التي يتخذونها. نحن ننظم التقييم عبر أربع طبقات متميزة، نوازن فيها بين تكلفة التقييم وتكلفة فشل النظام.

*تكلفة الاستنتاج للتقييم الليلي يمكن التنبؤ بها بدقة. تشغيل LLM-as-a-judge على 1,000 تتبع معقد باستخدام نموذج رائد (يستهلك حوالي 5,000 رمز إدخال لكل تتبع) يتطلب 5 ملايين رمز. بتكلفة توضيحية تبلغ 3.00 دولارات لكل مليون، تكون التكلفة الليلية 15.00 دولاراً. هذه التكلفة الإضافية البالغة 450 دولاراً شهرياً لا تكاد تذكر مقارنة بتكلفة وكيل مارق يفسد بيانات الإنتاج.

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

ما هو العائد على الاستثمار المتوقع (ROI) من إعداد إطار عمل للتقييم والتتبع مقارنة بتكلفة التنفيذ؟ عادةً ما يتم استرداد تكلفة الإعداد الأولية لإطار عمل التتبع والتقييم (والتي تتراوح عادةً بين 10,000 إلى 20,000 دولار في صورة ساعات عمل هندسية أو رسوم شركاء) خلال الربع الأول من النشر. يتحقق هذا الاسترداد من خلال منع حلقات الـ API اللانهائية (التي قد تكلف آلاف الدولارات في عطلة نهاية أسبوع واحدة)، وتقليل وقت تصحيح الأخطاء (debugging) للمطورين بنسبة تصل إلى 80%، وتجنب خسارة العملاء الناتجة عن إخفاقات النظام الصامتة.

كيف نقيس ما إذا كان الوكيل يوفر الوقت فعلياً إذا كان يتطلب أحياناً تدخلاً بشرياً؟ تقوم بقياس "معدل الإنجاز الذاتي" (autonomous completion rate) إلى جانب "معدل التصعيد" (escalation rate). إذا كان الوكيل يعالج نسبة توضيحية تبلغ 80% من الاستفسارات من البداية إلى النهاية دون تدخل بشري، ويوجه الـ 20% المتبقية إلى موظف بشري مع ملخص سياق جاهز بالكامل، فإن صافي الوقت الموفر يظل هائلاً. إن الهدف من التدخل البشري (human-in-the-loop) هو التعامل مع الحالات الاستثنائية عالية الخطورة بأمان، وليس إلغاء الأتمتة بالكامل. يمكنك تتبع إجمالي الوقت الذي يقضيه البشر في المهام المصعدة مقارنة بالوقت الذي كانوا يقضونه سابقاً في معالجة 100% من حجم العمل.

هل يمكننا استخدام نماذج أصغر وأرخص لتقييم استخدام الوكيل الرئيسي للأدوات؟ نعم، وهذا ممارسة قياسية لإدارة تكاليف التقييم. في حين أن الوكيل الأساسي قد يتطلب نموذجاً رائعاً ضخماً (frontier model) للتحليل واتخاذ القرارات المعقدة لاختيار الأدوات، فإن نموذج التقييم يعمل بميزة "الرؤية اللاحقة" (benefit of hindsight). من الأسهل بكثير التحقق مما إذا كان استدعاء الأداة صحيحاً مقارنة بإنشاء استدعاء الأداة الصحيح من الصفر. يمكن لنموذج تم ضبطه بدقة (fine-tuned) من فئة 8 مليارات معامل (8B parameters) تقييم مسارات استخدام الأدوات بشكل موثوق وبجزء بسيط من تكلفة تشغيل نموذج رائد كحَكَم.

ما الفرق بين التتبع (tracing) والتسجيل (logging) لوكلاء الذكاء الاصطناعي؟ يسجل التسجيل (logging) أحداثاً معزولة مثل: "خطأ 404 عند الساعة 10:02 صباحاً". أما التتبع (tracing) فيسجل دورة حياة الطلب بالكامل كمخطط متصل من الأحداث. يوضح التتبع موجّه المستخدم، وتفكير الوكيل، والأداة المحددة التي تم استدعاؤها، واستجابة الـ API، والإجراء التالي للوكيل، وكل ذلك مرتبط بمعرف تتبع (trace ID) واحد. عندما يفشل الوكيل، يخبرك السجل (log) بأنه تعطل؛ بينما يخبرك التتبع (trace) بالضبط بما كان يفكر فيه الوكيل عندما تعطل.

كيف نمنع الوكيل من اتخاذ إجراءات تخريبية في قاعدة بياناتنا؟ تقوم بفصل صلاحيات القراءة عن صلاحيات الكتابة على مستوى البنية التحتية. يُعطى الوكيل أدوات يمكنها فقط تنفيذ استعلامات SELECT أو قراءة واجهات برمجة التطبيقات (read APIs). إذا كان خط المعالجة يتطلب كتابة في قاعدة البيانات أو إجراءً تخريبياً، يُمنح الوكيل أداة تكتفي بصياغة التغيير المقترح وتجهيزه مؤقتاً (stages it). بعد ذلك، تتطلب طبقة تنسيق منفصلة إما فحص تحقق حتمي (deterministic validation check) أو موافقة بشرية قبل اعتماد الإجراء المجهز في قاعدة البيانات الحية.