500以上の研究と50以上のモデルを網羅したコードビッグモデルレビューがここにあります

BERT や GPT などの事前トレーニング済みのトランスフォーマーの登場により、言語モデリングは近年大きな進歩を遂げています。大規模言語モデル (LLM) が数千万のパラメータにまで拡張されるにつれて、汎用人工知能の兆候が見られ始めており、そのアプリケーションはもはやテキスト処理に限定されなくなりました。 Codex は、コード処理における LLM の優れた機能を初めて実証し、その後、GitHub Copilot などの商用製品や、StarCoder や Code LLaMA などのオープンソースコードモデルが登場しました。

しかし、コード処理のための事前トレーニング済みトランスフォーマーの応用は、デコーダーのみの自己回帰モデルが主流の技術になる前の時代にまで遡り、この分野の完全なレビューは存在しません。

上海交通大学とアントグループの研究チームがこのギャップを埋めました。彼らは、50 を超えるモデル、30 を超える下流タスク、および 500 を超える関連研究結果を網羅した、コードの言語モデルの包括的な概要を示しました。コード言語モデルは、一般的なドメインでトレーニングされた巨大なモデルから、コードの理解や生成タスク専用にトレーニングされた小さなモデルまで分類されます。

彼らは、これらのモデル間の関係と相違点に焦点を当てており、特に言語モデルのコード固有の機能 (抽象構文木やデータフローなど) と NLP 分野から借用した最新の技術を統合することに重点を置いています。

次に、Machine Intelligence がこのレビュー論文を紹介します。コード言語モデルの開発についてより包括的に理解したい場合は、オリジナルの論文をぜひ読んでみてください。さらに、チームは Code LLM の最新の成果を追跡して共有するために、GitHub 上に関連文献のオープンインデックスを構築しました。

論文アドレス: https://arxiv.org/pdf/2311.07989v1.pdf
リポジトリアドレス: https://github.com/codefuse-ai/Awesome-Code-LLM

背景

このセクションでは、著者は、単方向モデルと双方向モデルの共通の目標、および NLP で人気のあるモデルと設計など、Transformer ベースの言語モデリングの基本的な知識を要約します。

一方向言語モデル (因果言語モデルとも呼ばれる) は、文の確率を各トークンの条件付き確率と連鎖規則の積に分解します。

因果言語モデルとは異なり、双方向言語モデルのトレーニング目標は、自己回帰方式でテキストを生成するのではなく、テキストのより優れたコンテキスト表現を取得することです。

GPT スタイルの因果言語モデルと BERT スタイルの双方向言語モデルには、それぞれ長所と短所があります。 GPT は自己回帰生成に使用できますが、入力テキストの双方向表現がないため、翻訳や要約などのシーケンスツーシーケンスタスク (seq2seq) には適していません。一方、BERT は双方向表現を生成できますが、事前トレーニングの目標は生成ではなくマスクの充填です。

最も基本的な Transformer エンコーダー/デコーダーアーキテクチャは、GPT と BERT の利点を組み合わせたものです。 T5 はそのようなモデルであり、事前トレーニングプロセスでスパン破損を使用し、マスク言語モデリング (MLM) のバリエーションとして見ることができます。

因果言語モデリング (CLM) や MLM などの言語モデリングの目的は、トークンレベルで情報を取得できるようにモデルをトレーニングすることですが、ドキュメント構造を効率的にモデル化することはできません。したがって、モデルがグローバル情報を学習できるようにするために、通常は補助的な目的が追加されます。たとえば、BERT の事前トレーニングでは、MLM を使用しながら次の文の予測 (NSP) 目的を使用します。

また、事前トレーニング済み言語モデルの研究のほとんどはトレーニング目標の設計に重点を置いていますが、Transformer アーキテクチャ自体の低レベルの実装も継続的に改善されており、安定性、パフォーマンス、効率性が向上していることも言及する価値があります。

