Вот что я узнал после 6 месяцев работы над инструментом разработки CodeGen (пилотная версия GPT)

Последние 6 месяцев я работал над GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ), чтобы понять, насколько мы действительно можем автоматизировать кодирование с помощью ИИ, поэтому я хотел поделиться нашими знаниями. до сих пор и как далеко он может зайти.

Когда я начал создавать пилотную версию GPT, я написал в блоге пост о том, как она задумана. Теперь я хочу поделиться своим пересмотренным мышлением и рассказать, что сработало, а что нет.

Наконец, вы увидите примеры приложений, созданных с помощью GPT Pilot, и то, как вы можете создать приложение с помощью настоящего программиста пар искусственного интеллекта.

Какова идея пилотного проекта GPT?

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

AI похож на младшего разработчика? Или…

Я часто вижу инструменты на базе CodeGen GPT-4, в которых говорится, что они создают младшего разработчика искусственного интеллекта.

Почему-то у меня всегда были проблемы с этим, потому что, когда я использую ChatGPT для кодирования, он дает мне ответы и идеи, которые может дать только супер-старший человек — то, что абсолютно ни один младший разработчик не сможет даже понять. Тем не менее, ни один LLM не может создать приложение так же хорошо, как старший разработчик, но знания GPT-4 о кодировании намного превосходят любого младшего разработчика.

Я бы сказал, что GPT-4 обладает такими знаниями во всех аспектах разработки программного обеспечения, как будто он самый старший разработчик в мире, но с памятью золотой рыбки. Я представляю его как сверхчеловеческого робота, который просто стоит посреди комнаты и может выполнять только одно небольшое действие за раз, но он не может объединять множество действий и работать постоянно. Вы должны точно сказать ему, что ему следует делать дальше.

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

В упомянутом выше сообщении блога я изложил основные принципы, на которых был построен GPT Pilot. Но они немного изменились на основе знаний нашей команды, поэтому вот пересмотренные основные принципы:

1. Человек необходим для надзора за ИИ не только потому, что ИИ недостаточно хорош, но и потому, что вы можете захотеть изменить то, как что-то работает или выглядит после его реализации. Обычно разработчик или менеджер продукта, увидев, как выглядит реализация, решает изменить ее.

   
   

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

   
   

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

   
   

   Таким образом, человек может просмотреть реализацию каждой задачи (точно так же, как проверка кода перед объединением PR), прежде чем GPT Pilot перейдет к следующей задаче. Если человек скажет GPT Pilot, что не так, исправить проблемы в самой задаче будет гораздо проще. В то же время LLM имеет контекст того, что необходимо сделать в рамках задачи и что уже сделано.

   
   

3. ИИ может исправлять свои собственные ошибки. У меня такое ощущение, что многие люди оценивают способность ChatGPT писать код по тому, насколько хорошо он работает, когда вы впервые просите его что-то закодировать. Если он не создает рабочий код, многие сочтут его не впечатляющим. На самом деле люди почти никогда не пишут работающий код с первой попытки . Вместо этого вы пишете код, запускаете его, видите ошибки и выполняете итерацию. Это именно то, что GPT Pilot позволяет GPT-4 делать — после того, как он напишет код, GPT Pilot может запустить код, получить выходные данные и спросить LLM, верны ли выходные данные, нужно ли что-то исправить, и если да, то как .

   
   

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

   
   

5. Процесс кодирования не является прямой линией . Когда мы создавали первую версию GPT Pilot, мы думали, что нужно будет перебирать задачи, реализовывать код, исправлять его и двигаться дальше. На самом деле вы не постоянно совершенствуетесь при кодировании приложения — вы все время переписываете свой код.

   
   

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

   
   

   Чтобы GPT Pilot или любой другой разработчик ИИ мог работать в больших масштабах, ему необходим механизм, который позволит ему вернуться назад, выбрать альтернативный путь и переопределить задачу.

Чему мы научились?

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

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

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

1. Первоначальное описание приложения гораздо важнее, чем мы думали . Наша первоначальная идея заключалась в том, что с участием человека GPT Pilot сможет двигаться в правильном направлении и приближаться все ближе и ближе к рабочему решению, даже если первоначальное описание было расплывчатым.

   
   

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

   
   

   Сейчас, когда я пишу это, это кажется таким очевидным, но нам нужно было этому научиться – уделять больше внимания первоначальному описанию. Итак, мы создали новый агент под названием «Spec Writer», который поможет вам определить требования проекта до того, как он начнет писать код.

   
   

2. Кодирование – это не прямая линия . Как я упоминал выше в разделе «Основы», рефакторинг происходит постоянно, и GPT Pilot тоже должен это делать. Мы еще не реализовали решение для этой проблемы, но оно, вероятно, сработает, если добавить в GPT Pilot возможность создавать маркеры вокруг своего дерева решений, чтобы всякий раз, когда что-то не работает, он мог просматривать маркеры и думать о том, где это могло быть. свернул не туда.

   
   

3. Агенты могут проверять себя . Я думал, что если агент просматривает то, что сделал другой агент, это будет излишним, потому что это тот же самый LLM, обрабатывающий ту же информацию. Но оказывается, что когда агент проверяет работу другого агента, это работает на удивление хорошо. У нас есть два разных агента «Проверяющий», которые проверяют, как был реализован код.

   
   

   Один делает это на высоком уровне, например, как была реализована вся задача, а другой проверяет каждое изменение, прежде чем оно будет внесено в файл (например, выполнение git add -p).

   
   

4. LLM работают лучше всего, когда они могут сосредоточиться на одной проблеме, а не на нескольких проблемах в одной подсказке. Например, если вы скажете GPT Pilot внести два разных изменения в одно описание, ему будет сложно сосредоточиться на обоих. Итак, мы разделяем каждый ввод, вводимый человеком, на несколько частей на случай, если ввод содержит несколько разных запросов.

   
   

5. Подробные журналы помогают . Сейчас это совершенно очевидно, но изначально мы не говорили GPT-4 добавлять какие-либо журналы вокруг кода. Теперь он создает код с подробным журналированием, поэтому, когда вы запустите приложение и столкнетесь с ошибкой, GPT-4 будет гораздо легче отлаживать, когда он увидит, какие журналы были записаны и где эти журналы находятся в коде.

   
   

6. Разделение кодовой базы на более мелкие файлы очень помогает . Это тоже очевидный вывод, но нам пришлось его усвоить. В GPT-4 гораздо проще реализовать функции и исправить ошибки, если код разбит на множество файлов, а не на несколько больших файлов. Как и мы, люди, думаем – гораздо проще обрабатывать меньшие куски кода, чем большие. Мы делаем это, создавая уровни абстракции — функции, классы и т. д.

   
   

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

   
   

7. Чтобы человек смог исправить код, ему нужно четко показать, что было написано в задании и идею, лежащую в его основе . Цель GPT Pilot — выполнить 90% всех задач по кодированию, а остальные 10% оставить человеку. Эти 10% обычно включают исправления или небольшие изменения, которые LLM с трудом замечает, но для человека это может быть простое изменение.

   
   

   Однако проблема в том, что нелегко сказать человеку, что не работает и на какой код ему следует обратить внимание. Если GPT Pilot пишет 3000 строк кода, разработчику, если он хочет помочь GPT Pilot, необходимо понять всю кодовую базу, прежде чем углубляться в реальный код.

   
   

   В будущих версиях GPT Pilot разработчик-человек будет иметь подробное объяснение того, какой код был добавлен в текущую задачу, и причины этого. Таким образом, вы сможете помочь GPT Pilot.

   
   

8. Люди ленивы . LLM лучше задавать людям вопросы, чем позволять им думать обо всех возможных ошибках. Опять же, оглядываясь назад, это совершенно очевидно, но мы заметили, что люди гораздо охотнее отвечали на вопросы, которые им задавал GPT Pilot, вместо того, чтобы иметь открытое поле ввода, в котором они могли бы писать неограниченные отзывы.

   
   

9. Трудно заставить магистра права мыслить нестандартно . Это было для меня одним из самых больших уроков. Я подумал, что вы могли бы подсказать GPT-4, предоставив ему пару решений, которые он уже использовал для устранения проблемы, и попросить его подумать о другом решении. Однако это не так просто, как кажется.

   
   

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

Приложения, созданные с помощью GPT Pilot

В настоящее время с помощью GPT Pilot можно создавать простые, но нетривиальные приложения. Мы также видели, как люди создают с помощью GPT Pilot очень впечатляющие приложения, например приложение, которое может точно настроить модель ResNet для подсчета пальм, а затем, когда вы загружаете изображение, подсчитать деревья в нем. Вот пара приложений, которые мы создали, а также код, статистика и демо-версии:

Prompt Lab ( ДЕМО )

Думайте об этом как о игровой площадке OpenAI на стероидах — она позволяет вам загружать разговор из массива JSON или вводить его вручную, запускать разговор с LLM X количество раз, сохранять разговор в базе данных и загружать его обратно. Мы на самом деле используйте это приложение, когда мы разрабатываем приглашение и хотим посмотреть, как оно будет себя вести.

