گوگل قصد دارد پیش‌فرض «Answer type» را برای Gemini تغییر دهد؛ نگاهی به انقلاب UI هوش مصنوعی

پیش‌زمینهٔ تغییرات UI در Gemini

گوگل (Google) با عرضهٔ رابط کاربری جدید برای Gemini (Gemini) در ماه گذشته، دو دکمهٔ «Chat» و «Task» را روی صفحهٔ اصلی برنامهٔ Android (Android) گذاشت. این تصمیم پس از ماه‌ها آزمایش داخلی و بررسی رفتار کاربران صورت گرفت؛ پیش از این حتی گزینهٔ «Assign task» نیز در منوهای مخفی ظاهر شده بود. در نسخهٔ 17.72.13.sa.arm64 این برنامه، که به‌تازگی در دسترس کاربران اندروید 12 به بالا قرار گرفت، یک پنجرهٔ تنظیمات جدید به نام «Answer type» ظاهر شد. این پنجره به‌صورت واضح نشان می‌دهد که گوگل (Google) هنوز در حال آزمون مسیرهای متفاوت UI برای Gemini است و شاید در حال بازنگری استراتژی تجربهٔ کاربری باشد.

در مقایسه با دیگر رقیبان مثل ChatGPT (ChatGPT) یا Claude (Claude)، تغییرات سریع UI در Gemini می‌تواند یک مزیت رقابتی باشد؛ چرا که کاربران هوش مصنوعی به‌سرعت به‌روزرسانی‌های نرم‌افزاری عادت کرده‌اند. اما این سرعت می‌تواند به‌معنای نوسان در تجربهٔ کاربری هم باشد؛ به‌خصوص وقتی که یک تغییر اساسی مثل پیش‌فرض «Answer type» می‌تواند نحوهٔ تعامل روزانهٔ میلیون‌ها کاربر را تحت تأثیر قرار دهد.

پیشنهاد جدید «Answer type»؛ چه مشکلی حل می‌شود؟

گزینهٔ جدید «Answer type» (Answer type) به کاربران اجازه می‌دهد تا بین حالت‌های Chat و Task یکی را به‌عنوان پیش‌فرض ذخیره کنند. در عمل، وقتی کاربر برنامهٔ Gemini را باز می‌کند، بسته به تنظیمات ذخیره‌شده، مستقیماً به رابط Chat یا Task منتقل می‌شود و نیازی به فشار دادن دکمهٔ انتخابی نیست. این کار به‌ویژه برای کاربران حرفه‌ای که بیشتر از یک حالت استفاده می‌کنند، می‌تواند زمان تعامل را به‌طور قابل‌توجهی کاهش دهد.

از منظر فنی، این تغییر می‌تواند فشار روی حافظهٔ موقت (VRAM) را کاهش دهد؛ زیرا مدل Gemini (Gemini) نیازی به بارگذاری همزمان دو مسیر پردازشی Chat و Task ندارد. در حالت پیش‌فرض قبلی، هر بار که کاربر دکمهٔ Chat یا Task را می‌زد، مدل باید حالت مربوطه را فعال کند که منجر به بارگذاری موقت داده‌ها و کوانتایزیشن (Quantization) موقت می‌شود. با ذخیرهٔ پیش‌فرض، این عملیات فقط یک‌بار در زمان شروع برنامه انجام می‌شود و از این‌رو مصرف VRAM به‌طور متوسط 15‑20٪ به‌صرفه می‌شود.

آثار فنی بر حافظه VRAM و کوانتایزیشن مدل

Gemini (Gemini) بر پایهٔ معماری Mixture of Experts (MoE) ساخته شده است؛ به این معنی که برای هر درخواست، تنها زیرمجموعه‌ای از متخصصان (Experts) فعال می‌شوند. این ساختار به‌خوبی با کوانتایزیشن ترکیب می‌شود تا وزن‌های مدل را به‌صورت 4‑bit یا 8‑bit فشرده‌سازی کند و فشار روی VRAM را کاهش دهد. اما وقتی دو حالت Chat و Task به‌صورت همزمان در UI فعال هستند، سیستم مجبور است دو مسیر MoE متفاوت را آماده کند؛ این کار به‌صورت مؤثری «سرفهٔ حافظه» ایجاد می‌کند.