コードの言語モデルの評価

過去 10 年間にわたり、ソフトウェアエンジニアリングコミュニティは、コードモデルを評価するためのさまざまな評価タスクを提案してきました。 CodeXGLUE は、これらのほとんどを 1 つのベンチマークに統合し、クローン検出、欠陥検出などのコード理解タスクと、コード修復、コード変換、プログラム合成、コード要約などのシーケンス間生成タスクをカバーします。しかし、Chenら（2021）によるHumanEvalとCodexの導入以来、テキストからコードへの合成はNLPコミュニティの注目を集め、LLMを評価するための標準的なタスクになりました（図2）。

コードによって処理される下流のタスク

このレビューでは、著者らはソフトウェアエンジニアリングの慣例に従って、入力/出力形式に基づいてコード評価タスクを分類しました。これらのカテゴリは、テキストからコード、コードからコード、コードからテキスト、コードからパターン、テキストからテキストの 5 つの主要なカテゴリにまとめることができます。これらのタスクは以下に簡単にリストされており、これらのタスクの説明については元の論文を参照してください。

テキストからコードへのタスクは、テキストを入力として受け取り、コードを出力します。これらには、コード検索、コード合成、テキストから SQL、数学プログラミングが含まれます。

コードからコードへのタスクは、コードを入力コードとして受け取り、コードを出力します。これらには、コード検索、コード補完、コード翻訳、コード修復、空欄補充クイズ、コード補完、コード難読化、単体テスト生成、アサーション生成、ファジング、型予測が含まれます。

コードからテキストへのタスクは、コードを入力として受け取り、テキストを出力します。これらには、コードの要約、コードレビュー、識別子の予測が含まれます。

コードからパターンへのタスクは、コードの分類を実行することです。これらには、欠陥検出、クローン検出、コード分類、コード推論が含まれます。

テキストからテキストへのタスクは、テキストを入力として受け取り、テキストを出力します。これらには、ドキュメント翻訳、ログ分析が含まれます。

評価指標

コード理解タスクは形式が自然言語理解タスクに似ており、精度、F1、MRR (平均逆順位) などの同様の評価指標を使用しますが、識別子予測などの短い生成タスクは完全一致精度を使用して評価できます。コードからテキストへのタスクでは、BLEU などのテキスト生成タスクに共通の評価メトリックを使用できます。

コード生成を伴う評価タスクはより複雑です。初期の研究のほとんどは、構文の正確性、つまり、生成された結果のうち正常に解析できたものの割合を評価しました。 Chenら（2018）はそのような指標に反対し、参照結果と完全に一致する生成された結果の割合である参照一致指標を提案しました。 Renら（2020）は、コードの構文と意味の両方を考慮して、抽象構文木（AST）とデータフローの重複範囲を評価するBLEUの変種であるCodeBLUEを提案しました。

しかし、コード生成モデルの機能が長年にわたって向上するにつれ、同じ機能を実行するコードスニペットの語彙形式が大きく異なる可能性があるため、これらのコンテンツの重複に基づくメトリックではもはや十分ではないことがわかりました。

そのため、研究者たちは機能の正確性に注目しました。 pass@k もその 1 つです。 Kulal ら (2019) によって提案され、Chen ら (2021) によって最適化されたこのメトリックは、生成された任意の k 個のサンプルを使用して、モデルがプログラムのすべてのユニットテストに合格する確率を偏りなく推定できます。このメトリックは、passn@k (Li et al., 2022) に一般化することもできます。これにより、モデルの送信数が n に制限されますが、入力内の特定のユニットテストに基づいて k 個のサンプルをフィルター処理できます。

手続き型合成

長年にわたるコードモデルの進歩に伴い、研究者の焦点は徐々に実用的なプログラム合成タスクに移ってきました。

CONCODE 2018 はこの分野における初期のデータセットであり、100,000 を超える Java メソッドが含まれており、CodeXGLUE ベンチマークに統合されています。

