ساخت مدل جدید پیشنهادات درون‌خطی گیت‌هاب کوپایلوت: بخش دوم

جولیا گونگ (Julia Gong)

ببینید گیت‌هاب کوپایلوت چگونه قابلیت تکمیل کد را به مدل پیشنهادات درون‌خطی یکپارچه خود اضافه کرد، متن‌های کم‌رنگ (Ghost Text) و رفتار ویرایشگر را بهبود بخشید و رضایت کاربران را افزایش داد.

ساخت مدل جدید پیشنهادات درون‌خطی گیت‌هاب کوپایلوت: بخش دوم

۲۳ سپتامبر ۲۰۲۶، نوشته شده توسط جولیا گونگ، شنگجی ما، بن لیگت و اولوبک عبداله‌یف

متن‌های کم‌رنگِ سبک تکمیل خودکار، پیشنهادات ویرایش بعدی در نزدیکی مکان‌نما (Cursor) و ویرایش‌های دورتر، پیش‌تر توسط مدل‌های جداگانه‌ای پشتیبانی می‌شدند. ما یک مدل واحد برای هر سه مورد ساختیم و آموختیم که بهترین نتایج زمانی حاصل می‌شوند که آموزش، ارزیابی و طراحی ویرایشگر در هماهنگی با یکدیگر تکامل پیدا کنند.

فاز ۲: مدل ۳ در ۱

در بخش اول این مقاله، فاز نخست تلاش برای یکپارچه‌سازی مدل را به اشتراک گذاشتیم: ادغام NES و رفتار ویرایش از راه دور در یک مدل واحد ۲ در ۱.

شکل ۱. ما ابتدا مدل‌های NES و NES دوربرد را برای دستیابی به مدل یکپارچه ۲ در ۱ با یکدیگر ادغام کردیم و سپس با ترکیب مدل ۲ در ۱ با مدل تکمیل کد، به مدل ۳ در ۱ رسیدیم.

گام بعدی، آوردن قابلیت تکمیل کد (Completions) به درون مدل ۲ در ۱ بود. پیش‌تر، یک موقعیت ویرایش ممکن بود شامل یک درخواست تکمیل کد و به دنبال آن درخواستی دیگر برای ویرایش غنی‌تر توسط مدل ۲ در ۱ باشد. با مدل کاملاً یکپارچه ۳ در ۱، یک درخواست می‌تواند طیف کامل رفتارهای ویرایش کد را در نظر بگیرد و در هر لحظه، بهترین پاسخ را تعیین کند یا چندین مورد از آن‌ها را در یک پاسخ واحد به هم زنجیر کند.

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

به عنوان نمونه، در نامزد نهایی مدل ۳ در ۱ خود، متوجه شدیم که اگرچه نسبت متن‌های کم‌رنگِ کمتر مزاحم در مدل ۳ در ۱ در مقایسه با ساختار مدل ۲ در ۱ کاهش یافته بود، اما در عمل بهبودهای قابل‌توجه و قابل‌سنجشی در رضایت کاربران ایجاد شد. در ادامه این مقاله بیشتر درباره این موضوع صحبت خواهیم کرد.

آموزش مدل‌های نسخه ۴: افزودن قابلیت تکمیل کد

برای آموزش مدل ۳ در ۱، از آموخته‌های خود در جریان توسعه مدل ۲ در ۱ استفاده کردیم. از آنجا که هدف، افزودن رفتار تکمیل کد به مدل ۲ در ۱ بود، توزیع داده‌های آموزشی باید تغییر می‌کرد. ما داده‌های تکمیل متن کم‌رنگ را از طریق تکنیک‌های مختلفی جمع‌آوری کردیم؛ از جمله استخراج (Distillation) متن کم‌رنگ از مدل تکمیل کد اصلی و فیلتر کردن آن‌ها برای بررسی کیفیت با استفاده از یک مدل زبانی بزرگ به عنوان داور (LLM Judge). ما ضمن افزودن این داده‌های جدیدِ متن کم‌رنگ، از دستورالعمل‌های آموزشی اصلی مدل ۲ در ۱ نیز بهره بردیم.

