Три вещи, которые мы узнали о генеративном искусственном интеллекте и продуктивности разработчиков

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

В качестве примечания: нет надежного единого показателя для измерения производительности разработчика, учитывая его сложность. Вместо этого, как предполагалось Исследованиямы используем как количественные, так и качественные метрики. Первое включает в себя такие инструменты, как GIT, ДОРА и Потоки измерение качества и производительности кода. Последнее измеряется с помощью целенаправленных опросов разработчика.

Трек 1: существующие предложения

Многие компании и продукты появились в последние годы, чтобы воспользоваться успехами в искусственном интеллекте. Иногда это автономные коммерческие продукты, а иногда и инструменты, основанные на существующих LLM с открытым исходным кодом, таких как Llama или Gemma.

Мы расширили наше использование GitHub Copilotкоммерческое предложение всем нашим разработчикам в прошлом году. Наш тест на этот трек включал в себя пилот для Copilot, включающий 300 разработчиков – наполовину использование Copilot, и половина управляющей группы с аналогичными заданиями и способностями, но без капитала, в эксперименте A/B -теста, проведенном летом 2023 года. Мы выбрали Copilot из -за его популярности в мире разработчиков, и потому, что Ebay уже имеет наш кодовой баз на Githububub; Мы знакомы с тем, как работают их продукты.

Что сработало? Наши результаты были очень положительными. После двухнедельного периода развития, опросы разработчиков показали, что разработчики, использующие Copilot, увидели увеличение воспринимаемой производительности, наряду с 27% -ным уровнем принятия кода (как сообщается через телеметрию Copilot). Мы также обнаружили хорошие уровни точности: сгенерированные документы были точными на 70%, а генерируемый код составлял 60%. Кроме того, для экспериментальной группы копилот мы увидели создание снижения запроса (PR) на 17% (PR), чтобы объединить время, и снижение на 12% в Время выполнения перемен – косвенное преимущество эффективного кодирования. Мера качества кода через Сонар оставался неизменным для обеих групп.

Copilot смог предоставить функции, включая преобразование комментариев в код, предложение следующей строки кода, генерирование тестов и автоматический повторяющийся код-все меры для экономии времени. Но это также имело недостатки.

Что не сработало? Копилот имеет ограничение на его быстрый размер – по сути, сколько данных он может обрабатывать. LLMS есть улучшение Размер контекста с каждой итерацией, и для некоторых используется это не будет проблемой. Для компании размера eBay, однако, определенные задачи просто невозможно. У нас есть миллионы строк кода, и некоторые действия требуют знания всей кодовой базы eBay.

Трек 2: после обучения и настраиваемые LLMS

Существующие LLMS с открытым исходным кодом могут иногда достигать верхнего предела производительности; В конце концов, мы можем учиться на модели, которая не включает наши внутренние данные. Таким образом, второй трек-это пост-тренировочный и настройка LLM с открытым исходным кодом с использованием собственных предварительно обработанных данных нашей организации.

Мы использовали Code Llama 13b в качестве нашего базового LLM для этого упражнения, хотя это можно легко заменять на другое, если возникнет необходимость. Чтобы увидеть, насколько хорошо может работать после обучения и настраиваемого существующего LLM, мы создали то, что мы называем eBayCoder: код Llama, который обучается на кодовой базе eBay и связанной документации.

Что сработало? Мы обнаружили, что eBayCoder смог выполнить несколько задач, которые ранее были гораздо проще трудом и времени. Например, обслуживание программного обеспечения имеет решающее значение для всех технологических организаций. Как и другие компании в масштабе, eBay имеет свои собственные фундаментальные библиотеки и рамки, созданные на вершине программного обеспечения с открытым исходным кодом для серверов, очередей сообщений, партийных заданий, iOS и Android. Эти системы должны периодически обновляться для улучшения эргономики разработчика и устранения уязвимостей безопасности (например, обновление до последних Весна или Весенний ботинок) Усилия варьируются от нуля до огромного, в зависимости от текущей версии стека приложений. Благодаря существующим инструментам миграции на eBay мы по -прежнему тратим значительные инженерные ресурсы на обслуживание программного обеспечения. Это одна из областей, где мы считаем, что тонкий настраиваемый LLM может оказать очень большое влияние уже в краткосрочной перспективе.

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

Трек 3: внутренняя база знаний

Значительное количество продуктивного времени для любого разработчика тратится на расследование. Некоторые примеры этих вопросов, с которыми мы сталкиваемся здесь, на eBay: «Какой API я должен позвонить, чтобы добавить элемент в корзину?» «Где мне найти аналитическую панель для новых покупателей?» «Как мне создать конвейер для развертывания моего приложения для производства?»

В крупной компании есть много документации, но к ней не обязательно легко получить доступ. Внутренняя информация распределяется по первоисточникам, включая маркировки Enterprise Github, Google Docs, Jira, Slack и Wikis. Попытка найти ответы на, казалось бы, простые вопросы, иногда может потребовать нескольких встреч, мертвых концов и красных селений – все это составляет для снижения производительности и повышения раздражения.

Таким образом, мы создали внутренний GPT, который принимает определенные данные из соответствующих первичных источников. Вы знаете, как у каждой команды и каждой компании есть один сотрудник, который был там долгое время и к кому вы ходите, когда у вас есть вопрос, и вы даже не уверены, кого спрашивать? Это то, что мы сделали. Мы хотим, чтобы наши самые знающие и опытные разработчики сосредоточились на инновациях.

Что сработало? На высоком уровне мы использовали Поиск дополненного поколения (Rag) – Система, которая создает вектор встраивания для каждого фрагмента контента, которая затем хранится в векторной базе данных. Мы смогли сделать это автоматизированной, повторяющейся задачей.

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

Теперь, с запросом и контекстом в руках, мы называем наш личный экземпляр коммерческих и открытых LLMS с вопросом формы: ответьте на вопрос как можно более правдиво, используя предоставленный контекст, и если ответ не содержится в тексте ниже, скажем, «Я не знаю».

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

Что не сработало? Как и в случае с любой автоматизированной системой чата, иногда эти GPT могут давать бессмысленные ответы. Иногда это может быть разочаровывающим или бесполезным, но может быть улучшено с постоянными усилиями. На eBay мы зависим от наших сотрудников, чтобы дать отзыв через пользовательский интерфейс, который затем включается в саму систему. Эта техника – подкрепление, обучение от обратной связи с человеком, или RLHF – может сделать GPT лучше с течением времени.

Заключение

Эти три трека формируют основу для генеративной производительности разработчика ИИ, и они дают четкое представление о том, что они являются и как они приносят пользу каждому проекту. То, как мы разрабатываем программное обеспечение, меняется. Что еще более важно, выгоды, которые мы понимаем из генеративного ИИ, оказывают кумулятивное влияние на ежедневную работу. Убийство в производительности разработчика в начале экспоненциальной кривой, которую мы часто недооцениваем, поскольку проблема с экспоненциальным ростом заключается в том, что кривая вначале кажется плоской.

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