2021 年以降、関連するデータセットの数は急増しており、そのほとんどは APPS、HumanEval、MBPP などの Python 言語に焦点を当てています。また、最近では HumanEval を他のプログラミング言語に拡張する作業も行われています。 DS-1000 は、NumPy や SciPy などのデータサイエンスソフトウェアライブラリに重点を置いた、より現実的な Python データセットです。また、MathQA-Python や GSM8K-Python など、いくつかの数学的推論ベンチマークもプログラミングタスクに変換されています。

コードベースレベルの評価

上で説明した評価タスクのほとんどは、単一のファイルまたは単一の関数に制限されています。

最近のいくつかの研究では、コード補完のためにコードベースレベルのコンテキストを活用することが検討されており、Liu et al. (2023) はこれらのシステムを評価するための RepoBench を提案しました。最近、Bairiら（2023）は、より困難なコードベースレベルのAPI移行と時間編集タスクを研究し、Jimenezら（2023）は、対応するベンチマークSWEベンチを導入しました。

コードのためのユニバーサル言語モデル

言語モデルのパラメータの数は数千億にまで拡大したため、それらの多くは、特にコーディングするように設計またはトレーニングされていないにもかかわらず、驚くべきプログラミング可能性を示しています。 Codex の後、研究者たちは、コードの事前トレーニングを継続するだけで、言語モデルのコードパフォーマンスを大幅に向上できることを発見しました。

すぐに使える言語モデル

大規模な言語モデルの事前トレーニングでは、通常、スケーリング法則に従って数兆個のトークンが使用され、この膨大な量のテキストデータには、少量ながらも重要な量の多様なコードが含まれていることがよくあります。たとえば、Pile データセットには 95 GB のコードが含まれています (GitHub の 800 GB のオリジナルデータセットからクロール)。1.6 TB の多言語事前トレーニングデータセット ROOTS にも 163 GB のコードが含まれており、13 のプログラミング言語をカバーしています。これらは、多くの言語モデルをプログラム可能にする、最大規模のオープンソースの事前トレーニング済みデータセット 2 つです。たとえば、GPT-J、GPT-NeoX、BLOOM はすべて HumanEval で良好なパフォーマンスを示しました。

LLaMA (事前トレーニングデータセットには GitHub の 328 GB のコードが含まれています) は、HumanEval メトリックで 23.7 の pass@1 パフォーマンスを達成し、その後継モデルの LLaMA 2 はさらに高い 29.9 を達成しました。

一方、クローズドソースモデルは一般的にパフォーマンスが優れています。たとえば、LaMDA と PaLM は HumanEval でそれぞれ 14.0 と 26.2 の pass@1 パフォーマンスを達成していますが、GPT-4 は驚異的な 67.0 に達しており、これは最近までコードで特別に事前トレーニングされたモデルや命令で微調整されたモデルよりも高いものでした。

最近の傾向としては、スケーリング則の改訂版に従って、より大きなデータセットを使用してより小さなモデルをトレーニングすることが挙げられます。

2 つの例を挙げると、Baichuan 2 は 2.6T トークンでトレーニングされた 13B モデルであり、Qwen は 3T トークンでトレーニングされた 14B モデルです。 HumanEval での pass@1 パフォーマンスはそれぞれ 17.1 と 32.3 です。 Li et al. (2023) は、13億の小さなモデルでも、妥当な一般的なテキスト処理機能を維持しながら、より大きなモデルに匹敵するプログラミング機能を実現でき、思考連鎖推論などのいくつかの新たな機能も示すことができることを示しました。彼らのモデル Phi-1.5 は、ChatGPT によって生成された 210 億トークンの教科書データと、Stack Overflow および Refined Web からの 1000 億トークンのフィルタリングされた Web データでトレーニングされ、HumanEval での pass@1 パフォーマンスは 41.4 です。

