گوگل کلاد مهاجرت میان نسل‌های مدل پایه را با workflow عاملی از ماه‌ها به ساعت‌ها نزدیک کرد

یکی از دردناک‌ترین بخش‌های عملیات AI سازمانی، خودِ ساخت مدل نیست؛ مهاجرت مداوم بین نسل‌ها و checkpointهای تازه است. گوگل کلاد در یادداشت رسمی ۱۷ ژوئیه ۲۰۲۶ همین مسئله را هدف گرفته و توضیح می‌دهد چرا upgrade مدل‌های پایه معمولاً به پروژه‌ای کند، پرهزینه و آکنده از کار دستی تبدیل می‌شود. به‌گفته گوگل، بسیاری از تیم‌های مهندسی هنوز برای مهاجرت از یک checkpoint به checkpoint تازه، هفته‌ها یا ماه‌ها صرف ارزیابی دستی کیفیت، مقایسه پاسخ‌ها و تنظیم prompt می‌کنند. این در حالی است که cadence انتشار مدل‌های جدید آن‌قدر سریع شده که چنین روشی دیگر پایدار نیست.

نکته مهم خبر این است که گوگل صرفاً یک best practice کلی ارائه نمی‌دهد، بلکه از تجربه داخلی خود برای ساخت یک workflow عاملی حرف می‌زند که می‌تواند migration را از ماه‌ها به ساعت‌ها نزدیک کند. برای خواننده حرفه‌ای سایت، این دقیقاً همان نقطه‌ای است که AI engineering به architecture زیرساختی گره می‌خورد؛ چون موضوع فقط «مدل بهتر» نیست، بلکه ساخت فرایندی repeatable برای ارزیابی، انتخاب و rollout مدل جدید است.

لید خبری

گوگل کلاد می‌گوید مدل‌های جدید با سرعتی عرضه می‌شوند که فرایند کلاسیک ارزیابی انسانی دیگر توان همراهی با آن را ندارد. پاسخ پیشنهادی شرکت، جایگزینی migration دستی با یک loop عاملی است که discovery، ارزیابی، prompt optimization و orchestration را به‌شکل سازگار با نیاز هر تیم اجرا می‌کند.

نکات مهم

• گوگل می‌گوید از سال ۲۰۲۳ تاکنون شش تحول عمده در خانواده مدل‌هایش رخ داده و امروز به Gemini 3.5 رسیده است.
• تیم Applied ML این شرکت workflowای ساخته که ارتقای مدل را به‌جای ماه‌ها، در ساعت‌ها جلو می‌برد.
• سه درس کلیدی معرفی‌شده شامل discovery نزدیک به مسئله واقعی، پرهیز از rigid automation و pivot به معماری agentic منعطف است.
• الگوی پیشنهادی بر Agent Platform، ADK، Autorater و Google Antigravity تکیه دارد.
• نمونه عملی ارائه‌شده از سرویس ترجمه و دوبله ویدیو استفاده می‌کند که باید طول گفتار را بدون تغییر معنا با نسخه اصلی هماهنگ نگه دارد.

معرفی فنی

در متن رسمی، گوگل به‌درستی روی ریشه مسئله دست می‌گذارد: migration مدل فقط تعویض endpoint نیست. هر ارتقا می‌تواند روی کیفیت، latency، هزینه، tone پاسخ، نحوه پیروی از دستور و رفتارهای edge اثر بگذارد. اگر تیم شما محصولی حساس بر پایه LLM ساخته باشد، تغییر model family یا حتی checkpoint جدید می‌تواند زنجیره‌ای از regressionها را آزاد کند. برای همین، بسیاری از تیم‌ها ناچارند مجموعه‌های بزرگی از تست انسانی، بازبینی خط‌به‌خط و tuning دستی را تکرار کنند.

گوگل ابتدا همین مسیر سنتی را تجربه کرده است. درس اول آن‌ها «hands-on discovery» بود؛ یعنی مهندسان کنار تیم‌های محصول بنشینند و migration واقعی را از نزدیک ببینند تا requirementهای پیچیده و failure modeها روشن شود. این مرحله شاید ساده به نظر برسد، اما ارزشش در جلوگیری از ساخت automation خیالی است. اگر workflow از مسئله واقعی شروع نشود، خیلی زود به اسکریپتی خشک و بی‌فایده تبدیل می‌شود.

