Налаштування компаньйонів кодування для організацій | Веб-сервіси Amazon

Генеративні моделі штучного інтелекту для програмування компаньйонів здебільшого навчаються на загальнодоступному вихідному коді та тексті природною мовою. Хоча великий розмір навчального корпусу дозволяє моделям генерувати код для загальновживаних функцій, ці моделі не знають коду в приватних сховищах і пов’язаних стилів кодування, які застосовуються під час розробки з ними. Отже, згенеровані пропозиції можуть вимагати переписування, перш ніж вони стануть придатними для включення у внутрішній репозиторій.

Ми можемо усунути цю прогалину та звести до мінімуму додаткове ручне редагування, вставивши знання коду з приватних репозиторіїв поверх мовної моделі, навченої на загальнодоступному коді. Ось чому ми розробили можливість налаштування для Amazon Code Whisperer. У цій публікації ми покажемо вам два можливі способи налаштування компаньйонів кодування за допомогою генерації та тонкого налаштування розширеного пошуку.

Наша мета з можливістю налаштування CodeWhisperer полягає в тому, щоб дозволити організаціям адаптувати модель CodeWhisperer, використовуючи свої приватні репозиторії та бібліотеки, щоб генерувати рекомендації щодо коду для конкретної організації, які економлять час, дотримуються організаційного стилю та умов, а також уникають помилок або вразливостей безпеки. Це приносить користь розробці корпоративного програмного забезпечення та допомагає подолати такі проблеми:

1. Недостатня документація чи інформація для внутрішніх бібліотек і API змушує розробників витрачати час на вивчення раніше написаного коду для повторення використання.
2. Відсутність обізнаності та послідовності у впровадженні специфічних для підприємства практик кодування, стилів і шаблонів.
3. Ненавмисне використання розробниками застарілого коду та API.

Використовуючи внутрішні сховища коду для додаткового навчання, які вже пройшли перевірку коду, модель мови може виявити використання внутрішніх API і блоків коду, які подолають попередній список проблем. Оскільки довідковий код уже перевірено та відповідає високій планці замовника, ймовірність появи помилок або вразливостей системи безпеки також зведена до мінімуму. Ретельно вибираючи вихідні файли для налаштування, організації можуть скоротити використання застарілого коду.

Виклики дизайну

Налаштування пропозицій коду на основі приватних репозиторіїв організації має багато цікавих проблем у дизайні. Розгортання великих мовних моделей (LLM) для пропозицій поверхневого коду має фіксовані витрати на доступність і змінні витрати через висновок на основі кількості згенерованих маркерів. Тому наявність окремих налаштувань для кожного клієнта та їх індивідуальне розміщення, що спричиняє додаткові постійні витрати, може бути надзвичайно дорогим. З іншого боку, наявність кількох налаштувань одночасно в одній системі вимагає багатокористувацької інфраструктури для ізоляції власного коду для кожного клієнта. Крім того, можливість налаштування має відкривати ручки, щоб уможливлювати вибір відповідної підмножини навчання з внутрішнього сховища за допомогою різних показників (наприклад, файли з історією меншої кількості помилок або код, який нещодавно зафіксовано в сховищі). Вибравши код на основі цих показників, налаштування можна навчити, використовуючи код вищої якості, що може покращити якість пропозицій коду. Нарешті, навіть із сховищами коду, що постійно розвиваються, витрати, пов’язані з налаштуванням, мають бути мінімальними, щоб допомогти підприємствам заощадити кошти завдяки підвищенню продуктивності розробників.

Базовим підходом до створення налаштувань може бути попереднє навчання моделі на єдиному навчальному корпусі, що складається з існуючого (публічного) набору даних попереднього навчання разом із (приватним) корпоративним кодом. Хоча цей підхід працює на практиці, він вимагає (надлишкового) індивідуального попереднього навчання з використанням публічного набору даних для кожного підприємства. Це також вимагає надлишкових витрат на розгортання, пов’язаних із розміщенням індивідуальної моделі для кожного клієнта, яка обслуговує лише запити клієнтів, що надходять від цього клієнта. Цих надлишкових витрат можна уникнути, роз’єднавши навчання загальнодоступного та приватного коду та розгорнувши налаштування в системі з кількома клієнтами.

Як налаштувати

На високому рівні існує два типи можливих методів налаштування: пошуково-доповнена генерація (RAG) і тонка настройка (FT).