همچنین مجبور شدیم توزیع داده‌های چندویرایشی به ارث رسیده از دستورالعمل مدل ۲ در ۱ را به دقت بازتنظیم کنیم. مدل‌هایی که متن کم‌رنگ بسیار کمی نشان می‌دادند یا بیش از حد مشتاق بودند که از مکان‌نمای کاربر فاصله بگیرند، اغلب موجب اختلالات بیشتری در جریان کار کاربر و در نتیجه نرخ رد (Dismissal) بالاتری می‌شدند. این امر به طور طبیعی باعث ایجاد زیرمجموعه اختصاصی از داده‌های چندویرایشی شد که در آن اولین اصلاح (Patch)، یک تکمیلِ متن کم‌رنگ در محل مکان‌نمای کاربر بود. همان‌طور که پیش‌تر در بخش اول ذکر شد، در طول یادگیری تقویتی (RL)، طراحی ارزیاب را نیز حفظ کردیم که مدل را تشویق می‌کرد دنباله ویرایش‌های خود را با فوری‌ترین ادامه کار توسعه‌دهنده آغاز کند و سپس به سمت تغییرات پیگیرانه و مرتبط بعدی حرکت کند؛ این کار باعث می‌شد ویرایش‌ها کمترین مزاحمت را داشته باشند و جریان منطقی و پیوستگی حفظ شود.

نامزدهای اولیه مدل، در نتیجه‌ی این تغییرات، متن‌های کم‌رنگ بیشتر و به طور کلی پیشنهادات بیشتری تولید کردند. ما این نتایج را به صورت آفلاین با سه معیار (Benchmark) که در بخش اول بحث شد، اندازه‌گیری کردیم: تست‌های S، نوع نمای خروجی (Output View Kind) و ارزیابی شبه آنلاین. همچنین متوجه شدیم که نتایج معیار HumanEval به دلیل برخورداری از قابلیت‌های تکمیل کد قوی‌تر، بهبود یافته است.

هنگامی که این مدل‌های نسخه ۴ را در برابر تنظیمات فعلیِ در حال تولید (Production) مدل ۲ در ۱ و مدل تکمیل کد آزمایش پروازی (Flight) دادیم، نتایج بسیار امیدوارکننده بود: هیچ تغییر از نظر آماری معناداری در نرخ پذیرش، نرخ رد، نرخ نمایش و معیارهای تعامل کاربر مشاهده نشد. اما متوجه یک پس‌رفت (Regression) جزئی از نظر آماری معنادار در کاراکترهای پذیرفته‌شده و حفظ‌شده شدیم؛ یعنی تعداد کاراکترهایی که کاربر پس از پذیرش یک پیشنهاد، ظرف مدت‌زمان مشخصی آن‌ها را به حالت قبل بازنگردانده بود.

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

آموزش مدل‌های نسخه ۵: کامل بودن متن کم‌رنگ (Ghost Text)

فرضیه ما این بود که از آنجا که مدل در مقایسه با مدل تکمیل کد در حال تولید، پیشنهادات متن کم‌رنگ کمی کوتاه‌تری تولید می‌کرد، ممکن است کاربران پیشنهادات امیدوارکننده اما ناقص را می‌پذیرفتند. در نتیجه، ممکن است آن‌ها بیشتر اقدام به بازگردانی (Revert) یا ویرایش پیشنهادات می‌کردند. به عنوان مثال، نوشتن امضای تابع (Function Signature) و مستندات (Docstring) خوب است، اما اگر پیاده‌سازی کامل آن را دنبال نکنیم، کاربر ممکن است تابع را حذف کند، ویرایش‌هایی روی آن انجام دهد یا آن را به صورت دستی بازنویسی کند.

برای آزمایش این فرضیه، از آنچه آموخته بودیم در چالش‌های درجِ مدل ۲ در ۱ استفاده کردیم، زیرمجموعه‌ای از داده‌ها را که به‌طور خاص این نوع سناریوی خروجی طولانی‌تر را هدف قرار می‌دادند جمع‌آوری کردیم و وزن‌دهی افزایشی مشابهی روی آن‌ها انجام دادیم. علاوه بر این، یک ارزیاب کمکی دیگر مختص به کامل بودن متن کم‌رنگ اضافه کردیم و آن را روی همین نمونه‌های خاصِ گزینش‌شده محدود (Gated) کردیم. برای اندازه‌گیری تأثیر آفلاین این تغییر، نسخه دومی از مجموعه داده نوع نمای خروجی را نیز معرفی کردیم که طول کاراکترها و نسبت متن کم‌رنگ را در پاسخ‌های مدل در مقایسه با توزیع اصلی مدل تولیدی اندازه‌گیری می‌کرد.