表 1 にこれらのモデルのパフォーマンスを示します。

コード上の追加の事前学習済み言語モデル

Chen ら (2021) は、画期的なベンチマーク HumanEval により、コードに LLM を使用する時代を切り開きました。彼らの貢献は Codex です。これは GPT-3 チェックポイントモデルですが、追加の 100B のコードトークンで事前トレーニングされています。これは、10 億を超えるパラメータを持つ最初のコードモデルの 1 つです。

その後、PaLM-Coder と PaLM 2-S* が登場し、これらは順に HumanEval と MBPP の現在の最高峰となりました。同様に、Lewkowyczら（2022）は、385億トークンのarXiv論文と数学コンテンツを使用してPaLMをトレーニングしました。Rozièreら（2023）は、5000億を超えるコードトークンを使用してLLaMA 2をトレーニングし、HumanEvalでGPT-4を除くすべての以前の言語モデルを上回るパフォーマンスを発揮するCode LLaMAを取得しました。

Liuら（2023）は、マルチタスク微調整（MFT）を使用してCode LLaMAをさらにトレーニングし、CodeFuse-CodeLLaMAを取得しました。これは、HumanEvalでpass@1のパフォーマンス74.4を達成し、OpenAIが報告したGPT-4のパフォーマンスを上回りました。

これらのモデルは基本的に CLM で事前トレーニングされた Transformer デコーダーを使用しますが、研究者はこのアーキテクチャを継続的に改善し、並列アテンション、MQA、RoPE などの新しい方法を導入しています。

コード専用の言語モデル

GPT や BERT などの事前トレーニング済みのトランスフォーマーが自然言語処理で大きな成功を収めたことで、このようなモデルアーキテクチャ、学習パラダイム、トレーニング目標は、コードの理解と生成に特化したモデルを作成するためにソフトウェアエンジニアリングコミュニティに急速に採用されました。表 3 に、これらの事前トレーニング済みモデルの概要を示します。

コードトレーニングデータセット

現在、CodeSearchNet、CodeParrot、Stack など、大規模なコード事前トレーニングデータセットが多数存在し、それぞれ 20 GB、50 GB、3 TB のコードドキュメントが含まれています (表 2 を参照)。

エンコーダ

Kanade et al. (2020)は、コードコーパスに対してBERTトレーニングプロセスを繰り返し、CuBERTを取得しました。 Fengら（2020）は、CodeSearchNet上でMLMとELECTRAのRTDトレーニングを使用してCodeBERTを取得しました。また、CodeSearchNet からの明示的なテキストとコードのペアを活用し、それぞれ BERT 入力の最初のセグメントと 2 番目のセグメントとして使用しました。

これらの標準的なトレーニング目標に加えて、研究者はコーディングタスク専用に設計されたいくつかの補助目標も導入しました。 GraphCodeBERT と SynCoBERT は、それぞれデータフローグラフと抽象構文木に対応するグラフをソースコードから抽出し、それらを使用してノード間の型関係を予測するモデルをトレーニングします。さらに、SynCoBERT と Code-MVP は、事前トレーニングフェーズ中にタグの形式で型推論も追加します。

もう 1 つの共通の目標は対照学習です。SynCoBERT と Code-MVP は、入力のさまざまな観点 (コード、コメント、AST、変換されたコードなど) を比較します。一方、DISCO は難読化などの意味を保持する変換を通じて正の例のペアを構築し、人工的なエラーを挿入することで負の例のペアを構築します。

エンコーダー - デコーダー

エンコーダー/デコーダーは、条件付きテキスト生成に使用できる一方で、エンコーダー部分は常に単独で使用して、回帰などのエンコーダーのみのアーキテクチャを必要とするタスクを実行できるため、エンコーダーのみのモデルよりも当然強力です。

