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

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

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

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

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

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

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

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