CodeGen 開発ツール (GPT パイロット) を 6 か月間使って学んだこと

過去 6 か月間、私は AI を使用してコーディングを実際にどの程度自動化できるかを理解するために GPT Pilot ( ) に取り組んできました。そこで、私たちが学んだことを共有したいと思いました。これまでのところ、そしてどこまで行くことができるか。 https://github.com/Pythagora-io/gpt-pilot GPT Pilot の構築を開始したとき、それがどのように構想されているかについて 書きました。ここで、修正された私の考え方を共有し、何がうまくいき、何がうまくいかなかったのかを見ていきたいと思います。 このブログ投稿を 最後に、GPT Pilot で作成されたアプリの例と、 AI ペア プログラマーとアプリを作成する方法を示します。 実際の GPT パイロットの背後にあるアイデアとは何ですか? GPT Pilot は 、 として想定されています。むしろ、アプリや機能をどのように構築するかについての計画を作成し、コーディングを開始するのは開発者です。コーディングのほとんどを自分で実行したいと考えていますが、行き詰まった場合、指定された要件についての説明が必要な場合、またはコードレビューが必要な場合は、助けを求めます。 、オートコンプリートやチャットボットではなく 現実の AI 開発者 AI はジュニア開発者のようなものですか?または… CodeGen GPT-4 ベースのツールが AI ジュニア開発者を構築していると謳っているのをよく見かけます。 どういうわけか、私はこの点について常に問題を抱えていました。ChatGPT をコーディングに使用すると、超上級者だけが与えることができる答えやアイデアが得られるからです。それは、若い開発者には絶対に理解できないものです。それでも、上級開発者とほぼ同じようにアプリを構築できる LLM はありませんが、コーディングに関して GPT-4 が持つ知識は、どのジュニア開発者よりもはるかに優れています。 GPT-4 はソフトウェア開発のあらゆる部分について非常に多くの知識を持っており、世界で最も上級の開発者であるにもかかわらず、金魚の記憶力を持っていると言えます。私がイメージするのは、部屋の真ん中に立って、一度に 1 つの小さな動作しか実行できない超人的なロボットですが、多くの動作を組み合わせて繰り返し動作することはできません。次に何をすべきかを正確に伝える必要があります。 これが GPT パイロットで私たちが目指していることです。私たちは、超人的なロボットが以前の動作を修正して継続的に動作できるようにする LLM の思考フレームワークを作成し、フィードバック ループを持ち、次に何をすべきかを決定したいと考えています。最終目標、つまり本番環境に対応したアプリケーションを構築することを完了します。 、GPT Pilot の構築の主な柱について概説しました。ただし、これらは私たちのチームの学習に基づいて少し変更されたため、改訂された柱は次のとおりです。 上記のブログ投稿で AI が十分ではないからだけでなく、実装後の動作や外観を変更したい場合もあります。開発者やプロダクト マネージャーが実装がどのようなものであるかを確認すると、それを変更することを決定するのが一般的です。 AI を監視するために人間が必要になるのは、 あるいは、当初予想していたよりも多くのエッジケースがあることに気づき、すべての問題を修正するよりも現在の実装をリファクタリングする方が簡単だと考える場合もあります。問題は、アプリ全体を完成させてからそれをリファクタリングしようとするときです。このときは、すべての変更が他のすべての機能に影響を与えるため、非常に困難になります。 一方、変更をコミットする前にリファクタリングを実行すると、適切に記述されたコードに基づいて次の機能に進むことができます。このため 。 、AI 開発者にとって、タスクが実装されるたびに人間が関与することが重要です このようにして、GPT Pilot が次のタスクに進む前に、人間は各タスクの実装を (PR をマージする前のコード レビューと同様に) レビューできます。人間が GPT Pilot に何が問題なのかを伝えれば、タスク自体の問題を修正するのがはるかに簡単になります。同時に、LLM には、タスクで何を行う必要があるか、およびこれまでに何が行われたかというコンテキストが含まれます。 ChatGPT のコード作成能力は、初めて何かのコーディングを依頼したときにどれだけうまく機能するかによって判断される人が多いと感じています。動作するコードが生成されない場合、多くの人はそれが印象的ではないと考えるでしょう。実際には、 。代わりに、コードを作成し、実行し、エラーを確認し、反復します。これはまさに、GPT Pilot によって GPT-4 が実行できることです。コードを作成した後、GPT Pilot はコードを実行し、出力を取得し、出力が正しいかどうか、何かを修正する必要があるかどうか、修正する必要があるかどうかを LLM に問い合わせることができます。 。 AI は自らの間違いを繰り返すことができます。 人間が最初の試行で機能するコードを書くことはほとんどありません 。アプリを構築する際、すべての開発者が経験する繰り返しのルーチンが数多くあります。ルーチンの 1 つは、コードの作成、実行、エラーの読み取り、コードの変更、再実行などです。もう 1 つのより高いレベルのルーチンには、タスクの取得、実装、実装のテスト (すべてのテストが合格するまで繰り返します) などがあります。 、レビューのために送信し、問題を修正し（レビュー担当者が承認するまで繰り返します）、デプロイします。これらのルーチンの多くは、ループ内にインテリジェントな意思決定者 (LLM など) がいる場合に調整できます。 ソフトウェア開発を調整できます 。 GPT Pilot の最初のバージョンを作成したとき、タスクを繰り返し、コードを実装し、修正して次に進む必要があると考えました。実際には、アプリのコーディングは継続的に進歩するわけではなく、常にコードを書き直すことになります。 コーディングのプロセスは直線的なものではありません 場合によっては、最初の実装後に、何かを実装するより良い方法があることに気付いたために、コードベースをリファクタリングすることがあります。また、要件の変更のためにそれを行う場合もあります。 #1 で述べたように、ソリューションが機能していないことがわかった後は、多くの変更をロールバックし、問題の代替ソリューションを検討し、その方法で解決してみる必要がある場合があります。 GPT Pilot やその他の AI 開発者を大規模に動作させるには、元に戻り、代替パスを選択し、タスクを再実装できるメカニズムが必要です。 私たちは何を学びましたか? 一般に、LLM は、どのように機能するか、何が改善できるか、適切なプロンプト エンジニアリングを行う方法など、誰もが理解しようとしている新しいテクノロジーです 。 。私たちのアプローチは、アプリケーション層の構築に取り組むのではなく、アプリケーション層の構築に重点を置くことです。 LLM はより良い結果を出力します その理由は、LLM は改善され、プロンプトの最適化に数週間を費やせば、GPT の新しいバージョンで完全に解決される可能性があるということです。 代わりに、ユーザー エクスペリエンスがどうあるべきか、LLM が継続的に動作できるように LLM を制御するためにどのメカニズムが必要かに焦点を当て、最終ソリューションにどんどん近づいています。これまでに私たちが学んだことは次のとおりです。 。私たちの当初の考えは、たとえ最初の説明が曖昧であっても、人間の入力があれば、GPT Pilot は正しい方向にナビゲートし、実用的なソリューションにどんどん近づくことができるだろうと考えていました。 アプリの最初の説明は、私たちが思っているよりもはるかに重要です ただし、GPT Pilot の考え方は、最初の説明から始まり、プロンプト全体にわたって分岐します。そのため、最初のプロンプトで何か誤解を招くような内容があった場合、GPT Pilot が持つ他の情報はすべて間違った方向に導かれてしまいます。したがって、それを後で修正すると、この間違った方法に深くハマってしまい、正しい道に進むことはほとんど不可能になります。 これを書いている今、それはとても明白なことのように思えますが、それは私たちが学ぶ必要があることであり、最初の説明にもっと焦点を当てる必要がありました。そこで、私たちは「Spec Writer」と呼ばれる新しいエージェントを構築しました。このエージェントは、コーディングを開始する前にプロジェクトの要件を詳細に分析するのに役立ちます。 。柱のセクションで前述したように、リファクタリングは常に行われており、GPT Pilot も同様に行う必要があります。この問題に対する解決策はまだ実装されていませんが、GPT Pilot にデシジョン ツリーの周囲にマーカーを作成する機能を追加することで機能する可能性があります。これにより、何かが機能しない場合は常にマーカーを確認し、どこに問題があるかを考えることができます。道を間違えた。 コーディングは直線ではありません 。私の考えは、エージェントが他のエージェントが行ったことをレビューする場合、それは同じ情報を再処理する同じ LLM であるため、冗長になるだろうと考えました。しかし、エージェントが別のエージェントの仕事をレビューすると、驚くほどうまく機能することがわかりました。コードの実装方法をレビューする 2 つの異なる「レビュー担当者」エージェントがいます。 エージェントは自分自身をレビューできます 1 つはタスク全体がどのように実装されたかなど、高レベルでそれを行い、もう 1 つはファイルに加えられる前に各変更をレビューします (git add -p を実行するなど)。 。たとえば、GPT Pilot に 1 つの説明で 2 つの異なる変更を加えるように指示した場合、両方に焦点を当てるのは困難になります。そのため、入力に複数の異なるリクエストが含まれている場合に備えて、人間による各入力を複数の部分に分割します。 LLM は、1 つのプロンプトで複数の問題を解決するのではなく、1 つの問題に集中できる場合に最も効果的に機能します 。これは今では非常に明白ですが、当初はコードの周囲にログを追加するように GPT-4 に指示していませんでした。現在、GPT-4 は詳細なログを含むコードを作成するため、アプリを実行してエラーが発生したときに、どのログが書き込まれたか、それらのログがコード内のどこにあるかを確認することで、デバッグがはるかに簡単になります。 詳細なログが役に立ちます 。これも当然の結論ですが、私たちはそれを学ばなければなりませんでした。コードをいくつかの大きなファイルに分割するのではなく、多くのファイルに分割すると、GPT-4 で機能を実装したりバグを修正したりするのがはるかに簡単になります。私たち人間が考えるのと同じように、大きなコードの塊よりも小さなコードの塊を処理する方がはるかに簡単です。これを行うには、関数、クラスなどの抽象化レベルを作成します。 コードベースを小さなファイルに分割すると、非常に役立ちます LLM に、より管理しやすい抽象化を作成させる最も簡単な方法の 1 つは、より多くのモジュール コードを作成し、それをより多くのファイルに分割するように LLM に指示することです。それは驚くほどうまく機能し、最終的な結果は私たち開発者にとってもより良いものになります。 。 GPT Pilot の目標は、すべてのコーディング タスクの 90% を実行し、残りの 10% を人間に任せることです。この 10% には通常、LLM が気づきにくい修正や小さな変更が含まれますが、人間にとっては単純な変更である可能性があります。 人間がコードを修正できるようにするには、タスクに何が書かれているか、その背後にある考え方を明確に示す必要があります ただし、問題は、何が機能していないのか、どのコードを調べるべきかを人間に伝えるのは簡単ではないことです。 GPT Pilot が 3,000 行のコードを作成する場合、人間の開発者が GPT Pilot を支援したい場合は、実際のコードに入る前にコードベース全体を理解する必要があります。 GPT Pilot の将来のバージョンでは、人間の開発者は、現在のタスクにどのようなコードが追加されているか、およびその背後にある理由について詳細な説明を得ることができます。こうすることで、GPT パイロットを助けることができるようになります。 。 LLM は、考えられるすべてのエラーについて人間に考えさせるよりも、人間に質問するほうがよいでしょう。繰り返しになりますが、振り返ってみると非常に明白ですが、私たちが気づいたことの 1 つは、人々は制約のないフィードバックを書き込める自由入力フィールドを用意する代わりに、GPT Pilot が尋ねた質問にはるかに喜んで答えようとするということでした。 人間は怠け者です 。これは私にとって最大の学びの 1 つでした。私は、GPT-4 が問題を解決するためにすでに使用したいくつかの解決策を与えて、別の解決策を考えるように GPT-4 に指示できると考えました。ただし、これは思っているほど簡単ではありません。 LLM に既成概念にとらわれずに考えてもらうのは困難です 私たちが最終的にやったことは、LLM に、考えられるすべての解決策をリストし、それらをメモリに保存するよう依頼することでした。何か別のことを試す必要があるとき、私たちは代替ソリューションを引き出し、別の具体的なソリューションを試すように指示しました。 GPT パイロットで作成されたアプリ 現在、GPT Pilot を使用して、シンプルではあるが重要なアプリを作成できます。また、GPT Pilot を使用して、ヤシの木を数えるように 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 Pilot データベース構造に非常に固有の形式でデータベースからデータを取得しますが、他の構造に合わせて簡単に変更できます。 SQLite データベースを読み取ってアップロードし、特定のフィールドで行を分割し、行を値に解凍し、LLM 会話データをフォームに読み込み、メッセージの 1 つを変更するだけで 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 にこの機能の構築を依頼しました。 Stargazer 用に Github リポジトリをスクレイピングし、それらをデータベースに保存し、グラフ上にプロットし、グラフをズームインおよびズームアウトできるようにします。 ⏳ 滞在時間: 6 時間 💾 Github リポジトリ 結論 GPT Pilot で取り組んでいる現状、問題点、調査結果について少しでも理解していただけたでしょうか。 つまり、要約すると次のようになります。 私たちは、真の AI 開発者ツールは次の柱に基づいている必要があると考えています。 AIを監視するには人間が必要です。 AI が自身の間違いを反復できるようにする必要があります。 、LLM 上のレイヤーに実装する必要があります。 ソフトウェア開発は調整可能であり 実際にはコーディング プロセスは直線ではないため、 。 AI 開発者はコードベースをリファクタリングできる必要があります これまでのところ、次のことがわかりました。 アプリの最初の説明は私たちが思っているよりもはるかに重要です コーディングは直線的ではありません。エージェントは自分自身でレビューできます LLM は、1 つのプロンプトで複数の問題を解決するのではなく、1 つの問題に焦点を当てた場合に最も効果的に機能します。 詳細なログは奇跡を起こします コードベースを小さなファイルに分割すると非常に役立ちます 人間がコードを修正できるようにするには 何が書かれているか、そしてその背後にある考え方を明確に示さなければなりません 人間は怠け者だ LLM に既成概念にとらわれずに考えてもらうのは難しい どう思いますか？ LLM とのやり取りの中でこれらの行動に気づいたことはありますか? あるいは、これらの行動について別の意見をお持ちですか? ご意見をお待ちしております。以下にコメントを残すか、 までメールをお送りください。 zvonimir@gpt-pilot.ai ここで GPT Pilot を使用して AI を使用したアプリの作成を試すことができます。 GPT パイロットのオープンソース リポジトリ GPT パイロット VS コード拡張 この投稿を気に入っていただけましたら、 スターを付けていただければ大変有意義です。また、試してみたら、ご意見をお聞かせください。あなたのフィードバックは GPT パイロット チーム全体にとって非常に重要です。 GPT Pilot Github リポジトリに でも公開されています ここ