مدل Vision-Language-Action چیست و چرا آزمایشگاه آن را زمین میزند؟
بیایید اول روشن کنیم با چه چیزی طرف هستیم. مدل Vision-Language-Action یا به اختصار VLA، نوعی policy (سیاست تصمیمگیری) است که دو چیز را بهعنوان ورودی میگیرد — تصویر صحنه (یعنی پیکسلها) و یک دستور نوشتاری — و در خروجی، فرمان حرکتی سطح پایین ربات را تولید میکند. به بیان ساده، این مدل پلی است میان جملهای مثل «۲۰۰ میکرولیتر بافر به چاهک B3 اضافه کن» که در پروتکل نوشته شده، و حرکت واقعی بازوی ربات که آن کار را انجام میدهد.
نکتهی جالب مقالهی LabVLA که این ماه روی arXiv منتشر شد، در خود نوع نگاهش است. نویسندگان صراحتاً میگویند دو چیز گلوگاه اصلی استفاده از VLA در آزمایشگاههای علمی است: یکی داده و دیگری embodiment (یعنی سازگاری مدل با بدنه و سختافزار ربات مشخصی که قرار است کار را انجام دهد). مهم این است که این دو را همتراز با طراحی مدل میبینند، نه چیزی فرعی که بعد از ساخت مدل به آن میرسیم.
همین یک نکته، در واقع جان کلام است. هرکس مثل من سالها در پروژههای واقعی AI کار کرده باشد میداند که آن ادعای بیزرقوبرق — «دادهی درست نداریم، و راه یکپارچهای برای حرفزدن با رباتهای گوناگونی که همین حالا در ساختمان داریم نداریم» — تقریباً همیشه همان قیدی است که همهچیز را محدود میکند. مدل را میتوان آماده خرید؛ اما نوک پیپت، سطح شفاف مایع داخل ویال، و آن بازوی KUKA که چهار سال است روی میز پیچ شده — اینها را نمیتوان از قفسه برداشت.
مقاله دقیقاً چه چیزی پیشنهاد میدهد
LabVLA دو بخش دارد.
بخش اول یک data engine (موتور تولید داده) به نام RoboGenesis است. کار آن این است: گردشکارهای آزمایشگاهی را از مهارتهای پایه و کوچک (مثل «مکش مایع» یا «جابجایی تیوب») میسازد، آنها را در محیط شبیهسازی اجرا میکند، نتیجه را بررسی و فیلتر میکند، و در نهایت نمونههای آموزشی ساختاریافته را برای پروفایلهای مختلف ربات بیرون میدهد. بهجای آنکه کسی هزاران ساعت رفتار درست را دستی به ربات نشان دهد، این موتور آن داده را خودش میسازد.
بخش دوم خود policy است. پایهی آن یک مدل زبانی‑تصویری Qwen3-VL-4B-Instruct است که در دو مرحله آموزش میبیند. مرحلهی اول FAST action token pretraining نام دارد: پیش از آنکه مدل اصلاً با کنترل پیوسته آشنا شود، یادش میدهیم که مفهوم «کنش» را بفهمد و نسبت به آن «آگاه» شود. مرحلهی دوم flow matching در post-training است، که یک ماژول تخصصی تولید کنش (DiT action expert) را به مدل میچسباند. نویسندگان این مرحله را با مکانیزمی به نام knowledge insulation (عایقبندی دانش) انجام میدهند تا آموزش تازه، دانش قبلی مدل را خراب نکند.
روی بنچمارک LabUtopia، نویسندگان گزارش میکنند که بالاترین میانگین موفقیت را در میان مدلهای پایهی مقایسهشده داشتهاند — هم در دادههای آشنا (in-distribution) و هم در دادههای ناآشنا (out-of-distribution). کد هم روی GitHub منتشر شده است.
اگر آکرونیمها را کنار بگذاریم، کل این معماری دارد یک مسالهی مشخص را حل میکند. مشکل رایج این است: شما یک سر کنترل پیوسته را به یک مدل زبانی منجمد میچسبانید، اما آن مدل اصلاً نمیداند «کنش» یعنی چه. این دو مرحلهی آموزش، در واقع یک اعتراف صادقانه است — مدلی با چهار میلیارد پارامتر که روی متن وب آموزش دیده، ذاتاً نمیداند که آن دنبالهی token که تولید کرده، قرار است یک بازوی واقعی را تکان دهد. پس اول با FAST tokenها یک واژگان گسسته برای کنش به مدل میدهیم؛ بعد flow matching مسیر حرکت را بهصورت پیوسته و دقیق تنظیم میکند؛ و آن عایقبندی هم برای این است که در این مسیر، دانش زبانی‑تصویری اولیه آسیب نبیند. این یک مصالحهی کاملاً عملی است و هر تیمی که زمانی تلاش کرده یک مدل بزرگ را برای یک ربات یا کاربرد خاص و باریک تنظیم کند، حتماً با آن روبهرو شده است.
ادعای اصلی، دربارهی داده است
اگر بخواهم در نقش داور به این مقاله ایراد بگیرم، ایرادم به مدل نیست؛ به تصویر ضمنیای است که از آزمایشگاه میسازد. حق با نویسندگان است: مدلهای VLA موجود بیشتر روی نمونههای خانگی و رومیزی آموزش دیدهاند، و آزمایشگاه پر است از اشیائی که این مدلها تقریباً هرگز ندیدهاند. مایعات شفاف با سطح بازتابنده؛ ویالهای دهانباریک؛ رکهایی پر از تیوب کاملاً یکسان که فقط یک برچسب چاپی آنها را از هم متمایز میکند؛ و دستگاههایی که وضعیتشان فقط روی یک نمایشگر کوچک LCD نشان داده میشود. کار RoboGenesis دقیقاً این است که برای همین موقعیتهای دشوار، دادهی آموزشی بسازد — چون واقعاً هیچکس نمینشیند ده هزار ساعت پیپتزدن را دستی به ربات یاد بدهد.
این همان بخشی است که برای هرکس بخواهد خودکارسازی آزمایشگاه را واقعاً به مرحلهی تولید برساند، اهمیت دارد. در دنیای واقعی، سوال هرگز این نیست که «آیا مدل ما روی فلان بنچمارک بهترین است؟». سوال درست این است: چقدر دادهی واقعی از میز آزمایشگاه لازم داریم تا رفتاری که در شبیهسازی یاد گرفتهایم، وقتی به یک پروتکل واقعی و مرطوب میرسد، از هم نپاشد؟ پایپلاین LabVLA بخشی از این سوال را پاسخ میدهد، چون دادهی شبیهسازی را ارزان، ساختاریافته و قابل انتقال میان رباتهای گوناگون میکند.
اما به سوال سختتر پاسخ نمیدهد: فاصلهی میان شبیهسازی و واقعیت (sim-to-real gap) روی مایعات شفاف. و این یکی از واقعاً دشوارترین مسائل ادراک ماشینی در این حوزه است. شکست نور هنگام عبور از مایع، بازتابهای براق روی سطح، و این واقعیت که یک تیوب نیمهپر و یک تیوب پر، از زاویهی دوربینی که بالای مچ ربات نصب شده، تقریباً یکسان دیده میشوند. این چیزی است که شبیهسازی بهسختی میتواند درست بازتولید کند.
embodiment، یک شهروند درجهیک
نکتهی دیگری که باید جدی گرفت این است که نویسندگان embodiment را همتراز با داده، یک گلوگاه میدانند. منظور از embodiment این است که هر آزمایشگاه با سختافزار مشخص خودش کار میکند، و این سختافزارها بسیار متنوعاند. در عمل، هر آزمایشگاه دانشگاهی هرچه دارد با همان سر میکند: یک Opentrons اینجا، یک بازوی UR5 آنجا، و یک سازهی متحرک سفارشی که یک دانشجوی پسادکترا در سال ۲۰۲۱ ساخته. مدلی که فقط روی یکی از اینها کار کند، عملاً یک دموی پژوهشی است، نه چیزی که واقعاً در آزمایشگاه به کار بیاید.
اینکه RoboGenesis نمونههای آموزشی را برای پروفایلهای مختلف ربات بیرون میدهد، شکل درست راهحل است. ایده ساده اما مهم است: مهارت را — مثل «۲۰۰ میکرولیتر مکش کن» — از سینماتیکی که آن مهارت را اجرا میکند جدا میکنیم. آنگاه میگذاریم موتور داده، همان مهارت را برای هر ربات از نو و متناسب با بدنهی خودش بازسازی کند.
این دقیقاً همان الگویی است که، برای مثال، پایپلاینهای پردازش هوشمند اسناد بهسختی آموختهاند: برای هر مشتری یک مدل جداگانه آموزش نمیدهی؛ یک مدل را روی یک مولد دادهی پارامتریشده آموزش میدهی که میتواند انواع ساختارها را بسازد. این درس قابل تعمیم است. اگر موتور دادهی تو نتواند یک مهارت واحد را برای N نوع ربات تولید کند، در پایان مجبور میشوی N مدل جداگانه عرضه کنی — و هیچکدام را هم درست و حسابی نگه نمیداری.
این برای چه کسی واقعاً به درد میخورد؟
بگذارید صریح باشم. تیم خودکارسازی یک شرکت دارویی بزرگ که بودجه دارد، همین حالا میتواند یک دستگاه مدیریت مایع Hamilton یا Tecan بخرد که پروتکل را بهصورت کاملاً قطعی و قابلپیشبینی اجرا میکند، بدون آنکه هیچ VLAای در حلقه باشد. این تیم به LabVLA نیازی ندارد.
مخاطبی که واقعاً به آن نیاز دارد، آزمایشگاه دانشگاهی یا شرکت صنعتی نوپایی است که سه ویژگی دارد: اول، پروتکلهایش هر هفته عوض میشوند؛ دوم، تجهیزاتش ناهمگون است و از سازندههای مختلف؛ و سوم، استخدام یک تکنسین تازه اصلاً روی میز نیست. برای چنین جایی، یک VLA که یک پروتکل نوشتهشده را میخواند و هر بازویی که در دسترس باشد را به کار میگیرد، واقعاً ارزشمند است — به شرطی که نرخ موفقیتش روی میز واقعی، نه روی شبیهسازی LabUtopia، از یک آستانهی قابلاتکا بگذرد.
مقاله هنوز آن آستانه را به ما نمیگوید. نتایج گزارششده روی بنچمارک LabUtopia است، که شبیهسازیشده است. خوانش صادقانه این است: LabVLA یک دستورکار معتبر برای سمت آموزش VLAهای آزمایشگاهی است، و از طریق RoboGenesis یک ابزار عمومی مفید برای سمت داده و embodiment. اینکه مدل نهایی بتواند یک هفتهی کامل روی یک میز واقعی آزمایشگاه دوام بیاورد یا نه، پرسشی تجربی است که حالا جامعهی پژوهشی میتواند به آن پاسخ دهد — تا حدی به این دلیل که کد بهصورت باز منتشر شده است.
آن چارچوبی که نگه میدارم
جملهای که مدام به آن بازمیگردم، همان است که داده و embodiment را در کنار طراحی مدل، گلوگاه مینامد. در تجربهی من، تقریباً برای هر مسالهی کاربردی AI که به مرحلهی تولید رساندهام، همین نگاه درست بوده است. مدل، بخش دیدنی کار است؛ اما پایپلاین داده و رابطی که مدل را به سیستم فیزیکی یا سازمانی زیرین وصل میکند، همان بخشی است که در نهایت تعیین میکند چیزی به تولید میرسد یا نه. LabVLA کمتر به این دلیل که در یک بنچمارک اول شده جالب است، و بیشتر به این دلیل که قیدهای کسلکننده اما تعیینکننده را در عنوان اصلی کارش گذاشته است — درست همانجایی که باید باشند.
منابع
- LabVLA: Grounding Vision-Language-Action Models in Scientific Laboratories — arXiv · cs.AI · 2026-06-11