τ-bench: سنجش قابلیت اطمینان عامل‌های هوش مصنوعی در دامنه‌های واقعی استفاده از ابزار

پس از گذراندن هفته‌ها برای ردیابی ریشه استدلال جدولی و text-to-SQL، می‌خواستم کمی فاصله بگیرم و سوال متفاوتی بپرسم: عملکرد واقعی عامل‌های فعلی زمانی که آن‌ها را در یک چرخه عملیاتی زنده با یک کاربر واقعی قرار می‌دهید، چگونه است؟ τ-bench صادقانه‌ترین پاسخی را که دیده‌ام ارائه می‌دهد و اعداد آن تکان‌دهنده هستند.

مقاله

یائو، شین، رضوی و ناراسیمهان — همگی از پرینستون و Sierra Research — بنچمارک τ-bench (arXiv:2406.12045، ژوئن ۲۰۲۴) را منتشر کردند تا خلأیی را پر کنند که در نگاه به گذشته بدیهی به نظر می‌رسد: اکثر بنچمارک‌های عامل، وظیفه‌ای را به مدل می‌دهند و پاسخ نهایی آن را به صورت مجزا ارزیابی می‌کنند. پیاده‌سازی‌های واقعی به این شکل نیستند. یک عامل خدمات مشتری با وقفه مواجه می‌شود، سوالات تکمیلی از او پرسیده می‌شود، اطلاعات متناقضی دریافت می‌کند و انتظار می‌رود که در طول یک گفتگوی پایان‌باز، پیش از ایجاد هرگونه تغییر در پایگاه داده، سیاست‌های کسب‌وکار را اعمال کند.

τ-bench دو دامنه واقعی خدمات مشتری — خرده‌فروشی و خطوط هوایی — را در یک شبیه‌ساز قرار می‌دهد که در آن یک مدل زبانی نقش کاربر و دیگری نقش عامل را ایفا می‌کند. عامل به APIهای خاص دامنه (لغو سفارش، تغییر صندلی، اعمال کوپن) و یک سند سیاست مکتوب که مشخص می‌کند کدام اقدامات تحت چه شرایطی مجاز هستند، دسترسی دارد. ارزیابی مراحل میانی را نمره نمی‌دهد: بلکه وضعیت نهایی پایگاه داده را با یک وضعیت هدف نشانه‌گذاری شده مقایسه می‌کند. نویسندگان همچنین pass^k را معرفی می‌کنند، یک معیار قابلیت اطمینان که می‌پرسد یک عامل در چه کسری از آزمایش‌ها به‌طور مداوم در k تلاش مستقل برای یک وظیفه مشابه موفق می‌شود.

نکات کلیدی

• pass^k به عنوان معیار صادقانه: یک نمره تکی pass@1 بیش از حد نویز دارد. pass^k احتمال موفقیت یک عامل را در تمامی k بار اجرای مجدد همان وظیفه نشان می‌دهد — معیاری برای اینکه آیا در محیط عملیاتی به آن اعتماد می‌کنید یا خیر.
• شکاف ثبات (The consistency cliff): مدل GPT-4o در خرده‌فروشی امتیاز ۰.۶۰۴ را در pass@1 کسب می‌کند اما در pass@4 به ۰.۳۸۳ سقوط می‌کند. این بدان معناست که در حدود ۶۰٪ وظایف، حداقل یک بار در چهار تلاش شکست می‌خورد — که به سختی می‌توان آن را عاملی ایمن برای محیط عملیاتی دانست.
• دشواری خطوط هوایی نسبت به خرده‌فروشی: pass@1 مدل GPT-4o از ۰.۶۰۴ (خرده‌فروشی) به ۰.۴۲۰ (خطوط هوایی) کاهش می‌یابد. Claude 3.5 Sonnet (نسخه اکتبر ۲۰۲۴) بهتر عمل می‌کند — ۰.۶۹۲ در خرده‌فروشی / ۰.۴۶۰ در خطوط هوایی در pass@1 — اما pass@4 آن هنوز به ترتیب تنها به ۰.۴۶۲ و ۰.۲۲۵ می‌رسد.
• فراخوانی تابع (Function calling) بر ReAct غلبه می‌کند: نسخه عامل فراخوانی تابع GPT-4o (با pass@1 = ۰.۴۲۰ در خطوط هوایی) از هر دو مدل Act (۰.۳۶۵) و ReAct (۰.۳۲۵) در همان ساختار پایه بهتر عمل می‌کند، که نشان می‌دهد APIهای ابزار ساختاریافته خطاهای ناشی از قالب‌بندی را کاهش می‌دهند.
• شبیه‌سازی کاربر یک متغیر است: نویسندگان از یک مدل زبانی برای شبیه‌سازی کاربر استفاده می‌کنند که خود باعث ایجاد پراکندگی می‌شود. یک شبیه‌ساز کاربر ضعیف‌تر می‌تواند بسته به اینکه چقدر وفادارانه رفتارهای کاربر مخرب را بازنمایی می‌کند، امتیازات عامل را کاهش یا افزایش دهد.
• ارزیابی وضعیت پایگاه داده بازی‌های امتیازدهی جزئی را دور می‌زند: مقایسه وضعیت نهایی به جای مراحل گفتگو به این معنی است که عاملی که اقدام درستی انجام می‌دهد و سپس ناخواسته آن را به حالت قبل برمی‌گرداند، هیچ امتیازی نمی‌گیرد — که تصمیمی درست برای یک سیستم ثبت داده (write-back) است.