• Генерація з доповненим пошуком: RAG знаходить відповідні фрагменти коду в сховищі, які схожі на даний фрагмент коду (наприклад, код, який безпосередньо передує курсору в IDE), і доповнює підказку, яка використовується для запиту LLM, цими відповідними фрагментами коду. Це збагачує підказку, щоб допомогти підштовхнути модель до створення більш відповідного коду. Існує кілька методів, досліджених у літературі в цьому напрямку. Побачити Генерація з доповненим пошуком для наукоємних завдань НЛП, РЕАЛЬНО, кНН-ЛМ та РЕТРО.

• Тоне налаштування: FT приймає попередньо підготовлений LLM і навчає його далі на певній, меншій кодовій базі (порівняно з набором даних попереднього навчання), щоб адаптувати його для відповідного сховища. Тонка настройка коригує ваги LLM на основі цього навчання, роблячи його більш пристосованим до унікальних потреб організації.

І RAG, і тонке налаштування є потужними інструментами для підвищення продуктивності налаштування на основі LLM. RAG може швидко адаптуватися до приватних бібліотек або API з меншою складністю та вартістю навчання. Однак пошук і доповнення отриманих фрагментів коду до підказки збільшує затримку під час виконання. Натомість точне налаштування не потребує жодного розширення контексту, оскільки модель уже навчена на приватних бібліотеках та API. Однак це призводить до вищих витрат на навчання та складності в обслуговуванні моделі, коли кілька користувацьких моделей мають підтримуватися кількома корпоративними клієнтами. Як ми обговоримо пізніше, ці проблеми можна усунути шляхом подальшої оптимізації підходу.

Побудова розширеного пошуку

У RAG є кілька кроків:

Індексація

Якщо адміністратор вводить приватне сховище, індекс створюється шляхом поділу файлів вихідного коду на частини. Простіше кажучи, фрагментація перетворює фрагменти коду на засвоювані фрагменти, які, ймовірно, будуть найбільш інформативними для моделі та які легко отримати в контексті. Розмір фрагмента та спосіб його вилучення з файлу є параметрами дизайну, які впливають на кінцевий результат. Наприклад, блоки можна розділяти на основі рядків коду або синтаксичних блоків тощо.

Робочий процес адміністратора

Контекстний пошук

Шукайте набір індексованих фрагментів коду на основі кількох рядків коду над курсором і отримайте відповідні фрагменти коду. Це отримання може відбуватися за допомогою різних алгоритмів. Ці варіанти можуть включати:

• Сумка слів (BM25) - Функція пошуку пакетів слів, яка ранжує набір фрагментів коду на основі частот термінів запиту та довжини фрагментів коду.

Пошук на основі BM25

На наступному малюнку показано, як працює BM25. Щоб використовувати BM25, спочатку будується інвертований індекс. Це структура даних, яка зіставляє різні терміни з фрагментами коду, у яких ці терміни зустрічаються. Під час пошуку ми шукаємо фрагменти коду на основі термінів, присутніх у запиті, і оцінюємо їх на основі частоти.

Семантичний пошук

BM25 зосереджується на лексичній відповідності. Таким чином, заміна «додати» на «видалити» може не змінити оцінку BM25 на основі термінів у запиті, але отримані функції можуть бути протилежними необхідним. Навпаки, семантичний пошук зосереджується на функціональності фрагмента коду, навіть якщо імена змінних і API можуть відрізнятися. Як правило, комбінація BM25 і семантичного пошуку може добре працювати разом, щоб забезпечити кращі результати.

Розширений висновок

Коли розробники пишуть код, їх існуюча програма використовується для формулювання запиту, який надсилається до індексу пошуку. Після отримання кількох фрагментів коду за допомогою одного з описаних вище прийомів ми додаємо їх до вихідного запиту. Тут є багато варіантів оформлення, включаючи кількість фрагментів, які потрібно отримати, відносне розміщення фрагментів у підказці та розмір фрагмента. Остаточний вибір дизайну в основному визначається емпіричним спостереженням шляхом вивчення різних підходів із базовою мовною моделлю та відіграє ключову роль у визначенні точності підходу. Вміст повернутих фрагментів і вихідний код об’єднуються та надсилаються в модель для отримання індивідуальних пропозицій коду.

Робочий процес розробника