ما امیدوارکننده‌ترین نامزد مدل خود را آزمایش پروازی دادیم و خوشحال شدیم که دیدیم پس‌رفتِ کاراکترهای پذیرفته‌شده و حفظ‌شده کاهش یافته اما کاملاً از بین نرفته است و نرخ‌های رد روند صعودی داشتند. با این حال، مشاهداتی در طول تجربه استفاده داخلی (Dogfooding) انجام شد که باعث شد فراتر از خودِ مدل را نگاه کنیم. این موضوع درس مهمی را که از تکرار روی مدل‌های قبلی‌مان آموخته بودیم تقویت کرد: رفتار سمت کلاینت به اندازه خود مدل اهمیت دارد.

مدل بخشی از یک تجربه سرتاسری بزرگ‌تر است

تجربه نهایی کاربر بسیار فراتر از قابلیت‌های مدل است: یک تجربه عالی از پیشنهادات درون‌خطی، حاصل ترکیب یک مدل عالی با یک سیستم سرتاسری (End-to-End) عالی است. ارکستراسیون دقیق کلاینت نیز برای نمایش ویرایش‌ها به کاربر در بهترین زمان و به بهترین شکل ضروری است.

برای مثال، هنگام استفاده داخلی از امیدوارکننده‌ترین نامزد پروازی ۳ در ۱، متوجه تصمیم مهمی در رفتار قبلی کلاینت برای NES شدیم که ارزش بازنگری داشت. هنگامی که متن کم‌رنگ به کاربر نشان داده می‌شد اما نادیده گرفته می‌شد، اگر کاربر مکان‌نمای خود را به مکان دیگری منتقل می‌کرد، آن پیشنهاد کش‌شده‌ی متن کم‌رنگ مجدداً به عنوان یک ویرایش NES نشان داده می‌شد. پس از بررسی عمیق‌تر، تخمین زدیم که این رفتار کلاینت به تنهایی می‌تواند به طور بالقوه مسئول افزایش ۷ تا ۸ درصدی نرخ ردِ مدل ۳ در ۱ باشد. هنگامی که این مسئله را در یک پرواز آزمایشی A/B حذف (Ablate) کردیم، متوجه شدیم که تأثیر آن حتی بیشتر از حد تخمین ما بوده است؛ به طوری که نرخ رد از افزایش ۱۵.۹ درصدی به کاهش ۱۰.۱ درصدی تغییر یافت — یعنی یک تفاوت ۲۶ درصدی — در مقایسه با ساختار تولیدی ۲ در ۱.

دلیل این رفتار نیازمند مقداری زمینه تاریخی است. در ابتدا، پیشنهادات مدل مستقل NES می‌توانستند هم‌زمان با حرکت مکان‌نمای کاربر به صورت ناهم‌گام (Asynchronously) برسند، در حالی که متن کم‌رنگ مدل مستقل تکمیل کد با دور شدن مکان‌نما ناپدید می‌شد. در نتیجه، متن کم‌رنگ مدل مستقل NES به صورت عمدی پایدار (Persistent) ساخته شده بود تا بتواند با حرکت مکان‌نمای کاربر نمایش داده شود. با این حال، از آنجا که مدل ۳ در ۱ خود را به عنوان یک مدل NES به کلاینت معرفی می‌کرد، با وجود توانایی در ارائه متن کم‌رنگِ سبکِ تکمیل کد در محل مکان‌نما، این رفتار را به ارث برده بود. با حذف این رفتار پایداری متن کم‌رنگ NES از طریق یک تنظیمات کلاینت به نام nesMimicGhostTextBehavior، توانستیم در این رفتار بازنگری کرده و آن را تغییر دهیم تا انتخابی داشته باشیم که بهترین تناسب را با رفتار جدید مدل داشته باشد. این امر بر اهمیت آزمایش ویژگی به صورت سرتاسری در کلاینت تأکید می‌کند؛ مدل‌های جدید رفتارهای جدیدی دارند که ممکن است نیازمند تنظیمات متفاوتی در کلاینت باشند.

فراتر از این مطالعه حذف، ما همچنین آزمایش‌های گسترده‌ای انجام دادیم تا بهترین انتخاب‌های سمت کلاینت را برای ویرایش‌های مدل ۳ در ۱ انجام دهیم؛ از جمله بهینه‌سازی‌ها در کش کردن ویرایش، رمزگشایی گمانه‌زنی (Speculative Decoding)، نحوه رندر کردن ویرایش برای کاربر، و نمایش تدریجی ویرایش‌های طولانی‌تر. از طریق چندین دور استفاده داخلی و آزمایش A/B، متوجه شدیم که هر یک از این انتخاب‌های کلاینت تأثیر زیادی بر تجربه کاربر گذاشته است.

