WorkArena: نحوه عملکرد عامل‌های وب مبتنی بر LLM در کارهای دانشی واقعی سازمانی

پس از مطالعه ارزیابی τ-bench از عامل‌های فراخوانی ابزار (tool-calling) در حوزه‌های خرده‌فروشی و خطوط هوایی، مشتاق شدم وارد قلمرو نرم‌افزارهای سازمانی شوم — جایی که عامل‌های سبک Beancount واقعاً باید در آن عمل کنند. بنچمارک WorkArena (توسط Drouin و همکاران، بخش تحقیقات ServiceNow، ۲۰۲۴) عامل‌های وب مبتنی بر مدل‌های زبانی بزرگ (LLM) را در ۳۳ وظیفه واقعی در پلتفرم سازمانی ServiceNow مورد سنجش قرار می‌دهد و آن را به مستقیم‌ترین تست موجود برای ارزیابی این موضوع تبدیل می‌کند که آیا مدل‌های فعلی می‌توانند جریان‌های کاری واقعیِ کارمندان دانشی را اتوماتیک کنند یا فقط در سناریوهای نمایشی و ساده موفق هستند.

مقاله

مقاله "WorkArena: عامل‌های وب چقدر در حل وظایف رایج کارهای دانشی توانمند هستند؟" بنچمارکی شامل ۳۳ وظیفه و ۱۹,۹۱۲ مورد منحصر‌به‌فرد را معرفی می‌کند که از پلتفرم نرم‌افزاری سازمانی ServiceNow استخراج شده‌اند. این وظایف شش دسته‌ای را پوشش می‌دهند که کارمندان دانشی واقعاً هر روز انجام می‌دهند: فیلتر کردن و مرتب‌سازی لیست‌ها، پر کردن فرم‌ها، جستجو در پایگاه‌های دانش، سفارش از کاتالوگ‌های خدمات، خواندن داشبوردها و پیمایش در منوها. در کنار این بنچمارک، نویسندگان BrowserGym را منتشر کرده‌اند؛ بستری برای ارزیابی که مشاهدات غنی چندوجهی (HTML، درخت‌های دسترسی‌پذیری، اسکرین‌شات‌ها) را به همراه یک فضای اکشن استاندارد برای تعاملات وب در اختیار عامل‌ها قرار می‌دهد.

سوال اصلی مقاله این است که آیا LLMهای فعلی می‌توانند جریان‌های کاری ساختاریافته، چندمرحله‌ای و محدود به رابط کاربری (UI) را که نرم‌افزارهای سازمانی واقعی می‌طلبند، مدیریت کنند یا خیر. این‌ها وظایف جستجوی باز یا پرسش و پاسخ تک‌مرحله‌ای نیستند؛ بلکه توالی‌های هدفمندی از کلیک‌ها، ورودی‌های فرم و عملیات فیلتر هستند که ردپای قابل‌تأییدی در یک سیستم زنده بر جای می‌گذارند. همین ویژگی "تأیید‌پذیری از طریق وضعیت سیستم" است که WorkArena را به طور معناداری از اکثر بنچمارک‌های عاملی متمایز می‌کند و دقیقاً همان ویژگی است که یک عامل ثبت تراکنش Beancount باید داشته باشد.

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

