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

يدخل وكيل ذكاء اصطناعي (AI agent) غير مراقب في حلقة أخطاء تكرارية عند الساعة الثانية صباحاً. أثناء تكليفه بتحديث سجل في نظام الـ CRM، يقوم بالهلوسة وتوليد معامل (parameter) خاطئ في استدعاء الـ API. يعود نظام الـ CRM بخطأ standard 400 Bad Request. وبدلاً من التوقف، يقرأ الوكيل هذا الخطأ، ويخمن معاملًا خاطئاً آخر، ثم يحاول مجدداً. ولأن تاريخ الفشل بالكامل يُضاف إلى نافذة السياق (context window) الخاصة بالوكيل مع كل محاولة إعادة، ينمو حجم الـ tokens بشكل أسي. وبحلول الوقت الذي ينهي فيه نظام التشغيل العملية قسراً (hard timeout) بعد ثلاثين خطوة، تكون المهمة التي كان ينبغي أن تكلف أجزاءً من السنت قد استهلكت ميزانية الـ API بالكامل.

بالنسبة لمشتري الحلول المؤسسية ومؤسسي شركات الـ SaaS في الولايات المتحدة ومنطقة الخليج العربي الذين يتطلعون لتوسيع نطاق عملياتهم، فإن هذا ليس مجرد خلل تقني عابر—بل هو ضربة مباشرة للهوامش الإجمالية (gross margins) والاستقرار التشغيلي. تقييم مسار الوكيل (Agent trajectory evaluation) هو وسيلتك لمنع تدفقات عمل الذكاء الاصطناعي متعددة الخطوات من هلوسة الإجراءات، وتجاوز حدود الامتثال، وهدر رأس المال. على مستوى القطاع، فإن معظم مشاريع الذكاء الاصطناعي للمؤسسات تتعثر في مرحلة التجربة الأولية لأن الفرق تبني وكلاء يعملون بشكل رائع في المسار المثالي (happy path) أثناء العرض التوضيحي (demo)، لكنهم يفشلون بشكل غير متوقع عند مواجهة بيانات حقيقية ومعقدة. إنهم يراكمون ديوناً تقنية للذكاء الاصطناعي—سلاسل موجّهات (prompts) متشابكة ووكلاء غير مراقبين—وهو ما نسميه "سباغيتي الذكاء الاصطناعي" (AI spaghetti).

تقوم Verel Systems بنقل الذكاء الاصطناعي من مرحلة "السباغيتي" إلى بيئة الإنتاج الفعلية. إن بناء أنظمة وكلاء (agentic systems) جاهزة للإنتاج يتطلب التخلي عن فكرة إمكانية تقييم الذكاء الاصطناعي بمجرد قراءة إجابته النهائية. لحماية أرباحك وضمان اتفاقيات مستوى الخدمة (SLAs)، يجب عليك تقييم المسار (trajectory): التسلسل الدقيق للقرارات، واستدعاءات الأدوات (tool calls)، وتغييرات الحالة (state changes) التي مر بها الوكيل للوصول إلى تلك النتيجة.

التكلفة المالية لهلوسة الخطوات المتعددة

عندما يفشل نظام استرجاع معزز بالتوليد (RAG) بسيط، يكون التعرض المالي محدوداً نسبياً. يسترجع النظام المستند الخاطئ، ويولد إجابة ضعيفة، ويعيدها إلى المستخدم. وتنتهي العملية هنا.

ولكن عندما يفشل وكيل مستقل (autonomous agent)، تتوالى المخاطر المالية بشكل متتابع. تم تصميم الوكلاء للعمل في حلقات (loops): يراقبون الحالة، ويفكرون في الخطوة التالية، وينفذون إجراءً (مثل الاستعلام من قاعدة بيانات أو استدعاء API خارجي)، ثم يراقبون النتيجة. إذا كانت خطوة التفكير (reasoning) معيبة، سيتخذ الوكيل إجراءً خاطئاً. وإذا كان النظام يفتقر إلى تقييم المسار، فغالباً ما يحاول الوكيل "إصلاح" خطئه بنفسه، مما يؤدي إلى حلقات تكرارية لانهائية تستنزف ميزانيات الـ API وتضر بتجربة العميل.