エンコーダー/デコーダーアーキテクチャの進歩に刺激を受けて、研究コミュニティではコード処理のためのこのようなモデルを数多く提案してきました。

PyMT5 (Clement et al., 2020) と Mastropaolo et al. (2021) は、コードコーパスで T5 の事前トレーニングとマルチタスクの微調整プロセスを繰り返し、Ahmad et al. (2021) は、655GB の Java、Python、自然言語データの組み合わせで事前トレーニングされた BART モデルである PLBART を提案しました。 Lachaux ら (2021) は、識別子名が単一のコンテキストウィンドウに複数回出現することが多いため、MLM はプログラミング言語にとっては単純すぎるタスクである可能性があると主張し、難読化されたコードを元の形式に変換するようにモデルをトレーニングする難読化解除の事前トレーニング目標を提案しています。

これらの以前の研究結果に基づいて、Wangら（2021）は、事前トレーニングでT5独自のスパン破損、識別子タグ付け、マスクされた識別子予測、テキストからコード、コードからテキストへの生成を使用するCodeT5を提案しました。後継モデル CodeT5+ は UL2 からインスピレーションを得て、テキストとコードのマッチングに基づく対照的な目的に加えて、事前トレーニングプロセスに因果言語モデリング (CLM) を導入しています。

LiらによるAlphaCode (2022)も複数のトレーニング目標を使用しており、エンコーダーはMLMでトレーニングされ、デコーダーはCLMでトレーニングされています。さらに、浅いエンコーダーと深いデコーダー、マルチクエリアテンションなどのアーキテクチャ調整が行われており、モデル規模もCodeT5よりもはるかに大きく、最大410億のパラメーターがあります。

Chakraborty ら (2022) の NatGen 事前トレーニングでは、難読化解除に似た「自然化」目標を使用します。つまり、ループ変換、デッドコード挿入、変数名の変更などの定義済み操作を通じて、意味的には同等だが不自然なコードを生成し、これらの不自然なコードを元の形式に戻すようにモデルをトレーニングします。

これらの一般的な事前トレーニングの目的に加えて、Transformer エンコーダー/デコーダーをトレーニングする際のコード変換に焦点を当てた研究もあります。これは、コードの観点から見た Transformer モデルの自然な応用です。結局のところ、Transformer アーキテクチャは、機械翻訳タスク用に Vaswani ら (2017) によって最初に提案されました。ただし、自然言語とは異なり、コードには並列データがほとんどありません。

この問題を解決するために、Rozière ら (2020) は Transcoder を提案しました。これは、最初に XLM を使用してエンコーダーを事前トレーニングし、次にこのエンコーダーを使用して基本的な Transformer を初期化し、次にノイズ除去オートエンコーディング (DAE) を使用して事前トレーニングを続け、それを元に戻します。その後、Szafraniec ら (2023) も言語に依存しない中間表現を使用してこのプロセスを強化しました。

トレーニングデータと目的を除けば、これらのモデルは、表 3 に示すように、NLP コミュニティによって提案された元のアーキテクチャをほぼ保持しています。

デコーダ

GPT-3 のリリースとコンテキスト学習法の出現以来、デコーダーのみの Transformer モデルが言語モデリングの主流の手法になりました。コード処理の分野でも、GPT-C、CodeGPT、PolyCoder、CodeGen、PyCodeGPT、Pangu-Coder、CodeGeeX、Phi-1、CodeFuse、CodeShell、DeepSeek Coder など、CLM で事前トレーニングされたモデルと同様のモデルが数多く登場しています。これらのモデルの一部は、MLM と Masked CLM を使用する Pangu-Coder など、他のトレーニング目標で実験しましたが、パフォーマンスは CLM のみでトレーニングされた方法ほど良好ではありませんでした。 Zanら（2022）は、スケッチの継続的なトレーニング、つまり、最初にプログラムのドラフトを生成するようにモデルに学習させ、次に実際にコードを記述する方法も提案しました。

