עובדה אינה מספיקה: ProvenanceGuard בודק את מקור התשובה של סוכן MCP

סוכני LLM שמשתמשים בכלים כבר לא קוראים מטקסט אחד: דרך MCP הם מאחדים תוצאות של כמה כלים לתשובה אחת.

צוות Multiverse Computing הציג ב-29 בספטמבר ב-Hugging Face את העבודה ProvenanceGuard.

„מאומת במקום כלשהו“ אינו אומר „מאומת במקור הנכון“

מאמתים קיימים, מ-faithfulness של RAGAS ועד MiniCheck, AlignScore ו-SummaC, בודקים רק אם אוסף הראיות שכבר נאסף תומך בטענה.

המחברים מכנים זאת cross-source conflation: הטענה נכונה אי שם בראיות, אבל היא מיוחסת למקור הלא נכון. תשובת סוכן תמיכה עשויה לייחס את תקופת ההחזרה של 30 הימים לרשומת חשבון, בעוד שלמעשה מסמך מדיניות מאמת אותה.

מה עושה ProvenanceGuard

ProvenanceGuard הוא שכבת אימות לאחר יצירה שפועלת מעל סוכן MCP מסוג black-box. בלי לאמן מחדש את הסוכן, הוא קורא את העקבות המוקלטות עם תוצאות הכלים ומזהי המקור. יש חמישה שלבים: פיצול לטענות, איתור המקור המתאים לכל אחת, בדיקת תמיכה, השוואת המקור והחלטה — לאשר או לחסום.

בניסויים השתמשו במודלים מקומיים: MiniLM מחפש את המקור, מאמת NLI מבוסס DeBERTa בודק תמיכה, ומודל שפה מקומי מפצל את התשובה לטענות. מספר או תאריך שאינם במקור לא יעברו.

תוצאות

המערכת נבדקה על 281 עקבות אמיתיות של סוכן רפואי. מומחים בדקו 361 טענות מתוך 40 תשובות: לדעתם, 139 לא היו צריכות לעבור, ו-ProvenanceGuard תפס 138. הוא גם עצר 67 טענות מאומתות. את המקור הנכון הוא בחר בכ-86% מהמקרים.

לפי ציון F1 של טענות שצריך לחסום, הוא עקף את כולם — 0,802 (MiniCheck 0,783, RAGAS Faithfulness 0,758, AlignScore 0,662, SummaC-ZS 0,436).

במבחן קשה עם מקורות דומים המערכת קיבלה 0,846 F1 בחסימה, אבל ציינה את המקור המדויק רק ב-50,3% מהמקרים. במבחן מבוקר שם המקור שונה ב-50 מקרים — המערכת תפסה את כולם. מחזור תיקון בסגנון RARR פתר את כל 173 התשובות החסומות, אם כי 144 הסתיימו בטקסט חלופי. אותה גישה משמשת ב-NVFlow של NVIDIA עבור סוכן פיננסי.