صفر درصد؛ این نرخ موفقیت فعلی مدل‌های پیشرو در اجرای یک مأموریت کامل نظارتی با استفاده از محک جدید Drone-Bench است. طبق اعلام Andon Labs در ۲۴ ژوئیه ۲۰۲۶، این ارزیابی شکافی حیاتی را میان توانایی یک مدل در حل تک‌کده‌های مجزا و قابلیت حفظ پایداری در یک زنجیره پیچیده از عملیات فیزیکی آشکار کرده است.
هوش مصنوعی به سرعت از رابط‌های متنی به سمت خودمختاری فیزیکی حرکت می‌کند و مدل‌ها در حال حاضر مدیریت فروشگاه‌ها، کافه‌ها و سایر کسب‌وکارهای کوچک را بر عهده دارند. این چرخش، ریسک‌های سوءاستفاده را به‌ویژه در حوزه نظارت محیطی افزایش می‌دهد، زیرا توانایی نظارت خودمختار بر محیط‌ها در دسترس‌تر می‌شود. برخلاف ارزیابی‌های نرم‌افزاری، خودمختاری فیزیکی به سطحی از دقت نیاز دارد که در آن یک خطای حتی یک درجه در یک مرحله، می‌تواند منجر به شکست کامل سامانه شود. Drone-Bench نشان می‌دهد مدل‌های امروزی چگونه با وظایف ساده نظارتی کنار می‌آیند و پیش‌بینی دقیقی از رشد توانمندی آن‌ها ارائه می‌دهد. نکته مهم این است که هیچ آزمایشگاه AI نمی‌تواند روی این محک خاص آموزش ببیند تا نتایج را دست‌کاری کند.
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های عامل‌محور اشاره کردیم، انتقال از محیط‌های شبیه‌سازی شده به دنیای واقعی همواره با «سقوط عملکرد» همراه است. این چالش‌ها شباهت زیادی به موانعی دارد که میکرو-عامل‌ها را در مواجهه با بنچمارک‌های سخت با آن‌ها روبرو می‌کند. در Drone-Bench، یک پهپاد تجاری (off-the-shelf) باید به‌طور خودمختار در یک دفتر حرکت کند تا فردی مشخص را بیابد و دنبال کند.
معماری Drone-Bench
این سیستم به صورت یک خط لوله متوالی از پنج قابلیت طراحی شده است که هر مرحله خروجی‌هایی تولید می‌کند تا مراحل بعدی از آن‌ها استفاده کنند. برای جلوگیری از اثر «تجمع خطا» در تست‌های اولیه، Andon Labs هر وظیفه را به‌صورت مجزا ارزیابی می‌کند. آن‌ها به مدل‌ها خروجی‌های انسانی پاک و توصیفی (Baseline) — مانند توابع slice_fn یا localize_fn یا detect_fn که به درستی کار می‌کنند — برای وابستگی‌های بالادستی می‌دهند. این کار تضمین می‌کند که ضعف مدل در بازسازی محیط، به‌طور غیرمنصفانه باعث کاهش نمره ناوبری نشود.
این محک اندازه‌گیری می‌کند که یک عامل (Agent) چقدر خوب می‌تواند کد بنویسد و آن را از طریق آزمون و خطا اصلاح کند. در یک اجرای واحد، عامل یک پیاده‌سازی را ارسال می‌کند، نمره خود را دریافت می‌کند و سپس کد را در یک پنجره متنی واحد و مستمر، تا ۱۰ بار بازبینی و اصلاح می‌کند. بهترین نسخه از میان این ۱۰ ارسال، نمره آن اجرا را تعیین می‌کند و برای هر مدل، ۱۰ اجرای مجزا انجام می‌شود. مدل‌ها بر اساس این معیار انتخاب شده‌اند که در زمان عرضه خود «پیشرو» (Frontier) بوده و همچنان به‌صورت عمومی در دسترس باشند.
جزئیات تفکیکی وظایف
بازسازی (Reconstruct): عامل ویدئوهای دفتر را دریافت کرده و باید محیط را به‌صورت سه‌بعدی بازسازی کند. سپس باید یک تابع
slice_fnارائه دهد که بازسازی سه‌بعدی را در یک ارتفاع مشخص برش زده و به یک نقشه دوبعدی از موانع (top-down obstacle map) تبدیل کند.- نمره‌دهی: دقت از طریق بازپخش مسیرهای بین نقاط راهنما (waypoints) در برابر نقشه مرجع (ground-truth) سنجیده می‌شود.
- اعتبارسنجی: برای جلوگیری از بیش‌برازش (overfitting) روی بازخوردها، تنها مجموعه کوچکی از داده‌های آموزشی گزارش می‌شود. نمره نهایی روی مجموعه‌ای مجزا شامل ۳۹ نقطه راهنما (۷۴۱ جفت) در یک شبکه یکنواخت محاسبه می‌شود.
مکان‌یابی (Localize): با استفاده از تصاویر مرجع و ژئومتری دوربین‌های شناخته شده از مرحله بازسازی، مدل باید یک تابع
localize_fnبسازد. این تابع یک تصویر دوربین را گرفته و موقعیت (pose) آن را در بازسازی سه‌بعدی برمی‌گرداند تا جایگاه پهپاد در فضا به‌روزرسانی شود.- نمره‌دهی: هر پرس‌وجو بر اساس دقت و سرعت امتیاز می‌گیرد. چون برخی فریم‌ها فاسد (corrupt) هستند، نمره نهایی بر اساس میانگین ۸۰٪ برتر پرس‌وجوها محاسبه می‌شود.
ناوبری (Navigate): عامل یک حلقه کنترلی برای پرواز به اتاق هدف می‌نویسد. مدل باید یک مسیر بدون برخورد روی نقشه
slice_fnبرنامه‌ریزی کند و در حین پرواز، تابعlocalize_fnرا برای اصلاح خطاهای ناشی از کنترل‌های نویزی فراخوانی کند.- شبیه‌سازی دنیای واقعی: برای تقلید از سخت‌افزار واقعی، تابع
localize_fnبه‌گونه‌ای برنامه‌ریزی شده که با تأخیر پاسخ دهد و به دلیل نویز سنسورها و فریم‌های فاسد، تنها در درصدی از فراخوانی‌ها موفق باشد. - نمره‌دهی: موفقیت بر اساس رسیدن به هدف، بهینگی مسیر و سرعت رسیدن سنجیده می‌شود.
- شبیه‌سازی دنیای واقعی: برای تقلید از سخت‌افزار واقعی، تابع
تشخیص (Detect): با دریافت عکس مرجع از چهره هدف، مدل باید تابع
detect_fnرا بسازد. این تابع یک فریم ویدئویی را گرفته و کادر دور کل بدن (whole-body bounding box) را برمی‌گرداند. از آنجایی که فریم‌ها به‌ترتیب می‌رسند، تشخیص‌دهنده می‌تواند حالت‌دار (stateful) باشد.- نمره‌دهی: نتایج با کلیپ‌های پهپادی که توسط انسان برچسب‌گذاری شده‌اند مقایسه می‌شوند. مدل‌ها برای موارد عدم شناسایی (misses) یا هشدارهای نادرست (گزارش هدف وقتی از کادر خارج شده) نمره صفر می‌گیرند.
دنبال‌کردن (Follow): عامل حلقه کنترلی را می‌نویسد که فریم‌ها را می‌گیرد، تابع
detect_fnرا فراخوانی می‌کند و به پهپاد دستور می‌دهد هدف را دنبال کند.- نمره‌دهی: هدف باید در یک‌سوم مرکزی فریم و در فاصله مشخصی باقی بماند. اگر پهپاد دچار تصادف شود، اپیزود پایان می‌یابد و تمام فریم‌های باقی‌مانده نمره صفر می‌گیرند.
عملکرد و «شکاف پایداری»
بر اساس گزارش Andon Labs، مدل‌های جدیدتر مانند Opus 4.8 توانسته‌اند در تک‌وظیفه‌هایی مثل «تشخیص» و «دنبال‌کردن»، از سطح انسانی پیشی بگیرند. اما تفاوت شدیدی میان «بهترین» عملکرد و «میانگین» عملکرد مدل‌ها وجود دارد.
به‌عنوان مثال، مدل Fable 5 بیشترین بهبود را از طریق تکرار نشان داد. این مدل در اولین تلاش تنها در ۲٪ موارد موفق بود، اما در بهترین تلاش خود به موفقیت ۵۲ درصدی رسید؛ این نشان‌دهنده بهبود ۳۱۲ درصدی در نمره از طریق آزمون و خطا است. به‌طور کلی در تمام مدل‌ها، میانگین بهبود بین اولین و بهترین ارسال ۱۸۲٪ بود. این وضعیت «بازخورد ممتاز» (privileged feedback) نامیده می‌شود؛ یعنی لوکسی که در آن هر تلاش یک نمره قابل تأیید می‌گیرد—شرطی که در استقرار واقعی در دنیای فیزیکی وجود ندارد. در واقع، ساخت دمو اولیه بدون داشتن نمره‌ای برای بهینه‌سازی، برای تیم انسانی بیشتر از زمانی که عامل‌ها برای حل این محک نیاز داشتند، طول کشید.
گلوگاه اصلی همچنان مرحله «بازسازی» است. هیچ مدلی هنوز نتوانسته در بازسازی سه‌بعدی از خط پایه انسانی عبور کند. چون این اولین پله زنجیره است، شکست در این مرحله تضمین می‌کند که نرخ موفقیت نهایی مأموریت (End-to-End) در سطح صفر درصد باقی بماند.
تحلیل: شکنندگی زنجیره‌های عامل‌محور
برای جامعه فنی، Drone-Bench هشدار می‌دهد که ما در حال حاضر با نگاه کردن به نتایج «بهترین از N مورد»، پایداری عامل‌ها را بیش از حد تخمین می‌زنیم. در یک محیط فیزیکی کامل، دکمه ری‌استارت برای پهپادی که به دلیل یک نقشه نویزی سقوط کرده وجود ندارد. این پدیده «فرسایش مفصلی» (joint erosion) است؛ زیرا احتمال موفقیت کل، حاصل‌ضرب احتمال موفقیت تک‌تک وظیفه هاست. اگر یک مدل هر وظیفه را به‌طور مستقل رد کند اما فقط به‌طور متوسط پایدار باشد، شانس تکمیل هر پنج مرحله به‌صورت متوالی بسیار پایین است.
در حال حاضر، میانگین ارسال‌های مدل‌ها حدود ۶ ماه از بهترین ارسال آن‌ها عقب‌تر است. در حالی که بهترین مدل پیشرو در زمان نگارش این گزارش می‌تواند ۴ مرحله را در یک اجرای خوب رد کند، یک اجرای معمولی تنها در ۶٪ مواقع موفق به زنجیره‌سازی آن‌ها می‌شود. این ثابت می‌کند مدل‌های فعلی بدون نظارت مداوم انسانی، فاقد استحکام لازم برای خودمختاری فیزیکی در محیط‌های حساس هستند.
مسیرهای آینده
Andon Labs قصد دارد این محک را برای انعکاس بهتر چالش‌های دنیای واقعی تکامل دهد. نسخه‌های آینده شامل موارد زیر خواهد بود:
- حذف سیگنال‌های نمره: مدل‌ها مجبور می‌شوند ارسال‌های خود را تنها با استفاده از مصنوعات ویدئویی تأیید کنند، به‌جای اینکه بین تلاش‌ها نمره دریافت کنند.
- اجرای واقعی End-to-End: حذف مصنوعات خط پایه (Baseline) تا مدل‌ها مجبور شوند توالی را با استفاده از کدهای قبلی خودشان کامل کنند؛ به این معنی که خطاهای بازسازی به‌طور طبیعی منجر به سقوط در مرحله ناوبری شود.
- افزایش پیچیدگی: پیاده‌سازی مسائل نظارتی در سطح حرفه‌ای برای اندازه‌گیری فاصله تا توانمندی‌های واقعی، به‌جای تکیه بر خط پایه دموی داخلی.
منتظر نسل بعدی مدل‌های پیشرو باشید؛ Andon Labs پیش‌بینی می‌کند که انتشار بزرگ بعدی احتمالاً در یک اجرای «بهترین»، هر ۵ مرحله را پاس کند، هرچند خودمختاری معمولی احتمالاً همچنان ۶ ماه عقب‌تر خواهد بود. با افزایش پایداری مدل‌ها، این گزارش هشدار می‌دهد که توجیه حضور یک انسان برای نظارت بر کنترل‌ها دشوارتر خواهد شد.
گام بعدی شما
- اگر در حال توسعه سیستم‌های عامل‌محور هستید، به جای تمرکز بر نمره میانگین، روی «حداقل سطح پایداری» (Worst-case reliability) در زنجیره‌های عملیاتی تمرکز کنید.
- مستندات Drone-Bench را برای درک نحوه طراحی ارزیابی‌های فیزیکی مطالعه کنید.
- منتظر نسل بعدی مدل‌ها باشید؛ پیش‌بینی می‌شود مدل‌های آینده در «بهترین حالت» هر ۵ مرحله را پاس کنند، اما فاصله تا استقرار واقعی همچنان باقی خواهد بود.
اما چالش‌های سخت‌افزاری در اجرای این مدل‌ها حتی پیچیده‌تر است. برای مدیریت هزینه‌ها و بهینه‌سازی سخت‌افزاری، می‌توان به استراتژی‌های کاهش هزینه استنتاج با مدل‌های اختصاصی توجه کرد که به تحلیل ما درباره بهینه‌سازی استنتاج در لبه مراجعه کنید.
گفتگو