ما پنج بهینه‌سازی سمت کلاینت را به عنوان یک پیکربندی مشترک ارزیابی کردیم که منجر به بهترین تجربه مدل یکپارچه سرتاسری شد:

• رمزگشایی گمانه‌زنی (Speculative decoding): مدل مستقل NES قبلی نیز برای کاهش تأخیر پیشنهاد از رمزگشایی گمانه‌زنی استفاده می‌کرد، اما فرمت خروجی مدل یکپارچه جدید نیازمند بازنگری در این بود که چه خروجی‌ای باید گمانه‌زنی شود. ما چندین نسخه جایگزین از متن گمانه‌زنی‌شده را با هدایت‌های به تدریج قوی‌تر به سمت رفتار تکمیل کد حذف و آزمایش کردیم: فقط هدر مسیر فایل (بدون مشخص کردن هیچ خطی، پیش‌فرض استفاده شده برای مدل‌های ۲ در ۱)، جایگزینی خط فعلی (مشخص کردن خط فعلی اما نه یک نوع نمای خاص)، و تکمیل خط فعلی (مشخص کردن هم خط فعلی و هم نوع نمای متن کم‌رنگ). پس از تست بارگذاری، تحلیل تأخیر، تحلیل توزیع نوع نما و پروازهای آنلاین مقایسه این گزینه‌ها، ما گمانه‌زنی تکمیل را در خط فعلی انتخاب کردیم که پایین‌ترین تأخیر پیشنهاد را بدون تأثیر منفی بر تجربه کاربر به همراه داشت.
• نمایش تدریجی متن کم‌رنگ (Ghost-text progressive reveal): نمایش تدریجی ابتدا بخش فوری مرتبط از یک پیشنهاد متن کم‌رنگ طولانی‌تر را نشان می‌دهد و سپس بقیه آن را به صورت تدریجی نمایان می‌کند. این کار مانع از آن می‌شود که کاربر در حالی که پیشرفت تدریجی در کار خود دارد، مجبور باشد یک بلوک طولانی از متن را بررسی کند. نمایش تدریجی متن کم‌رنگ یک ویژگی حیاتی کلاینت بود که چندین دور بهینه‌سازی را برای مدل‌های مستقل اصلی تکمیل کد پشت سر گذاشت و بعدها کارایی آن به مدل‌های مستقل NES نیز تسری یافت؛ بنابراین ما این تکنیک را به رفتار کلاینت مدل یکپارچه منتقل کردیم.
• رندر کردن ویرایش مبتنی بر تفاوت (Diff-based edit rendering): برای مدل‌های مستقل NES، کلاینت کد موجود در پنجره بازنویسی‌شده را تجزیه (Parse) می‌کرد تا تفاوت کد (Diff) و در نتیجه انواع نمای متناظر را برای نمایش ویرایش‌ها به کاربر تعیین کند. این کار لازم بود زیرا کد خام بازنویسی‌شده باید تجزیه می‌شد تا حداقل ویرایش به کاربر نمایش داده شود. با این حال، برای مدل‌های یکپارچه با فرمت‌های خروجی پچ تفاوت، ما یک انتخاب داشتیم — آیا باید انواع نمای دلالت‌شده توسط خودِ پچ‌های خام را نمایش دهیم، یا این رندرینگ مبتنی بر تفاوت را برای هر پچ به صورت مجزا نیز اجرا کنیم؟ پیش‌تر متوجه شدیم که مدل ممکن است در ازای کیفیت کلی بهتر پیشنهاد، پچ‌هایی با بهره‌وری زیربینه تولید کند (بحث اعتبار پچ را در بخش اول این مقاله ببینید). برای مثال، مدل ممکن است پچ زیر را تولید کند: aquarium.py:2 -cuttlefish +axolotl +blobfish +cuttlefish +dolphin اگر از پچ خام استفاده می‌کردیم، یک نمای «تفاوت» دوطرفه به کاربر نشان می‌دادیم که در آن cuttlefish با axolotol، blobfish، cuttlefish و dolphin جایگزین می‌شود. با این حال، اگر تجزیه می‌شد، این می‌توانست بهینه‌سازی شود به طوری که کاربر ابتدا این متن کم‌رنگِ درج را ببیند: aquarium.py:2 -cuttlefish +axolotl +blobfish +cuttlefish و به دنبال آن این درج در خطی دیگر: aquarium.py:4 -cuttlefish +cuttlefish +dolphin بنابراین، فرضیه ما این بود که رندرینگ می‌تواند به عنوان یک محافظ دیگر عمل کند، در صورتی که راه قوی‌تری برای ارائه ویرایش به کاربر نسبت به آنچه خروجی مدل دلالت داشت وجود داشته باشد. از طریق آزمایش A/B آنلاین، متوجه شدیم که این در واقع یک تغییر مثبت برای تجربه کاربر است. بنابراین، ما ابتدا هر تغییر را در پچ تفسیر می‌کنیم و سپس آن را از طریق تعامل رندرشده مناسب ارائه می‌دهیم (برای مثال، متن کم‌رنگ، بازنویسی نزدیک، بازنویسی دورتر، پیشنهاد میان‌فایلی، یا بدون پیشنهاد)، به‌جای اینکه ویرایش‌ها را بر اساس ساختار پچ خام مدل رندر کنیم.
• تنظیمات تأخیر کش و رفع پرش (Cache delay and debounce settings): ارائه فوری پیشنهادات زمانی که خیلی سریع می‌رسند می‌تواند مختل‌کننده باشد و منجر به تجربه کاربری بدتری شود. ایجاد یک تأخیر جزئی قبل از ارائه یک پیشنهاد کش‌شده، بهتر با ریتم تایپ کردن توسعه‌دهنده هماهنگ می‌شود تا به او کمک کند در جریان کار باقی بماند، به خصوص با کاهش تأخیر پیشنهاد ناشی از بهینه‌سازی رمزگشایی گمانه‌زنی. این تنظیمات از قبل در حال استفاده بود و ما چندین پیکربندی از مدت‌زمان‌های تأخیر کش را آزمایش کردیم تا به پیکربندی متناسب با مدل‌های یکپارچه برسیم. ما همین کار را برای تنظیمات رفع پرش (Debounce) نیز انجام دادیم — یعنی آیا در حالی که کاربر هنوز در حال تایپ کردن است، فراخوانی مدل برای پیشنهاد به تأخیر بیفتد یا خیر — و متوجه شدیم که فراخوانی فوری مدل در حالی که کاربر هنوز در حال تایپ کردن است، منجر به تجربه بدتری نمی‌شود.
• سرکوب پیشنهاد نادیده‌گرفته‌شده میان‌حالی (Cross-mode ignored suggestion suppression): همان‌طور که در بالا بحث شد، این ویژگی مانع از آن می‌شود که متن کم‌رنگ نادیده‌گرفته‌شده پس از جابجایی مکان‌نما، بلافاصله به عنوان پیشنهاد ویرایش بعدی دوباره ظاهر شود. برای سیستم، این‌ها ممکن است نماهای متفاوتی باشند، اما برای توسعه‌دهنده، آن‌ها همان پیشنهاد ناخواسته هستند.

این کار نکته‌ای را برجسته کرد که در سراسر سیستم‌های هوش مصنوعی تعاملی صدق می‌کند: در نهایت، یک مدل خوب تنها یک جزء از یک سیستم پیچیده است — مانند تجربه کاربری (UX)، منطق کلاینت، شبکه‌سازی و منطق سمت سرور، و غیره — و تمام بخش‌های آن سیستم باید با دقت طراحی شوند و به طور عمدی بهینه‌سازی شوند تا تجربه‌ای عالی برای کاربر ایجاد شود. تجربه سرتاسری همان محصول است.

دست‌آوردها و آموخته‌ها

ادغام قابلیت‌های تکمیل کد در مدل یکپارچه سرعت توسعه بسیار بالاتری داشت زیرا مستقیماً بر روی پایه و اساس ۲ در ۱ ساخته شده بود، که نشان می‌دهد چگونه انباشت آموخته‌ها هر فاز استراتژیک را تسریع می‌کند. چند درس قابل ذکر:

• روی موفقیت‌ها بنا کنید. پس‌رفت طول متن کم‌رنگ با همان روش کار فاز ۱ حل شد: داده‌های هدفمند با خروجی طولانی‌تر، وزن‌دهی افزایشی و یک ارزیاب کمکی اختصاصی محدودشده به کامل بودن. شناسایی الگوهای موفق و استفاده مجدد از آن‌ها در صورت لزوم بسیار حیاتی بود.
• مدل تنها بخشی از یک تجربه سرتاسری است. هنگام تغییر رفتار اساسی مدل و فرموله‌سازی وظیفه، برخی بخش‌های سیستم سرتاسری نیز باید تغییر می‌کردند. برخی از رفتارهای کلاینت انتخاب‌های عمدی بهینه‌شده برای مدل مستقل NES قبلی بودند و با پذیرش رفتار تکمیل کد توسط مدل یکپارچه، نیاز به بازنگری داشتند. از طریق آزمایش دقیق، یکی از این تغییرات — یعنی جلوگیری از ظاهر شدن مجدد متن کم‌رنگ نادیده‌گرفته‌شده به عنوان پیشنهادات NES — کمک کرد تا نرخ رد ۲۶ درصد تغییر کند و از ۱۵.۹+ درصد به ۱۰.۱- درصد برسد.
• زیبایی یکپارچه‌سازی. مدل یکپارچه ۳ در ۱ در طول آزمایش آنلاین، با وجود نمایش ۱۳ درصد متن کم‌رنگ کمترِ غیرمزاحم، شاهد کاهش ۱۰.۱ درصدی در نرخ رد بود و هیچ پس‌رفتی در معیارهای کلیدی نداشت. تصمیم‌گیری یک مدل برای بهترین ویرایش سرتاسری، ارکستراسیون متخصصان مستقل را شکست داد و نشان داد که تجربه یکپارچه بیشتر از مجموع بخش‌های آن است.

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

