تغییر تمرکز مهندسی رباتیک از آموزش مدل به طراحی لایه‌های حفاظتی

تصور کنید یک برنامه‌نویس رباتیک دیگر نیازی به آموزش مدل‌های پیچیده برای هر حرکت ساده ندارد و فقط باید ابزارهای درست را در اختیار هوش مصنوعی قرار دهد. این تغییر رویکرد، نقطهٔ پایان عصر آموزش‌های سخت‌گیرانه برای هر ربات و آغاز دوران «عامل‌های کاربر-ربات» است.

به گزارش گفتگوهای ۱۱ اکتبر ۲۰۲۶ با بنیان‌گذاران Waddle Labs و RoboCurve، گلوگاه پیشرفت در هوش مصنوعی فیزیکی از توانایی مدل‌ها به لایه‌های ارتباطی یا همان سیستم عصبی منتقل شده است. در حالی که مدل‌های چندمنظوره اکنون به اندازه کافی قدرتمند هستند تا ربات‌ها را بدون نیاز به آموزش‌های گسترده و اختصاصی (که پیش از این ضروری بود) کنترل کنند، مهندسی هوش مصنوعی فیزیکی در حال تغییر جهت است.

برای سال‌ها، صنعت بر مدل‌هایی مانند RT-2 تکیه می‌کرد که برای خروجی دادن مستقیمِ حرکات ربات، تنظیم دقیق (Fine-tuning) — شبیه وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — شده بودند. در این حالت، ربات صرفاً به عنوان یک امتداد تخصصی از مدل در نظر گرفته می‌شد.

اکنون پارادایم به سمت «عامل‌های استفاده از ربات» تغییر کرده است؛ مفهومی که پروفسور Phillip Isola از MIT آن را پیش برده است. در این ساختار، هوش مصنوعی ربات را نه به عنوان بخشی از خود، بلکه به عنوان مجموعه‌ای از ابزارها می‌بیند که می‌تواند از طریق نوشتن کد، آن‌ها را فراخوانی کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرچه لایه‌ی واسط پیچیده‌تر شود، مدیریت دسترسی‌ها حیاتی‌تر می‌شود. در اینجا نیز «هارنس» (Harness) یا همان لایه‌ی نرم‌افزاری پیرامون مدل، اکنون از خودِ مدل اهمیت بیشتری یافته است. این موضوع با تحلیل ما درباره‌ی وابستگی پایداری عامل‌ها به مهندسی هارنس همسو است که نشان می‌دهد لایه‌ی کنترلی، تضمین‌کننده‌ی عملکرد پیش‌بینی‌پذیر است. این لایه است که ابزارهای قابل فراخوانی توسط هوش مصنوعی را مدیریت می‌کند، بررسی‌های ایمنی را برای جلوگیری از تصادفات انجام می‌دهد و چارچوب‌های ارزیابی را برای اندازه‌گیری میزان موفقیت عملیات پیاده می‌کند.

چهار ستون اصلی عامل‌های رباتیک

پیاده‌سازی فنی اکنون بر چهار مکانیزم کلیدی متمرکز است:

• کد به مثابه سیاست: مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به جای پیش‌بینی مقادیر خام موتور، برنامه‌ای با توابع سطح بالا (مثل pick_up_object یا حرکت به یک ژست/پوز خاص) می‌نویسد. این روش از آموزش‌های قبلی مدل روی حجم عظیمی از کدهای توالی‌بندی شده بهره می‌برد. طبق مستندات گوگل در پروژه «Code as Policies» (۲۰۲۲)، ثابت شد که این سیستم می‌تواند تنها با ارائه چند نمونه در پرامپت به درستی عمل کند.
• کامپایل مهارت‌ها: برای حل مشکل تأخیر (Latency)، کارهای تکراری به «مهارت‌های» قابل استفاده و بازیافتی تبدیل می‌شوند. این کار اجازه می‌دهد مدل روی تغییرات سطح بالا — مانند شناسایی یک شیء ناشناس یا تصمیم‌گیری درباره نحوه بازیابی پس از شکست یک اقدام — تمرکز کند، در حالی که لایه‌ی حفاظتی (هارنس)، حرکات روتین را با سرعت بالا اجرا می‌کند. طبق گفته‌ی مهمانان این گفتگو، تأخیر مدل‌های پیشرو ماهانه حدود ۲ برابر کاهش می‌یابد که کنترل بلادرنگ (Real-time) را به واقعیت نزدیک‌تر می‌کند.
• استدلال فضایی از طریق استفاده از کامپیوتر: داده‌های محیط‌های دیجیتال، مانند کشیدن مکان‌نما برای چرخش دور یک مدل CAD، به مدل‌ها می‌آموزد که چگونه درباره روابط فضایی بالا-پایین، چپ-راست و دور-نزدیک استدلال کنند. طراحی ابزارهای رباتیک به گونه‌ای که از ابزارهای استفاده از کامپیوتر تقلید کنند، عملکرد فیزیکی ربات را بهبود می‌بخشد.
• ارسال محصول مبتنی بر ارزیابی: یادگیری در بستر متن (In-context learning) معمولاً بعد از ۲۰ تا ۴۰ نمونه به سقف می‌رسد و متوقف می‌شود. بنابراین، درس‌های آموخته شده از محیط واقعی باید از پرامپت خارج شده و به صورت مهارت‌های کدنویسی‌شده یا وزن‌های مدل در لایه‌ی حفاظتی ثبت شوند. بدون ارزیابی‌های سخت‌گیرانه، غیرممکن است بفهمیم که آیا تغییری در هارنس واقعاً به بهبود عملکرد کمک کرده است یا خیر.