Игровая площадка недостаточно хороша, потому что многократный повтор одного запроса отнимает много времени. С помощью Prompt Lab вы можете выбрать, сколько раз запускать ее, и позволить приложению запускать подсказку несколько раз.

После завершения вы можете проанализировать результаты. Это может быть полезно для людей, которые создают приложения с искусственным интеллектом и которым необходимо оптимизировать свои подсказки.

• ⏳ Затраченное время: ~2 дня
• 💾 Репозиторий Github

Инструмент анализатора базы данных SQLite ( ДЕМО )

Это также приложение, которое мы используем для внутреннего анализа локальной базы данных SQLite. Он извлекает данные из базы данных в формате, который очень специфичен для структуры базы данных GPT Pilot, но его можно легко изменить для соответствия другим структурам.

Он считывает и загружает вашу базу данных SQLite, разбивает строки по определенному полю, распаковывает строки в значения, загружает данные разговора LLM в форму и позволяет вам просто изменить одно из сообщений и отправить запрос LLM в GPT-4. чтобы увидеть, как будут выглядеть результаты.

Таким образом, вы можете проанализировать разговоры агентов GPT Pilot с LLM и легко понять, что произошло бы, если бы подсказки были другими.

• ⏳ Затраченное время: ~2 дня
• 💾 Репозиторий Github

Заклинатель кода ( ДЕМО )

Code Whisper — это забавный проект, который мы создали в качестве примера для демонстрации. Идея состоит в том, что вы можете использовать его, чтобы задавать LLM вопросы о вашей кодовой базе. Вы вставляете ссылку на общедоступный репозиторий Github.

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

После этого вы можете задать приложению вопросы о кодовой базе, и кодовая база покажет вам ответ. В этой демонстрации мы используем GPT-3.5.

• ⏳ Затраченное время: 7 часов
• 💾 Репозиторий Github

Звездная история ( ДЕМО )

Я выпускаю проекты с открытым исходным кодом уже много лет, и мне всегда хотелось увидеть, насколько быстро растет мой репозиторий Github по сравнению с другими успешными репозиториями на https://star-history.com/ . Проблема в том, что в Star History я не могу увеличить график, поэтому новое репо с 1000 звезд нельзя сравнивать с большим репо с 50 000, потому что вы не можете увидеть, как ведет себя более крупное репо в начале. .

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

• ⏳ Затраченное время: 6 часов
• 💾 Репозиторий Github

Заключение

Надеюсь, вы получили некоторое представление о текущем состоянии, проблемах и выводах, с которыми мы имеем дело в GPT Pilot.

Итак, подведем итог:

Мы считаем, что настоящий инструмент разработчика ИИ должен основываться на следующих принципах:

• Для наблюдения за ИИ необходим человек.

  
  

• Мы должны позволить ИИ исправлять свои собственные ошибки.

  
  

• Разработка программного обеспечения может быть организована , что должно быть реализовано на уровне поверх LLM.

  
  

• Разработчик ИИ должен иметь возможность провести рефакторинг кодовой базы , поскольку на самом деле процесс кодирования не является прямой линией.

На данный момент мы узнали, что:

1. Первоначальное описание приложения гораздо важнее, чем мы думали

2. Кодирование — это не прямая линия, агенты могут проверять себя

3. LLM работают лучше всего, когда они сосредоточены на одной проблеме, а не на нескольких проблемах в одной подсказке.

4. Подробные журналы творят чудеса

5. Разделение кодовой базы на более мелкие файлы очень помогает.

6. Чтобы человек мог исправить код

7. Им должно быть ясно показано, что написано, и идея, лежащая в основе этого.

8. Люди ленивы

9. Трудно заставить LLM мыслить нестандартно.

   
   

Что вы думаете? Замечали ли вы какое-либо подобное поведение при взаимодействии с LLM или у вас другое мнение по любому из них?

Я был бы очень рад услышать ваше мнение, поэтому оставьте комментарий ниже или напишите мне по адресу [email protected] .

Вы можете попробовать создать приложение с искусственным интеллектом с помощью GPT Pilot здесь:

• Репозиторий GPT Pilot с открытым исходным кодом
• Расширение GPT Pilot VS Code

Если вам понравился этот пост, это будет много значить, если вы пометите репозиторий GPT Pilot Github , и если вы попробуете его, дайте нам знать, что вы думаете. Ваш отзыв очень важен для всей пилотной команды GPT.

Также опубликовано здесь