الحسابات المالية وراء هذه الحلقات تدمر اقتصاديات الوحدة (unit economics). لنأخذ مثالاً لوكيل دعم فني يعالج تذكرة عميل. المسار الناجح يبدو كالتالي:

1. ▸قراءة التذكرة (500 input tokens)
2. ▸استدعاء search_knowledge_base (1,000 input tokens، و50 output tokens)
3. ▸قراءة المستندات المسترجعة (2,000 input tokens)
4. ▸صياغة الرد (500 input tokens، و200 output tokens)

بأسعار النماذج الرائدة القياسية (حوالي 5.00 دولارات لكل مليون input tokens و15.00 دولاراً لكل مليون output tokens)، تكلف هذه العملية الناجحة حوالي 0.02 دولار تقريباً.

الآن، لننظر في مسار حلقة أخطاء حيث يواجه الوكيل صعوبة في استخدام الأدوات في بيئة الإنتاج (مثل استدعاء search_docs بدلاً من search_knowledge_base). يعود النظام بخطأ. يعيد الوكيل المحاولة. ومع كل محاولة، يتم إلحاق الأخطاء السابقة بنافذة السياق (context window) ليعرف النموذج ما حاول القيام به بالفعل.

• ▸سياق المحاولة الأولى: 1,500 tokens
• ▸سياق المحاولة الثانية: 2,000 tokens
• ▸سياق المحاولة الثالثة: 2,500 tokens
• ▸سياق المحاولة الرابعة: 3,000 tokens
• ▸سياق المحاولة الخامسة: 3,500 tokens

قبل أن يوقف نظام التشغيل العملية بسبب انتهاء الوقت (timeout)، يكون الوكيل قد استهلك أكثر من 12,500 tokens لمجرد قراءة سجل فشله، وهو ما يكلف حوالي 0.06 دولار لرموز الإدخال (input tokens) وحدها. هذا يضاعف التكلفة الأساسية بمقدار 3 مرات فعلياً. وعند احتساب رموز الإخراج (output tokens) المهدورة ووقت الحوسبة للأنظمة الخلفية (backend systems) التي تتعرض لضغط مستمر بطلبات API مشوهة، يمكن للوكلاء المستقلين غير المراقبين مضاعفة تكاليف المهام بسهولة بسبب حلقات الأخطاء التكرارية.

قياس الأثر على الأعمال: إذا كانت منصتك تعالج 10,000 تدفق عمل مؤتمت يومياً، فإن معدل خطأ متواضع بنسبة 15% في الحلقات التكرارية التي تصل إلى حد 30 خطوة يحول فاتورة API يومية متوقعة بقيمة 200 دولار إلى عبء مالي يتجاوز 800 دولار يومياً. على مدار ربع سنوي واحد، يترجم هذا إلى 54,000 دولار من الإنفاق المهدور على الـ API وحده. والأهم من ذلك، يمثل هذا 1,500 تدفق عمل فاشل يومياً يتطلب تدخلاً هندسياً يدوياً لحل المشكلات—مما يكلف ما يقدر بـ 12,000 دولار شهرياً من الأعباء الإضافية للمطورين، فضلاً عن المخاطرة بخسارة العملاء (churn) نتيجة لخرق اتفاقيات مستوى الخدمة (SLAs).

لماذا تفشل مقاييس RAG التقليدية مع الوكلاء المستقلين

