اخیراً گوگل زیرساخت مدل زبانی بزرگ (LLM) Gemini را در سخت‌افزار Nest و سرویس‌های خانه هوشمند خود ادغام کرده است. این تغییر، اجرای فرمان‌های ساده را از تطبیق الگوی قطعی (Deterministic Pattern Matching) به پردازش زبان طبیعی مبتنی بر ابر (Cloud-based NLP) منتقل کرده است. نتیجه برای برخی کاربران، افزایش تأخیر و وابستگی بیشتر به اتصال اینترنت است.
جمینای برای خانه؛ ارتقا یا افت تجربه؟
بر اساس گزارش XDA Developers، مسیریابی فرمان‌هایی مانند «لامپ میز را روشن کن» از طریق خط لوله استنتاج LLM از راه دور (Remote LLM Inference Pipelines)، تأخیرهای متغیر اجرا (Variable Execution Delays) و وابستگی به اتصال ابری (Cloud Connection Dependencies) ایجاد می‌کند. مدل‌های مولد در پرسش‌های باز و استخراج قصد پیچیده (Complex Intent Extraction) عملکرد خوبی دارند، اما برای کنترل‌های ساده و قطعی خانه، همین مسیر ابری می‌تواند تجربه را کندتر کند.
Google Assistant نیز ابری بود، اما از سامانه فرمان محدودتر و سخت‌گیرانه‌تری استفاده می‌کرد. با Gemini، یک مدل زبانی بزرگ اکنون درخواست‌ها را تفسیر می‌کند و پردازش سنگین‌تری پیش از بازگشت پاسخ به رفت‌وبرگشت ابری (Cloud Roundtrip) اضافه می‌شود. مسیریابی و دست‌دهی API ابری (Cloud API Routing and Handshake) نیز سربار قابل‌توجهی ایجاد می‌کند.
چرا پردازش ابری فرمان‌های ساده را کند می‌کند
بسیاری از دستیارهای صوتی ابری حتی وقتی دستگاه در شبکه محلی قرار دارد، فرمان‌ها را از سرورهای فروشنده عبور می‌دهند؛ بنابراین روشن کردن یک لامپ در چند قدمی نیز می‌تواند به یک رفت‌وبرگشت راه دور وابسته باشد. گوگل از اجرای محلی برای برخی دستگاه‌ها پشتیبانی می‌کند، اما روشن نیست این قابلیت تا چه حد به Gemini for Home تعمیم داده شده است. در تجربه گزارش‌شده، تأخیر برای فرمان‌های ساده گاه تا ۸ ثانیه رسیده است.
تغییرپذیری شبکه و نقاط شکست مرتبط با اینترنت همیشه از مشکلات سرویس‌های خانه هوشمند ابری بوده‌اند. افزودن تأخیر پردازش LLM به این مجموعه، تجربه را آزاردهنده‌تر می‌کند. کنترل‌کننده صوتی ابری برای روشن کردن یک کلید به اتصال فعال شبکه گسترده (WAN) نیاز دارد و هر تأخیر ISP بالادستی، ازدحام صف سرور یا افت کیفیت API ابری مستقیماً اجرای کنترل‌های پایه خانه هوشمند را متوقف یا کند می‌کند.
معماری محلی Home Assistant Assist چگونه کار می‌کند
جایگزین محلی این معماری، Home Assistant Assist همراه با ماهواره‌های صوتی محلی (Local Satellites) است. در این روش، کنترل‌کننده صوتی خانه هوشمند تا زمانی که دستگاه‌های دیگر سازگار باشند، می‌تواند کاملاً محلی بماند. Home Assistant استفاده از LLM را به‌طور کامل کنار نمی‌گذارد؛ Assist می‌تواند به‌صورت اختیاری برای درخواست‌های پیچیده‌تر از یک LLM استفاده کند، اما خط لوله پیش‌فرض فرمان‌های شناخته‌شده را به‌صورت قطعی پردازش می‌کند و کاربر می‌تواند زمان دخالت LLM را انتخاب کند.
معماری صوتی Home Assistant پردازش را با پروتکل Wyoming به سه ریزسرویس (Microservices) محلی تقسیم می‌کند: موتور کلمه بیدارباش (Wake Word Engine) مانند openWakeWord، موتور تبدیل گفتار به متن (Speech-to-Text) مانند Whisper یا گزینه سبک‌تر تبدیل گفتار به عبارت (Speech-to-Phrase)، و موتور تبدیل متن به گفتار (Text-to-Speech) مانند Piper. با تنظیم درست، یک دستیار صوتی محلی می‌تواند به‌اندازه Google Voice Assistant یا حتی سریع‌تر احساس پاسخ‌گویی ایجاد کند.
سرعت به‌شدت به انتخاب موتور تبدیل گفتار به متن بستگی دارد. گزینه تبدیل گفتار به عبارت فقط عبارت‌های ساخته‌شده از دستگاه‌ها و فضاهای کاربر را تشخیص می‌دهد و می‌تواند بسیار سریع‌تر باشد؛ در مقابل، Whisper انعطاف بیشتری دارد اما کندتر است و به سخت‌افزار قوی‌تری نیاز دارد.
Home Assistant Assist بر تطبیق قطعی قصد (Deterministic Intent Matching) تکیه دارد. به‌جای فرستادن عبارت‌ها به یک LLM پرمصرف، عامل گفت‌وگوی داخلی Home Assistant از HassIL (Home Assistant intent language) استفاده می‌کند؛ یک تطبیق‌دهنده جمله مبتنی بر قالب (Template-based Sentence Matcher) که متن تشخیص‌داده‌شده را به‌صورت محلی به یک اقدام تبدیل می‌کند. برای فرمان یا پاسخ سفارشی نیز می‌توان از intent_script استفاده کرد. برای نمونه، وقتی کاربر می‌خواهد چراغ آشپزخانه روشن شود، مرحله تطبیق قصد تنها چند میلی‌ثانیه طول می‌کشد و مستقیماً به light.turn_on در ماشین حالت محلی (Local State Machine) نگاشت می‌شود. زمان پاسخ کل به کل خط لوله بستگی دارد، اما با تنظیم سریع تشخیص گفتار می‌تواند به‌راحتی از رفت‌وبرگشت ابری پیشی بگیرد.
مزیت‌ها و محدودیت‌های اجرای محلی
- وابستگی صفر به WAN: حتی اگر سرویس‌دهنده اینترنت کاملاً قطع شود، ماهواره صوتی محلی می‌تواند چراغ‌ها را روشن و خاموش کند، خودکارسازی‌ها را اجرا کند و وضعیت اتاق‌ها را از طریق زیرشبکه محلی گزارش دهد.
- حریم خصوصی فیزیکی: می‌توان کلیدهای سخت‌افزاری قطع برق میکروفن را اضافه کرد تا نگرانی درباره ضبط‌های ناخواسته ابری، استخراج داده‌های تله‌متری پس‌زمینه (Telemetry Data Mining) یا تغییر سیاست‌های حریم خصوصی فروشنده کاهش یابد.
- نام‌گذاری دقیق موجودیت‌ها: موتورهای صوتی محلی به نمایش هدفمند دستگاه (Intentional Device Exposure) نیاز دارند. نام‌گذاری و نمایش صریح موجودیت‌های مشخص برای دستیار صوتی از ابهام فرمان (Command Ambiguity) جلوگیری می‌کند و تطبیق را قابل‌اعتمادتر می‌سازد.
- نیاز به ماهواره‌های سخت‌افزاری: سخت‌افزار ماهواره‌های محلی ممکن است چالش‌برانگیزتر از پشته نرم‌افزاری باشد. Home Assistant نسخه Home Assistant Voice Preview Edition را ارائه کرده است که یک ESP32-S3 مجهز به ESPHome را با پردازنده صوتی XMOS XU316 ترکیب می‌کند؛ این پردازنده حذف اکو، سرکوب نویز و کنترل خودکار بهره را در خود دستگاه انجام می‌دهد. برای ساخت DIY نیز می‌توان از ESP32-S3 همراه با فرانت‌اند صوتی سازگار استفاده کرد.
- ماهیت پیش‌نمایش: Voice Preview Edition دقیقاً یک نسخه پیش‌نمایش است و پشتیبانی از آن، به‌ویژه در زبان و کلمه بیدارباش، هنوز در حال گسترش است. ممکن است تجربه کاملاً بی‌نقص نباشد و به تنظیم دستی نیاز داشته باشد.
- سخت‌افزار میزبان: برای اجرای کم‌تأخیر تبدیل گفتار به متن، به یک سرور متوسط مانند مینی‌پی‌سی Intel N100 یا یک گره آزمایشگاه خانگی (Home Lab Node) نیاز است تا پردازش بلادرنگ قطعات صوتی بدون اشباع پردازنده (CPU Choking) انجام شود. اگر از قبل سرور خانگی دارید، این محدودیت ممکن است مسئله‌ای ایجاد نکند.
جمع‌بندی
ارتقای دستیارهای خانه هوشمند با LLMهای ابری اغلب نوآوری مکالمه‌محور (Conversational Novelty) را بر سودمندی خام (Raw Utility) مقدم می‌دارد. برای کنترل‌های ضروری اتاق، تأخیر ابری یک پسرفت مستقیم (Direct Regression) در تجربه کاربری است. با جدا کردن فرمان‌های صوتی از سرورهای راه دور، استفاده از ماهواره‌های صوتی محلی اختصاصی و پردازش خط لوله صوتی روی سخت‌افزار محلی، می‌توان سرعت و قابلیت اطمینان یک خانه هوشمند بدون ابر (Unclouded Smart Home) را بازیابی کرد.