6개월간 CodeGen 개발 도구(GPT 파일럿) 작업을 하면서 배운 점은 다음과 같습니다.

지난 6개월 동안 저는 AI로 코딩을 얼마나 자동화할 수 있는지 이해하기 위해 GPT 파일럿( ) 작업을 진행해 왔으며, 배운 내용을 공유하고 싶었습니다. 지금까지, 얼마나 멀리 갈 수 있는지. https://github.com/Pythagora-io/gpt-pilot 저는 GPT 파일럿 구축을 시작했을 때 이것이 어떻게 구상되는지에 대해 썼습니다. 이제 나는 수정된 생각을 공유하고 무엇이 효과가 있었고 무엇이 효과가 없었는지 살펴보고 싶습니다. 이 블로그 게시물을 마지막으로 GPT Pilot으로 만든 앱의 예와 AI 쌍 프로그래머로 앱을 만드는 방법을 볼 수 있습니다. 실제 GPT 파일럿의 아이디어는 무엇입니까? GPT Pilot은 로 구상됩니다. 오히려 앱이나 기능을 구축하는 방법에 대한 계획을 세우고 코딩을 시작하는 것은 개발자입니다. 대부분의 코딩을 자체적으로 수행하고 싶지만 막히면 주어진 요구 사항에 대한 설명이 필요하거나 코드 검토가 필요하면 도움을 요청합니다. 자동 완성이나 챗봇이 아닌 실제 AI 개발자 AI는 주니어 개발자와 같나요? 또는… AI 주니어 개발자를 구축하고 있다고 말하는 CodeGen GPT-4 기반 도구를 자주 봅니다. 어쨌든 나는 코딩에 ChatGPT를 사용할 때 최고 선배만이 줄 수 있는 답변과 아이디어를 제공하기 때문에 항상 문제가 있었습니다. 이는 어떤 후배 개발자도 이해할 수 없는 것입니다. 그럼에도 불구하고 어떤 LLM도 시니어 개발자만큼 앱을 구축할 수는 없지만 GPT-4가 코딩에 대해 갖고 있는 지식은 주니어 개발자보다 훨씬 뛰어납니다. GPT-4는 소프트웨어 개발의 모든 부분에 대해 세계 최고 수준의 개발자이지만 금붕어의 기억력을 갖고 있는 것처럼 많은 지식을 갖고 있다고 말하고 싶습니다. 나는 그것을 방 한가운데 서서 한 번에 하나의 작은 동작만 할 수 있지만 많은 동작을 결합하여 반복적으로 작업할 수 없는 초인적인 로봇으로 상상합니다. 다음에 무엇을 해야 하는지 정확하게 알려주어야 합니다. 이것이 바로 우리가 GPT Pilot을 통해 추구하는 것입니다. 우리는 초인적 로봇이 이전 작업을 수정하여 지속적으로 작업하고, 피드백 루프를 갖고, 다음에 수행해야 할 작업을 결정하도록 하는 LLM에 대한 사고 프레임워크를 만들고 싶습니다. 프로덕션에 바로 사용할 수 있는 애플리케이션을 구축하는 최종 목표를 완료합니다. GPT 파일럿이 구축된 주요 기둥에 대해 설명했습니다. 하지만 이는 우리 팀의 학습을 바탕으로 약간 변경되었으므로 수정된 기본 사항은 다음과 같습니다. 위에서 언급한 블로그 게시물에서는 AI가 충분하지 않을 뿐만 아니라 작동 방식이나 구현 후 관리 방법을 변경하고 싶을 수도 있기 . 개발자나 제품 관리자가 구현의 모습을 확인한 후 변경하기로 결정하는 것은 흔한 일입니다. 때문에 AI를 감독하려면 인간이 필요합니다 또는 처음에 예상했던 것보다 더 많은 극단적인 경우가 있다는 것을 깨닫고 모든 문제를 해결하는 것보다 현재 구현을 리팩터링하는 것이 더 쉽다고 생각합니다. 문제는 전체 앱을 완성한 다음 리팩터링을 시도할 때입니다. 모든 변경 사항이 다른 모든 기능에 영향을 미치기 때문에 이 작업이 훨씬 더 어려워집니다. 반면, 변경 사항을 커밋하기 전에 리팩터링을 수행하면 잘 작성된 코드 위에 다음 기능을 진행할 수 있습니다. 이것이 이유입니다. AI 개발자가 작업이 구현될 때마다 루프에 사람을 참여시키는 것이 중요한 이렇게 하면 GPT 파일럿이 다음 작업을 계속하기 전에 사람이 각 작업의 구현을 검토할 수 있습니다(PR을 병합하기 전의 코드 검토와 마찬가지로). 사람이 GPT Pilot에게 무엇이 잘못되었는지 알려주면 작업 자체 내에서 문제를 해결하는 것이 훨씬 쉬울 것입니다. 동시에 LLM은 업무에서 수행해야 할 작업과 지금까지 수행된 작업에 대한 컨텍스트를 가지고 있습니다. 나는 많은 사람들이 ChatGPT의 코드 작성 능력을 처음 코딩을 요청할 때 얼마나 잘 전달하는지에 따라 판단한다고 생각합니다. 작동하는 코드가 생성되지 않으면 많은 사람들이 그것이 인상적이지 않다고 생각할 것입니다. 실제로 . 대신 코드를 작성하고 실행하고 오류를 확인하고 반복합니다. 이것이 바로 GPT 파일럿이 GPT-4를 통해 수행할 수 있는 작업입니다. 코드를 작성한 후 GPT 파일럿은 코드를 실행하고 출력을 가져온 다음 LLM에 출력이 올바른지, 수정해야 하는 부분이 있는지, 그렇다면 어떻게 해야 하는지 물어볼 수 있습니다. . AI는 자신의 실수를 반복할 수 있습니다. 인간은 첫 번째 시도에서 작동하는 코드를 거의 작성하지 않습니다 . 모든 개발자가 앱을 구축할 때 겪는 반복적인 루틴이 많이 있습니다. 루틴 중 하나는 코드 작성, 실행, 오류 읽기, 코드 변경, 재실행 등일 수 있습니다. 또 다른 상위 수준의 루틴은 작업 수행, 구현, 구현 테스트(모든 테스트가 통과할 때까지 반복)일 수 있습니다. , 검토를 위해 보내고 문제를 수정한 후(검토자가 승인할 때까지 반복) 배포합니다. LLM과 같은 지능적인 의사 결정권자가 루프에 있다면 이러한 루틴 중 상당수를 조정할 수 있습니다. 소프트웨어 개발을 조율할 수 있습니다 . GPT 파일럿의 첫 번째 버전을 만들 때 작업을 반복하고, 코드를 구현하고, 수정한 후 계속 진행해야 한다고 생각했습니다. 실제로는 앱 코딩을 지속적으로 진행하지 않고 항상 코드를 다시 작성합니다. 코딩 과정은 직선이 아닙니다 때로는 초기 구현 후에 무언가를 구현하는 더 좋은 방법이 있다는 것을 깨닫기 때문에 코드베이스를 리팩터링합니다. 다른 경우에는 요구 사항이 변경되어 이를 수행합니다. #1에서 언급한 것처럼 솔루션이 작동하지 않는 것을 확인한 후에는 때때로 여러 변경 사항을 롤백하고 문제에 대한 대체 솔루션을 생각한 후 그런 식으로 해결해 보아야 합니다. GPT Pilot이나 다른 AI 개발자가 대규모로 작업할 수 있도록 하려면 돌아가서 대체 경로를 선택하고 작업을 다시 구현할 수 있는 메커니즘이 필요합니다. 우리는 무엇을 배웠는가? 일반적으로 LLM은 작동 방식, 개선할 수 있는 작업, 적절한 프롬프트 엔지니어링 수행 방법 등 모든 사람이 이해하려고 노력하는 새로운 기술입니다. . 우리의 접근 방식은 응용 프로그램 계층을 구축하는 데 중점을 두는 것입니다. LLM은 더 나은 결과를 출력합니다 그 이유는 LLM이 더 좋아질 것이고 프롬프트를 최적화하는 데 몇 주를 소비한다면 새 버전의 GPT로 완전히 해결될 수 있다는 것입니다. 대신 우리는 사용자 경험이 어떤 모습이어야 하는지, 그리고 LLM이 지속적으로 작동하여 최종 솔루션에 점점 더 가까워지도록 LLM을 제어하는 데 필요한 메커니즘에 중점을 두고 있습니다. 지금까지 우리가 배운 내용은 다음과 같습니다. . 우리의 원래 생각은 초기 설명이 모호하더라도 인간의 입력을 통해 GPT Pilot이 올바른 방향으로 탐색하고 작업 솔루션에 점점 더 가까워질 수 있다는 것이었습니다. 앱에 대한 초기 설명은 우리가 생각했던 것보다 훨씬 더 중요합니다 그러나 GPT Pilot의 생각은 초기 설명부터 시작하여 프롬프트 전반에 걸쳐 분기됩니다. 따라서 초기 프롬프트에서 잘못된 내용이 있는 경우 GPT 파일럿에 포함된 다른 모든 정보는 잘못된 방향으로 이어질 것입니다. 따라서 당신이 그것을 바로잡을 때, 그것은 이 잘못된 길에 너무 깊게 빠져서 올바른 길로 가는 것이 거의 불가능할 것입니다. 지금 이 글을 쓰고 있는 지금, 그것은 너무나 당연해 보이지만, 초기 설명에 훨씬 더 집중하기 위해 우리가 배워야 할 것입니다. 그래서 우리는 코딩을 시작하기 전에 프로젝트 요구 사항을 분석하는 데 도움을 주는 "Spec Writer"라는 새로운 에이전트를 구축했습니다. . 위에서 기둥 섹션에서 언급했듯이 리팩토링은 항상 발생하며 GPT Pilot도 이를 수행해야 합니다. 이에 대한 솔루션은 아직 구현되지 않았지만 GPT 파일럿이 결정 트리 주위에 마커를 생성하는 기능을 추가하면 작동할 가능성이 높습니다. 그러면 무언가 작동하지 않을 때마다 마커를 검토하고 가능한 위치를 생각할 수 있습니다. 방향을 잘못 잡았습니다. 코딩은 직선이 아닙니다 . 내 생각에는 에이전트가 다른 에이전트가 수행한 작업을 검토하면 동일한 정보를 재처리하는 동일한 LLM이기 때문에 중복될 것이라고 생각했습니다. 하지만 에이전트가 다른 에이전트의 작업을 검토하면 놀라울 정도로 잘 작동하는 것으로 나타났습니다. 코드가 어떻게 구현되었는지 검토하는 2명의 "검토자" 에이전트가 있습니다. 상담원은 자신을 검토할 수 있습니다 하나는 전체 작업이 어떻게 구현되었는지와 같은 높은 수준에서 수행하고, 다른 하나는 파일에 적용하기 전에 각 변경 사항을 검토합니다(예: git add -p 수행). . 예를 들어 GPT Pilot에 단일 설명에서 두 가지 다른 변경 사항을 적용하도록 지시하면 두 가지 모두에 집중하기가 어렵습니다. 따라서 입력에 여러 가지 다른 요청이 포함되어 있는 경우를 대비하여 각 사람의 입력을 여러 조각으로 나눕니다. LLM은 단일 프롬프트의 여러 문제에 비해 하나의 문제에 집중할 수 있을 때 가장 잘 작동합니다 지금은 매우 분명하지만 처음에는 GPT-4에 코드 주변에 로그를 추가하라고 지시하지 않았습니다. 이제 자세한 로깅을 사용하여 코드를 생성하므로 앱을 실행하고 오류가 발생할 때 GPT-4는 작성된 로그와 해당 로그가 코드의 어디에 있는지 확인할 때 훨씬 쉽게 디버깅할 수 있습니다. 자세한 로그 도움말 . 이것도 당연한 결론이지만 우리는 배워야만 했다. 코드가 몇 개의 큰 파일 대신 여러 파일로 분할되면 GPT-4가 기능을 구현하고 버그를 수정하는 것이 훨씬 쉽습니다. 우리 인간이 생각하는 것처럼 큰 코드보다는 작은 코드 덩어리를 처리하는 것이 훨씬 쉽습니다. 우리는 함수, 클래스 등 추상화 수준을 생성하여 이를 수행합니다. 코드베이스를 더 작은 파일로 나누는 것이 많은 도움이 됩니다 LLM이 보다 관리하기 쉬운 추상화를 생성하도록 하는 가장 쉬운 방법 중 하나는 더 많은 모듈식 코드를 생성하고 이를 더 많은 파일로 분할하도록 지시하는 것입니다. 놀랍도록 잘 작동하며 최종 결과는 우리 개발자에게도 더 좋습니다. . GPT Pilot의 목표는 모든 코딩 작업의 90%를 수행하고 나머지 10%를 사람에게 맡기는 것입니다. 이 10%는 일반적으로 LLM이 알아채기 힘든 수정 사항이나 작은 변경 사항으로 구성되지만 사람에게는 단순한 변경일 수 있습니다. 사람이 코드를 수정할 수 있으려면 작업에 작성된 내용과 그 뒤에 숨은 아이디어가 명확하게 표시되어야 합니다 그러나 문제는 무엇이 작동하지 않고 어떤 코드를 살펴봐야 하는지 인간에게 알려주기가 쉽지 않다는 것입니다. GPT 파일럿이 3,000줄의 코드를 작성하는 경우, 인간 개발자가 GPT 파일럿을 돕고 싶다면 실제 코드를 살펴보기 전에 전체 코드베이스를 이해해야 합니다. GPT 파일럿의 향후 버전에서는 인간 개발자가 현재 작업에 추가된 코드와 그 이유에 대해 자세히 설명할 것입니다. 이렇게 하면 GPT 파일럿을 도울 수 있습니다. . LLM은 인간이 가능한 모든 오류에 대해 생각하도록 하는 것보다 인간에게 질문하는 것이 더 좋습니다. 돌이켜보면 매우 당연한 일이지만, 우리가 알아차린 것 중 하나는 사람들이 제한 없는 피드백을 작성할 수 있는 개방형 입력 필드를 갖는 대신 GPT Pilot이 묻는 질문에 훨씬 더 기꺼이 답변한다는 것입니다. 인간은 게으르다 . 이것은 나에게 가장 큰 교훈 중 하나였습니다. 문제를 해결하는 데 이미 사용한 몇 가지 솔루션을 GPT-4에 제공하고 다른 솔루션을 생각하라고 지시하여 GPT-4에 메시지를 보낼 수 있다고 생각했습니다. 그러나 이는 말처럼 쉽지 않습니다. LLM이 고정관념에서 벗어나 생각하도록 하는 것은 어렵습니다 결국 우리가 한 일은 LLM에게 생각할 수 있는 모든 가능한 솔루션을 나열하고 이를 메모리에 저장하도록 요청하는 것이었습니다. 다른 것을 시도해야 할 때 대체 솔루션을 선택하고 다르지만 구체적인 솔루션을 시도하라고 지시했습니다. GPT 파일럿으로 생성된 앱 현재 GPT 파일럿을 사용하면 간단하지만 사소하지 않은 앱을 만들 수 있습니다. 또한 사람들이 GPT 파일럿을 사용하여 매우 인상적인 앱을 만드는 것을 보았습니다. 예를 들어 ResNet 모델을 미세 조정하여 야자수 수를 세고 이미지를 업로드할 때 그 안의 나무 수를 세는 앱이 있습니다. 다음은 코드, 통계 및 데모와 함께 우리가 만든 몇 가지 앱입니다. 프롬프트 랩( ) 데모 https://www.youtube.com/watch?v=UXhC4nx0pvs&embedable=true 이를 스테로이드의 OpenAI Playground로 생각하십시오. JSON 배열에서 대화를 로드하거나 수동으로 입력하고, LLM X와 대화를 여러 번 실행하고, 대화를 데이터베이스에 저장하고, 다시 로드할 수 있습니다. 실제로 프롬프트를 설계하고 그것이 어떻게 작동하는지 보고 싶을 때 이 앱을 사용합니다. 단일 프롬프트를 반복적으로 다시 실행하는 데 시간이 많이 걸리기 때문에 놀이터는 충분하지 않습니다. Prompt Lab을 사용하면 실행할 횟수를 선택하고 앱이 프롬프트를 반복적으로 실행하도록 할 수 있습니다. 완료되면 결과를 분석할 수 있습니다. 이는 AI 앱을 구축하고 프롬프트를 최적화해야 하는 사람들에게 유용할 수 있습니다. ⏳ 소요 시간: ~2일 💾 Github 저장소 ( ) SQLite 데이터베이스 분석 도구 데모 https://www.youtube.com/watch?v=gKgswTm5tFo&embedable=true 이는 또한 로컬 SQLite 데이터베이스를 분석하기 위해 내부적으로 사용하는 앱이기도 합니다. 이는 GPT 파일럿 데이터베이스 구조에 매우 특정한 형식으로 데이터베이스에서 데이터를 가져오지만 다른 구조에 맞게 쉽게 수정할 수 있습니다. SQLite 데이터베이스를 읽고 업로드하고, 행을 특정 필드로 분할하고, 행을 값으로 압축을 풀고, LLM 대화 데이터를 양식에 로드하고, 간단히 메시지 중 하나를 변경하고 LLM 요청을 GPT-4에 제출할 수 있습니다. 결과가 어떻게 보이는지 확인하세요. 이렇게 하면 GPT Pilot 상담원이 LLM과 나누는 대화를 분석하고 프롬프트가 다를 경우 어떤 일이 발생할지 쉽게 탐색할 수 있습니다. ⏳ 소요 시간: ~2일 💾 Github 저장소 코드 위스퍼러( ) 데모 https://www.youtube.com/watch?v=8qzq6F5DtyE&embedable=true Code Whisper는 우리가 선보일 예시로 만든 재미있는 프로젝트입니다. 아이디어는 이를 사용하여 코드베이스에 대한 LLM 질문을 할 수 있다는 것입니다. 공개 Github 저장소에 대한 링크를 붙여넣습니다. 그런 다음 리포지토리를 복제하고 분석을 위해 관련 파일을 LLM으로 보냅니다. LLM은 코드의 기능에 대한 각 파일에 대한 설명을 생성하고 해당 설명을 데이터베이스에 저장합니다. 그런 다음 앱에 코드베이스에 대한 질문을 하면 코드베이스에 응답이 표시됩니다. 이 데모에서는 GPT-3.5를 사용합니다. ⏳ 소요 시간: 7시간 💾 Github 저장소 스타 히스토리( ) 데모 https://www.youtube.com/watch?v=mjc4vnlLz3M&embedable=true 저는 수년 동안 오픈 소스 프로젝트를 출시해 왔으며 항상 의 다른 성공적인 리포지토리와 비교하여 내 Github 리포지토리가 얼마나 빨리 성장하는지 보고 싶었습니다. 문제는 Star History에서 그래프를 확대할 수 없기 때문에 별이 1,000개 있는 새 저장소는 처음에 더 큰 저장소가 어떻게 작동하는지 볼 수 없기 때문에 별이 50,000개 있는 큰 저장소와 비교할 수 없다는 것입니다. . https://star-history.com/ 그래서 저는 GPT Pilot에게 이 기능을 구축해 달라고 요청했습니다. Stargazers를 위한 Github 저장소를 긁어 데이터베이스에 저장하고 그래프에 플롯하며 그래프를 확대 및 축소할 수 있습니다. ⏳ 소요 시간: 6시간 💾 Github 저장소 결론 GPT 파일럿에서 다루는 현재 상태, 문제, 조사 결과에 대한 통찰력을 얻으셨기를 바랍니다. 요약하면 다음과 같습니다. 우리는 실제 AI 개발자 도구는 다음 요소를 기반으로 해야 한다고 생각합니다. AI를 감독하려면 인간이 필요합니다. 우리는 AI가 자신의 실수를 반복할 수 있도록 해야 합니다. 이는 LLM 위의 레이어에서 구현되어야 합니다. 소프트웨어 개발은 조정될 수 있으며 . AI 개발자는 실제로 코딩 과정이 직선이 아니기 때문에 코드베이스를 리팩터링할 수 있어야 합니다 지금까지 우리는 다음을 배웠습니다. 초기 앱 설명은 생각보다 훨씬 더 중요합니다. 코딩은 직선이 아니므로 상담원이 직접 검토할 수 있습니다. LLM은 단일 프롬프트의 여러 문제에 비해 하나의 문제에 집중할 때 가장 잘 작동합니다. 자세한 로그는 기적을 일으킵니다 코드베이스를 더 작은 파일로 분할하면 많은 도움이 됩니다. 사람이 코드를 고칠 수 있으려면 작성된 내용과 그 뒤에 숨은 아이디어가 명확하게 표시되어야 합니다. 인간은 게으르다 LLM이 고정관념에서 벗어나 생각하도록 하는 것은 어렵습니다. 어떻게 생각하나요? LLM과의 상호 작용에서 이러한 행동을 발견한 적이 있습니까? 아니면 이에 대해 다른 의견을 가지고 있습니까? 여러분의 의견을 매우 기쁘게 생각합니다. 아래에 의견을 남기거나 로 이메일을 보내주세요. zvonimir@gpt-pilot.ai 여기에서 GPT 파일럿을 사용하여 AI가 포함된 앱을 만들어 볼 수 있습니다. GPT 파일럿 오픈소스 저장소 GPT 파일럿 VS 코드 확장 이 게시물이 마음에 드셨다면 별표를 표시해 주시면 큰 의미가 있을 것입니다. 시도해 보시고 어떻게 생각하시는지 알려주세요. 귀하의 의견은 전체 GPT 파일럿 팀에 매우 중요합니다. GPT Pilot Github 저장소에 게시됨 여기에도