از منظر علمی، مدل ۲ در ۱ تیم ما را ملزم به بیش از ۱۵ اجرای آموزش SFT، ۱۷۰ اجرای آموزش RL و چندین برابر آن اجرای انتخاب چک‌پوینت (checkpoint-selection) کرد که در نهایت منجر به ۱۴ نامزد ارزیابی A/B پیش از نامزد نهایی انتشار شد. در مقابل، مدل ۳ در ۱ صرفاً با استفاده از RL بر روی مدل ۲ در ۱ توسعه یافت و تنها به ۳۵ اجرای آموزش RL و ۱۰ نامزد ارزیابی A/B نیاز داشت. هر دستاورد مدل‌سازی از آموخته‌های مراحل قبلی بهره برده، بر پایه آن‌ها ساخته شده و توسط آن‌ها شتاب گرفته است.

این تکرار و بهبود، بسیار فراتر از خود مدل رفت. در همین بازه زمانی، تیم کلاینت VS Code تعداد ۱۱۳ درخواست ادغام (PR) برای بهبود و پشتیبانی از تجربه NES ارائه کرد که شامل تغییرات ذکر شده در بخش‌های قبلی این مقاله نیز می‌شود. این موارد طیف وسیعی را پوشش می‌دادند: آزمایش و قابلیت تنظیم، یکپارچه‌سازی مدل، ساخت پرامپت و زمینه (context)، سرویس‌دهی و ارکستراسیون درخواست‌ها، کش کردن و ری‌بیس (rebase)، رندرینگ و تعامل، تله‌متری و قابلیت مشاهده، صحت و استحکام، و همچنین تلاش‌های مداوم و گسترده برای حفظ عملکرد روان تجربه کاربری همزمان با عرضه آن به میلیون‌ها کاربر در هر هفته.

این همان پاداش ساخت محصول به عنوان یک سیستم سرتاسری (end-to-end) است: مدل و تجربه کاربری پیرامون آن در کنار یکدیگر تکامل یافتند و آموخته‌های هر کدام به طور مداوم دیگری را شکل داد. شتابی که در بهبود یادگیری و پیشرفت سیستم سرتاسری مشاهده می‌کنیم، به اندازه‌ی هر نقطه عطف فردی هیجان‌انگیز است، اگر نگوییم بیشتر!

شکل ۲. حلقه یادگیری میان مدل و تجربه کامل سرتاسری یک مسیر دوطرفه است و ارزیابی و بازخورد در هر مرحله به تمامی اجزای این تجربه کمک می‌کند.

نتایج آنلاین

