چرا اکثر عوامل هوش مصنوعی هنوز نمی توانند حلقه بزنند – و به همین دلیل است که برنامه های هوش مصنوعی منفجر نشده اند

بیش از سه سال از راه اندازی ChatGPT می گذرد. مدل‌ها به‌طور چشمگیری بهتر شده‌اند، ده‌ها فریم‌ورک Agent ارسال شده‌اند، و با این حال، تعداد برنامه‌های کاربردی هوش مصنوعی که در واقع جریان‌های کاری کامل تجاری را در تولید بدون حضور انسان در حلقه اجرا می‌کنند، به‌طور شگفت‌آوری کم است. مدل‌های کلاس GPT-4 می‌توانند کد بنویسند، اسناد را تجزیه و تحلیل کنند و اطلاعات را در سطحی استخراج کنند که تصور آن سه سال پیش دشوار بود. پایگاه‌های داده برداری، پروتکل‌های فراخوانی ابزار، استدلال چندوجهی – بخش‌های زیرساخت عمدتاً وجود دارند. بنابراین در واقع چه چیزی از دست رفته است؟

پر کردن یک فرم وب، کاری است که اکثر نمایندگان اکنون می توانند انجام دهند – فیلدها را شناسایی کنید، روی ورودی ها کلیک کنید، مقادیر را تایپ کنید. اما پس از زدن ارسال چه اتفاقی می افتد؟ آیا فرم انجام شد؟ آیا خطا داده است؟ اگر خطا داشت، آیا مشکل اعتبارسنجی بوده یا مهلت زمانی؟ آیا باید به عقب برگردید و یک زمین را تعمیر کنید؟ اکثر Agent ها اکشن را اجرا می کنند و متوقف می شوند. منتظر دستور بعدی هستند. حلقه «عمل کنید، نتیجه را مشاهده کنید، تصمیم بگیرید که آیا کارتان تمام شده است، اگر نه، تنظیم کنید» چیزی است که یک نسخه نمایشی را از چیزی که واقعاً کار می کند جدا می کند. وقتی آن را می نویسید بی اهمیت به نظر می رسد. این نیست.

زمانی که ساختن Mano-AFK، سازنده اپلیکیشن مستقل خود را شروع کردیم، فرض اولیه این بود که پیچیدن یک حلقه while در اطراف یک عامل تک مرحله ای کافی است. این نبود. اجرای اقدامات فردی گلوگاه نیست. گلوگاه حفظ یک حلقه تصمیم در ده‌ها یا صدها مرحله است – مدام ارزیابی اینکه چقدر از هدف فاصله دارید، آیا آخرین اقدام شما را نزدیک‌تر کرده یا دورتر می‌کند، آیا نیاز به عقب‌نشینی دارید. حلقه های کوتاه 3 تا 5 مرحله ای به خوبی کار می کنند. ایجاد یک حلقه برای اجرای 50 یا 100 مرحله بدون تغییر مسیر، یک مشکل کاملا متفاوت است.

سخت ترین بخش این حلقه تأیید است. شما روی یک دکمه کلیک کردید و صفحه به جایی رفت – صفحه درست بود یا اشتباه؟ تست ها اجرا شدند و ناموفق بودند – آیا اشکالی در کد وجود دارد یا خود تست اشتباه است؟ یک ساخت شکست خورد – وابستگی وجود ندارد یا پیکربندی بد؟ هیچ قانون کلی برای این قضاوت ها وجود ندارد. مدل باید در واقع بفهمد که وظیفه چیست. این فقط نمی تواند الگوی تطابق داشته باشد.

متداول‌ترین حالت شکستی که در آزمایش‌های اولیه Mano-AFK دیدیم این نبود که Agent قادر به انجام کاری نبود، بلکه این بود که Agent کار اشتباهی انجام می‌داد و متوجه نشد و سپس خطا را ترکیب می‌کرد. یک فیلد با پیکربندی نادرست باعث می‌شود که یک بیلد از کار بیفتد، Agent آن را به‌عنوان یک مشکل وابستگی تفسیر می‌کند و شروع به نصب مجدد بسته‌ها می‌کند، و ده قدم بعد به طور ناامیدکننده‌ای از مسیر درست فاصله می‌گیرد. ما در نهایت یک بازبینی مخالف اضافه کردیم – یک نمونه Agent جداگانه که به طور مستقل ارزیابی می کند که آیا تصمیمات نماینده اصلی با هدف در هر مرحله همسو هستند یا خیر، و زمانی که همه چیز از مسیر خارج می شود مجبور به تلاش مجدد می شود. پس از آن ثبات به طرز چشمگیری بهبود یافت. مکانیسم پیچیده نیست. تفاوتی که ایجاد می کند بزرگتر از تعویض با مدل جدیدتر است.

