تحدي التحقق من صحة المعلومات في الوكلاء المتعددة الأدوات

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

تتجاهل معظم أنظمة التحقق الحالية، مثل RAGAS faithfulness وMiniCheck، هوية المصدر، وتكتفي بسؤال ما إذا كانت الادعاءات مدعومة بالأدلة المجمعة. هذا النهج 'الأعمى عن المصدر' قد يسمح بمرور معلومات صحيحة لكنها منسوبة لمصدر خاطئ، وهو خطأ قد يكون خطيراً في المجالات الحساسة.

مشكلة الخلط بين المصادر (Cross-Source Conflation)

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

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

آلية عمل ProvenanceGuard

تعمل ProvenanceGuard كطبقة تحقق بعد التوليد (Post-generation verification) فوق وكيل MCP 'الصندوق الأسود'. لا تدمج الأدلة في سياق مجهول، بل تحافظ على هوية المصدر عبر خط الأنابيب. تبدأ العملية بقراءة مسار MCP المسجل، بما في ذلك مخرجات الأدوات ومعرفات المصادر، دون الحاجة لإعادة تدريب الوكيل الأصلي.

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

التصميم التقني والنماذج المستخدمة

اعتمدت التجارب في الورقة البحثية على نماذج محلية لمعالجة المسارات في بيئة محكومة دون اتصال. استخدمت النموذج MiniLM لإيجاد المصدر ذي الصلة، ونموذج DeBERTa NLI للتحقق من الدعم، ونموذج لغة محلي لتفكيك الإجابات. كما تتحقق الأداة بدقة من القيم الحرفية مثل الأرقام والتواريخ، فلا يمكن لقيمة غير موجودة في المصدر أن تمرر لمجرد أن الجملة تبدو معقولة.

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

نتائج الاختبارات والأداء

اختُبرت الأداة على إجابات من وكيل طبي استخدم سجلات المرضى والمقالات البحثية، مما أتاح دراسة 281 مساراً حقيقياً. في الاختبار الرئيسي، فحص خبراء بشريون 361 ادعاءً من 40 إجابة. حدد الخبراء 139 ادعاءً يجب عدم السماح بها، ونجحت ProvenanceGuard في كشف 138 منها، بينما سمحت بمرور ادعاء واحد فقط. كما احتفظت بـ 67 ادعاءً اعتبرها الخبراء مدعومة لإرسالها للمراجعة، مما يعكس طبيعتها الحذرة.

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

إصلاح الإجابات المحظورة

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

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

المصادر

• Hugging Face BlogGetting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents