درون چالش‌های مهندسی سخت‌افزاری برای تجاری‌سازی مدل‌های بینایی ماشین

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

بر اساس تحلیل فنی منتشرشده در ۲۷ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، فاصلهٔ میان یک دموی جذاب و یک محصول تجاری viable، به هوشمندی مدل مربوط نمی‌شود، بلکه به قابلیت اطمینان «حلقهٔ زمان-واقعی» (Real-time loop) بازمی‌گردد. بسیاری از تیم‌ها بینایی ماشین را صرفاً یک مسئلهٔ تشخیص (Detection) می‌بینند، در حالی که در واقعیت، این یک مسئلهٔ خط لوله (Pipeline) است. در این راستا، شناخت وظایف کلیدی بینایی ماشین می‌تواند به تیم‌ها کمک کند تا سریع‌تر به بازگشت سرمایه صنعتی دست یابند. درست است که مدل‌های بنیادی (Foundation Models) — که شبیه به ابزارهای همه‌کاره‌ای هستند که پیش از این روی میلیاردها داده آموزش دیده‌اند تا هر چیزی را بشناسند — هزینهٔ ساخت نسخهٔ اول را به‌شدت کاهش داده‌اند، اما دشواری‌های یکپارچه‌سازی سخت‌افزاری و پیش‌بینی‌ناپذیری محیط را از بین نبرده‌اند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی چالش‌های استقرار مدل‌های لبه اشاره کردیم، تفاوت میان تئوری و عمل در لایه‌های زیرین سخت‌افزار نهفته است. بسیاری از تیم‌ها الگوی شکست‌خوردهٔ ثابتی دارند: یک مدل را تنظیم دقیق (Fine-tuning) می‌کنند — یعنی مثل وقتی که به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه خاص دقیق شود — و پس از رسیدن به عددی خیره‌کننده در یک کلیپ منتخب، جشن می‌گیرند. اما وقتی سیستم وارد دنیای واقعی می‌شود، نور تغییر می‌کند، دوربین تکان می‌خورد یا کاربر لباسی می‌پوشد که مدل هرگز در داده‌های آموزشی ندیده است.

وقتی پاسخ مدل حتی نیم ثانیه دیر برسد، کل سیستم شکسته به نظر می‌رسد. بینایی ماشین صرفاً «مدلی که اشیا را می‌شناسد» نیست؛ بلکه یک چرخهٔ کامل است: حس کردن، تصمیم گرفتن و عمل کردن. این فرآیند باید در دنیایی که توسعه‌دهنده هیچ کنترلی روی آن ندارد، سریع و قابل اطمینان باشد.

اگر تجربه ساخت سیستم‌های زمان-واقعی داشته باشید، می‌دانید که مدل بینایی باید تنها به عنوان یک سرویس در مسیر درخواست (Request Path) دیده شود. مدل ورودی می‌گیرد، خروجی می‌دهد و یک هزینهٔ استنتاج (Inference) — یعنی همان لحظهٔ آشپزی واقعی بعد از آموزش — دارد. مهندسی واقعی در اطراف این گره اتفاق می‌افتد: فریم‌ها از کجا می‌آیند؟ خروجی چه سرنوشتی دارد؟ و سیستم چگونه با لحظاتی که مدل اشتباه می‌کند کنار می‌آید؟ برای مدیریت این خطاها، گاهی تغییر در معماری سیستم راهکاری مؤثرتر از اصلاحات سطحی برای رفع توهمات و خطاهای مدل است.

برای درک بهتر، سیستم Raqts (یک دیوار واکنش‌سریع برای ورزش‌های راکتی) را در نظر بگیرید. نرم‌افزار باید ضربه را حس کند، مسیر را محاسبه کند و یک پاسخ فیزیکی را تحریک کند. اگر Raqts ضربه را با نیم ثانیه تأخیر تشخیص دهد، هیچ مقدار دقتی نمی‌تواند تجربهٔ کاربر را نجات دهد. در اینجا عملکرد زمان-واقعی یک وضعیت باینری است: یا کار می‌کند یا نمی‌کند.

طبق گزارش‌های منتشرشده، چهار عامل اصلی شکست محصولات بینایی ماشین در مرحلهٔ تولید وجود دارد که هیچ‌کدام با «انتخاب مدل بهتر» حل نمی‌شوند:

• صحت در دنیای واقعی: این عدد با صحت در بنچمارک‌ها متفاوت است. دنیای فیزیکی مانند ورودی‌های نامعتبر کاربر، خصمانه است؛ نورپردازی‌های تست‌نشده و شلوغی‌های پس‌زمینه، دقت مدل را می‌کوبد. سوال کلیدی این نیست که «مدل چقدر دقیق است»، بلکه این است که «در چه شرایط واقعی دقیقی است و شما از کجا این را می‌دانید؟»
• بودجهٔ تأخیر (Latency Budget): این یک محدودیت مهندسی سخت است. یک بودجهٔ زمانی ثابت از دوربین تا استنتاج و سپس عمل وجود دارد. این بودجه تعیین می‌کند چه مدلی انتخاب شود، کجا اجرا شود و چه سخت‌افزاری آن را پشتیبانی کند.
• جایگاه معماری: تصمیم دربارهٔ محل اجرای مدل اثرات عمیقی دارد:
  • استقرار ابری (Cloud): محاسبات ارزان و به‌روزرسانی ساده است، اما تأخیر شبکه و وابستگی به اینترنت ایجاد می‌کند.
  • رایانش لبه (Edge Computing): تأخیر را کم کرده و آفلاین کار می‌کند، اما محدود به توان سخت‌افزاری محلی است و به‌روزرسانی را سخت می‌کند.
• درزهای سخت‌افزاری (Hardware Seams): محصولات بینایی ماشین فقط نرم‌افزار نیستند. دوربین‌ها، پایه-نگهدارنده‌ها، کنترل نور و محرک‌ها، هر کدام یک «درز سخت‌افزاری» هستند. شکست‌های سیستم معمولاً در این درزها اتفاق می‌افتد، نه در خودِ مدل.

برای تبدیل یک «پروژهٔ علمی» به یک «محصول»، باید پنج متغیر را تثبیت کرد:

۱. تعریف یک تصمیم واحد: یک وظیفهٔ شفاف (مثل شمارش یا ردیابی) که با اطمینان انجام شود، بهتر از پنج وظیفهٔ مبهم است.
۲. ثبت شرایط دنیای واقعی: مستند کردن نور، زاویه، فاصله و سرعت.
۳. تعیین بودجهٔ تأخیر: تصمیم‌گیری دربارهٔ اینکه پاسخ باید چقدر سریع به نظر برسد.
۴. انتخاب آگاهانه لبه یا ابر: بر اساس نیاز به حریم خصوصی و سرعت، نه بر اساس عادت.
۵. شمارش درزهای سخت‌افزاری: فهرست کردن تمام قطعات فیزیکی که سیستم باید آن‌ها را کنترل کند.

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

گام بعدی شما

• اگر در حال توسعه محصول هستید، ابتدا «بودجهٔ تأخیر» را به میلی‌ثانیه تعریف کنید و سپس مدل را انتخاب کنید.
• فهرستی از «درزهای سخت‌افزاری» پروژه خود تهیه کنید و برای هر یک یک سناریوی شکست (Failure Mode) بنویسید.
• داده‌های تست خود را با تغییر متغیرهای محیطی (نور و زاویه) به جای داده‌های پاک آزمایشگاهی به‌روز کنید.

این پیچیدگی‌های سخت‌افزاری تنها بخشی از ماجراست؛ اثرات مشابه در رایانش لبه برای مدل‌های زبانی را در تحلیل ما درباره‌ی SLM-Edge بررسی کنید.