گوگل: توکن‌محوری در مقیاس عامل‌های هوش مصنوعی شکست می‌خورد

تصور کنید یک کارمند تنها، مدیریت ۱۰۰ عامل خودکار را بر عهده دارد که ۲۴ ساعته کار می‌کنند؛ این سناریو مارپیچی از هزینه‌ها ایجاد می‌کند که بودجه‌بندی‌های نرم‌افزاری سنتی توان مقابله با آن را ندارند. اندی گاتمنز (Andi Gutmans)، مدیر بخش داده‌های عامل‌محور در گوگل، هشدار می‌دهد که صنعت در حال حاضر دچار وسواس «بیشینه‌سازی توکن» (Token Maxing) شده است؛ یعنی تلاش برای فشار آوردن به مرزهای پنجرهٔ زمینه (Context Window) — شبیه به میز کاری که هرچه بزرگ‌تر باشد، وسایل بیشتری روی آن جا می‌گیرد اما لزوماً سرعت کار را زیاد نمی‌کند — که به باور او هدفی اشتباه برای استقرار در مقیاس تولید است.

این تغییر دیدگاه در حالی رخ می‌دهد که سازمان‌ها از چت‌بات‌های ساده به سمت گردش‌کارهای عامل‌محور (Agentic) حرکت می‌کنند. در دوران پیشین، تمرکز بر این بود که آیا مدل به‌اندازه کافی «باهوش» هست تا یک پرامپت را دنبال کند، اما چالش فعلی سیستمی است. دیگر بحث تنها بر سر مدل نیست، بلکه تعامل میان مدل، چارچوب اجرایی (Harness)، زمینه و شخصی‌سازی است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، پیچیدگی سیستم‌های توزیع‌شده همیشه فراتر از توان تک‌تک اجزای آن است.

به نقل از پادکست Stack Overflow، گاتمنز استدلال می‌کند که برای اکثر وظایف اتوماسیون فعلی، مدل‌های موجود به‌اندازه کافی «خوب» هستند. مزیت رقابتی واقعی اکنون در یافتن کم‌پیچیده‌ترین مدلی است که بتواند با کمترین هزینه ممکن، نتیجه‌ای قابل‌اعتماد ایجاد کند. او Gemini 1.5 Flash را به‌عنوان نمونه‌ای از یک مدل سبک و ارزان‌قیمت معرفی می‌کند که برای موارد خاص عالی است، در حالی که برخی دیگر همچنان به قدرت Gemini Pro نیاز دارند.

سیستم‌سازی هوش مصنوعی

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