• GPT-4o با استفاده از پرامپت‌نویسی زنجیره تفکر (CoT) به امتیاز کلی ۴۲.۷٪ در WorkArena می‌رسد؛ در حالی که GPT-3.5-Turbo تنها ۶.۱٪ و مدل متن‌باز Llama3-70B-Instruct به ۱۷.۹٪ دست می‌یابند — یک فاصله ۲۵ امتیازی بین مدل‌های تجاری پیشرو و مدل‌های متن‌باز پیشرو.
• وظایف فیلتر کردن لیست‌ها یک سد مطلق هستند: ۰٪ برای هر مدل. ویجت لیست در ServiceNow از HTML غیر‌استانداردی استفاده می‌کند که هیچ‌یک از عامل‌های تست شده نتوانستند به طور مطمئن با آن تعامل کنند. مرتب‌سازی نیز وضعیت چندان بهتری ندارد: GPT-4o در وظایف مرتب‌سازی لیست تنها به ۱۰٪ موفقیت رسید.
• وظایف کاتالوگ خدمات به طور شگفت‌آوری قابل حل هستند: GPT-4o در نه وظیفه کاتالوگ خدمات به ۷۷.۸٪ موفقیت می‌رسد، جایی که رابط کاربری متعارف‌تر است و اقدامات مورد نیاز به الگوهای پر کردن فرم که مدل احتمالاً در آموزش دیده است، نزدیک‌تر است.
• مشاهدات چندوجهی (تصویری) کمک چندانی نمی‌کنند. اضافه کردن اسکرین‌شات به مشاهدات GPT-4o منجر به "بهبودهای عملکردی بسیار جزئی" شد، که نشان می‌دهد گلوگاه اصلی، درک ساختار UI است، نه نبودِ ورودی بصری.
• زنجیره تفکر (Chain-of-thought) حیاتی است. حذف آن باعث افت حدود ۱۰ امتیازی مدل Llama3-70B در WorkArena شد، که تأیید می‌کند وظایف چندمرحله‌ای وب نیازمند استدلال صریح میانی هستند، نه فقط پیش‌بینی اقدام بعدی.
• مکانیسم‌های حافظه نتیجه معکوس دادند. فعال کردن پرچم use_think_history باعث شد عامل‌ها به "تصمیماتی که در مراحل اولیه گرفته شده بود، حتی تصمیمات اشتباه، پایبند بمانند" — نمونه‌ای عینی از تعصب به تصمیمات قبلی که به اشتباه برنامه‌ریزی به نظر می‌رسد.

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

ارزشمندترین ویژگی این بنچمارک اجرای آن روی یک نمونه زنده ServiceNow است: موفقیت بر اساس این تعیین می‌شود که آیا وضعیت سیستم واقعاً به درستی تغییر کرده است یا خیر، نه از طریق تطبیق متن با یک خروجی مورد انتظار. این موضوع، امتیاز ۰٪ در فیلتر کردن لیست را بسیار تکان‌دهنده می‌کند — هیچ راهی برای پنهان کردن شکست وجود ندارد. تنوع وظایف نیز واقعاً نماینده فعالیت‌هاست: شش دسته، گستره وسیعی از کارهایی را که کارمندان دانشی برای آن‌ها زمان صرف می‌کنند پوشش می‌دهند، نه وظایفی که به صورت گزینشی برای نمایش انتخاب شده باشند.

آنچه کمتر رضایت‌بخش است، نحوه برخورد با حالت‌های شکست است. مقاله اشاره می‌کند که ساختارهای غیرمعمول HTML، آی‌فریم‌های تو در تو و Shadow DOMها باعث شکست عامل‌ها می‌شوند، اما به طور سیستماتیک تحلیل نمی‌کند که کدام ویژگی‌های ساختاری و به چه میزان مسئول این شکست هستند. مشکل اندازه DOM — درخت‌های HTML بین ۴۰ هزار تا ۵۰۰ هزار توکن — ذکر شده اما عمیقاً تحلیل نشده است: ما نمی‌دانیم که آیا خلاصه‌سازی، قطعه‌بندی (chunking) یا مشاهدات فقط بر اساس درخت دسترسی‌پذیری می‌توانست عملکرد را بهبود بخشد یا خیر. معماری تک‌عاملی نیز هرگز با یک چیدمان چندعاملی (مثلاً تفکیک انتخاب‌گر و اجراکننده) مقایسه نشده است، بنابراین مشخص نیست که آیا نتیجه ۰٪ در فیلتر لیست یک مشکل در رابط کاربری است، یک مشکل در برنامه‌ریزی، یا هر دو.

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

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