تحاول معظم الفرق الهندسية تقييم وكلائها الجدد باستخدام نفس المقاييس التي استخدموها سابقاً لخطوط معالجة توليد النصوص. ويستخدمون أطر عمل مثل RAGAS لقياس استرجاع السياق (context recall)، وملاءمة الإجابة (answer relevancy)، والأمانة العلمية (faithfulness).

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

يعود السبب في هذه الفجوة إلى البنية الهيكلية. تم تصميم مقاييس RAG لخط معالجة ثابت يتكون من خطوتين: استرجاع البيانات، ثم توليد النص. وهي تقيم العلاقة بين موجّه (prompt) المستخدم، والنص المسترجع، والمخرج النهائي.

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

لنفترض سيناريو يُسأل فيه الوكيل: "ما هو إجمالي الإيرادات للربع الثالث؟" ينبغي على الوكيل استدعاء أداة query_financial_db. وبدلاً من ذلك، يهلوس ويستدعي أداة web_search للبحث في الإنترنت العام عن إيرادات شركتك الخاصة للربع الثالث. وعندما لا يجد شيئاً، يجيب: "ليس لدي صلاحية الوصول إلى بيانات إيرادات الربع الثالث".

إذا قمت بتشغيل تقييم RAG قياسي على هذا المخرج، فقد يسجل مقياس "الأمانة" (faithfulness) درجة مثالية 100%. فالإجابة النهائية ("ليس لدي صلاحية الوصول") دقيقة تقنياً ومتوافقة مع السياق المسترجع (نتيجة بحث ويب فارغة). يرى مقيّم RAG نظاماً يعمل كما هو مخطط له. لكن الواقع التجاري هو أن الوكيل فشل تماماً لأنه اختار الأداة الخاطئة—وربما قام بتسريب النوايا أو البيانات الوصفية (metadata) إلى محركات البحث العامة.

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

كيف يبدو التقييم السليم: تقييم مسارات الوكلاء

البناء لبيئة الإنتاج يعني نقل استراتيجية قابلية الملاحظة (observability) لديك من اختبار الصندوق الأسود (black-box testing) إلى تتبع الصندوق الأبيض (white-box tracing). يترجم هذا التحول مباشرة إلى تقليل المخاطر التشغيلية، وتسريع دورات تصحيح الأخطاء (debugging)، وضمان سلوك نظام يمكن التنبؤ به. أنت بحاجة إلى رؤية ما يحدث داخل الحلقة.

المسار (trajectory) هو التسلسل الكامل والمرتب للحالات التي ينتقل بينها الوكيل أثناء التنفيذ. وهو يشمل مدخلات المستخدم، وموجّهات النظام، والتفكير الوسيط للنموذج (والذي يُسمى غالباً "سلسلة الأفكار" أو Chain of Thought)، والأدوات المحددة التي تم استدعاؤها، وحمولة الـ JSON الدقيقة الممررة لتلك الأدوات، وزمن استجابة (latency) تنفيذ الأداة، والمخرج النهائي.

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

عندما تقوم Verel Systems ببناء أنظمة إنتاجية، نقوم بتهيئة رسم بياني للوكيل (agent graph) بحيث تصدر كل عملية انتقال بين العقد تتبعاً (trace). إذا فشل نظام multi-agent، فإننا لا نرى مجرد خطأ عام مثل "فشلت المهمة". بل نرى بدقة مكان حدوث الخلل.

على سبيل المثال، قد يكشف التتبع ما يلي:

1. ▸العقدة: Analyze_Request (ناجحة، 400ms)
2. ▸العقدة: Select_Tool (ناجحة، 800ms) - تم اختيار update_inventory
3. ▸العقدة: Format_Parameters (فاشلة، 1200ms) - تم تمرير النص "five" بدلاً من العدد الصحيح 5.
4. ▸العقدة: Execute_Tool (خطأ، 100ms) - رفضت واجهة برمجة التطبيقات (API) الحمولة.