در اینجا یک یافته است که ما را شگفت زده کرد. Mano-CUA-4B که به تنهایی روی 100 کار رابط کاربری گرافیکی macOS اجرا می شود، 56 درصد موفقیت را به دست آورده است. دسترسی ابزار bash را اضافه کنید و به 90% رسید. دلیل آن این نیست که bash به اجرای عملیات بیشتر کمک کرد. Bash به Agent یک حافظه خارجی داد – می‌توانست حالت میانی، محدودیت‌ها و بررسی‌های کامل را روی فایل‌ها بنویسد و در صورت نیاز دوباره آنها را بخواند. کاهش توجه در مکالمات طولانی واقعی است. اینطور نیست که پنجره زمینه خیلی کوچک باشد. مدل‌ها به سادگی تمرکز خود را بر روی محدودیت‌های اولیه در 20-30 مرحله از دست می‌دهند. پس از مشاهده آن نتیجه، Mano-AFK به گونه‌ای طراحی شد که تمام حالت‌های میانی را به‌طور صریح در سیستم فایل به جای تکیه بر مدل برای به خاطر سپردن چیزها حفظ کند.

اگر فرآیند در مرحله 50 از کار بیفتد چه اتفاقی می افتد؟ نمایندگان تک مرحله ای اهمیتی نمی دهند – شما فقط دوباره امتحان کنید. یک Loop Agent باید در هر مرحله حالت را سریالی کند تا بتواند از هر نقطه از سر گرفته شود. به نظر یک جزئیات مهندسی خسته کننده است. همچنین این چیزی است که تعیین می کند آیا چیزی می تواند در تولید اجرا شود یا خیر.

تابلوهای امتیازات بنچمارک با امتیازهای بالاتر به روز می شوند، اما بیشتر آنها دقت عمل تک مرحله ای را اندازه گیری می کنند. این یک قابلیت اساساً متفاوت از تکمیل یک کار کامل بدون دخالت انسان است. در تست‌های CUA Benchmark Mano-AFK، مدل 4B محلی W8A16 به 58% نرخ تکمیل خودکار سرتاسر در 5 برنامه وب و 100 مورد تست دست یافت. با کوانتیزاسیون Cider W8A8 که اندکی به 54٪ کاهش می یابد، اما سرعت پر کردن اولیه به 1453 توکن در ثانیه می رسد. 58٪ در جدول امتیازات چشمگیر به نظر نمی رسند. اما این 58 درصد از وظایف کاملاً مستقل از PRD از طریق تولید کد، استقرار، آزمایش، و رفع اشکال انجام می‌شود – که همگی به صورت محلی و بدون دخالت انسان اجرا می‌شوند. در بررسی شکست‌ها، بیشتر مواردی نبودند که مدل نتواند یک مرحله را اجرا کند. آنها مواردی بودند که در میان حلقه یک تماس قضاوت اشتباه انجام شد و دستگیر نشد.

هزینه بعد دیگری است که در تفکر تک مرحله ای ظاهر نمی شود. یک تماس API تنها چند ثانیه و چند سنت هزینه دارد. حلقه ای که 100 مرحله را اجرا می کند، هزینه و تأخیر را در 100 ضرب می کند. Mano-P با اجرای محلی روی M5 Pro، تقریباً 80 توکن در ثانیه با هزینه API صفر رمزگشایی می کند. برای استقرار دسته ای سازمانی، تفاوت هزینه تعیین کننده است. کوانتیزه‌سازی INT8 سیدر، پیش‌پر را حدود 1.8 برابر نسبت به W8A16 در M5 Pro بهبود می‌بخشد – شما به سختی متوجه می‌شوید که در یک تماس واحد، اما در یک حلقه 100 مرحله‌ای که در آن از پیش پر کردن هر نوبت اتفاق می‌افتد، اثر ترکیبی قابل توجه است.

انتظار برای مدل بعدی برای حل همه اینها یک غریزه طبیعی است. از آنچه که در ساخت Mano-AFK دیده‌ایم، گلوگاه فقط قابلیت مدل خام نیست. این است که چگونه حلقه مشاهده-طرح-عمل-تأیید را ساختار می‌دهید، جایی که بررسی مستقل را انجام می‌دهید، چگونه حالت افق طولانی را ادامه می‌دهید، چگونه بازیابی از شکست‌ها را مدیریت می‌کنید، و چگونه خطاها را قبل از اینکه آبشار شوند، تشخیص می‌دهید. اینها مشکلات مهندسی هستند و با بالا رفتن تعداد پارامترها به طور خودکار حل نمی شوند.

Mano-AFK و Cider SDK منبع باز تحت آپاچی 2.0 در https://github.com/Mininglamp-AI/Mano-P هستند.