τ²-bench: اندازه‌گیری هزینه کنترل دوگانه در عامل‌های هوش مصنوعی مکالمه‌ای

من در چند هفته گذشته در حال مطالعه خانواده τ-bench بوده‌ام و τ²-bench (arXiv:2506.07982) همان مقاله‌ای است که منتظرش بودم: این مقاله بالاخره می‌پرسد وقتی کاربر صرفاً یک توزیع‌کننده غیرفعال اطلاعات نیست، بلکه یک مشارکت‌کننده فعال با مجموعه ابزار خاص خود است، چه اتفاقی می‌افتد. برای هر کسی که در حال ساخت یک عامل حسابداری مکالمه‌ای است، این شکاف همیشه مشهود بوده است.

مقاله

ویکتور بارس، هونگهوا دونگ، سوهام ری، زوجی سی و کارتیک ناراسیمهان (Sierra AI و دانشگاه تورنتو) τ²-bench را به عنوان گسترش مستقیم τ-bench اصلی معرفی می‌کنند. مشاهده اصلی این است که بنچمارک‌های قبلی برای عامل‌های هوش مصنوعی مکالمه‌ای، کنترل واحد هستند: فقط عامل می‌تواند ابزارها را فراخوانی کند؛ کاربر به پیام‌های زبان طبیعی محدود شده است. پشتیبانی فنی در دنیای واقعی این فرض را می‌شکند. وقتی یک عامل خدمات مشتری به شما می‌گوید "حالت هواپیما را خاموش کنید"، شما در حال انجام یک فراخوانی ابزار (tool call) روی دستگاه خود هستید، نه فقط روایت ترجیحات خود.

نویسندگان این فرآیند را به عنوان یک فرآیند تصمیم‌گیری مارکوف نیمه‌مشاهده‌پذیر غیرمتمرکز (Dec-POMDP) مدل‌سازی می‌کنند، جایی که هم عامل و هم شبیه‌ساز کاربر دارای فضاهای عملیاتی متمایز (فراخوانی توابع و پیام‌ها) روی یک وضعیت جهانی مشترک و پویا هستند. سمت عامل شبیه به یک CRM استاندارد است: می‌تواند سوابق مشتری را جستجو کند، رومینگ را فعال کند یا سیم‌کارت را تعویض کند. سمت کاربر یک تلفن شبیه‌سازی شده با ابزارهای خواندن (get_status_bar, get_sim_status) و ابزارهای نوشتن (toggle_airplane_mode, toggle_data, reseat_sim_card) است. این بنچمارک با یک دامنه مخابراتی جدید (۱۱۴ وظیفه نمونه‌برداری شده از ۲۲۸۵ واریانت تولید شده به صورت برنامه‌نویسی شده) در کنار دامنه‌های تایید شده خرده‌فروشی (۱۱۵ وظیفه) و خطوط هوایی (۵۰ وظیفه) از τ-bench اصلی عرضه می‌شود.

ایده‌های کلیدی

• صورت‌بندی کنترل دوگانه: بازنمایی Dec-POMDP به وضوح آنچه را که هر بازیکن مشاهده می‌کند و ابزارهایی را که هر کدام می‌توانند فراخوانی کنند، جدا می‌کند. این روش دقیق‌تر از رویکرد ادهوک "کاربر با یک گوشی" است که ممکن است به یک سیستم تک‌عاملی موجود اضافه کنید.
• مولد وظایف ترکیبی: وظایف از ۱۵ گروه زیروظیفه اتمی شامل سه نوع قصد (service_issue, mobile_data_issue, mms_issue) با مقیاس‌بندی صریح دشواری بر اساس تعداد مراحل مورد نیاز برای حل، تشکیل شده‌اند.
• عملکرد در حوزه مخابرات (pass¹): مدل GPT-4.1 تنها به ۳۴٪ می‌رسد؛ o4-mini به ۴۲٪؛ Claude 3.7 Sonnet به ۴۹٪؛ و GPT-4.1-mini حدود ۵۰٪. نمره همه مدل‌ها در اینجا به طور قابل توجهی کمتر از حوزه‌های خرده‌فروشی یا خطوط هوایی است.
• جریمه کنترل دوگانه: یک تحلیل مقایسه‌ای (ablation) حالت پیش‌فرض (Default - کاربر ابزار دارد) را با حالت بدون کاربر (No-User - عامل تمام ابزارها را خودش کنترل می‌کند) مقایسه می‌کند. GPT-4.1 با افت ۱۸ واحد درصدی و o4-mini با افت ۲۵ واحدی مواجه می‌شوند. این شکاف، هزینه هماهنگی با یک کاربر فعال است که از دشواری خالص استدلال جدا شده است.
• شکاف طرح اوراکل (Oracle-plan gap): حتی زمانی که توالی کامل اقدامات از قبل در اختیار عامل قرار می‌گیرد، عملکرد به ۱۰۰٪ نمی‌رسد، که نشان می‌دهد اجرا و هماهنگی با کاربر، خطایی مضاعف بر خطای برنامه‌ریزی اضافه می‌کند.
• ابزارهای ساختاریافته کاربر نویز شبیه‌ساز را به شدت کاهش می‌دهند: شبیه‌ساز کاربر مخابرات تنها ۱۶٪ خطا تولید می‌کند (۶٪ بحرانی)، در حالی که این رقم برای خرده‌فروشی در τ-bench اصلی ۴۰٪ (۱۲٪ بحرانی) بود. این بهبود ناشی از جایگزینی پرومپت‌های زبان طبیعی آزاد با یک رابط ابزار به شدت محدود شده است که وضعیت دستگاه را ردیابی می‌کند.

