CodeAct: چرا کدهای پایتون قابل اجرا، دقت عوامل LLM را ۲۰٪ افزایش میدهند
پس از مطالعه مقاله «ناتوانی در خوداصلاحی» در هفته گذشته، یک سوال طبیعی پیش میآید: اگر مدلهای زبانی بزرگ (LLMها) نمیتوانند خروجی خود را به طور قابل اعتمادی ممیزی کنند، چه فرمتی برای اکشنها بهترین شانس را به عوامل (Agents) میدهد تا خطاها را به طور خودکار شناسایی و بازیابی کنند؟ مقاله CodeAct که توسط شینگیائو وانگ و همکاران منتشر و در ICML 2024 پذیرفته شده است، استدلال میکند که پاسخ در کد پایتون نهفته است — نه به این دلیل که کد جادو میکند، بلکه به این دلیل که یک مفسر پایتون دقیقاً همان نوع بازخورد خارجی و قطعی را ارائه میدهد که ادبیات خوداصلاحی نشان میدهد LLMها به شدت به آن نیاز دارند.
مقاله
مقاله "Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) نوشته شینگیائو وانگ، یانگی چن، لیفان یوآن، ییژه ژانگ، یونژو لی، هائو پنگ و هنگ جی، پیشنهاد میکند که فرمتهای اکشن متنی و JSON که در عوامل فراخوان ابزار رایج هستند، با کدهای پایتون قابل اجرا جایگزین شوند. ایده اصلی این است که کد نسبت به دستورالعملهای زبان طبیعی یا JSON ساختاریافته، زبان مشترک (lingua franca) بهتری برای اکشنهای عامل است، زیرا کد در حال حاضر جریان کنترل (control flow)، وابستگیهای دادهای و ترکیب چندمرحلهای را در خود دارد — و همچنین LLMها به شدت روی آن آموزش دیدهاند.
این مقاله سه دستاورد دارد: (۱) یک استدلال مفهومی برای کد به عنوان یک فضای اکشن یکپارچه؛ (۲) M3ToolEval، یک بنچمارک جدید شامل ۸۲ وظیفه دستچین شده توسط انسان که نیازمند ترکیب چندین ابزار است؛ و (۳) CodeActAgent، یک مدل ۷ میلیاردی (7B) تنظیمشده که بر روی CodeActInstruct آموزش دیده است؛ مجموعهدادهای شامل ۷۱۳۹ مسیر کدپایه چند مرحلهای که حوزههای بازیابی اطلاعات، پکیجهای نرمافزاری، حافظه خارجی و برنامهریزی ربات را پوشش میدهد.
ایدههای کلیدی
- در M3ToolEval، مدل GPT-4 با استفاده از CodeAct به نرخ موفقیت ۷۴.۴٪ دست یافت، در حالی که با اکشنهای متنی این میزان ۵۳.۷٪ بود — یک بهبود مطلق حدود ۲۰ درصدی در پیچیدهترین تنظیمات چند-ابزاری.
- CodeAct نسبت به عوامل مبتنی بر JSON در وظایف مشابه، به حدود ۳۰٪ گامهای تعاملی کمتری نیاز دارد. تعداد گام کمتر مهم است: هر چرخه اضافی، فرصت دیگری برای انتشار خطا است.
- مفسر پایتون به عنوان یک سیگنال خطای خودکار و بدون هزینه عمل میکند. یک محاسبه میانی اشتباه بلافاصله یک استثنا (exception) ایجاد میکند؛ عامل ردیابی خطا (traceback) را میبیند و میتواند بدون نیاز به مرحله نقد جداگانه، آن را اصلاح کند.
- مدلهای متنباز بیش از مدلهای تجاری سود میبرند. مدل CodeActAgent (Mistral 7B) در M3ToolEval به ۱۲.۲٪ میرسد، در حالی که قویترین عامل متنباز قبلی (Lemur-70B با متن) ۳.۷٪ بود. این بهرهوری بالاتر است زیرا پایتون در دادههای پیشآموزش فراوان است، اما فرمتهای تخصصی فراخوانی ابزار JSON اینگونه نیستند.
- CodeActInstruct بر روی چهار حوزه که به طور خاص برای تست استرس ترکیب ابزارها ان تخاب شدهاند، آموزش میبیند: جستجوی اطلاعات، فراخوانی پکیج، مدیریت حافظه خارجی و برنامهریزی ربات. اینها همگی وظایف چند مرحلهای و وابسته به حالت هستند — دقیقاً همان حالتهای شکستی که در آن عوامل JSON از کار میافتند.
چه چیزی پابرجا میماند — و چه چیزی نه
بهبود ۲۰ درصدی در M3ToolEval واقعی است، اما M3ToolEval تنها ۸۲ وظیفه دارد. این یک نمونه کوچک است و مقاله فواصل اطمینان را گزارش نمیدهد. همچنین بنچمارک توسط همان تیمی تهیه شده که روش را پیشنهاد داده است، که در این حوزه استاندارد است اما باید به آن توجه داشت. من ترجیح میدهم قبل از اینکه ۷۴.۴٪ را یک عدد قابل اعتماد بدانم، شاهد تکرار آن در یک بنچمارک کاملاً مستقل باشم.
ادعای کارایی — ۳۰٪ گامهای کمتر — محتمل است اما دو مورد را با هم ترکیب میکند. گامهای کمتر میتواند به معنای دقت بیشتر عامل در هر مرحله باشد، یا میتواند به معنای پایان زودتر در صورت شکست باشد. مقاله این موارد را به وضوح تفکیک نکرده است.
شکاف تایید شده بین مدلهای متنباز و تجاری بسیار زیاد است و توسط CodeAct از بین نرفته است. CodeActAgent (Mistral 7B) با ۱۲.۲٪ بسیار بهتر از Lemur-70B با ۳.۷٪ است، اما GPT-4 با CodeAct روی ۷۴.۴٪ قرار دارد. فرمت کمک میکند، اما شکاف ۶۰ امتیازی در توانمندی را پر نمیکند. هر کسی که قصد دارد یک عامل متنباز Beancount را مستقر کند، باید این عدد را به دقت بررسی کند.
مسئله سندباکس (sandboxing) تنها در یک پاراگراف مطرح شده است. اجرای کد دلخواه در یک بافت مالی، یک مورد خاصِ جزئی نیست — بلکه نگرانی اصلی امنیتی است. مقاله به این موضوع نمیپردازد که وقتی عامل کدی تولید میکند که فایلها را حذف میکند، تماسهای شبکهای برقرار میکند یا کتابخانههای غیرمنتظره را وارد میکند، چه اتفاقی میافتد. برای یک عامل حسابداری در محیط عملیاتی، طراحی سندباکس حداقل به اندازه فرمت اکشن اهمیت دارد.
چرا این موضوع برای هوش مصنوعی در امور مالی مهم است
مسئله نوشتن داده در Beancount اساساً هما ن مشکلی است که CodeAct برای حل آن طراحی شده است: یک عامل باید چندین عملیات (خواندن موجودی فعلی، اعتبارسنجی تراکنش، نوشتن یک ثبت جدید، بررسی تراز بودن حساب) را با ترتیبی خاص و با جریان داده بین مراحل ترکیب کند. فراخوانی ابزار JSON این کار را به خوبی انجام نمیدهد زیرا هر فراخوانی ایزوله است. پایتون این کار را به طور طبیعی مدیریت میکند.
به طور ملموستر: یک عامل Beancount به سبک CodeAct میتواند کل گردش کار مغایرتگیری را به عنوان یک اسکریپت واحد پایتون بیان کند — استعلام از دفتر کل از طریق یک کتابخانه، محاسبه تفاوتها، پیشنهاد ورودیهای جدید و اجرای bean-check روی نتیجه — همه اینها قبل از نهایی کردن هر چیزی انجام میشود. مفسر خطاهای بدیهی را میگیرد؛ LLM فقط نیاز دارد خطاهای معنایی را مدیریت کند. این تقسیم کار بسیار بهتر از این است که از LLM بخواهیم JSON خودش را اعتبارسنجی کند.
نگرانی امنیتی جنبه دیگری هم دارد. عاملی با قابلیت اجرای نامحدود پایتون روی یک دفتر کل مالی، یک سطح حمله بزرگ است. طراحی صحیح تقریباً به طور قطع یک سندباکس به شدت محدود شده است — بدون نوشتن در فایلسیستم خارج از یک دایرکتوری موقت مشخص، بدون دسترسی به شبکه، بدون دستورات شل — که با یک گیت اجباری bean-check قبل از دست زدن به هر فایلی ترکیب شده است. CodeAct فرمت اکشن را به شما میدهد؛ اما ساخت قفس همچنان بر عهده شماست.
آنچه باید در ادامه بخوانید
- OpenHands (سابقاً OpenDevin) — سیستم عامل تولیدی که بر اساس CodeAct توسط همان گروه تحقیقاتی ساخته شده است؛ نشان میدهد که محیط سندباکس و اجرا چگونه در واقعیت پیادهسازی میشوند (arXiv:2407.16741)
- ToolBench / ToolLLM — بنچمارکها و دادههای آموزشی برای عوامل فراخوان ابزار با استفاده از REST APIها به جای پایتون؛ تضادی مفید با رویکرد اول-کد در CodeAct (arXiv:2307.16789)
- SWE-bench — عوامل را روی مسائل واقعی گیتهاب ارزیابی میکند، که نیازمند اجرای کد چند مرحلهای و ویرایش فایل است؛ نزدیکترین بنچمارک موجود به آنچه که یک عامل نوشتن داده Beancount برای قبولی نیاز دارد (arXiv:2310.06770)