من خلال عزل الفشل في خطوة Format_Parameters، تتوقف عن التخمين حول سبب فشل الوكيل. يمكنك على الفور تنفيذ حل حتمي (deterministic)—مثل إضافة خطوة تحقق صارمة من مخطط JSON (JSON schema validation) قبل عقدة تنفيذ الأداة، مما يجبر النموذج اللغوي الكبير (LLM) على إخراج نوع البيانات الصحيح.

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

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

الأثر المالي لتقييم المسار

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

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

تنفيذ حواجز حماية المسار في بيئة الإنتاج

يتطلب بناء هذه البنية التحتية الابتعاد عن سلاسل الموجّهات الخطية البسيطة واعتماد أنظمة multi-agent حفظ الحالة (stateful). نحن نستخدم LangGraph لأنه يسمح لنا بنمذجة تدفق عمل الوكيل كآلة حالة حتمية (deterministic state machine)، مما يمنح قادة الأعمال تحكماً كاملاً في الحدود التشغيلية للذكاء الاصطناعي الخاص بهم.

في الرسم البياني حفظ الحالة (stateful graph)، تكون "الحالة" عبارة عن قاموس مشترك (shared dictionary) يتم تحديثه مع انتقال التنفيذ من عقدة إلى أخرى. يتضمن تقييم المسار كتابة تأكيدات برمجية (programmatic assertions) مقابل قاموس الحالة هذا عند الانتقالات الحرجة.

بالنسبة للأعمال، يعمل كود التحقق أدناه كقاطع تيار (circuit breaker) مالي وتشغيلي مؤتمت. وبدلاً من السماح للنموذج اللغوي الكبير بالاستعلام المتكرر من قاعدة بيانات مؤسسية مكلفة أو API خارجي بمعاملات غير صالحة، نقوم باعتراض التنفيذ باستخدام تحقق حتمي. هذا يمنع تدهور أداء قاعدة البيانات وتراكم تكاليف الـ API قبل حدوثها.

def validate_tool_parameters(state: AgentState):
    """
    Circuit breaker: Ensure the LLM provided valid parameters 
    before making the expensive/risky API call.
    """
    tool_calls = state.get("pending_tool_calls", [])
    
    for call in tool_calls:
        if call.name == "update_crm":
            # Deterministic check, not an LLM check
            if not isinstance(call.args.get("customer_id"), int):
                return {"error": "customer_id must be an integer", "next_node": "recovery"}
                
    return {"next_node": "execute"}

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

نحن ندمج إدارة الحالة هذه مع أدوات قابلية الملاحظة. في كل مرة يتم فيها تفعيل دالة validate_tool_parameters، يتم رفع علم (flag) في Weave أو Langfuse. على مدار أسبوع من حركة مرور البيانات في بيئة الإنتاج، يمكنك الاستعلام عن هذه التتبعات لمعرفة الأدوات التي يواجه النموذج صعوبة في تنسيقها بدقة. إذا أظهرت التتبعات أن النموذج يفشل بشكل متكرر في تنسيق أداة update_crm، فلديك الآن بيانات قابلة للتنفيذ. يمكنك إعادة كتابة وصف الأداة في موجّه النظام، أو تبسيط مخطط JSON، أو الانتقال إلى عائلة نماذج تتمتع بقدرات أقوى في اتباع التعليمات، مما يحمي هوامشك ويضمن موثوقية النظام.

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

هل يؤدي تقييم المسار إلى إبطاء الوكيل في بيئة الإنتاج؟ لا، فعمليات التتبع والتحقق من الحالة تضيف زمن استجابة (latency) ضئيلاً للغاية لا يكاد يُذكر (عادةً بضعة أجزاء من الثانية لتنفيذ كود Python القياسي). أما تقييم التتبعات—مثل استخدام نموذج لغوي كبير كحَكَم (LLM-as-a-judge) لتقييم جودة خطوات التفكير—فيتم بشكل غير متزامن (asynchronously) بعد اكتمال العملية. كما أن قواطع التيار المضمنة (inline circuit breakers) هي دوال Python حتمية بسيطة وليست استدعاءات لنماذج لغوية كبيرة، لذا فهي لا تؤثر على السرعة التي يواجهها المستخدم.