آنچه پابرجا می‌ماند — و آنچه نه

قاب‌بندی Dec-POMDP یکی از دقیق‌ترین فرمول‌بندی‌های مسئله‌ای است که در بنچمارک‌های عامل‌ها دیده‌ام. مولد وظایف برنامه‌نویسی شده واقعاً مفید است: وظایف با درستی اثبات‌شده و پیچیدگی قابل کنترل صریح را ارائه می‌دهد، برخلاف مجموعه‌ وظایف دستی که اکثر بنچمارک‌ها را دچار مشکل کرده است. اعداد مربوط به قابلیت اطمینان شبیه‌ساز کاربر متقاعدکننده هستند — کاهش خطاهای بحرانی از ۱۲٪ به ۶٪ زمانی که می‌خواهید به سیگنال ارزیابی خود اعتماد کنید، بسیار مهم است.

با این حال، دامنه مخابراتی محدود است. چهار مشتری، نه خط تلفن، پنج طرح: این یک آزمایشگاه کنترل شده است، نه یک سیستم سازمانی. اعداد pass¹ برای gpt-4.1-mini و Claude 3.7 Sonnet (حدود ۵۰٪) با توجه به اینکه نویسندگان می‌گویند این دامنه چقدر سخت است، به طرز عجیبی بالا به نظر می‌رسند، که باعث می‌شود فکر کنم آیا ۱۱۴ وظیفه برای جلوگیری از بالا رفتن نمرات بر اثر شانس کافی است یا خیر. خود نویسندگان نیز اذعان دارند که مجموعه وظایف آن‌ها یک زیرنمونه است. همچنین تحلیل شخصیت کاربر (persona) را ضعیف یافتم: مقاله نشان می‌دهد که شخصیت "سخت" (بازنشسته ۶۴ ساله با اعتماد به نفس فنی پایین) سخت‌تر از شخصیت "آسان" است، که جای تعجب ندارد. چیزی که من می‌خواستم ببینم این بود که آیا نوع شکست در هماهنگی متفاوت است یا خیر — آیا یک شخصیت سخت‌تر باعث خطاهای استدلالی بیشتری می‌شود یا خطاهای ارتباطی بیشتر؟

این مقاله همچنین بررسی نمی‌کند که اگر سند خط‌مشی (policy document) عامل اشتباه یا ناقص باشد چه اتفاقی می‌افتد، که سناریویی واقع‌بینانه برای استقرار در محیط عملیاتی است. تمام نتایج فرض می‌کنند که خط‌مشی‌های دقیقی به عامل داده شده است.

چرا این برای هوش مصنوعی مالی مهم است

فرض کنترل واحد که در τ-bench، WorkArena و اکثر بنچمارک‌های گفتگو-محور نهفته است، با سناریوی واقعی پشتیبانی Beancount به خوبی مطابقت ندارد. کاربری که از یک عامل Beancount می‌خواهد دفتر کل (ledger) او را اصلاح کند، صرفاً یک مشکل را روایت نمی‌کند — او ممکن است همزمان در حال ویرایش فایل در ویرایشگر متن خود، اجرای bean-check یا آپلود یک فایل خروجی CSV جدید از بانک خود باشد. این دقیقاً یک محیط کنترل دوگانه به مفهوم τ²-bench است.

افت ۱۸ تا ۲۵ واحد درصدی هنگام تغییر از حالت No-User به Default، عددی است که من مدام به آن فکر خواهم کرد. این نشان می‌دهد که حتی اگر یک عامل Beancount بسازیم که در دستکاری خودکار دفتر کل نزدیک به کامل باشد، معرفی یک کاربر فعال که دسترسی نوشتن مشترک دارد، نرخ موفقیت را تقریباً یک‌چهارم کاهش می‌دهد. طراحی‌های بازنویسی ایمن که در نظر گرفته بودیم (GuardAgent، ShieldAgent، MCP قابل تایید) برای محیط‌های تک‌کنترلی طراحی شده بودند؛ اگر کاربر نیز یک عامل فراخواننده ابزار در همان محیط باشد، این طراحی‌ها نیاز به بازنگری دارند.

بهبود قابلیت اطمینان شبیه‌ساز کاربر نیز مستقیماً قابل اجراست. اگر بخواهم ارزیابی‌های آفلاین یک عامل Beancount را بدون استخدام حسابداران انسانی انجام دهم، متصل کردن صریح کاربر شبیه‌سازی شده به یک محیط دفتر کل قطعی (deterministic) — به جای تکیه بر نقش‌آفرینی آزادانه مدل‌های زبانی — انتخاب مهندسی درستی است.

چه چیزی را بعداً بخوانیم

• τ-bench (Yao et al., arXiv:2406.12045): پایه‌ای که این کار آن را گسترش می‌دهد — ارزش دارد قبل از تفسیر نتایج τ²-bench، ساختار وظایف اصلی و طراحی معیار pass^k را مطالعه کنید.
• ToolSandbox (Lu et al., arXiv:2408.04682): ابزارهای حالت‌دار (stateful) را برای ارزیابی دقیق عامل معرفی می‌کند؛ مرتبط‌ترین معماری برای طراحی یک بستر تست Beancount با کنترل دوگانه.
• TheAgentCompany (Xu et al., arXiv:2412.14161): ۱۷۵ وظیفه در یک شرکت نرم‌افزاری شبیه‌سازی شده با ابزارهای داخلی واقعی؛ واقع‌بینانه‌ترین بنچمارک اتوماسیون سازمانی که در حال حاضر موجود است و مقاله بعدی در لیست مطالعه من.