با پیش‌فرض «Answer type»، تنها یک مسیر MoE فعال می‌ماند؛ بنابراین زمان بارگذاری اولیه کاهش می‌یابد و هزینهٔ انرژی GPU (مثلاً RTX 3060 یا 4070) در دستگاه‌های موبایل به‌ویژه کاهش می‌یابد. این به‌خصوص برای کاربران که Gemini را به‌صورت محلی (offline) با Ollama یا سایر فریم‌ورک‌های متن‌باز اجرا می‌کنند، مهم است؛ زیرا در این سناریو حافظهٔ VRAM محدودیت جدی است و هر صرفه‌جویی می‌تواند امکان اجرای مدل‌های بزرگتر را فراهم کند.

چالش‌های تجربه کاربری: انعطاف‌پذیری در برابر سادگی

اگرچه پیش‌فرض «Answer type» می‌تواند کار را برای کاربران ساده‌تر کند، اما هزینه‌ای برای انعطاف‌پذیری می‌گیرد. کاربرانی که به‌صورت ترکیبی از Chat و Task استفاده می‌کنند—مثلاً برای مکالمات طولانی و سپس تبدیل آن‌ها به تسک‌های عملی—حالا مجبورند برای جابجایی بین دو حالت تنظیمات را تغییر دهند. این مساله می‌تواند باعث شود کاربران احساس «قفل شدن» در یک حالت کنند و در نتیجه تجربهٔ کاربری را کمتر لذت‌بخش ببینند.

از سوی دیگر، این تغییر می‌تواند نشانگر یک استراتژی کلی‌تر گوگل (Google) باشد: تمرکز بر روی یک تجربهٔ «یک‌دکمه‌ای» که برای اکثر کاربران کافی باشد. این رویکرد مشابه تصمیمات قبلی در Google Assistant (Google Assistant) بود که به‌جای منوهای متعدد، گزینهٔ «Quick phrase» را به‌صورت پیش‌فرض فعال کرد. اما در حوزهٔ هوش مصنوعی، تنوع کاربردها بسیار بالاتر است؛ بنابراین، اگر گوگل (Google) به‌سرعت یک UI ثابت معرفی کند، ممکن است کاربران پیشرفته را از خود دور کند.

چشم‌انداز آینده: آیا گوگل به سمت UI ثابت می‌روید؟

با توجه به سرعتی که گوگل (Google) در به‌روزرسانی Gemini نشان می‌دهد، احتمال دارد که این تغییر تنها یک «پروتوتایپ» باشد. اگر بازخورد کاربران مثبت باشد، ممکن است «Answer type» به‌صورت دائمی در نسخهٔ نهایی پیاده شود و دیگر گزینه‌های «Assign» یا «Assign task» به‌صورت کامل حذف شوند. اما اگر کاربران نسبت به کاهش انعطاف‌پذیری واکنش منفی نشان دهند، ممکن است گوگل (Google) دوباره به‌سوی یک UI ترکیبی برگردد که هر دو دکمهٔ Chat و Task را در دسترس نگه دارد.

در هر صورت، این تحولات نشان می‌دهد که شرکت‌های بزرگ همچون گوگل (Google) به‌سرعت در حال آزمون مسیرهای مختلف UI برای مدل‌های بزرگ زبانی هستند؛ مسیری که نه تنها تجربهٔ کاربری را بهبود می‌بخشد، بلکه هزینهٔ محاسباتی و مصرف VRAM را بهینه می‌کند. برای ما که در حوزهٔ ایجنتیک و مدل‌های متن‌باز فعالیم، این یک فرصت طلایی است تا با ابزارهایی مثل Ollama یا LLaMA‑2 به‌صورت محلی این تغییرات را شبیه‌سازی کنیم و بررسی کنیم که آیا می‌توانیم با همان کارایی، هزینهٔ سخت‌افزاری را کاهش دهیم.

در نهایت، چشم‌انتظار ما این است که گوگل (Google) شفافیت بیشتری در برنامه‌های UI خود ارائه دهد؛ چرا که هر بار یک «پشت صحنه» جدید ظاهر می‌شود، ما به‌عنوان توسعه‌دهندگان و کاربران نهایی باید آمادهٔ ارزیابی دقیق فنی و تجربه‌ای باشیم.