آنچه پابرجاست — و آنچه نیست

چارچوب pass^k واقعاً مفید است و انتظار دارم فراتر از این بنچمارک خاص باقی بماند. تصمیم برای ارزیابی بر اساس وضعیت پایگاه داده به جای شباهت در سطح توکن صحیح است — این کار مستقیماً اندازه‌گیری می‌کند که آیا عامل وظیفه را انجام داده است یا خیر، نه اینکه آیا کلمات درستی گفته است یا نه.

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

همچنین این سوال وجود دارد که pass^k واقعاً چه چیزی را اندازه‌گیری می‌کند. اگر شبیه‌سازی کاربر خود تصادفی باشد، پراکندگی در k آزمایش، عدم ثبات عامل را با عدم ثبات شبیه‌ساز در هم می‌آمیزد. مقاله به این نکته اشاره می‌کند اما به طور کامل دو منبع پراکندگی را از هم جدا نمی‌کند. برای کاربردهای حساس از نظر ایمنی، شما می‌خواهید ریشه شکست‌ها را بیابید — آیا عامل سیاست را نادیده می‌گیرد، قصد کاربر را اشتباه متوجه می‌شود یا فقط قالب اشتباهی را برای فراخوانی ابزار انتخاب می‌کند؟

جدول امتیازات در llm-stats.com اکنون مدل‌هایی مانند Step-3.5-Flash را با امتیاز ۰.۸۸۲ نشان می‌دهد، که اگر متوجه نشوید تنظیمات ارزیابی احتمالاً تغییر کرده است، پیشرفتی چشمگیر به نظر می‌رسد: به نظر می‌رسد ورودی‌های جدیدتر با نسخه‌های متفاوتی از شبیه‌ساز کاربر و احتمالاً تقسیم‌بندی‌های متفاوتی از وظایف امتیازدهی شده‌اند. مقایسه بین ورودی‌های مختلف در بنچمارک‌های در حال تکامل همیشه جای تردید دارد.

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

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

یافته pass^k کاربردی‌ترین نتیجه برای ماست. اگر یک مدل پیشرفته مانند Claude 3.5 Sonnet در خرده‌فروشی — که دامنه نسبتاً آسانی است — به pass@4 تنها ۰.۴۶۲ دست می‌یابد، باید انتظار ثبات مشابه یا بدتری در ثبت داده‌های دفتر کل داشته باشیم، جایی که اشتباهات در تراکنش‌ها انباشته می‌شوند و نقض سیاست‌ها ممکن است بلافاصله قابل مشاهده نباشد. طراحی برای ثبات در k-تلاش از همان ابتدا — و نه فقط بهینه‌سازی برای pass@1 — معماری را تغییر می‌دهد: این موضوع بر استفاده محافظه‌کارانه از ابزار (پرسیدن قبل از ثبت، نه بعد از آن)، مراحل صریح بررسی سیاست قبل از هر فراخوانی API و یک عامل تأییدکننده مجزا که تفاوت پیشنهادی در دفتر کل را پیش از نهایی شدن بازرسی می‌کند، تأکید دارد.

روش ارزیابی وضعیت پایگاه داده نیز مستقیماً قابل انتقال است. فرمت فایل ساختاریافته Beancount باعث می‌شود مقایسه وضعیت مورد انتظار دفتر کل با وضعیت واقعی پس از یک جلسه ثبت داده ساده باشد، که همان نوع سیگنال ارزیابی عینی را که τ-bench استفاده می‌کند به ما می‌دهد.

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

• τ²-bench (arXiv:2506.07982): دنباله‌ای که به محیط‌های با کنترل دوگانه گسترش می‌یابد، جایی که کاربران نیز ابزارها را فراخوانی می‌کنند؛ اگر کاربر را به جای یک درخواست‌کننده غیرفعال، به عنوان یک شرکت‌کننده فعال در اصلاحات دفتر کل مدل‌سازی کنیم، مستقیماً مرتبط است.
• AgentEval / GAIA (arXiv:2311.12983): بنچمارک GAIA دستیاران عمومی هوش مصنوعی را در وظایف دنیای واقعی که نیاز به وب‌گردی و استفاده از ابزار دارند ارزیابی می‌کند؛ یک مکمل مفید برای تمرکز خاص دامنه τ-bench.
• WorkArena (arXiv:2403.07718): عامل‌ها را در وظایف واقعی نرم‌افزارهای سازمانی در ServiceNow ارزیابی می‌کند؛ این دامنه به جریان‌های کاری حسابداری نزدیک‌تر از خرده‌فروشی یا خطوط هوایی است و برای یادگیری درس‌هایی در طراحی وظایف ارزش خواندن دارد.