Habr AI: لماذا تحتاج أنظمة الوكلاء إلى مقاييس تحكم وأمان جديدة

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

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

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

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

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

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

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

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

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