ضرورت یک داور محلی
از ویژگی‌های عامل مصرفی به‌طور فزاینده انتظار می‌رود که در ریتم تعامل انسانی پاسخ دهند: پردازش کلمه بیدارباش، تخمین نگاه، همجوشی حسگر، طبقه‌بندی متن کوتاه. این گام‌ها به تأخیر حساس‌اند و روی داده‌ای کار می‌کنند که یا پیوسته است (صدا، حرکت، فریم‌های دوربین) یا به‌قدری شخصی که فرستادن آن به یک نقطه پایانی راه دور یک سطح خروج داده با سود عملکردی ناچیز اضافه می‌کند. رفت‌وبرگشت‌های ابری هزینه، تأخیر دنباله‌ای و یک مرز حریم خصوصی تحمیل می‌کنند که بیشتر این گام‌ها نیازی به عبور از آن ندارند.
یک عامل فقط-راه‌دور همچنین در حالت آفلاین شکست می‌خورد. برای یک دستیار سطح دستگاه، رفتار آفلاین یک حالت تنزل‌یافته نیست؛ یک نیاز پایه است. اگر داور نتواند بدون یک پرش شبکه به کلمه بیدارباش یا یک طبقه‌بندی محلی پاسخ دهد، ویژگی در هواپیما، در آسانسور، یا روی یک سلول شلوغ در دسترس نیست. داور وجود دارد تا گام‌های کوتاه را محلی نگه دارد و ارتقا را به یک تصمیم صریح و قابل حسابرسی تبدیل کند.
داور چه چیزی را تصمیم می‌گیرد
داور بر اساس کلاس وظیفه مسیریابی می‌کند، نه بر اساس درخواست فردی. یک تقسیم‌بندی عملی:
- محلی بماند. پردازش کلمه بیدارباش، تشخیص فعالیت صوتی، همجوشی نگاه و حسگر، طبقه‌بندی کوتاه، جست‌وجوهای embedding در برابر یک ایندکس محلی کوچک، و قالب‌بندی یا گذارهای وضعیت که فقط به زمینه محلی اخیر وابسته‌اند.
- ارتقا یابد. گام‌هایی که به زمینه طولانی، یک مدل بزرگ‌تر، یا ابزاری نیاز دارند که دستگاه نمی‌تواند به آن دسترسی داشته باشد (یک ایندکس retrieval راه دور، یک API پرداخت یا رزرو، یک مخزن وضعیت مشترک چندکاربره).
قاعده مسیریابی باید به‌صورت سیاست کدگذاری شود، نه به‌عنوان یک heuristic مدفون در کد برنامه. یک شیء سیاست، برای هر کلاس وظیفه، اهداف اجرای مجاز، حداکثر زمینه محلی، کلاس حریم خصوصی، و رفتار fallback را وقتی هدف محلی در دسترس نیست اعلام می‌کند. برنامه از داور درخواست تصمیم می‌کند و یک هدف به‌همراه یک کد دلیل دریافت می‌کند. این کار تقسیم را قابل بازرسی و قابل آزمون نگه می‌دارد، و مانع می‌شود که یک شاخه ویژگی خوش‌نیت بی‌سروصدا یک بافر میکروفون را به یک نقطه پایانی راه دور بفرستد.
یک مکانیزم مشخص: هر گام را به‌صورت یک توصیف‌گر کوچک با فیلدهایی برای کلاس وظیفه، بودجه تخمینی token یا فریم، ابزارهای موردنیاز، کلاس حریم خصوصی و مهلت نمایش دهید. داور توصیف‌گر را در برابر قابلیت‌های دستگاه (مدل محلی موجود، حافظه آزاد، وضعیت حرارتی، دسترسی‌پذیری شبکه) ارزیابی می‌کند و یکی از local، remote، یا defer را برمی‌گرداند. تصمیم و ورودی‌هایش برای هر اجرا ثبت می‌شوند. بدون آن لاگ، تقسیم بازتولیدپذیر نیست؛ با آن، یک ارتقا می‌تواند بازپخش و توضیح داده شود.
محدودیت‌هایی که تقسیم را شکل می‌دهند
سقف حافظه و بودجه حرارتی. یک گوشی فقط می‌تواند تعداد محدودی گام محلی را قبل از throttle اجرا کند. داور باید فضای حرارتی را به‌عنوان یک ورودی درجه‌یک در نظر بگیرد، نه یک پس‌اندیش. وقتی دستگاه گرم است، رفتار درست معمولاً این است که ارزان‌ترین گام‌های محلی را محلی نگه دارد و بقیه را به تعویق بیندازد یا ارتقا دهد، نه اینکه همه چیز را اجرا کند و بگذارد زمان‌بند کل خط لوله را تنزل دهد. این یک trade-off واقعی است: ارتقا تحت فشار حرارتی هزینه و تأخیر ابری را دقیقاً زمانی افزایش می‌دهد که کاربر بیشترین احتمال توجه را دارد، اما اجرای گام‌های محلی به وضعیت throttle تأخیر بدتر و کم‌قابل‌پیش‌بینی‌تری تولید می‌کند.
انحراف نسخه مدل. مدل دستگاه و مدل سرور از هم فاصله می‌گیرند. مگر اینکه تقسیم برای هر اجرا ثبت شود — کدام مدل کدام گام را در کدام نسخه سرو کرده — یک تغییر رفتار قابل انتساب نیست. یک رکورد بازتولیدپذیری باید تصمیم داور، شناسه و نسخه مدل برای هر گام اجراشده، و بازبینی سیاست در نیرو را ثبت کند. این تفاوت بین یک سیستم قابل اشکال‌زدایی و سیستمی است که فقط روی ماشینی که در آن ساخته شده درست رفتار می‌کند.
طبقه‌بندی حریم خصوصی قبل از سریال‌سازی. طبقه‌بندی حریم خصوصی باید قبل از سریال‌سازی payload اتفاق بیفتد، نه بعد از آن. وقتی یک بافر به بدنه درخواست کدگذاری شد، طبقه‌بندی یک ویژگی transport است، نه داده، و برای گرفتن تصمیم مسیریابی روی آن خیلی دیر است. ابتدا توصیف‌گر گام را طبقه‌بندی کنید؛ سپس تصمیم بگیرید؛ سپس فقط آنچه هدف انتخاب‌شده مجاز به دریا
گران است.
آزمون تقسیم
تقسیم یک مرز سیستم است، پس به ارزیابی خودش نیاز دارد. سه رویه مهم‌اند.
مسیر فقط-محلی را جدا از مسیر ارتقایافته اندازه بگیرید. یک نرخ موفقیت تجمیعی واحد این واقعیت را پنهان می‌کند که مدل محلی ممکن است دقیقاً روی مواردی که ارتقا می‌یابند شکست بخورد. موفقیت وظیفه را به‌ازای هر مسیر، و به‌ازای هر کلاس وظیفه در هر مسیر گزارش دهید. اگر نرخ موفقیت مسیر محلی پایدار است اما نرخ ارتقا در حال افزایش است، مدل محلی در حال تنزل است یا توزیع ورودی جابه‌جا شده است.
نرخ ارتقا را به‌عنوان یک متریک درجه‌یک ابزارگذاری کنید. نرخ ارتقا واضح‌ترین سیگنال سلامت مدل محلی است. نرخ صعودی یعنی دستگاه بیشتر به ابر تکیه می‌کند، که هزینه، تأخیر و مواجهه حریم خصوصی را تغییر می‌دهد. آن را به‌ازای هر کلاس وظیفه و هر رده دستگاه ردیابی کنید، و یک آستانه بازبینی تعیین کنید نه آستانه هشدار: هدف این است که انحراف را قبل از تبدیل شدن به یک مسئله هزینه یا انطباق متوجه شوید.
شرایط آفلاین و شبکه تنزل‌یافته را به‌عنوان سناریوهای ارزیابی استاندارد شبیه‌سازی کنید. آفلاین برای یک دستیار سطح دستگاه یک مورد لبه‌ای نیست. اجراهای ارزیابی باید شامل این‌ها باشند: کاملاً آفلاین، شبکه قابل‌دسترس با تأخیر بالا، و قابل‌دسترس-سپس-قطع‌شده در میانه گام. مسیر defer داور و رفتار fallback آن باید تمرین شوند، نه فرض. یک گام که ارتقا می‌یابد و سپس شبکه را از دست می‌دهد باید به روشی تعریف‌شده شکست بخورد، و آن تعریف به مجموعه ارزیابی تعلق دارد.
یک trade-off صادقانه
تقسیم محلی-اول رایگان نیست. نگه داشتن یک مدل محلی به‌روز یعنی ارسال به‌روزرسانی‌های مدل، مدیریت تفاوت‌های قابلیت رده دستگاه، و پذیرش این که برخی گام‌ها توسط مدلی کوچک‌تر از آنچه ابر می‌تواند ارائه دهد سرو شوند. داور یک لایه تصمیم اضافه می‌کند که خودش باید آزمون شود، و سیاستش باید در کنار مدل‌ها نسخه‌بندی شود. جایگزین — یک عامل فقط-راه‌دور — ساختش ساده‌تر و حفظ یکدستی‌اش آسان‌تر است، اما در آفلاین شکست می‌خورد، به هر گام کوتاه یک رفت‌وبرگشت اضافه می‌کند، و سطح خروج داده را گسترده‌تر می‌کند. برای دستیارهای دستگاه مصرفی، داور محلی پیش‌فرض قابل‌دفاع‌تری است، به شرطی که تقسیم ثبت، اندازه‌گیری و به‌عنوان یک مرز مهندسی برخورد شود نه یک جزئیات پیاده‌سازی.