ما هو العائد على الاستثمار (ROI) لتنفيذ تقييم المسار مقارنة بتكلفة بنائه؟ بالنسبة للمؤسسات أو منصات الـ SaaS سريعة النمو التي تعالج أكثر من 10,000 عملية يومياً، فإن تقييم المسار يغطي تكلفته عادةً في غضون أول 60 إلى 90 يوماً. يتم تعويض التكلفة المسبقة لبناء حواجز الحماية حفظ الحالة (stateful guardrails) من خلال خفض يتراوح بين 70% إلى 90% في الإنفاق المهدور على رموز الـ API (tokens)، وتقليل كبير في ساعات دعم المطورين المستهلكة في تصحيح أخطاء الصندوق الأسود، ومنع الأخطاء الصامتة الكارثية التي تتسبب في خسارة العملاء.

هل يمكننا استخدام النماذج اللغوية الكبيرة (LLMs) لتقييم المسار؟ نعم، ولكن بشكل غير متزامن فقط. إن تشغيل نموذج لغوي كبير للتحقق من عمل نموذج آخر في كل خطوة يزيد بشكل كبير من زمن الاستجابة والتكاليف. في بيئة الإنتاج، تستخدم عمليات تحقق حتمية (التحقق من المخطط، التحقق من النوع، مطابقة النصوص) بشكل مضمن للتحكم في تدفق الرسم البياني. وتستخدم أسلوب LLM-as-a-judge في وضع عدم الاتصال (offline) على بيانات التتبع الخاصة بك (عبر Langfuse أو Weave) لتقييم المنطق العام وتحديد مجالات تحسين الموجّهات.

كيف نصلح وكيلاً يهلوس باستمرار بمعاملات الأدوات (tool parameters)؟ أولاً، تحقق من مخططات الأدوات (tool schemas) الخاصة بك. تحدث معظم هلوسات المعاملات لأن مخطط JSON المقدم للنموذج معقد للغاية أو يفتقر إلى أوصاف واضحة. قم بتبسيط المخطط. وإذا استمر الخطأ، فقم بتنفيذ عقدة إعادة محاولة (retry node) في بنية LangGraph الخاصة بك تلتقط خطأ التحقق المحدد وتعيده إلى النموذج مع تعليمات تنسيق صارمة. واجعل هذا مقتصرًا على محاولة إعادة واحدة فقط لمنع الحلقات اللانهائية.

ما الفرق بين التتبع والتقييم؟ التتبع (Tracing) هو جمع البيانات: تسجيل كل خطوة، وموجّه، واستدعاء أداة قام به الوكيل. أما التقييم (Evaluation) فهو قياس تلك البيانات وتصنيفها: التأكد مما إذا كان المسار المسلوك صحيحاً، وفعالاً، وآمناً. لا يمكنك تقييم وكيل متعدد الخطوات دون تتبع مساره أولاً.

إن الاعتماد على مقاييس الإجابة النهائية للوكلاء المستقلين هو ضمان للفشل المستقبلي. إذا كانت مبادرات الذكاء الاصطناعي لديك متعثرة لأن الوكلاء لا يمكنهم التعامل بموثوقية مع الحالات الاستثنائية (edge cases) دون الدخول في حلقات تكرارية أو هلوسة الإجراءات، فالمشكلة ليست في النموذج. المشكلة تكمن في غياب قابلية ملاحظة المسار (trajectory observability). توقف عن معاملة وكلائك كصناديق سوداء، وقم بتنفيذ حواجز حماية حفظ الحالة (stateful guardrails)، وتتبع كل خطوة في مسار التنفيذ.