Точне налаштування:

Тонка настройка створено мовну модель трансферне навчання у якому вагові коефіцієнти попередньо навченої моделі навчаються на нових даних. Мета полягає в тому, щоб зберегти відповідні знання з моделі, яка вже навчена на великому корпусі, і вдосконалити, замінити або додати нові знання з нового корпусу — у нашому випадку, нової кодової бази. Просте навчання на новій кодовій базі призводить до катастрофічне забування. Наприклад, мовна модель може «забути» свої знання про безпеку або API, які на сьогоднішній день рідко використовуються в кодовій базі підприємства. Існують різноманітні методики, як повторний досвід, GEM та ПП-ТФ які використовуються для вирішення цієї проблеми.

Тонка настройка

Є два способи тонкого налаштування. Один із підходів полягає у використанні додаткових даних без додавання підказки для точного налаштування моделі. Інший підхід полягає в тому, щоб збільшити підказку під час тонкого налаштування шляхом отримання відповідних пропозицій коду. Це допомагає покращити здатність моделі надавати кращі пропозиції за наявності отриманих фрагментів коду. Потім модель оцінюється на набір прикладів після її навчання. Згодом налаштована модель розгортається та використовується для створення пропозицій коду.

Незважаючи на переваги використання спеціальних LLM для генерації коду в приватних сховищах, витрати можуть бути непомірно високими для малих і середніх організацій. Це пояснюється тим, що виділені обчислювальні ресурси необхідні, навіть якщо вони можуть недостатньо використовуватися з огляду на розмір команд. Одним із способів досягнення економічної ефективності є обслуговування кількох моделей на одному комп’ютері (наприклад, Багатокористувацький SageMaker). Однак мовні моделі вимагають одного або кількох виділених графічних процесорів у кількох зонах для обробки затримки та обмежень пропускної здатності. Отже, мультиоренда повної моделі хостингу на кожному GPU є неможливою.

Ми можемо подолати цю проблему, обслуговуючи кількох клієнтів на одному комп’ютері за допомогою невеликих Адаптери до LLM. Методи ефективного налаштування параметрів (PEFT), наприклад оперативне налаштування, настройка префіксата адаптація низького рангу (Лора) використовуються для зниження витрат на навчання без втрати точності. Особливо LoRA досягла великого успіху в досягненні подібної (або кращої) точності, ніж повна тонка настройка моделі. Основна ідея полягає в тому, щоб розробити матрицю низького рангу, яка потім додається до матриць із вихідною вагою матриці цільових шарів моделі. Як правило, ці адаптери потім об’єднуються з вагами оригінальної моделі для обслуговування. Це призводить до такого ж розміру та архітектури, що й оригінальна нейронна мережа. Зберігаючи адаптери окремо, ми можемо обслуговувати одну базову модель з багатьма модельними адаптерами. Це повертає нашим малим і середнім клієнтам ефект масштабу.

Адаптація низького рангу (LoRA)

Вимірювання ефективності налаштування

Нам потрібні показники оцінки, щоб оцінити ефективність індивідуального рішення. Показники офлайн-оцінки діють як захист від налаштувань доставки, які є нижчими порівняно з моделлю за замовчуванням. Створюючи набори даних із утримуваного набору даних із наданого сховища, підхід до налаштування можна застосувати до цього набору даних для вимірювання ефективності. Порівняння існуючого вихідного коду з пропозицією налаштованого коду кількісно оцінює корисність налаштування. Загальні заходи, які використовуються для цього кількісного визначення, включають такі показники, як редагувати схожість, точна відповідність і КодBLEU.

Також можна виміряти корисність, визначивши, як часто внутрішні API викликаються настроюванням, і порівнявши це з викликами в попередньому джерелі. Звичайно, для успішного завершення важливо правильно визначити обидва аспекти. Для нашого підходу до налаштування ми розробили спеціалізований показник, відомий як індекс якості налаштування (CQI), єдиний зручний показник у діапазоні від 1 до 10. Показник CQI показує корисність пропозицій налаштованої моделі порівняно з кодом пропозиції із загальною публічною моделлю.

Підсумки