تغییرات یا مشخصات

درس دوم گوگل هشدار درباره rigid automation است. شرکت می‌گوید راهنماهای اولیه را به فرایند استاندارد خودکار تبدیل کرد و quick win هم گرفت، اما خیلی زود معلوم شد automation کلاسیک برای data formatهای مختلف، edge caseها و نیازهای متفاوت تیم‌ها بیش از حد خشک است. این دقیقاً همان تجربه‌ای است که در بسیاری از سازمان‌ها با MLOps و GenAIOps دیده می‌شود: pipeline ظاهراً خودکار است، اما به‌محض تغییر ورودی یا هدف کسب‌وکار، همه‌چیز به دخالت دستی برمی‌گردد.

درس سوم و مهم‌تر، حرکت به‌سوی معماری agentic منعطف است. گوگل می‌گوید نقطه عطف زمانی بود که ابزار را به‌جای workflow rigid، به agent بازطراحی کرد؛ عاملی که می‌تواند داده را تحلیل کند، promptها را پویا آزمایش کند و با اقتضای هر پروژه سازگار شود. در مثال تیم ویدیو، سیستم ground-truth dataset و baseline prompt را می‌گیرد و به‌طور خودکار quality را hill-climb می‌کند تا سرویس از stack سفارشی قبلی به foundation model پیش‌فرض جدید مهاجرت کند.

کاربرد سازمانی

برای سازمان‌ها، اهمیت این خبر فقط در صرفه‌جویی زمانی نیست. اگر migration میان مدل‌ها همچنان دستی باقی بماند، technical debt زیرساخت AI به‌سرعت بالا می‌رود. تیم‌ها روی نسخه‌های قدیمی‌تر می‌مانند، featureهای تازه را از دست می‌دهند و در نهایت برای نگه‌داری prompt، guardrail و fine-tuneهای قدیمی هزینه بیشتری می‌پردازند. گوگل عملاً استدلال می‌کند که migration باید خود یک workflow عاملی باشد، نه task فرعی برای تیم محصول.

از منظر اجرایی، سه گام پیشنهادی گوگل نیز روشن‌اند: اول Autoraterها را به‌جای human review محدود در مقیاس قرار دهید؛ دوم با ADK یک agentic loop بسازید؛ سوم orchestration و حتی coding tasks را با Antigravity خودکارتر کنید. این سه لایه در کنار هم migration را از «بازبینی دستی خروجی‌ها» به «ارزیابی و اصلاح مداوم در مقیاس» تبدیل می‌کنند.

محدودیت‌ها و زمان عرضه

البته این رویکرد بدون پیش‌نیاز نیست. سازمان باید dataset مرجع، معیارهای روشن کیفیت و آمادگی کافی برای model-based evaluation داشته باشد. Autorater ضعیف یا data نامتوازن می‌تواند migration را سریع ولی نادرست کند. همچنین برخی workloadها هنوز آن‌قدر domain-specific هستند که مهاجرت آن‌ها به foundation model عمومی بدون fine-tune ممکن است به نتیجه مطلوب نرسد.

این خبر هم بیش از آنکه release note یک محصول مستقل باشد، blueprint عملیاتی برای engineering teamها است. با این حال ارزشش بالا است، چون direction گوگل را نشان می‌دهد: migration مدل باید به مسئله‌ای زیرساختی و خودکارشونده تبدیل شود.

جمع‌بندی تحلیلی

در نهایت، یادداشت گوگل کلاد یک پیام مهم برای تیم‌های AI سازمانی دارد: اگر هنوز upgrade مدل‌ها با spreadsheet، بازبینی انسانی پراکنده و آزمایش دستی جلو می‌رود، این فرایند دیر یا زود به گلوگاه رشد تبدیل می‌شود. Agent Platform، Autorater و Antigravity قرار است این گلوگاه را بشکنند و migration را به loopی سازگار، تکرارپذیر و سریع‌تر بدل کنند. برای مطالب نزدیک‌تر، دسته نرم‌افزار زیرساخت و گزارش پیشین ما درباره پلتفرم‌های عامل‌محور تصویر کامل‌تری از این روند می‌دهند.

منابع

• Google Cloud Blog – Three lessons in accelerating foundation model upgrades
• لینک داخلی مرتبط اول
• لینک داخلی مرتبط دوم