Настройка помощников по кодированию для организаций | Веб-сервисы Amazon

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

Мы можем устранить этот пробел и минимизировать дополнительное ручное редактирование, встраивая знания кода из частных репозиториев поверх языковой модели, обученной на общедоступном коде. Вот почему мы разработали возможность настройки для Amazon Code Whisperer. В этом посте мы покажем вам два возможных способа настройки помощников по кодированию с использованием дополненной генерации и тонкой настройки.

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

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

Используя внутренние репозитории кода для дополнительного обучения, которые уже прошли проверку кода, языковая модель может выявить использование внутренних API и блоков кода, которые позволяют преодолеть предыдущий список проблем. Поскольку эталонный код уже проверен и соответствует высоким требованиям заказчика, вероятность появления ошибок или уязвимостей безопасности также сведена к минимуму. А благодаря тщательному выбору исходных файлов, используемых для настройки, организации могут сократить использование устаревшего кода.

Проблемы дизайна

Настройка предложений кода на основе частных репозиториев организации сопряжена со многими интересными проблемами проектирования. Развертывание больших языковых моделей (LLM) для выявления предложений по коду имеет фиксированные затраты на доступность и переменные затраты из-за вывода, основанного на количестве сгенерированных токенов. Поэтому иметь отдельные настройки для каждого клиента и размещать их индивидуально, что приводит к дополнительным постоянным затратам, может оказаться непомерно дорогим. С другой стороны, одновременное наличие нескольких настроек в одной системе требует мультитенантной инфраструктуры для изоляции проприетарного кода для каждого клиента. Кроме того, возможность настройки должна включать ручки, позволяющие выбирать подходящее обучающее подмножество из внутреннего репозитория с использованием различных показателей (например, файлов с историей меньшего количества ошибок или кода, который недавно был зафиксирован в репозитории). Выбрав код на основе этих показателей, можно провести настройку с использованием более качественного кода, что может улучшить качество предлагаемого кода. Наконец, даже при постоянном развитии репозиториев кода затраты, связанные с настройкой, должны быть минимальными, чтобы помочь предприятиям добиться экономии средств за счет повышения производительности разработчиков.

Базовый подход к созданию настройки может заключаться в предварительном обучении модели на одном обучающем корпусе, состоящем из существующего (публичного) набора данных для предварительного обучения вместе с (частным) корпоративным кодом. Хотя этот подход работает на практике, он требует (избыточного) индивидуального предварительного обучения с использованием общедоступного набора данных для каждого предприятия. Это также требует избыточных затрат на развертывание, связанных с размещением индивидуальной модели для каждого клиента, которая обслуживает только клиентские запросы, исходящие от этого клиента. Этих избыточных затрат можно избежать, разделив обучение общедоступного и частного кода и развернув настройку в мультитенантной системе.

Как настроить

На высоком уровне существует два типа возможных методов настройки: генерация с расширенным поиском (RAG) и точная настройка (FT).

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

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

И RAG, и точная настройка являются мощными инструментами повышения производительности настройки на основе LLM. RAG может быстро адаптироваться к частным библиотекам или API с меньшими сложностями и затратами на обучение. Однако поиск и добавление полученных фрагментов кода в приглашение увеличивает задержку во время выполнения. Вместо этого точная настройка не требует какого-либо расширения контекста, поскольку модель уже обучена на частных библиотеках и API. Однако это приводит к более высоким затратам на обучение и усложнению обслуживания модели, когда несколько корпоративных клиентов должны поддерживать несколько пользовательских моделей. Как мы обсудим позже, эти проблемы можно устранить путем дальнейшей оптимизации подхода.

Поисковая дополненная генерация

RAG состоит из нескольких этапов:

Индексирование

Если администратор указал частный репозиторий, индекс создается путем разделения файлов исходного кода на фрагменты. Проще говоря, разбиение на фрагменты превращает фрагменты кода в удобоваримые фрагменты, которые, вероятно, будут наиболее информативными для модели и которые легко извлечь с учетом контекста. Размер фрагмента и способ его извлечения из файла — это выбор дизайна, который влияет на конечный результат. Например, фрагменты можно разделить на основе строк кода или синтаксических блоков и т. д.

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

Контекстный поиск

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

• Мешочек слов(БМ25) – Функция поиска набора слов, которая ранжирует набор фрагментов кода на основе частоты терминов запроса и длины фрагмента кода.

