گیتهاب برای انتخاب خودکار مدل در Copilot سه سطح تازه معرفی کرده است: Efficiency، Balance و Intelligence. این تنظیم مشخص میکند مسیریاب Copilot هنگام انتخاب مدل برای هر درخواست، هزینه، زمان پاسخ و کیفیت مورد انتظار را با چه اولویتی بسنجد؛ مجموعه مدلهای مجاز در هر سه حالت همان مجموعهای است که کاربر و سیاست سازمان اجازه میدهند.
در ظاهر با یک گزینه تنظیمات ساده روبهرو هستیم، اما تغییر مهمتری پشت آن دیده میشود: در ابزارهای کدنویسی چندمدلی، انتخاب مدل دیگر لزوماً تصمیمی نیست که برنامهنویس یکبار در ابتدای کار بگیرد. این انتخاب به یک سیاست اجرایی در زمان پردازش هر درخواست تبدیل میشود.
یک محدودیت مهم هم وجود دارد. انتخاب Efficiency سقف هزینه ایجاد نمیکند و Intelligence نیز تضمین نمیکند همه درخواستها به گرانترین یا قویترین مدل بروند. هزینه همچنان براساس مدلی محاسبه میشود که Auto واقعاً انتخاب کرده است.
مسیریاب حالا هدف قابلانتخاب دارد
Copilot Auto پیش از این هم مدل را پویا انتخاب میکرد. طبق مستندات GitHub، حالت بهینهسازی بر اساس نوع کار پیچیدگی کار را همراه سلامت و دسترسپذیری مدلها بررسی میکند و تلاش دارد مدلهای استدلالی پرهزینه را برای کارهایی نگه دارد که واقعاً به آنها نیاز دارند.
سه سطح تازه یک هدف قابلانتخاب به همین فرایند اضافه میکنند.
Efficiency هزینه کمتر را در اولویت میگذارد و برای کارهای سریع و ساده در نظر گرفته شده است. Balance میان هزینه، کیفیت و تأخیر تعادل برقرار میکند. Intelligence کیفیت را برای مسئلههای پیچیدهتر بالاتر میبرد. با این حال، هر سه حالت از همان مجموعه مدل استفاده میکنند و هر درخواست جداگانه ارزیابی میشود.
این نکته آخر مهم است. GitHub میگوید حتی در حالت Intelligence ممکن است یک کار ساده، مانند افزودن توضیح مستندات تابع به تابع موجود، به مدل کوچکتری سپرده شود. بنابراین سطح جدید یک ترجیح در تابع تصمیمگیری مسیریاب است، نه نگاشتی ثابت از هر سطح به یک مدل خاص.
ترجیح کمهزینه با سقف بودجه فرق دارد
نام Efficiency میتواند برای تیمهای سازمانی سوءبرداشت ایجاد کند.
ممکن است یک تیم آن را حالت «کنترل هزینه» بداند، اما GitHub صریحاً میگوید هزینه مصرف براساس مدلی محاسبه میشود که Auto انتخاب میکند، مستقل از نام سطح. کاربران پولی همچنان برای مصرف از طریق Auto ده درصد تخفیف دارند، ولی مبلغ نهایی به مدل انتخابشده و میزان مصرف بستگی دارد.
تحلیل Aipolix این است که Efficiency را باید یک ترجیح بهینهسازی دانست، نه یک کنترل مالی قطعی.
اگر سازمان به سقف واقعی هزینه نیاز دارد، همچنان باید از محدودیت بودجه، پایش مصرف یا سیاست محدودکننده مدلها استفاده کند. مسیریابی که «ترجیح میدهد» مدل ارزانتری انتخاب کند میتواند هزینه متوسط را کاهش دهد، اما جایگزین محدودیتی نیست که بیرون از الگوریتم اجرا میشود.
همین تفاوت در جهت مقابل هم وجود دارد. Intelligence اولویت کیفیت را بالا میبرد، اما تضمین نمیکند هر درخواست با یک مدل ردهبالا اجرا شود یا به امتیاز مشخصی در معیار ارزیابی برسد.
سیاست سازمان همچنان مرز مدلهای مجاز را تعیین میکند
مستندات GitHub میگویند Auto فقط از میان مدلهایی انتخاب میکند که طرح اشتراک و سیاستهای سازمان اجازه میدهند. مدلی که مدیر سازمان مسدود کرده، با الزامهای محل نگهداری داده سازگار نیست یا تحت محدودیت FedRAMP قرار گرفته، وارد مجموعه انتخاب نمیشود.
این جداسازی معماری مهمی است.
سازمان ابتدا تعیین میکند چه مدلهایی اصولاً مجازند. سپس مسیریاب درون همین مجموعه مجاز بهینهسازی میکند. در نتیجه، کاربر میتواند Intelligence را انتخاب کند بدون آنکه این تنظیم بهطور پنهانی ممنوعیت سازمان درباره یک ارائهدهنده یا مدل را دور بزند.
هرچه مسیریابها مستقلتر شوند، اهمیت این مرز بیشتر میشود. بهینهسازی هزینه و کیفیت باید داخل محدوده مجوز انجام شود، نه اینکه خودش محدوده مجوز را تعیین کند.
چرا این تغییر برای عاملهای کدنویسی مهم است
عاملهای کدنویسی بهتدریج از یک پرسش و پاسخ کوتاه فاصله گرفتهاند و جلسههای طولانی چندمرحلهای انجام میدهند: بررسی مخزن کد، تولید کد، اجرای تست، رفع خطا و بازبینی. همه این مراحل به یک سطح از مدل نیاز ندارند.
یک لایه مسیریابی میتواند کارهای ساده را به مدل کوچکتر بدهد و توان استدلال گرانتر را برای مرحلههای دشوار نگه دارد. GitHub همچنین میگوید مسیریاب بهینهسازی مبتنی بر نوع کار تلاش میکند تغییر مدل را در مرزهای طبیعی حافظه نهان انجام دهد، چون تعویض بیموقع مدل در میانه جلسه میتواند هزینه حافظه نهان را بالا ببرد بدون اینکه بهبود کافی در کیفیت ایجاد کند.
سه سطح تازه هدف این هماهنگسازی را برای کاربر قابلمشاهدهتر میکنند.
در مقابل، نیاز تازهای برای قابلیت مشاهدهپذیری به وجود میآید. اگر تیمی بخواهد Efficiency، Balance و Intelligence را مقایسه کند، صرفاً دیدن هزینه کل کافی نیست. باید بداند کدام مدلها انتخاب شدهاند، تأخیر چقدر بوده، چند کار واقعاً کامل شده، چند بار تلاش مجدد رخ داده و چه مقدار بازبینی انسانی لازم بوده است. GitHub در سطوح پشتیبانیشده نام مدل استفادهشده برای هر پاسخ را نشان میدهد و این حداقل بخشی از داده لازم را فراهم میکند.
هنوز چه چیزهایی معلوم نیست
این قابلیت در Visual Studio Code، Copilot CLI و برنامه GitHub Copilot در حال عرضه تدریجی است و GitHub آن را قدم اول برای قابلتنظیمتر شدن انتخاب مدل میداند.
با این حال، شرکت معیار ارزیابی عمومی منتشر نکرده که نشان دهد هر سطح دقیقاً چه میزان هزینه، تأخیر یا کیفیت کدنویسی را تغییر میدهد. قاعده قطعی انتخاب مدل برای یک درخواست مشخص هم منتشر نشده است. بنابراین نمیتوان از نام گزینهها درصد مشخصی برای صرفهجویی یا بهبود کیفیت نتیجه گرفت.
اهمیت فنی تغییر در جای دیگری است: یک محصول کدنویسی چندمدلی، هدف مسیریابی را به کنترل سطح اول تبدیل کرده، در حالی که صورتحساب و سیاست مجاز بودن مدلها مستقل باقی ماندهاند.
این مسیر مفیدی است، اما یک تفاوت مهم را هم آشکارتر میکند: «ترجیح مدل ارزانتر» همان «بیشتر از این هزینه نکن» نیست؛ همانطور که «اولویت کیفیت» با «همیشه قویترین مدل را اجرا کن» فرق دارد.