Christopoulou ら (2022) は、ノイズ除去の目的はデコーダーのみのモデルよりもパフォーマンスが悪いと報告していますが、ノイズ除去やマルチタスクの事前トレーニングをデコーダーアーキテクチャと組み合わせた研究もいくつかあります。 Incoder、SantaCoder、および StarCoder はすべて、中間補完 (FIM) 目標 (因果マスキングとも呼ばれます) を使用してトレーニングされます。これは、本質的にはデコーダーアーキテクチャのみによるスパン破損です。これらの補完目標には明らかな利点があります。モデルが推論時に入力コードのギャップを埋めることができるのに対し、CLM では自己回帰生成のみが可能です。ただし、表 4 に示すように、これらの目標により、CodeGen などの CLM のみのモデルと比較して、下流のタスクでのモデルのパフォーマンスも向上します。

ユニLM

一部の研究者は、コード処理に別の Transformer モデルである UniLM も使用しています。 CugLM は交互の注意マスクを備えた CLM と MLM+NSP を使用しますが、UniXcoder は CLM、MLM、Span Corruption、および対照学習やテキストコード双方向生成などの補助目的でトレーニングされます。ただし、どちらのモデルもサイズが比較的小さいため、このアーキテクチャがコード処理に適しているかどうかはまだ検討されていません。

拡散モデル

現在、Transformer アーキテクチャがテキスト生成の分野で主流となっていますが、一部の研究者は、コンピュータービジョンの分野の拡散モデルを使用してテキストを生成することを検討しています。

最近の CodeFusion では、拡散モデルがコードモデリングの分野に導入され、研究により、7,500 万のパラメータを持つ拡散モデルが、3 つのコード合成データセットで StarCoder、CodeT5+、GPT-3 よりも優れていることが示されました。

コードの微調整と強化学習の手順

自然言語分野の研究成果に続いて、コードコミュニティの研究者も命令の微調整技術を活用してきました。 Wangら（2023）は、InstructGPTによって生成された20,000の命令データを使用してCodeT5+を微調整し、InstructCodeT5+を取得しました。 WizardCoder は WizardLM アプローチに従い、20K コードの Alpaca サンプルを 78K データセットに進化させ、その後 StarCoder を微調整するために使用されます。 Pangu-Coder 2 は、WizardLM の Evol-Instruct を使用して、20,000 個の Alpaca コードから 68,000 個の命令サンプルを生成します。また、Rank Responses による強化学習を導入し、テストと教師のフィードバック (RRTF) を調整します。

OctoCoder は別の方法を採用し、Git コミット履歴を指示データとして使用して、StarCoder と CodeGeeX2 を微調整します。最近の CodeFuse では、マルチタスクの微調整も使用して、複数のダウンストリームタスクを命令データに明示的に導入します。表 4 には、これらの命令調整されたコードモデルのパフォーマンスも示されています。

NLP の分野では、命令の微調整に密接に関連するもう 1 つの手法として、人間のフィードバックによる強化学習 (RLHF) があり、これは LLM を人間の価値観に合わせる上で重要な役割を果たします。強化学習をコードに適用すると、コンパイラが言語モデルによって生成されたコードサンプルのフィードバックを自動的に生成できるため、当然の利点があります。

CodeRL は、生成されたプログラムごとに 4 つのレベルの報酬 (コンパイルエラー、実行時エラー、単体テストの失敗、合格) と、批評家モデルによって推定されるきめ細かいトークンレベルの報酬を定義するモデルの 1 つです。そのアクターモデルは CodeT5 から拡張され、REINFORCE アルゴリズムを使用してトレーニングされます。同様に、CompCoder と PPOCoder はそれぞれ CodeGPT と CodeT5 をトレーニングするために近似ポリシー最適化 (PPO) を使用しますが、RLTF はコンパイラによって提供されるエラー情報と場所に基づいてきめ細かいフィードバックを提供することを提案し、合格したテストケースの割合を考慮した適応型フィードバックを使用します。