ما مدل ۳ در ۱ را در مقایسه با نسخه پایه پروداکشنِ وقت (مدل‌های ۲ در ۱ و تکمیل‌کننده) آزمایش کردیم. بسیار هیجان‌زده بودیم که دیدیم در مدل یکپارچه جدید، بدون هیچ‌گونه افت آماری معنادار در معیارهای کلیدی (از جمله کاراکترهای پذیرفته‌شده و حفظ‌شده)، ۱۰.۱ درصد کاهش در نرخ رد کردن (dismissals) مشاهده شد. این موضوع به‌ویژه با توجه به اینکه نسبت متن کم‌رنگ (ghost text) در محل مکان‌نما نسبت به نسخه کنترل ۱۳ درصد کاهش یافته بود، بسیار قابل‌توجه بود و ابعاد تازه‌ای به آموخته‌های قبلی ما اضافه کرد که نشان می‌داد افزایش نسبت متن کم‌رنگِ کمتر مزاحم، نرخ رد کردن را کاهش می‌دهد.

این مسئله مزیت یک مدل یکپارچه را برجسته می‌کند. مدل می‌تواند بهترین ویرایش را برای زمینه داده‌شده انتخاب کند، که اغلب بسیار مؤثرتر از منطق پیچیده کلاینت برای ارکستراسیون مدل‌های مستقل است. ما این را یک نقطه داده امیدوارکننده می‌دانیم که نشان می‌دهد تجربه یکپارچه می‌تواند فراتر از مجموع قطعات تشکیل‌دهنده خود باشد.

ما بسیار هیجان‌زده‌ایم که شما این سیستم یکپارچه را امتحان کنید؛ سیستمی که ویرایش درون‌خطی را به عنوان یک طیف پیوسته در نظر می‌گیرد؛ از تکمیل خط فعلی گرفته تا اعمال تغییرات در سرتاسر فایل.

قدم بعدی چیست؟

امیدواریم از این بررسی عمیق دوقسمتی در خصوص آموزش مدل‌های جدید پیشنهادات درون‌خطی یکپارچه لذت برده باشید (و اگر آن را از دست داده‌اید، می‌توانید بخش اول را از اینجا پیدا کنید: ساخت مدل جدید پیشنهادات درون‌خطی گیت‌هاب کوپایلوت: بخش اول). لطفاً منتظر یک گزارش فنی دقیق‌تر نیز باشید!

ما همچنین روی گسترش قابلیت‌های این مدل کار می‌کنیم تا تجربه ویرایش کد حتی یکپارچه‌تر و بصری‌تر شود. این شامل تمایل شخصی‌سازی‌شده مدل (model eagerness) است که بر اساس کار ما روی کیفیت مدل شکل گرفته و نحوه پیش‌قدم شدن مدل در پیشنهاد ویرایش‌ها را با ترجیحات کاربر تطبیق می‌دهد.

آن را امتحان کنید

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

دفعه بعد که در ویرایشگر هستید، چه در حال کار روی یک بازسازی ساختار (refactor) باشید و چه در حال نوشتن یک تابع جدید، آن را امتحان کنید. امیدواریم از تجربه «تب-تب-تب» لذت ببرید و مشتاقانه منتظر شنیدن نظرات شما هستیم!

در بخش دوم این پست وبلاگ، عمیق‌تر به نحوه انتقال به مدل ۳ در ۱ برای پیشنهادات درون‌خطی خواهیم پرداخت. منتظر باشید!

کدنویسی شاد و لذت‌بخشی داشته باشید! 💙

قدردانی‌ها

تشکر ویژه از Luciana Abud، Alexandru Dima، Yu Hu، Simona Liao، Gaurav Mittal، Elsie Nallipogu و Nick Trogh به خاطر بازخوردها، بینش‌ها و مشارکت‌های ارزشمندشان در این پست وبلاگ.

ما عمیق‌ترین سپاس خود را نثار جامعه توسعه‌دهندگان خود می‌کنیم که با بازخوردهای مداومشان، ما را به ارائه بهترین تجربیات ممکن با VS Code و گیت‌هاب کوپایلوت ترغیب می‌کنند. تشکر فراوان از محققان، مهندسان، مدیران محصول و طراحان در سراسر گیت‌هاب و مایکروسافت که داده‌های آموزشی را گردآوری کردند، پایپ‌لاین آموزشی، مجموعه‌های ارزیابی و استک سرویس‌دهی را ساختند، و همچنین از تیم‌های VS Code و گیت‌هاب کوپایلوت برای انتشار روان مدل‌ها سپاسگزاریم.