معماری یک لایه‌ی حفاظتی مدرن

در عمل، این سیستم از الگوی سه‌مرحله‌ای پیروی می‌کند: مدل می‌پرسد، لایه‌ی حفاظتی بررسی می‌کند و آداپتور (Adapter) — لایه‌ای که دستورات مدل را به زبان سخت‌افزار ترجمه می‌کند — اجرا می‌کند. توسعه‌دهندگان با چارچوب‌هایی مثل FastMCP می‌توانند یک لایه کنترل ایجاد کنند که سخت‌افزارهای مختلف — مانند یک ربات چهارپا و یک ربات انسان‌نما — را پشت یک رابط ابزار واحد قرار دهد.

در این ساختار، مدل هرگز لایه‌ی انتقال (مانند ROS، WebRTC یا DDS) را نمی‌بیند و فقط با ابزارها در ارتباط است. ایمنی توسط لایه‌ی حفاظتی تضمین می‌شود؛ برای مثال، محدوده‌ی کاری (Workspace limit) مانند تعریف یک محدوده متری برای محورهای X و Y و Z، یک بررسی سخت‌افزاری در پایتون است که هیچ پرامپتی نمی‌تواند آن را دور بزند. این رویکرد برای مقابله با ریسک‌های امنیتی ضروری است، چرا که محک RoboHarm نشان داد مدل‌های پیشرو در صورت نبود لایه‌های حفاظتی سخت‌گیرانه، ممکن است دستورات خطرناک را اجرا کنند. این یعنی ایمنی فیزیکی ربات به «خوب رفتار کردن» مدل وابسته نیست.

هر ابزار نتیجه‌ای شفاف برمی‌گرداند. وقتی هدفی خارج از محدوده مجاز باشد، لایه‌ی حفاظتی وضعیت «رد شده» (Rejected) را اعلام می‌کند. این شکست‌های مشهود برای مدل حیاتی است تا بتواند مراحل بازیابی (Recovery steps) را فعال کند و برای توسعه‌دهندگان ضروری است تا ارزیابی‌ها را اجرا کنند.

گسترش لایه‌ی کنترل

برای تبدیل یک نمونه اولیه به سیستم آماده برای تولید صنعتی، لایه‌ی حفاظتی به سه جزء اضافی نیاز دارد:

• مجموعه وظایف (Task Suites): یک مجموعه جامع از تست‌ها با بررسی‌های پاس/فیل برای هر ابزار، تا اطمینان حاصل شود که هر تغییر در هارنس اندازه‌گیری می‌شود. برای جلوگیری از رفتارهای غیرقابل پیش‌بینی در مدل‌های محلی، می‌توان از الگوی عامل‌های محدود بهره برد تا از تغییرات بازگشتی و ناخواسته جلوگیری شود.
• گزارش‌گیری دقیق (Logging): ثبت تمام فراخوانی‌های ابزار و نتایج آن‌ها، به طوری که شکست‌های فیزیکی را بتوان در محیط شبیه‌سازی بازپخش و تحلیل کرد.
• مسیر ارتقا (Promotion Paths): مکانیزمی که در آن توالی از فراخوانی‌ها که سه بار متوالی با موفقیت اجرا شده است، به طور خودکار به عنوان یک مهارت دائمی ذخیره شود تا مدل مجبور نباشد دوباره راه حل را کشف کند.

این تغییر یعنی مهندسی هوش مصنوعی فیزیکی دقیقاً شبیه مهندسی عامل‌ها (Agent Engineering) شده است. برنده کسی نیست که لزوماً بهترین مدل را دارد، بلکه کسی است که مستحکم‌ترین طراحی ابزار و سخت‌گیرانه‌ترین گیت‌های ایمنی را ساخته است.

توسعه‌دهندگان اکنون باید بر ساخت مجموعه‌های وظایف با بررسی‌های پاس/فیل برای هر ابزار تمرکز کنند. با ثبت هر فراخوانی و ارتقای توالی‌های موفق به مهارت‌های دائمی، سیستم از یک پرامپت شکننده به یک ابزار صنعتی قابل اعتماد تبدیل می‌شود. اکنون چه چیزی اهمیت بیشتری دارد: یک مدل بهتر یا یک هارنس بهتر؟

گام بعدی شما

• طراحی مجموعه‌ای از تست‌های Pass/Fail برای هر ابزاری که به مدل می‌دهید.
• پیاده‌سازی سیستم Logging برای بازپخش شکست‌های فیزیکی در محیط شبیه‌سازی.
• تبدیل توالی‌های موفق به مهارت‌های دائمی برای کاهش وابستگی به استنتاج لحظه‌ای مدل.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.