Ми розробили можливість налаштування Amazon CodeWhisperer на основі поєднання провідних технічних прийомів, розглянутих у цій публікації в блозі, і оцінили їх за допомогою досліджень продуктивності розробників, проведених компанією Persistent Systems. У цих двох дослідженнях, проведених на замовлення AWS, розробникам було запропоновано створити медичне програмне забезпечення на Java, яке вимагає використання їхніх внутрішніх бібліотек. У першому дослідженні розробникам без доступу до CodeWhisperer знадобилося (в середньому) ~8.2 години для виконання завдання, тоді як ті, хто використовував CodeWhisperer (без налаштування), виконували завдання на 62 відсотки швидше (в середньому) за ~3.1 години.

У другому дослідженні з іншою когортою розробників розробники, які використовували CodeWhisperer, який був налаштований за допомогою їхньої приватної кодової бази, виконували завдання в середньому за 2.5 години, на 28 відсотків швидше, ніж ті, хто використовував CodeWhisperer без налаштування та виконували завдання приблизно за 3.5 години. годин в середньому. Ми твердо переконані, що такі інструменти, як CodeWhisperer, налаштовані відповідно до вашої кодової бази, відіграють ключову роль у подальшому підвищенні продуктивності розробників, і рекомендуємо запустити їх. Для отримання додаткової інформації та для початку відвідайте веб-сайт Сторінка Amazon CodeWhisperer.

---

Про авторів

Цин Сун є старшим прикладним науковим співробітником AWS AI Labs і працює над AWS CodeWhisperer, генеративним помічником кодування на основі штучного інтелекту. Її наукові інтереси пов’язані з обробкою природної мови, AI4Code та генеративним ШІ. У минулому вона працювала над кількома сервісами на основі НЛП, такими як Comprehend Medical, система медичної діагностики в Amazon Health AI і система машинного перекладу в Meta AI. Вона отримала ступінь доктора філософії в Virginia Tech у 2017 році.

Араш Фарахані є прикладним науковцем Amazon CodeWhisperer. Зараз його цікавить генеративний штучний інтелект, пошук і персоналізація. Араш захоплено створює рішення, які вирішують проблеми розробників. Він працював над багатьма функціями в CodeWhisperer і запровадив рішення NLP у різні внутрішні робочі потоки, які стосуються всіх розробників Amazon. Він отримав ступінь доктора філософії в Університеті Іллінойсу в Урбана-Шампейн у 2017 році.

Сяофей Ма є менеджером прикладної науки в AWS AI Labs. Він приєднався до Amazon у 2016 році як прикладний науковець в організації SCOT, а потім у AWS AI Labs у 2018 році працював над Amazon Kendra. Сяофей працював науковим менеджером для кількох служб, зокрема Kendra, Contact Lens і нещодавно CodeWhisperer і CodeGuru Security. Його наукові інтереси лежать у сфері AI4Code та обробки природної мови. Він отримав ступінь доктора філософії в Університеті Меріленда, Коледж-Парк у 2010 році.

Муралі Крішна Раманатан є головним прикладним науковим співробітником лабораторій AWS AI Labs і одним із керівників AWS CodeWhisperer, генеративного супутника кодування на основі штучного інтелекту. Він захоплений створенням програмних інструментів і робочих процесів, які допомагають підвищити продуктивність розробників. У минулому він розробив Piranha, автоматизований інструмент рефакторингу для видалення коду через застарілі позначки функцій і керував ініціативами щодо якості коду в Uber Engineering. Він є лауреатом нагороди викладачів Google (2015), нагороди ACM SIGSOFT Distinguished paper (ISSTA 2016) і нагороди Моріса Холстеда (Purdue 2006). У 2008 році він отримав ступінь доктора філософії з комп’ютерних наук в університеті Пердью.

Рамеш Наллапаті є старшим головним прикладним науковим співробітником AWS AI Labs і одним із керівників CodeWhisperer, генеративного компаньйона кодування на основі штучного інтелекту, і Titan Large Language Models в AWS. Його інтереси зосереджені в основному в області обробки природної мови та генеративного штучного інтелекту. У минулому Рамеш забезпечив наукове лідерство у розробці багатьох продуктів AWS на основі НЛП, таких як Kendra, Quicksight Q і Contact Lens. Він обіймав дослідницькі посади в Стенфорді, CMU та IBM Research, а також отримав ступінь доктора філософії. в 2006 році в Університеті штату Массачусетс Амгерст.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://aws.amazon.com/blogs/machine-learning/customizing-coding-companions-for-organizations/