پیتر اوکانور (Peter O'Connor)، مدیر مهندسی پلتفرم در Stack Overflow، این وضعیت را با یک سیستم دریل مقایسه می‌کند. او می‌گوید داشتن یک مته بهتر بی‌فایده است اگر کل سیستم بیش از حد تخصصی یا دست‌وپاگیر باشد. او اشاره می‌کند که دریل‌ها اکنون می‌توانند مواد را مخلوط کنند، قطعات را به هم متصل کنند یا چوب را ببرند، اما اگر بیش از حد تخصصی شوند، خودشان به یک مشکل تبدیل می‌شوند. بنابراین تمرکز باید روی توانایی سیستم در انجام وظیفه باشد، نه فقط قدرت یک جزء مجزا.

مسئله بهره‌وری زمینه

گاتمنز «مشکل زمینه» را یکی از سه چالش سخت در هوش مصنوعی امروز می‌داند. او نسبت به فروشندگانی که ادعا می‌کنند این مشکل را با غنی‌سازی ساده داده‌ها یا هستی‌شناسی‌های (Ontologies) سازمان‌یافته حل کرده‌اند، تردید دارد و این‌ها را رویکردهایی تئوریک و نه عملی می‌نامد. او معتقد است شهود انسانی درباره اینکه چه چیزی «مفید» است، همیشه جواب نمی‌دهد و انسان‌ها نیز مانند مدل‌ها ممکن است دچار توهم (Hallucination) — شبیه به دوستی که خاطره‌ای را با اطمینان اما اشتباه تعریف می‌کند — شوند.

• رویکرد «بالارفتن از تپه»: گوگل از روشی به نام «بالارفتن از تپه» (Hill Climbing) استفاده می‌کند که در آن مدل و پلتفرم داده‌ها را به‌طور هم‌زمان و در همکاری با DeepMind بهینه می‌کند. این استراتژی تضمین می‌کند که عامل فقط حداقل زمینه لازم برای انجام وظیفه را دریافت کند. گوگل به‌عنوان یک ابرمقیاس‌دهنده (Hyperscaler) با توسعه مدل‌های داخلی و پلتفرم داده‌ای متمایز، در این جایگاه برتری دارد.
• عامل جست‌وجو: گاتمنز تأکید می‌کند که جست‌وجو برای تعیین اینکه کدام زمینه واقعاً اهمیت دارد، حیاتی است. او اشاره می‌کند که اکثر فروشندگان جست‌وجو را نادیده می‌گیرند، در حالی که این یک ستون اصلی در حل مشکل زمینه است. هر کسی که ادعای حل کامل این موضوع را دارد، دقیق نیست.
• ارزیابی‌های عامل-محور: بهینه‌سازی باید برای عامل‌ها طراحی شود، نه انسان‌ها. شهود انسانی درباره اطلاعات مفید، هنگام اعمال بر مسیرهای ماشینی اغلب شکست می‌خورد. این امر نیازمند روشی سیستماتیک برای شناسایی متغیرهای اثرگذار از طریق ارزیابی دقیق مسیرهای اجرا (Trajectories) است.
• انسان در چرخه: اوکانور اشاره می‌کند که در محصول B2B خود یعنی Stack Internal، آن‌ها پذیرفته‌اند که مشکل زمینه دشوار است؛ بنابراین استراتژی آن‌ها این است که عامل‌ها مسائل را حل کنند اما یک انسان به‌عنوان مرجع نهایی در چرخه حضور داشته باشد تا نتایج تجاری تضمین شود.

مکانیسم‌های محدودسازی زمینه

تعیین مقدار دقیق دانشی که یک عامل نیاز دارد، یک مانع فنی بزرگ است. گاتمنز نسبت به روش‌های قدیمی که در آن انسان‌ها هستی‌شناسی‌های دستی می‌سازند تا عامل‌ها را بهتر کنند، هشدار می‌دهد و آن را تئوری می‌خواند.

در مقابل، گوگل رویکرد «اول-هوش مصنوعی» را اتخاذ کرده که در آن «مشتری» همان عامل است. این کار شامل حجم عظیمی از ارزیابی‌ها برای درک مسیرهای اجراست. اگر خطایی رخ دهد، تیم باید تشخیص دهد که اصلاح باید در سطح مدل (با همکاری DeepMind) باشد یا در زمینه‌ای که به مدل ارائه شده است.

اقتصاد مقیاس در عصر عامل‌ها

وقتی از چند کاربر انسانی به میلیون‌ها عامل مهاجرت می‌کنیم، محاسبات اقتصادی تغییر می‌کند. انسان‌ها محدود به تعداد کلیک‌های روزانه خود هستند، اما عامل‌ها نه؛ آن‌ها ۲۴ ساعته کار می‌کنند و نیازی به خواب ندارند.

• مقیاس‌دهی غیرخطی: بدون حاکمیت سخت‌گیرانه، سیستم‌های عامل‌محور می‌توانند وارد مارپیچ هزینه‌ای شوند چون با سرعتی بسیار فراتر از ظرفیت انسانی عمل می‌کنند. تیم‌های پلتفرم باید تضمین کنند ابزارهایی که عامل‌ها فراخوانی می‌کنند، از جمله پلتفرم داده، به‌صورت غیرخطی مقیاس‌پذیر باشند.
• بازگشت سرمایه (ROI) به‌جای توکن: گاتمنز معتقد است ROI باید بر اساس نتایج متمایز اندازه‌گیری شود، نه حجم توکن‌های پردازش‌شده. او مثال‌های واقعی می‌زند:
  • پشتیبانی مشتری: اندازه‌گیری تعداد تیکت‌های مدیریت‌شده و کیفیت نتایج.
  • Deutsche Telekom: استفاده از عملیات شبکه خودکار برای نگهداری پیش‌دستانه و بهینه‌سازی شبکه.
  • SRE (مهندسی قابلیت اطمینان سایت): افزایش رضایت مشتری و بهره‌وری عملیاتی.
• چرخش در نمونه‌سازی: هزینه آزمایش‌ها به‌شدت کاهش یافته است. گاتمنز توصیف می‌کند که چگونه یک نمونه اولیه کاربردی را در یک آخر هفته ساخت تا «هنر ممکن‌ها» را به تیمش نشان دهد؛ فرآیندی که پیش‌تر به یک مهندس اختصاصی و سه تا چهار ماه توسعه نیاز داشت. این سرعت در نمونه‌سازی اجازه می‌دهد ریسک‌های طراحی زودتر شناسایی شوند و از صرف شش ماه زمان روی مسیر اشتباه جلوگیری شود.

مهندسی پلتفرم برای «شخصیت عامل»

اوکانور و گاتمنز پیشنهاد می‌کنند که تیم‌های پلتفرم باید اکنون با «عامل» به‌عنوان یک شخصیت درجه‌یک برخورد کنند، درست همان‌طور که با توسعه‌دهندگان، دانشمندان داده یا کاربران تجاری برخورد می‌کنند. این دیدگاه با تحلیل‌های پیشین گاتمنز همسو است که در آن تأکید می‌کرد هر توسعه‌دهنده در عصر جدید در واقع مدیر تیمی از عامل‌هاست.

• نیازهای زیرساختی: عامل‌ها به مدل‌های نظارتی (Observability)، امنیتی و حاکمیتی تخصصی نیاز دارند. تیم‌های پلتفرم باید دسته‌بندی‌های امنیتی، مدیریت هزینه و در دسترس بودن را به‌طور خاص برای شخصیت عامل بسازند. این شامل ایجاد مهارت‌های لازم برای اپراتورهای انسانی است که به‌عنوان ارکستراتور عمل می‌کنند.
• قیاس با Spanner: گاتمنز اشاره می‌کند که یوتیوب در ابتدا روی MySQL اجرا می‌شد که در مقیاس بالا شکست خورد. گوگل سپس Spanner را ساخت تا مالکیت مقیاس‌پذیری را از توسعه‌دهنده به سیستم داده منتقل کند. به همین ترتیب، زیرساخت‌های جدید هوش مصنوعی باید لایه‌های «اعتماد» و «مقیاس» را خودکار کنند تا اگر عاملی نیاز به مقیاس‌دهی داشت، به‌سادگی این اتفاق بیفتد.
• محو شدن مرز شخصیت‌ها: خط بین کاربران تجاری و مهندسان در حال کمرنگ شدن است. همان‌طور که PHP به غیرتوسعه‌دهندگان اجازه داد اپلیکیشن وب بسازند، تجربه‌های عامل‌محور به کاربران تجاری اجازه می‌دهد نتایج علوم داده و مهندسی را هدایت کنند. تا زمانی که کاربر قصد و نتیجه مطلوب را بفهمد، جزئیات فنی آموزش و استقرار مدل ثانویه می‌شوند.
• نقش مهندسی داده: اوکانور می‌پرسد که آیا دانشمندان داده و مهندسان باید بخشی از تیم پلتفرم توسعه‌دهنده باشند. گاتمنز توصیه می‌کند که آن‌ها برای تضمین کیفیت و حاکمیت داده‌های آماده برای فعال‌سازی در تحلیل‌ها و AI حیاتی هستند. اگرچه عامل‌ها کاربران را توانمند می‌کنند، اما قضاوت انسانی برای اطمینان از اینکه عامل در مسیر اشتباه نمی‌رود، همچنان لازم است؛ به‌ویژه در مواردی مثل تشخیص کلاهبرداری و پیش‌بینی. او به‌طور خاص استخدام در این نقش‌ها را برای فراهم کردن قضاوت لازم توصیه می‌کند.

آینده آموزش علوم کامپیوتر

برای کسانی که امروز وارد این رشته می‌شوند، گاتمنز رویکردی سه‌گانه پیشنهاد می‌کند تا برای دنیایی آماده شوند که در آن پاندول دوباره به سمت سخت‌افزار و معماری سیستم‌ها می‌چرخد.

اول، مبانی سنتی علوم کامپیوتر — ریاضیات، معماری سیستم و درک نحوه ساخت سیستم‌ها — همچنان ضروری هستند. اوکانور می‌افزاید که این اصول (مانند پیمایش گراف و گره‌ها) به مهندسان اجازه می‌دهد فناوری‌های جدید را فارغ از زبان برنامه‌نویسی (مثل جاوا یا Ada) درک کنند. درک نحوه ساخت سیستم‌ها با فناوری، مهم‌تر از صرفاً کدنویسی است.

دوم، «تسلط عامل‌محور» (Agentic Fluency) اکنون یک ابرقدرت اجباری است. مهندسان باید بدانند چگونه با ارکستره کردن عامل‌ها، تأثیری ۱۰ برابری ایجاد کنند، به‌جای اینکه فقط کد خام بنویسند. این یعنی تسلط بر کدنویسی عامل‌محور برای رسیدن به نتایج خاص.

در نهایت، قضاوت تجاری به اندازه مهارت فنی حیاتی شده است. چون یک فرد اکنون می‌تواند ارتشی از عامل‌ها را هدایت کند، توانایی شناسایی و حل یک مسئله تجاری با ارزش بالا، اهرم اصلی رشد شغلی است. گاتمنز پیشنهاد می‌کند طرز فکر یک MBA — تمرکز بر مسئله تجاری — اکنون برای دانشجویان علوم کامپیوتر ضروری است. او استدلال می‌کند که توانایی تأثیرگذاری بر کسب‌وکار امروز برای یک فرد بسیار بیشتر از گذشته است.

این تکامل نشان می‌دهد که «MBA برای مهندسان» دیگر یک مدرک ثانویه نیست، بلکه یک نیاز اصلی در عصر عامل‌هاست تا ایده‌های درست، فارغ از اینکه ارکستراتور یک مهندس باسابقه است یا یک مدیر تجاری با تسلط عامل‌محور بالا، به نتایج عملی تبدیل شوند.

گام بعدی شما

• به‌جای تمرکز بر مدل‌های غول‌پیکر، برای هر وظیفه کوچک‌ترین مدل ممکن (مانند Gemini Flash) را تست کنید تا هزینه استنتاج را بهینه کنید.
• در طراحی سیستم‌های عامل‌محور، به‌جای تکیه بر پنجره متنی بزرگ، روی مکانیزم‌های بازیابی داده (Retrieval) و جست‌وجوی دقیق تمرکز کنید.
• اگر مهندس هستید، یادگیری مفاهیم مدیریت کسب‌وکار و شناسایی نقاط درد (Pain Points) تجاری را در اولویت قرار دهید تا بتوانید از ارتش عامل‌ها برای حل مسائل واقعی استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.