2,341 測定値

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

に Zvonimir13m2024/02/29

長すぎる; 読むには

最も強力な CodeGen 開発ツール GPT Pilot を 6 か月間使って私が学んだことは次のとおりです。 1. アプリの最初の説明は思ったよりもはるかに重要です 2. コーディングは直線ではありません。エージェントは自分自身でレビューできます。 3. LLM は、1 つのプロンプトで複数の問題を解決するよりも、1 つの問題に焦点を当てたときに最も効果的に機能します。 4. 詳細なログは奇跡を起こす 5. コードベースを小さなファイルに分割すると非常に役立ちます 6. 人間がコードを修正できるようにするには 7. 何が書かれているか、その背後にある考え方を明確に示さなければなりません 8. 人間は怠け者だ 9. LLM に既成概念にとらわれずに考えてもらうのは難しい

featured image - 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 には、タスクで何を行う必要があるか、およびこれまでに何が行われたかというコンテキストが含まれます。
AI は自らの間違いを繰り返すことができます。 ChatGPT のコード作成能力は、初めて何かのコーディングを依頼したときにどれだけうまく機能するかによって判断される人が多いと感じています。動作するコードが生成されない場合、多くの人はそれが印象的ではないと考えるでしょう。実際には、人間が最初の試行で機能するコードを書くことはほとんどありません。代わりに、コードを作成し、実行し、エラーを確認し、反復します。これはまさに、GPT Pilot によって GPT-4 が実行できることです。コードを作成した後、GPT Pilot はコードを実行し、出力を取得し、出力が正しいかどうか、何かを修正する必要があるかどうか、修正する必要があるかどうかを LLM に問い合わせることができます。。
ソフトウェア開発を調整できます。アプリを構築する際、すべての開発者が経験する繰り返しのルーチンが数多くあります。ルーチンの 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 を実行するなど)。
LLM は、1 つのプロンプトで複数の問題を解決するのではなく、1 つの問題に集中できる場合に最も効果的に機能します。たとえば、GPT Pilot に 1 つの説明で 2 つの異なる変更を加えるように指示した場合、両方に焦点を当てるのは困難になります。そのため、入力に複数の異なるリクエストが含まれている場合に備えて、人間による各入力を複数の部分に分割します。
詳細なログが役に立ちます。これは今では非常に明白ですが、当初はコードの周囲にログを追加するように 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 が尋ねた質問にはるかに喜んで答えようとするということでした。
LLM に既成概念にとらわれずに考えてもらうのは困難です。これは私にとって最大の学びの 1 つでした。私は、GPT-4 が問題を解決するためにすでに使用したいくつかの解決策を与えて、別の解決策を考えるように GPT-4 に指示できると考えました。ただし、これは思っているほど簡単ではありません。

私たちが最終的にやったことは、LLM に、考えられるすべての解決策をリストし、それらをメモリに保存するよう依頼することでした。何か別のことを試す必要があるとき、私たちは代替ソリューションを引き出し、別の具体的なソリューションを試すように指示しました。

GPT パイロットで作成されたアプリ

現在、GPT Pilot を使用して、シンプルではあるが重要なアプリを作成できます。また、GPT Pilot を使用して、ヤシの木を数えるように ResNet モデルを微調整し、画像をアップロードするとそこに含まれる木を数えるアプリなど、非常に印象的なアプリを作成している人も見かけました。ここでは、私たちが作成したいくつかのアプリと、コード、統計、デモを示します。

プロンプトラボ (デモ)

これを OpenAI Playground の強化版と考えてください。これにより、会話を JSON 配列から読み込むか、手動で入力し、LLM X 回会話を実行し、会話をデータベースに保存して、再度読み込むことができます。プロンプトを設計し、それがどのように動作するかを確認したいときに、実際にこのアプリを使用します。

プレイグラウンドは、単一のプロンプトを繰り返し再実行するのに時間がかかるため、十分ではありません。 Prompt Lab を使用すると、実行回数を選択して、アプリにプロンプトを繰り返し実行させることができます。

完了したら、結果を分析できます。これは、AI アプリを構築していて、プロンプトを最適化する必要がある人にとって役立つ可能性があります。

⏳ 所要時間: ~ 2 日
💾 Github リポジトリ

SQLite データベースアナライザーツール(デモ)

これは、ローカル SQLite データベースを分析するために内部で使用するアプリでもあります。 GPT Pilot データベース構造に非常に固有の形式でデータベースからデータを取得しますが、他の構造に合わせて簡単に変更できます。

SQLite データベースを読み取ってアップロードし、特定のフィールドで行を分割し、行を値に解凍し、LLM 会話データをフォームに読み込み、メッセージの 1 つを変更するだけで LLM リクエストを GPT-4 に送信できるようにします。結果がどのように表示されるかを確認します。

このようにして、GPT Pilot のエージェントと LLM との会話を分析し、プロンプトが異なる場合に何が起こるかを簡単に調査できます。

⏳ 所要時間: ~ 2 日
💾 Github リポジトリ

コードウィスパラー (デモ)

Code Whisper は、私たちが紹介するサンプルとして作成した楽しいプロジェクトです。これを使用して、コードベースについて LLM に質問できるという考えです。パブリック Github リポジトリへのリンクを貼り付けます。

次に、リポジトリのクローンを作成し、分析のために関連ファイルを LLM に送信します。LLM は、コードの動作に関する各ファイルの説明を作成し、それらの説明をデータベースに保存します。

その後、アプリにコードベースに関する質問をすると、コードベースから応答が表示されます。このデモでは GPT-3.5 を使用します。

⏳ 滞在時間: 7 時間
💾 Github リポジトリ

スターヒストリー (デモ)

私は何年もオープンソースプロジェクトをリリースしてきましたが、 https://star-history.com/にある他の成功したリポジトリと比較して、自分の Github リポジトリがどのくらいの速度で成長しているかを常に知りたいと思っていました。問題は、Star History ではグラフを拡大できないため、1,000 個のスターを持つ新しいリポジトリと 50,000 個のスターを持つ大きなリポジトリを比較することができないことです。なぜなら、より大きなリポジトリが最初にどのように動作するかを見ることができないからです。。

そこで、GPT Pilot にこの機能の構築を依頼しました。 Stargazer 用に Github リポジトリをスクレイピングし、それらをデータベースに保存し、グラフ上にプロットし、グラフをズームインおよびズームアウトできるようにします。