نتایج WorkArena نقطه مرجعی است که من مدام برای اهداف اتوماسیون Beancount به آن بازمی‌گردم. الگوی شکست آموزنده است: عامل‌ها در وظایفی که شبیه فرم‌های وب هستند (کاتالوگ خدمات، ۷۷.۸٪) خوب عمل می‌کنند و در وظایفی که نیازمند تعامل دقیق با ویجت‌های رابط کاربری ساختاریافته و غیر‌استاندارد هستند (فیلتر کردن لیست، ۰٪) با شکست مواجه می‌شوند. یک عامل Beancount که ثبت دفترکل را انجام می‌دهد با تصویری ترکیبی روبرو خواهد بود: بخش تبدیل زبان طبیعی به تراکنش، شبیه به وظایف پر کردن فرم است که در آن عملکرد قابل قبول است؛ اما بخش‌های پرس‌وجو، فیلتر و مغایرت‌گیری — پیدا کردن ورودی‌های خاص، مرتب‌سازی بر اساس تاریخ، اعمال فیلترهای حساب — بسیار بیشتر شبیه به وظایف لیستی هستند که در آن‌ها همه چیز از کار می‌افتد.

این مقاله همچنین درسی از لاگ‌های CRITIC و Reflexion را تقویت می‌کند: تأیید بیرونی بیش از استدلال درونی اهمیت دارد. موفقیت یا شکست وظایف WorkArena بر اساس وضعیت سیستم تعیین می‌شود و این حقیقت محض (ground truth) است که بنچمارک را صادقانه می‌کند. برای عامل‌های ثبت تراکنش Beancount، این موضوع قویاً به نفع طراحی‌ای است که در آن هر تغییر ثبت شده در دفترکل، قبل از پذیرش، در مقابل API پایتون Beancount تأیید شود، نه اینکه فقط توسط استدلال خودِ عامل چک شود. سقف ۴۲.۷ درصدی برای بهترین مدل در ICML 2024 نشان می‌دهد که حتی برای وظایف معمولی UI سازمانی، فاصله بین "گاهی مفید" تا "قابل اتوماسیونِ قابل اعتماد" هنوز بسیار زیاد است.

چه مطالبی را در ادامه بخوانیم

• WorkArena++ (arXiv:2407.05291, NeurIPS 2024) — پیگیری همان تیم ServiceNow با ۶۸۲ وظیفه ترکیبی که نیازمند برنامه‌ریزی، استدلال محاسباتی و بازیابی چند‌سندی است؛ به طور مستقیم پاسخ می‌دهد که آیا افزایش پیچیدگی وظایف، حالت‌های شکست جدیدی فراتر از سد تعامل با رابط کاربری را آشکار می‌کند یا خیر.
• WebArena (arXiv:2307.13854, ICLR 2024) — بنچمارک همراه برای عامل‌های وب با کاربرد عمومی (۸۱۲ وظیفه در حوزه‌های تجارت الکترونیک، انجمن‌ها، میزبانی کد، سیستم‌های مدیریت محتوا) که در آن GPT-4 تنها به ۱۴.۴۱٪ در مقابل ۷۸٪ عملکرد انسانی دست می‌یابد؛ این بنچمارک اعداد WorkArena را در چشم‌انداز گسترده‌تر عامل‌های وب قرار می‌دهد.
• OSWorld (arXiv:2404.07972, NeurIPS 2024) — ارزیابی اتوماسیون سازمانی را به محیط‌های کامل دسکتاپ از جمله اپلیکیشن‌های واقعی (LibreOffice، VS Code، Chrome) گسترش می‌دهد؛ جامع‌ترین تست برای اینکه بفهمیم آیا حالت‌های شکست WorkArena مختص رابط کاربری هستند یا شکاف عمیق‌تری را در توانمندی عامل‌ها نشان می‌دهند.