言語モデルで使用されるコード機能

プログラミング言語と自然言語の主な違いの 1 つは、前者は手動で定義され、正確で曖昧さがないように努め、実行前にエラーなしでコンパイル (または解釈) する必要があることです。これにより、CLM、MLM、Span Corruption などの語彙操作に加えて、コードの事前トレーニング目標をより柔軟に設計できるようになります。

プログラミング言語には、構文機能などの面で大きな利点があります。 C、Python、Java などのすべての主流プログラミング言語には、抽象構文木 (AST)、言語に依存しない中間表現 (IR)、各トークンの型や制御/データフローグラフ (CFG/DFG) などの補助情報など、プログラムの意味情報を簡単かつ正確に抽出できる、すぐに利用できるコンパイラツールキットがあります。そのため、コードの Transformer スタイルの言語モデリングでは、多くの研究でこれらの機能をトレーニングプロセスに統合しています。

抽象構文木と中間表現

Jiangら（2021）が提案したTreeBERTは、Transformerベースの事前トレーニング微調整フレームワークでASTを使用することを試みた最も初期のモデルの1つです。これは、ツリー MLM とノード順序予測を使用して事前トレーニングされた Transformer エンコーダー/デコーダーモデルです。

その後、SynCoBER、SPT-Code、UniXcoderなどの研究成果も出ています。詳しくは原論文をご覧ください。

コンパイルプロセス中、AST の後には通常、LLVM IR などの言語に依存しない中間表現が続きます。特定のプログラミング言語から独立しているため、翻訳ハブとして最適です。

制御フローとデータフロー

研究では、AST と IR は特定のタスク (コードトランスパイルなど) には役立つことが示されていますが、ソースコードと同様に本質的に静的であり、実行時にのみ明らかになるコードのセマンティックプロパティをキャプチャできない可能性があります。制御フローやデータフローなどの動的機能には、このようなセマンティクスが含まれます。

AST と同様に、事前トレーニング済みの Transformer が登場する前は、ProGraML で使用されるメッセージパッシングニューラルネットワークなど、特殊なネットワークがそのような情報を処理するために使用されていました。しかし、AST とは異なり、事前トレーニング済みの Transformer が主流になった後も、この方向性を探った研究はほとんどありませんでした。

GraphCodeBERT は、フローグラフ内の変数に特別なトークンと位置の埋め込みを作成し、この変数シーケンスをテキストとソースコードに連結してモデル入力を構築する研究の 1 つです。また、コードと変数セグメント用にカスタマイズされたアテンションマスクも使用します。

タイプ

AST、IR、データフローに加えて、型情報も言語モデルによるコード処理を支援するために使用されます。たとえば、CugLM は、微調整中に単方向 MLM (単方向アテンションマスクを使用した MLM) でのトークン予測を支援するために型情報を使用します。まず、最終的な Transformer レイヤーの表現に基づいてマスクされたトークンの型を予測し、次に、非表示の表現と予測された型に基づいてトークン自体を予測します。対照的に、CodeT5 と SynCoBERT の両方の事前トレーニング目標には、粗粒度の型予測として見ることができる識別子タグが含まれています。

Wang ら (2022) は、ソースコード、ドキュメント文字列、AST、CFG、識別子の名前変更、ループのスワッピング、デッドコードの挿入によって変換されたソースコードなど、上記の機能の多くを Code-MVP に統合したことは注目に値します。モデルは GraphCodeBERT から初期化され、MLM、きめ細かい型予測、さまざまな視点からの対照学習 (テキストとコード、コードと AST、コードと CFG など) を使用してトレーニングされます。

ソフトウェア開発における法学修士

