[LLM 論文]アプリ全自動開発"ChatDev"の日本語訳
こちらで紹介された論文が面白かったのでChatGPTを使用して日本語に訳してみました。一語一句訳すというよりは小さく区切って分かりやすく要点をまとめてもらってます。
仮想のLLMチャット駆動型ソフトウェア開発会社「ChatDev」を設立し、さまざまな役割を持つエージェント達に仕事をサポートさせましょう。
— AIDB (@ai_database) August 30, 2023
北京大学などの研究グループにより開発されたアーキテクチャが公開されました。
○ Chen Qian et al. Communicative Agents for Software Development… pic.twitter.com/YWHquTSGtv
要約
ソフトウェアを作るのは難しい仕事で、経験や相談が必要です。でも、最近の深層学習の技術の進歩で、そのやり方が大きく変わりつつあります。今回の論文では、ソフトウェアを開発する過程全体で大規模な言語モデル（LLM）を使う新しい方法を提案しています。それにより、開発の各ステップで別々の技術やツールを使う必要がなくなります。
この新しい方法の中心は「CHATDEV」というシステムです。これは、ソフトウェアを作る過程を4つのステップ（設計、コーディング、テスト、説明書の作成）に分けて、それぞれのステップでチャットのようにコミュニケーションを取りながら進めていく仕組みです。これにより、ステップごとのタスクを小さく分けて、効率よく作業を進めることができます。
CHATDEVの実際の評価結果によれば、このシステムを使ってソフトウェアの開発を7分以内で、1ドル未満のコストで完了させることができました。このシステムは、ソフトウェアの問題点を早く見つけて修正するだけでなく、コストも抑えられるのが強みです。CHATDEVの可能性は、これからのソフトウェア開発の新しい方向性を示しています。このシステムの詳細は、指定されたGitHubのリンクで確認できます。
1, はじめに
「共同作業は、私たち一人ひとりが知ることができる以上のことを知る手助けとなる。共同作業により、異なる考え方ができ、普段手に入らない情報にアクセスでき、共通の目標に向かって一緒に取り組む中でアイディアを組み合わせることができる。」- Paul Solarz
ソフトウェアを作るためには、計画的で厳格な手法が必要です[4]。しかし、ソフトウェアを作る際の複雑さから、経験を持つ開発者との短い相談や直感に基づいて決断を下すことがよくあります[14]。深層学習の新しい技術の進展により、その技術をソフトウェア作成にどう適用するか研究が進められており、その効果や効率、コスト削減の面での改善を目指しています。これまでの研究では、ソフトウェアの要件定義、設計、実装、テスト、メンテナンスといったさまざまなタスクに関しての取り組みが行われてきました[34; 29]。ソフトウェアを開発する過程は、役割の調整、タスクの割り当て、コードの作成、システムのテスト、ドキュメントの準備など、多くのステップが含まれます。これは、開発サイクルが長いため、細部に注意を払う必要がある複雑な作業です[17; 4]。
近年、大規模な言語モデル（LLM）は、自然言語処理（NLP）[5]やコンピュータビジョン（CV）[35]の分野で注目される成果を上げています。巨大なデータセットでの学習を経て、LLMは質問応答や機械翻訳、コード生成などのタスクで驚異的なパフォーマンスを示しています。実際、ソフトウェア開発の中心となるコードやドキュメントは、言語（文字の並び）として考えることができます[7]。この観点から、この論文ではLLMを駆使したソフトウェア開発の一貫したフレームワークを探求しています。これには、要件の分析、コードの開発、システムのテスト、ドキュメントの生成が含まれ、ソフトウェア開発のための統一的で効率的でコスト効果の高い方法を提供することを目指しています。
しかし、LLMだけを使ってソフトウェアシステム全体を生成することは、コードに誤りや不足が生じるリスクがあります。これは、自然言語の知識を問い合わせる際に「幻覚」と呼ばれる現象に似ています[2]。この幻覚には、機能の不完全な実装や依存関係の欠如、発見されていないバグなどが含まれます。このような幻覚が生じる主な理由は、LLMがソフトウェアシステムを一度に生成する際のタスクの具体性の欠如や、意思決定過程での十分な検討の欠如にあります[9]。各モデルのインスタンスは異なる答えを提案するため、他のモデルのインスタンスからのレスポンスを検討し、正確な答えに収束する必要があります[12]。これには、コードの査読やフィードバックの提案などが含まれます。
先述の問題点に対処するため、私たちはCHATDEVという仮想のチャット駆動型ソフトウェア技術会社を設立しました。この会社は古典的なウォーターフォールモデル[3]に従い、設計、コーディング、テスト、ドキュメンテーションの4つのフェーズにプロセスを分けています。各フェーズで、CHATDEVはプログラマーやレビュアー、テスターといった異なる役割を持つエージェントを募集します。効果的なコミュニケーションと協力を促進するため、CHATDEVは各フェーズを原子的なサブタスクに分けるチャットチェーンを使用します。このチェーン内で、各ノードは特定のサブタスクを表し、2つの役割がコンテキストに応じた多回転の議論を持ちながら解決策を提案し、検証します。このアプローチにより、クライアントの要件が分析され、クリエイティブなアイディアが生み出され、プロトタイプシステムが設計・実装され、潜在的な問題が特定・対処され、デバッグ情報が説明され、魅力的なグラフィックが作成され、ユーザーマニュアルが生成されます。このチャットチェーンに沿ってソフトウェア開発プロセスを進めることで、CHATDEVはユーザーに最終的なソフトウェアを提供します。これにはソースコード、依存環境の仕様、ユーザーマニュアルが含まれます。
実験では、70のユーザー要件に応じてCHATDEVによって生成されたすべてのソフトウェアを分析しました。平均して、CHATDEVはソフトウェアごとに17.04のファイルを生成し、コードの幻覚によって引き起こされる潜在的なコードの脆弱性を13.23回軽減しました。ソフトウェアの製造時間は409.84秒で、製造コストは$0.2967でした。レビュアーとプログラマーの間の議論により、約20種類のコードの脆弱性が特定・修正されました。一方、テスターとプログラマーの間の議論により、10種類以上の潜在的なバグが特定・解決されました。まとめると、私たちの主な貢献は以下の通りです：
CHATDEVを提案しました。これはチャットベースのソフトウェア開発フレームワークです。タスクを指定するだけで、CHATDEVは設計、コーディング、テスト、ドキュメンテーションを順次処理します。この新しいパラダイムは、言語コミュニケーションを通じて主要なプロセスを統一し、各フェーズでの専門的なモデルの必要性を排除することでソフトウェア開発を簡素化します。
開発プロセスを逐次的な原子的なサブタスクに分解するためのチャットチェーンを提案します。各サブタスクでは、2つの役割の間で共同作業と相互調査が必要です。このフレームワークは、複数のエージェントの協力、中間出力のユーザー検査、エラー診断、および推論介入を可能にします。それは各チャット内の特定のサブタスクに対する詳細な焦点を確保し、効果的な協力を促進し、所望の出力の達成を促進します。
コードの幻覚に関連する潜在的な課題をさらに軽減するために、コードの完成、レビュー、およびテスト中の各独立したチャットプロセスにおいて思考指示メカニズムを導入します。『役割の反転』を実行することで、指示者はコードの変更のための特定の考えを明示的に注入し、アシスタントプログラマーをより正確に指導します。
実験は、CHATDEVの自動ソフトウェア開発プロセスの効率とコスト効果を示しています。各チャットの役割間での効果的なコミュニケーション、提案、および相互試験を通じて、フレームワークは効果的な意思決定を可能にします。
2, CHATDEV
LLMs（大規模言語モデル）を自然言語クエリングに使用する際に遭遇する幻覚と同様に、LLMsを直接使用してソフトウェアシステム全体を生成すると、実装の不完全さや欠落している依存関係、未発見のバグなど、重大なコードの幻覚が発生することがあります。これは、タスクの明確さが欠けていることや意思決定における相互試験の不在に起因する可能性があります。この制限を克服するために、図1に示されているように、私たちはCHATDEVという仮想のチャット駆動型ソフトウェア技術会社を設立しました。これには、幹部やプロのプログラマー、テストエンジニア、アートデザイナーなど、多様な社会的背景を持つエージェントが含まれます。タスクが提示されると、CHATDEVの多様なエージェントが協力して、実行可能なシステム、環境ガイドライン、ユーザーマニュアルを含む必要なソフトウェアを開発します。このアプローチは、大規模言語モデルを中心とした思考コンポーネントを活用することに焦点を当てており、エージェントがソフトウェア開発プロセス全体をシミュレートすることが可能となります。これにより、追加のモデルトレーニングの必要性を回避し、望ましくないコードの幻覚をある程度軽減することができます。
2.1 チャットチェーン
CHATDEVは、ソフトウェア開発の一般的な手法であるウォーターフォールモデルを採用しています。このモデルでは、ソフトウェア開発プロセスを「設計」「コーディング」「テスト」「文書化」の4つの明確なフェーズに分けます。設計フェーズでは、アイデアをブレインストーミングで生み出し、技術的な要件を定義します。コーディングフェーズでは、ソースコードの開発とレビューが行われ、テストフェーズでは全てのコンポーネントを統合し、インタープリタからのフィードバックを使用してデバッグします。文書化フェーズでは、環境の仕様やユーザーマニュアルが生成されます。これらの各フェーズは、多くの役割間での効果的なコミュニケーションを必要としますが、どのように進行し誰と連携するかを決定するのは難しいことがあります。
この問題を解決するため、各フェーズを具体的なチャットに分解し、2つの明確な役割を持つタスク指向のロールプレイに特化させる一般的なアーキテクチャを提案します。参加するエージェント間の指示と協力を通じて、各チャットの目的の出力が得られます。このプロセスの例は図2に示されており、中間タスクを解決する一連のチャット、つまり「チャットチェーン」が表示されています。各チャットでは、指導者が指示を開始し、アシスタントがそれに従って適切な解決策を提供し、実行可能性についての議論を行います。双方は複数回の対話を通じて合意に達するまで協力し、タスクが成功裏に完了したと判断します。
チャットチェーンにより、ソフトウェア開発プロセスが透明になり、意思決定の道のりやエラーが発生した際のデバッグの機会が明らかになります。これにより、ユーザーは中間の出力を検査したり、エラーの診断や必要に応じて推論プロセスに介入することができます。さらに、チャットチェーンは各フェーズの特定のサブタスクに焦点を当てることで、効果的な協力を促進し、望ましい出力の達成を促進します。
2.2 デザインフェーズ
デザイン段階では、CHATDEVは人間のクライアントから初期のアイディアを受け取ります。このフェーズには、CEO（最高経営責任者）、CPO（最高製品責任者）、CTO（最高技術責任者）という3つの事前定義された役割が含まれます。チャットチェーンは、デザインフェーズを連続する原子的なチャットタスクに分解します。これには、目標とするソフトウェアのモダリティ（CEOとCPO）およびプログラミング言語（CEOとCTO）に関する決定が含まれます。
ロールの割り当てについて(このセクションの数式は正しく翻訳できてないかも)
システムプロンプト/メッセージ:
この方法では、エージェントに役割を割り当てるために、システムプロンプトやメッセージが使用されます。
ロールプレイングの初期設定:
他の会話型の言語モデルとは異なり、ロールプレイングのシナリオを開始するためだけにプロンプトの技術を使用しています。
指導者は`PI`として示され、アシスタントは`PA`として示されます。
対話が開始する前に、これらのプロンプトを使用してエージェントに役割が割り当てられます。
LIとLAモデル:
これらは大規模な言語モデルを示し、それぞれ指導者とアシスタントのエージェントとして機能します。
役割の特化:
このフレームワークでは、指導者は初めにCEOとして行動し、アシスタントはCPOとしてタスクを実行し、応答を提供します。
エージェントが役割を適切に果たすために、特定のプロンプト技術を使用しています。
これらのプロンプトには、指定されたタスクや役割、通信プロトコル、終了条件など、重要な詳細が含まれています。
不望ましい振る舞いの防止:
プロンプトには、冗長な指示、情報のない応答、無限ループなど、不望ましい振る舞いを防ぐための制約も含まれています。
エージェント間の対話の中で、特定の役割とタスクを効果的に管理するために、これらのロールの割り当てとプロンプトの仕組みが使用されています。
メモリストリームについて
メモリストリームは、エージェントが過去の会話を記録して保持するシステムのことです。このシステムを使用することで、エージェントは以前の対話を参考にして、新しい問題や指示に効果的に対応することができます。
構造:
時点`t`での指導者のメッセージは`It`として示され、アシスタントのメッセージは`At`として示されます。
これらの会話の集合は、`Mt`というリストで保持されます。`Mt`は、過去から現在までのすべての会話を時系列に記録しています。
次のステップ:
新しい指示や応答を生成する際、エージェントはこの`Mt`を参考にします。
指導者は`Mt`を基に新しい指示`It+1`を提供します。アシスタントは、この指示と`Mt`を参考にして応答`At+1`を生成します。
メモリの更新:
新しい指示や応答が生成された後、これらは`Mt`リストに追加され、メモリが更新されます。
通信の終了:
特定の条件（例:「<MODALITY>: Desktop Application」のような形式）が満たされたとき、エージェント間の会話は終了します。このようなフォーマットに従うことで、エージェント間の合意が達成されたことが確認できます。
このようなシステムを使用することで、エージェントは過去の情報を活用して、新しい問題や指示に迅速かつ効果的に対応することができます。また、過去のエラーや課題を繰り返さないようにするための参照としても役立ちます。
セルフリフレクションについて
問題の背景:
ときどき、両方のエージェントが合意に達しても、予め定義された通信プロトコルの終了条件を引き起こさない対話が観察されます。
セルフリフレクションのメカニズム:
このような場合、思い出を抽出して取り出すセルフリフレクションというメカニズムを導入します。
「疑似セルフ」としての新しい質問者:
実装するために、新しい質問者として「疑似セルフ」を用意します。
この疑似の質問者は、前の対話からのすべての歴史的記録を現在のアシスタントに伝え、対話からの結論的な情報の要約を要求します。
リフレクションの効果:
このメカニズムにより、アシスタントは対話中に提案され、議論された決定について反省することが励まされます。
このセルフリフレクションのメカニズムは、エージェントが以前の対話から得られた情報を効果的に再評価し、合意に達した内容をしっかりと確認するためのものです。
2.3 コーディング
役割の定義:
- コーディングのフェーズでは、CTO、プログラマ、およびアートデザイナーの3つの役割が定義されています。
- このフェーズは、完全なコードの生成やグラフィカルユーザーインターフェース (GUI) の設計など、連続的なチャットタスクに分解されます。
CTOの指示:
- 前のフェーズで議論された主要な設計に基づき、CTOはmarkdown形式を使用してプログラマにソフトウェアシステムを実装するよう指示します。
デザイナーの役割:
- デザイナーは、テキストベースのコマンドの代わりにユーザーインタラクションのためのグラフィカルなアイコンを使用したユーザーフレンドリーなGUIを提案します。
- その後、外部のテキストからイメージに変換するツールを使用して視覚的に魅力的なグラフィックスを作成します。
コード管理:
- CHATDEVは、Pythonのようなオブジェクト指向のプログラミング言語を使用して複雑なソフトウェアシステムを取り扱います。
- オブジェクト指向のモジュール性は、問題解決や共同開発を支援します。
- 「バージョン進化」というメカニズムは、役割間での最新のコードバージョンの可視性を制限し、古いコードバージョンをメモリストリームから削除します。
- プログラマはGit関連のコマンドを使用してプロジェクトを管理します。提案されたコードの変更は、ソフトウェアバージョンを1.0増加させます。
考えの指示 (Thought Instruction)
背景:
伝統的な質問応答は、特にコード生成において、単純な指示が予期しない誤解を生む可能性があります。例えば、全ての未実装のメソッドを実装するようにプログラマに指示すると、実装されていないインターフェースとして予約されたメソッドが含まれるなどの問題が発生する可能性があります。
提案される解決策:
これを解決するために、「考えの指示」というメカニズムを提案します。これは、[44]のchain-of-thought promptingに触発されたものです。
この方法では、具体的な問題解決の考え方を指示に明示的に取り入れることで、順序立てて部分タスクを解決するのに似ています。
手法の詳細:
Figure 4(a)および4(b)に示されるように、考えの指示は、まだ実装されていないメソッドについて問い合わせるための役割の交代を含み、その後、プログラマにもっと正確な指示を提供するために役割を元に戻します。
考えの指示を取り入れることで、コーディングプロセスがより集中的かつ目的指向になります。
利点:
指示の中で具体的な考え方を明示的に表現することで、曖昧さを減少させ、生成されるコードが意図された目的と整合性を持つようにします。
このメカニズムにより、コードの完成に対するより正確で文脈認識のあるアプローチが可能となり、誤解の発生を最小限に抑え、より信頼性の高い包括的なコード出力が得られます。
2.4 テスト
背景:
人間のプログラマであっても、最初に書いたコードが常にエラーがないわけではありません。エラーコードを直ちに破棄するのではなく、人間は通常、コードの実行結果を分析・調査し、実装エラーを特定・修正します [8]。
CHATDEVにおけるテスト:
テストフェーズでは、3つの役割があります：プログラマ、レビュアー、テスター。
プロセスは、ピアレビュー (プログラマとレビュアー間) とシステムテスト (プログラマとテスター間) という、順番に行われるチャットタスクから成り立っています。
ピアレビューは、ソースコードを調査して潜在的な問題を特定する手法です。
システムテストは、プログラマがインタープリタを使用してテストを実行することでソフトウェアの実行を確認するものです。このテストは、ブラックボックステストを通じてアプリケーションのパフォーマンスを評価することに重点を置いています。
課題と解決策:
２つのエージェントがインタープリタからのフィードバックメッセージのみでコミュニケーションすると、バグのないシステムが得られるわけではありません。プログラマの変更がフィードバックに厳密に従わないことがあるため、誤解が生じる可能性があります。
これに対処するために、デバッグの考えを指示に明示的に表現するための「考えの指示」メカニズムをさらに採用しています。
テスターはソフトウェアを実行し、バグを分析し、修正を提案し、プログラマに指示を出します。この反復プロセスは、潜在的なバグが排除され、システムが成功裏に動作するまで続けられます。
人間のクライアントの関与:
細かい論理的な問題を特定するのが難しい場合、ソフトウェアテストに人間のクライアントの関与がオプションとなります。
CHATDEVは、人間のクライアントに、レビュアーやテスターと同様に、ブラックボックステストや他の戦略を使用して、自然言語でフィードバックや提案を提供することを可能にします。CHATDEVは、人間からの入力に基づいて、このフィードバックを理解し利用して、ソフトウェアシステムを洗練させます。
2.5 ドキュメント作成
背景:
設計、コーディング、テストのフェーズが終了した後、CHATDEVはソフトウェアプロジェクトのドキュメントを生成するために四つのエージェント（CEO、CPO、CTO、プログラマ）を活用します。
ドキュメント生成の手法:
大規模な言語モデルを用いて、文書生成のためのin-contextの例を使ったfew-shot prompting [5] を利用します。
役割分担:
CTOは、環境依存性のための設定指示を提供するようプログラマに指示します。その結果、requirements.txtのようなドキュメントが生成されます。このドキュメントは、ユーザが独立して環境を設定できるようにします。
同時に、CEOは要件とシステム設計をCPOに伝え、CPOはユーザーマニュアルを生成します。
3. 実験
使用モデル:
実験では、ChatGPTの「gpt3.5-turbo-16k」バージョンを使用して、複数のエージェントによるソフトウェア開発をシミュレートします。
言語モデルの設定:
言語モデルの温度は、コントロールされた生成のために0.2に設定されています。
コーディングフェーズ:
コード完成のために最大5回の試行を許可します。
レビュアーは、修正を提案するために最大5回のチャットを許可されています。
テスティングフェーズでは、ソフトウェアシステムのテストを最大5回実施します。
インタープリタ:
Pythonベースのシステムのテストには、Python 3.8.16を使用します。
データセット:
Camel [23] は、20のプログラミング言語、50のドメイン、そしてドメインごとに50のタスクを網羅する指示に従った対話データセットをまとめています。
この広範なタスクセットから、具体的なケースと比較的抽象的なケースを含む70のタスクをランダムに選択し、CHATDEVソフトウェア開発の分析の基礎として使用しました。
ソフトウェア統計
概要:
CHATDEVによって生成されたソフトウェアシステムの統計分析を行いました。
対話ターンの総数、使用されたトークン、ソフトウェアファイル、イメージアセット、バージョンの更新などの主要な指標を調査しました。
分析の内容:
この統計分析は、バージョン管理、ファイル構成、コードの複雑さ、開発の反復などの側面を網羅して、CHATDEVの開発の包括的な概要を提供しています。
ソフトウェアの構成:
生成されたソフトウェアは、通常、2から8のコードファイルを含んでおり、平均で4.26のファイルがあります。
アートデザイナーが外部ツール[35]を使用して作成したアセットファイルは、0から21の範囲で、平均で8.74のファイルがあります。
例: プログラマーがデザイナーにイメージを作成するように依頼する簡潔なテキストの説明は、次のようなものがあります:「ユーザーがデータを入力できるテキストエントリフィールド」、「金融ダッシュボードの背景画像」、「ゲーム内のプレイヤーキャラクターを表す画像」。
ソフトウェアには、依存関係の要件仕様、ユーザーマニュアル、開発ログ、ソフトウェアのメタ情報など、平均して4〜5のドキュメントファイルが付属しています。
コードの行数:
通常、39から359行の間で、平均で131.61行です。
CHATDEVは比較的小規模なコードを生成する傾向があります。これは、オブジェクト指向プログラミングの設計により、継承を通じてコードを再利用することができ、冗長性を減少させるためです。
より非具体的なタスクを指定した場合、生成されるソースコードは平均で約110.97行となり、短くなる傾向があります。
依存関係:
環境の依存関係の数は、平均で2.90で、1から5の範囲です。
CHATDEVのソフトウェア環境には、numpy、matplotlib、pandas、tkinter、pillow、flaskなどが含まれています。
ユーザーマニュアル:
ユーザーマニュアルは、平均で53.96行、31から232行の範囲です。
通常、ユーザーマニュアルには、導入、クイックインストール、主要機能、使用方法などのセクションが含まれています。
バージョンの更新:
ソフトウェアのバージョン更新の数は、平均で13.23、5から42の範囲です。これはソースコードが平均で約13回の修正を受けることを示しています。
実行の成功率:
生成されたソフトウェアの約86.66%が完璧に実行され、開発されたソフトウェアの堅牢性と信頼性を示しています。しかしながら、13.33%のソフトウェアで実行の失敗が見られました。
失敗の主な要因は、APIのトークン長制限と外部依存関係の問題でした。
結論:
小さな失敗の割合にもかかわらず、実験結果はCHATDEVの実行可能なソフトウェアシステムを生成する実現可能性と効果を示しています。
ソフトウェア制作時間の分析
CHATDEVを使用したさまざまなリクエストプロンプトのソフトウェア制作時間を調査するために時間分析を行いました。
開発時間の変動は、割り当てられたタスクの複雑さと明確さの違いを反映しています。
最も長いソフトウェア制作時間は1030.00秒で、これはレビュアーとプログラマーの間の詳細なコミュニケーションに起因するものでした。
対照的に、最も短いソフトウェア開発時間は169.00秒でした。この短時間は、重要なバグが少なく、コーディングとテストの段階での対話が少なかったためです。
平均的に、CHATDEVを使用した小規模ソフトウェアやインターフェイスの開発には409.84秒、つまり7.00分未満かかりました。これは、伝統的なカスタムソフトウェア開発サイクルと比較して非常に短いです。
対話の統計
CHATDEVでは、ソフトウェア開発を促進するためにチャットチェーン機構を採用しています。
各チャットチェーンは、特定のタスクのソフトウェアの制作を示し、複数の多発話チャットラウンドで構成されています。
エージェントは、言語の選択、解決策の提案、最終的な決定などの予め定義されたサブタスクを処理するために議論に参加します。
サブタスクをすべて完了すると、チャットチェーンはソフトウェア製品の開発で終わります。
我々は、対話の中で感謝の表現が繰り返される場合があることに気付きましたが、これは最終結果に大きな影響を及ぼすものではありません。
セルフリフレクションメカニズムを使用することで、エージェントはテキスト要約のような能力を使用して、対話から意思決定結果や結論を抽出することができます。
APIの利用とトークンの使用に関する情報
平均的に、CHATDEVは1つのソフトウェアを開発するのに36,902.23のプロンプトトークン、11,567.37の完了トークン、合計で48,469.60のトークンを必要とします。
ソフトウェアの生産における平均的な総コストは約$0.15693です。
CHATDEVでのソフトウェア開発の総コストを決定するために、デザイナーが作成した画像のコストも考慮します。平均的なデザイナーコストは、平均して8.74のグラフィックス作成が含まれるソフトウェア生産ごとにソフトウェアあたり$0.1398です。
そのため、CHATDEVでのソフトウェア開発の平均コストは$0.2967であり、これは伝統的なカスタムソフトウェア開発企業の経費よりもかなり低いです。
レビュアーとプログラマーの対話の分析
このセクションでは、コーディングフェーズ中にコード関連の問題についてレビュアーとプログラマーの間で行われる主要な対話を詳しく調査します。
レビュアーがコーディング段階でのプログラマーのソースコードを評価した結果をまとめています。
Figure 7では、レビュアーの提案内容を円グラフで視覚的に示しています。
この図に示されているように、コードレビュー中のレビュアーとプログラマーのコミュニケーションで最も頻繁に議論される問題は、「実装されていないメソッド」で、その割合は34.85%です。
この問題は、コアの機能がPythonの「pass」のようなプレースホルダーラベルを受け取り、さらに完成する必要がある複雑なモデルのコード生成で一般的に生じます。
また、「インポートされていないモジュール」のトピックも頻繁に取り上げられる問題で、19.70%の割合で発生します。
この問題は、生成されたコードが細かい詳細を見逃す傾向にあるコード生成の性質から生じます。
ただし、コード生成の文脈では、コードの実行可能性を確保することが非常に重要です。
幸いにも、この論文で提案されている指示メカニズムは、これらの問題に効果的に対処するために、レビュアーに不完全なメソッドを特定するように指示し、プログラマーにそれらを補完するように要求します。
このメカニズムは、大きなモデルに基づいてタスクが完了しているが、一部が欠落している他のシナリオにも適用できます。
興味深いことに、レビュアーはコードの堅牢性の重要性を強調しています。
未来の潜在的な例外の取り扱いについての考慮事項を強調し、重複カテゴリの回避に関するヒントを提供しています（3.03%）。
さらに、レビュアーはコード内の未使用のクラスに関する提案を提供し（1.52%）、無限ループを特定し（1.52%）、適切な環境初期化の必要性を強調しています（1.52%）。
テスターとプログラマーの対話分析
このセクションでは、テスティングフェーズ中にテスターとプログラマーの間で行われるデバッグ対話を分析し、遭遇した主要なバグのタイプをカテゴリー別にまとめます。
結果はFigure 8に示されています。
この図からわかるように、テスターとプログラマーの間での最も頻繁なデバッグ問題は「モジュールが見つからない」で、ケースの約45.76%を占めています。
これは、モデルが非常に細かい詳細を見逃す傾向があることを反映しています。
幸い、この論文で提案されている指示メカニズムを使用することで、このようなバグは、必要なクラスやメソッドをインポートすることで簡単に解決できることが多いです。
二番目に一般的なエラーのタイプは「アトリビュートエラー」と「未知のオプション」で、それぞれがケースの15.25%を占めています。
「アトリビュートエラー」は、クラスの属性の使用に関するエラーを指します。
「未知のオプション」は、メソッド呼び出しのパラメータに関するエラーを示します。
また、「インポートエラー」というエラータイプもあり、これは「モジュールが見つからない」と似ており、インポートステートメントのミス、例えば間違ったクラスのインポートや間違ったインポートパスの使用によって主に引き起こされます。
これらの一般的なエラータイプに加えて、CHATDEVは、不適切に初期化されたGUI（5.08%）、誤ったメソッド呼び出し（1.69%）、不足しているファイルの依存関係（1.69%）、未使用のモジュール（1.69%）、デコレータの構文エラー（1.69%）など、比較的まれなエラータイプも検出する能力を持っています。
ケーススタディ
Figure 9では、CHATDEVが五目並べ（別名「五連勝」や「Gobang」としても知られる）のゲームを開発する例を示しています。
左側には、GUIを持たない単純なソフトウェアで作成された結果が表示されています。このバージョンのゲームはコマンド端末を通してしかプレイできず、その対話性や全体的な楽しさが限られています。
対照的に、GUIのデザインを取り入れることで、CHATDEVは視覚的に魅力的な小さなゲームを作成することができます。このバージョンは、対話性やユーザーエクスペリエンスの面でインターフェースのないバージョンを上回っており、より楽しく、魅力的なゲームプレイの環境を提供します。
さらに、CHATDEVのデザイナーは、機能性を損なうことなく、GUIの美しさと使いやすさを向上させるための追加のグラフィックスを作成するためにプログラマーを支援することができます。これらのグラフィックスは、デザイナーが丁寧に作成したものであり、GUIをより視覚的に魅力的でユーザーフレンドリーにするために貢献しています。
また、人間のユーザーがアートデザイナーが作成した画像に満足していない場合、CHATDEVがソフトウェアを完成させた後、元の画像を手動で置き換える柔軟性があります。これにより、ソフトウェアのコアな機能性に影響を与えることなく、ユーザーの好みに合わせてさらにカスタマイズすることができます。ユーザーは、視覚的な要素を自分の好みに合わせて調整することができ、個々の好みに合わせたパーソナライズされたソフトウェア体験を得ることができます。
より包括的な理解のために、設計時にプログラミング言語の選択を行うダイアログプロセスを例示しています。五目並べのゲームのチャットチェーンから抽出されたさらなる例示的な対話は、Appendix Aに示されており、我々が設計したプロンプトや各フェーズでのエージェント間の対話プロセスが含まれています。スペースの制約のため、対話中の主要な情報のみを表示し、細かすぎる詳細は省略していることに注意してください。
4. 議論
CHATDEVは革新的なソフトウェア開発方法を提供しますが、潜在的なリスクや制約が存在することを認識しています。
一貫性のない出力：大規模言語モデルの温度パラメータを非常に低い値に設定しても、生成された出力に固有のランダム性があることが観察されます。このため、この技術は、バリエーションが許容されるオープンで創造的なソフトウェア生産シナリオに最適です。
デザイナーエージェント：このエージェントは画像を生成できるが、必ずしもGUIの美学を向上させるわけではない。一貫性のない画像生成がユーザーエクスペリエンスを損なう可能性がある。
バイアスの問題：大規模言語モデルは固有のバイアスを持ち、現実のプログラマーの問題解決の考え方と必ずしも一致しないコードパターンを生成する可能性がある。
リスク：大規模言語モデルは有害な使用を完全に回避するようには調整されておらず、悪意のあるユーザーによる悪用が考えられる。さらに、生成されたソフトウェアは、敏感なファイル操作の悪意のある意図の識別を欠いている。
CHATDEVの評価：生成されるタスクの範囲と多様性が広いため、多くのドメイン専門家の積極的な参加が必要です。
制約：このシステムで高レベルや大規模なソフトウェア要件の完璧なソースコードを生成することは困難である。エージェントは具体的な実装の詳細を自律的に決定する能力に制約があるため、長い議論が必要となることが多い。大規模なソフトウェア開発は、レビュアーやテスターにとっても挑戦的です。
5. 関連研究
ディープラーニングに基づくソフトウェアエンジニアリング
ソフトウェアエンジニアリングは、ソフトウェアの設計、開発、テスト、維持を方法的、厳格、計測可能な方法で行うプロセスです。
ディープラーニングの技術が急速に進展しており、多くの研究者がこれをソフトウェアエンジニアリングに適用して効果と効率を向上させています。
現存するDLベースのSE作業は、ソフトウェアエンジニアリングのライフサイクルの5つのステージに分けて焦点を当てています。
これらのアプローチは分断されており、ソフトウェアエンジニアリングの全手順を完了することはできません。また、これらの方法は大量の特定のタスクに特化したトレーニングデータを必要とします。
マルチエージェントの協力
大規模言語モデルは多くのドメインで驚くべき能力を示しています。
最近の研究では、いくつかの目的を達成するためにLLMs間の相互作用を利用することが探求されています。
行動シミュレーション: 複数のエージェントを使用して人間の行動をシミュレートします。
データ構築: 異なる役割を持つエージェントを使って、多者間の会話を収集・評価する。
性能向上: 複数のエージェントを利用して、性能を向上させたり、問題を解決する。
これらの研究は、異なる役割や能力を持つエージェントが複雑なタスクや問題を効果的に処理する能力を強化することを示唆しています。
6. 結論
本研究では、ソフトウェア開発プロセスに関与する複数の役割間での効果的なコミュニケーションと協力を促進するためにLLMsを活用した、チャットベースのエンドツーエンドのソフトウェア開発フレームワーク、CHATDEVを紹介しました。
チャットチェーンを使用して開発プロセスを連続的な原子的なサブタスクに分解することで、各サブタスクに対する詳細な焦点と望ましい出力を促進します。
コード補完、レビュー、テストの間に特定のコード修正を通じてプログラマを導くことで、コードの幻覚に関連する課題を軽減します。
複数の異なる役割を持つエージェントを採用することで、新しいパラダイムを提案し、コードの脆弱性を軽減し、潜在的なバグを識別し解決します。
各チャット内の役割間の協力的な相互作用と相互検討は、各サブタスクのための効果的な意思決定に貢献しています。
今後の研究では、CHATDEVのパフォーマンスと効果性を向上させるために、コミュニケーションプロトコルの洗練や各チャット内の相互作用の動的な最適化に焦点を当てることができます。
また、強化学習や説明可能なAIなどの新しい技術の統合を探ることで、課題への対応や全体のソフトウェア開発プロセスの向上に関する貴重な洞察を提供できます。
最終的には、より効率的なソフトウェア生産プロセスを実現することを目指しています。このフレームワークの潜在能力が、LLMsをソフトウェア開発に統合する新しい可能性を明らかにし、自然言語処理、ソフトウェアエンジニアリング、集合知の分野における新しいフロンティアの夜明けを示すことを期待しています。
その他
↓論文はこちら
↓デモやソースコードはこちら