Поиск на базе BM25

На следующем рисунке показано, как работает BM25. Чтобы использовать BM25, сначала строится инвертированный индекс. Это структура данных, которая сопоставляет различные термины с фрагментами кода, в которых они встречаются. Во время поиска мы ищем фрагменты кода на основе терминов, присутствующих в запросе, и оцениваем их на основе частоты.

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

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

Расширенный вывод

Когда разработчики пишут код, их существующая программа используется для формулирования запроса, который отправляется в поисковый индекс. После получения нескольких фрагментов кода с помощью одного из описанных выше методов мы добавляем их к исходному приглашению. Здесь существует множество вариантов дизайна, включая количество извлекаемых фрагментов, относительное расположение фрагментов в приглашении и размер фрагмента. Окончательный выбор дизайна в первую очередь определяется эмпирическими наблюдениями путем изучения различных подходов с базовой языковой моделью и играет ключевую роль в определении точности подхода. Содержимое возвращенных фрагментов и исходного кода объединяются и отправляются в модель для получения индивидуальных предложений кода.

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

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

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

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

Есть два способа тонкой настройки. Один из подходов — использовать дополнительные данные без дополнения подсказки для точной настройки модели. Другой подход — дополнить подсказку во время тонкой настройки получением соответствующих предложений по коду. Это помогает улучшить способность модели предоставлять более точные предложения при наличии извлеченных фрагментов кода. Затем модель оценивается на заранее заданном наборе примеров после ее обучения. Впоследствии настроенная модель развертывается и используется для генерации предложений по коду.

Несмотря на преимущества использования выделенных LLM для генерации кода в частных репозиториях, затраты могут быть непомерно высокими для малых и средних организаций. Это связано с тем, что выделенные вычислительные ресурсы необходимы, даже если они могут использоваться недостаточно, учитывая размер команд. Одним из способов достижения экономической эффективности является обслуживание нескольких моделей на одном компьютере (например, Мультиарендность SageMaker). Однако для языковых моделей требуется один или несколько выделенных графических процессоров в нескольких зонах для обработки ограничений задержки и пропускной способности. Следовательно, мультитенантность хостинга полной модели на каждом графическом процессоре невозможна.

Мы можем решить эту проблему, обслуживая нескольких клиентов на одном компьютере, используя небольшие адаптеры в 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 и работает над AWS CodeWhisperer, помощником по кодированию на базе генеративного искусственного интеллекта. Ее исследовательские интересы лежат в области обработки естественного языка, AI4Code и генеративного искусственного интеллекта. В прошлом она работала над несколькими сервисами на основе НЛП, такими как Comprehend Medical, система медицинской диагностики в Amazon Health AI и система машинного перевода в Meta AI. В 2017 году она получила докторскую степень в Технологическом институте Вирджинии.

Араш Фарахани — учёный-прикладник в Amazon CodeWhisperer. В настоящее время его интересы связаны с генеративным искусственным интеллектом, поиском и персонализацией. Араш увлечен созданием решений, которые решают болевые точки разработчиков. Он работал над множеством функций CodeWhisperer и внедрил решения NLP в различные внутренние рабочие процессы, которые затрагивают всех разработчиков Amazon. Он получил докторскую степень в Университете Иллинойса в Урбана-Шампейн в 2017 году.

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

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

Рамеш Наллапати — старший научный сотрудник в области прикладного программирования в лабораториях искусственного интеллекта AWS и соруководитель CodeWhisperer, помощника по генеративному программированию на основе искусственного интеллекта, а также компании Titan Large Language Models в AWS. Его интересы в основном связаны с обработкой естественного языка и генеративным искусственным интеллектом. В прошлом Рамеш обеспечивал научное лидерство в разработке многих продуктов AWS на основе НЛП, таких как Kendra, Quicksight Q и Contact Lens. Он занимал исследовательские должности в Стэнфорде, CMU и IBM Research, а также получил докторскую степень. Степень бакалавра компьютерных наук Массачусетского университета в Амхерсте в 2006 году.

• SEO-контент и PR-распределение. Получите усиление сегодня.
• PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
• ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
• ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
• ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
• Источник: https://aws.amazon.com/blogs/machine-learning/customizing-coding-companions-for-organizations/