Dream Labs من فريق NVIDIA DreamZero تجمع 90 مليون دولار وتطلق API للروبوتات

خرجت Dream Labs، وهي شركة ناشئة أسسها فريق DreamZero، من وضع التخفي بخبرين في آنٍ واحد. الأول جولة seed بقيمة 90 مليون دولار، وهو مبلغ كبير جدًا كبداية لشركة ليس لها سجل مبيعات معلن. والثاني إطلاق Dream API، الذي يصفه مطوّروه بأنه أول API عام في العالم لـ«دماغ» الروبوتات. وتولّى منصب المدير التقني غه يونهاو (葛云皓). تبدو الفكرة بسيطة: تربط الـ API بروبوتك، وتكتب المهمة بلغة عادية، وتقرر المنظومة ما ينبغي فعله.

ما الذي أُطلق بالضبط

كان الوصول إلى النماذج التي تتحكم بالآلات الفيزيائية حتى الآن يسير على نحو مختلف. فإما أن تكون أنظمة داخلية مغلقة لدى المختبرات الكبرى، وإما نقاط حفظ (checkpoints) مفتوحة المصدر عليك نشرها بنفسك، وإعادة تدريبها لتناسب عتادًا محددًا، وصيانتها. أما Dream Labs فتقترح صيغة مألوفة للمطوّرين: يذهب الطلب إلى الـ API، ويعود الرد على شكل إجراءات ينفذها الروبوت.

تُستخلص من الجزء المتاح من الإعلان ثلاث حقائق. الوصول مفتوح للعموم، وليس مقتصرًا على قائمة مغلقة من الشركاء. وواجهة التحكم مبنية على اللغة الطبيعية. ويمكن ربط الـ API بروبوت يملكه المستخدم، أي أن الشركة لا تبيع آلة جاهزة، بل تبيع طبقة الذكاء.

من أين تنبع هذه التقنية

يُعرف DreamZero بأنه مشروع بحثي من NVIDIA يدور حول ما يسمى world action models. وجوهر هذا النهج أن النموذج لا يكتفي بمطابقة الصورة مع الأمر، بل يستند إلى تمثيل داخلي لكيفية تغيّر العالم بعد تنفيذ الفعل. ولتحقيق ذلك تُستخدم أفكار من نماذج توليد الفيديو. والهدف العملي من هذا النهج هو نقل المهارات إلى مهام وبيئات جديدة دون إعادة تدريب لكل واحدة منها.

إذا كان Dream API يستند فعلًا إلى هذا الإرث، فالرهان واضح. المشكلة الرئيسية في الروبوتات اليوم ليست نقص العتاد، بل هشاشة البرمجيات. فالروبوت الذي يطوي المناشف ببراعة في المختبر كثيرًا ما يرتبك في مطبخ غريب. و«دماغ» عام خلف API قد يزيل هذه الهشاشة، أو على الأقل ينقلها إلى السحابة حيث تُعالج مركزيًا.

ما المعروف من الإعلان

• الجولة: seed، بقيمة 90 مليون دولار
• المنتج: Dream API، بوصول عام
• المُدخل: تعليمات بلغة طبيعية
• المُخرج: التحكم بالروبوت المتصل
• المدير التقني: غه يونهاو (葛云皓)
• الأصل: فريق DreamZero
• غير معلن في المادة المتاحة: المستثمرون، والأسعار، وقائمة المنصات المدعومة، وزمن الاستجابة، ومقاييس نجاح المهام

البند الأخير أهم من غيره. فزمن الاستجابة حاسم بالنسبة للروبوت: إذا كان الأمر يذهب إلى السحابة ويعود، فسيتعين إبقاء ردود الفعل السريعة، مثل إمساك جسم ما، على متن الروبوت نفسه. وهذا يعني أن البنية على الأرجح تقسّم العمل بين تخطيط سحابي ووحدة تحكم محلية. لكن هذا استنتاج، وليس حقيقة معلنة.

كيف ينبغي للمطوّرين التعامل مع هذا

ما زال الوقت مبكرًا لإعادة كتابة منظومتكم البرمجية حول Dream API، لكنه يستحق التجربة. والترتيب العملي كالتالي:

• اختاروا مهمة ضيقة واحدة، مثل نقل الأجسام من مكان إلى آخر أو فرز بسيط، وصيغوها بثلاث أو أربع تعليمات مختلفة. بهذا ترون مدى ثبات المنظومة أمام اختلاف الصياغة.
• قيسوا زمن الاستجابة من الأمر حتى أول حركة، وقارنوه بمتطلبات ميكانيكا روبوتكم. وإذا تجاوز بضع مئات من الميلي ثانية، فستحتاجون إلى طبقة أمان محلية.
• اسألوا الشركة عن الأذرع الروبوتية والمنصات المتنقلة المدعومة، وعمّا يلزم للتكامل: المعايرة والكاميرات وصيغة التحكم.
• فكّروا مسبقًا في تحمّل الأعطال. فخدمة سحابية تتحكم بجهاز فيزيائي، وهذا يعني أن على الروبوت أن يتوقف بأمان عند انقطاع الاتصال.
• اطلبوا شروط التسعير. فنموذج الدفع لكل طلب أو لكل دقيقة تشغيل سيحدد ما إذا كان الـ API يصلح لمنتجات تُنتَج بكميات كبيرة أم للنماذج الأولية فقط.

السؤال الرئيسي الموجّه إلى Dream Labs بسيط: ما مدى جودة عمل هذا «الدماغ» على روبوت لم يسبق له أن رآه؟ والجواب ستكشفه اختبارات مستقلة، لا عرض تقديمي. فإن كان مقنعًا، فسيجد أصحاب الشركات الناشئة العاملة بالعتاد طريقة لتجنب توظيف فريق مستقل لتدريب سياسات التحكم. وإن لم يكن كذلك، فسيصبح مبلغ 90 مليون دولار محاولة مكلفة أخرى لتحويل عرض بحثي توضيحي إلى بنية تحتية.