言語モデルがソフトウェアエンジニアリングのベンチマークで新しい記録を樹立するにつれ、ソフトウェアエンジニアリングの手法は言語モデルの限界を押し広げ、それを現実の開発サイクルに取り入れるようになっています。

プログラミングツールによるLLMの拡張

NLP コミュニティの調査によると、LLM は計算機、機械翻訳システム、検索エンジンなどの外部ツールの使用方法を学習できることがわかっています。したがって、インタープリターを使用すると、LLM が複雑な推論タスクを処理する能力を高めることができます。 PAL と PoT はどちらも Python インタープリターを使用して Codex を拡張し、数値計算機能を有効にしますが、ViperGPT はビジュアル API を呼び出すことで Codex をさらに拡張し、ビジュアル入力から情報を抽出して関連する質問に答えられるようにします。

抽象推論タスクにおける数値計算の負担を軽減することに加えて、インタープリターはコード生成プロセス自体に関するフィードバックを提供し、ユニットテストを実行することもできます。 CodeT と TiCoder は Codex を使用してユニットテストを生成します。ユニットテストは生成されたコードサンプルで実行され、コード合成時のモデルのパフォーマンスを向上させることができます。同様に、TransCoder-ST は、コード変換の外部ユニットテストを実行することで、TransCoder と DOBF を強化します。さらに、ユニットテストの実行結果は、コード強化学習の自然な監視信号として機能します。

特筆すべきは、OpenAIが2023年3月にChatGPT用のインタープリタープラグインをリリースしたことだ。このプラグインは、ユーザーのファイル入力を受け入れ、ユーザーの指示に従ってコードを生成し、リアルタイム実行を通じてフィードバックを提供できる。 Zhou ら (2023) の研究では、この機能により GPT-4 が自己デバッグできることが示されています。

LLM 研究において、ツールの使用と密接に関連するトピックはエージェントとしての計画であり、理論的研究と実験的研究の両方で、これが LLM の能力を向上できることが示されています。 Ruan ら (2023) は、LLM は複雑なタスクを解決するための計画に外部 SQL ジェネレーターと Python ジェネレーターを使用できるのに対し、CodePlan は適応型計画を通じてコードベースレベルのプログラミングを実行できることを発見しました。

別の種類の作業では、LLM を使用して、自己コラボレーション、ChatDev、MetaGPT などのコード生成用のマルチエージェントシステムを作成します。これらのフレームワークでは、複数の LLM がプログラマー、レビュー担当者、マネージャーなどのさまざまな役割を果たします。これらの役割は相互に連携し、コード生成タスクをさまざまな段階（設計、コーディング、テスト、ドキュメント作成など）に分割し、コラボレーションを通じて複雑なタスクを完了します。

ソフトウェア開発へのLLMの統合

LLM のインタラクティブプログラミング機能が向上するにつれて、研究者はそれをソフトウェア開発プロセス全体に統合し始めました。

自動コード補完は、ソフトウェア開発における言語モデルの最も初期のアプリケーションの 1 つです。このタスクでは、次のトークンを予測する機能のみが必要です。言語モデルが数十億のパラメータに達する前から、Pythia や IntelliCode などのコード補完システムは一般的な IDE に統合されていました。

しかし、最近では、コード言語モデルの応用は単純なコード補完を超えています。 GitHub Copilot は、コード生成、脆弱性検出、証明書管理など、幅広い機能を備えた、最も人気のある AI プログラミングアシスタントの 1 つです。CodeFuse は、コード生成、コード変換、コード注釈、テストケース生成を 1 つの IDE プラグインに統合します。ただし、コード言語モデルが大きくなるにつれて、クライアントの展開とリアルタイムパフォーマンスに新たな課題が生じています。

LLM が進化し続けるにつれて、LLM に基づいたアプリケーションを構築すること自体が価値のあるタスクになりつつあります。このようなアプリケーションには、LangChain、AutoGPT、WorkGPT など、すでに多くのオープンソースフレームワークが存在します。