RetryBench: Separating Retry Permission from Recovery Outcomes in GPT Tool Use

مسئله

وقتی فراخوانی یک ابزار به مهلت زمانی می‌خورد، ایجنت باید تصمیم بگیرد آن را دوباره بفرستد یا نه. اگر قرارداد ابزار اجازه‌ی تکرار امن را ندهد، تکرار می‌تواند کار را دو بار انجام دهد؛ مثلاً یک پرداخت دو بار ثبت شود. نویسنده‌ها این خطا را «اجازه‌ی تکرار نادرست» می‌نامند و می‌گویند بنچمارک‌هایی که فقط بازیابی موفق را می‌سنجند آن را نمی‌بینند.

روش

بنچمارک RetryBench این خطا را از بازیابی واقعی جدا می‌کند. نویسنده‌ها روی سه نقطه‌ی پایانی ثابت GPT با نام‌های Sol و Terra و Luna چند آزمایش کنترل‌شده اجرا کردند: کلیدهای تکرار معتبر و تغییریافته، حذف کلید پیشنهادی، برداشتن برچسب «قرارداد ضعیف» و یک قرارداد صریح.

یافته‌ها

• در آزمایش ۷۲۰ پاسخی، کلیدهای معتبر معمولاً پیشرفت امن را ممکن کردند، اما کلید تغییریافته در Sol یک بار از ۸۰، در Terra ۵۵ بار از ۸۰ و در Luna ۶۰ بار از ۸۰ به تکرار بی‌پشتوانه انجامید.
• وقتی کلید پیشنهادی حذف شد و مدل باید خودش کلید می‌ساخت، Luna هنوز ۸ بار از ۸۰ تکرار بی‌پشتوانه کرد و Sol و Terra هیچ؛ پس پذیرفتن کلید بدِ نمایش‌داده‌شده همه‌ی خطاها را توضیح نمی‌دهد.
• برداشتن برچسب «قرارداد ضعیف» تکرارها را در Sol و Terra بیشتر کرد، و با قرارداد صریح، مدل در همه‌ی ۷۶۲ پاسخ تصمیم را به تعویق انداخت.

محدودیت‌ها

نویسنده‌ها می‌گویند شواهد فقط چهار تسک انتخاب‌شده، نقطه‌های پایانی ثابت GPT و یک تصمیم بازیابی را پوشش می‌دهد و نه سازوکار درونی را نشان می‌دهد و نه ایمنی در سطح کل یک اجرا را.