廃止されたAPIのLLMコード補完における課題

大規模言語モデル（LLM）は、与えられたプロンプトに基づいてコードを作成できるコンピュータプログラムだよ。こういうモデルはたくさんのコーディングデータで訓練されてるから、コードの補完提案がかなり効果的なんだけど、古いコードや関数、つまり非推奨APIを使うと大きな問題が発生するんだ。開発者が使うライブラリやフレームワークが進化するにつれて、いくつかの関数やメソッドが時代遅れになって新しいものに置き換えられる。こうした変化は、LLMのパフォーマンスに影響を及ぼすことがあるんだよ。特に、古いコードを提案してきた場合、そのコードがうまく動かないこともあるからね。

プログラミングライブラリの急速な更新や変化は、何が有効または推奨されたコードなのかが常に変わり続けることを意味するんだ。それで、これらのモデルがどれくらいの頻度で非推奨APIを提案しているのか、そしてその理由を調査することが重要なんだ。このレポートは、この問題の詳細を分析して、コーディング環境での状況を改善する方法を提示することを目的としているんだ。

#非推奨APIの問題

ソフトウェアを開発する際、プログラマーはしばしばサードパーティのライブラリに頼るんだ。これらは、便利な機能を提供するために事前に書かれたコードのコレクションだよ。各ライブラリには、API（アプリケーションプログラミングインターフェイス）と呼ばれるルールのセットがあって、どのようにそれらとやり取りするかをガイドしているんだ。時間が経つにつれて、ライブラリはアップデートを受けて古い関数が非推奨になることがある。非推奨の関数は、もはや使用が推奨されていないもので、将来のアップデートで削除される可能性があるんだ。

例えば、深層学習のための人気ライブラリPyTorchでは、ある関数が削除されて別のものに置き換えられたんだ。ライブラリが改善されるにつれて、古い関数が新しいものに置き換わって、より良いパフォーマンスや新機能を提供することがあるよ。非推奨のAPIを使うと、コードに問題が生じることがあって、新しいデザインやデータとうまく組み合わさって動かない場合があるから、ソフトウェアプロジェクトにバグを引き起こす可能性があるんだ。

LLMの使用が増えているにもかかわらず、これらのモデルがどのくらい非推奨APIを使うかについての研究は限られてる。前の研究は主にこれらのモデルの全体的な精度に焦点を合わせていて、提案する際にどれだけ古いコードを避けるかを具体的に評価していなかったんだ。

#研究の目的

この研究の主な目的は、LLMがコード補完を行う際に非推奨APIを使用する頻度とその理由を調査することなんだ。これを達成するために、いくつかの研究質問を設定したよ。

1. LLMベースのコード補完における非推奨API使用の現状は？
2. 非推奨APIに関するLLMの予測に、異なるタイプのプロンプトはどんな役割を果たすの？
3. ライブラリの選択は、LLMによる非推奨APIの使用にどのように影響する？

これらの質問に答えることで、非推奨APIの使用理由をより深く理解し、LLMのコード生成性能を向上させるための解決策を探ることができることを期待しているんだ。

#方法論

この問題に取り組むために、いくつかのLLMとサンプルコーディングライブラリを使って徹底的な研究を行ったよ。プログラミングコミュニティで広く使われている8つの人気Pythonライブラリに焦点を当てて、データ操作と機械学習フレームワークを含む多様なAPIのセットを分析したんだ。

#データ収集

選んだライブラリから、合計145の非推奨APIとその置き換えのデータを集めたよ。これは、各ライブラリの公式文書と更新ログをレビューして、どのAPIが非推奨になったか、そしてその置き換えは何かを特定する作業を含んでた。最終的に、9,022の非推奨API使用例と19,103のその置き換えの例を集めたんだ。

#実験

LLMが非推奨API提案をどれだけうまく扱えるかを評価するために、具体的なプロンプトを作成したよ。各プロンプトは、非推奨APIやその置き換えを使用する関数に基づいて構築したんだ。それから、7つの先進的なLLMにこれらのプロンプトを入力して、どんな反応があるかを見たよ。

例えば、プロンプトに非推奨の関数が含まれている場合、そのモデルがその関数かその置き換えを提案するかどうかをチェックしたんだ。この分析によって、モデルが古い提案を避ける能力や、そのパフォーマンスがプロンプトや使用されるライブラリによって変化するかを理解したんだ。

#結果の評価

データを集めた後、いくつかの異なる方法で評価したよ。

#モデルのパフォーマンス

テストした全てのLLMは、正しいAPIの使用を予測するのに苦労していたんだ。一般的に、モデルは古い関数よりも新しい関数を予測する方がパフォーマンスが良かったよ。これは、LLMがコードの補完に役立つことができても、訓練データに非推奨APIが存在するためにしばしば混乱することを示してるんだ。

#プロンプトの影響

LLMに与えたプロンプトの種類は、彼らのパフォーマンスに大きく影響したよ。非推奨APIを用いた関数を参照するプロンプトの場合、モデルはその古い関数を提案する傾向があったけど、その置き換えを提案することは少なかったんだ。一方で、最新のAPIを使った関数から派生したプロンプトでは、モデルが正しい新しいAPIを提案する可能性が高かったよ。これは、プロンプトのコンテキストがモデルの提案を導くために重要であることを示してるんだ。

#ライブラリのばらつき

異なるライブラリは、LLMがAPIを提案する方法にさまざまな影響を与えたよ。一部のライブラリは、古いAPIから新しいAPIへの移行がより明確だったけど、他のライブラリは混乱を引き起こした。この傾向は、APIの使用パターンを変更せずにわずかに変更したライブラリで特に顕著だったんだ。その場合、モデルは古いバージョンと新しいバージョンの違いを識別できなかったため、非推奨APIを提案することがあったんだ。

#提案された解決策

非推奨APIの使用の問題に対処するために、LLMがより良いコード補完を提供するための2つの簡単な戦略を提案したよ。これらの戦略は、非推奨APIの知識の処理方法を改善することで、上記の課題に取り組むことを目指しているんだ。

#ReplaceAPIアプローチ

最初の解決策はReplaceAPIと呼ばれていて、提案されたコード内の非推奨APIのインスタンスを直接置き換える方法なんだ。モデルが非推奨の関数を予測すると、このアプローチはそれを置き換えに置き換えて、その変更に基づいて残りのコードを生成するんだ。このシンプルな方法は、最新のAPIだけが提案されることを確実にするのに役立つよ。

#InsertPromptアプローチ

2つ目のアプローチはInsertPromptで、モデルにコード生成時に新しいAPIを使用するように指示する追加のプロンプトを加える方法だよ。この追加の指示をプロンプトに直接追加することで、モデルは非推奨のものよりも正しい関数を好むように導かれるんだ。この方法は、モデルが予測を行う際のコンテキストを洗練することに焦点を当てているんだ。

#解決策の評価

提案した戦略が非推奨APIの使用の問題にどのくらい対処できるかをテストしたんだ。各アプローチのパフォーマンスは、いくつかの指標を使って測定されたよ。

1. 修正率（FR）： 我々の戦略を適用した後に正しいAPIを使用した補完の割合。
2. 編集類似度（ES）： 提案が要求された編集に基づいて正しいコードとどれだけ一致しているか。
3. 完全一致（EM）： 正しいコードと完全に一致する補完の割合。

#ReplaceAPIからの結果

ReplaceAPI戦略は有望な結果をもたらしたよ。テストしたすべてのLLMは高い修正率を達成し、しばしば85％を超えたんだ。これは、モデルが非推奨の提案を改善する能力を持っていることを意味するんだよ。提案された編集もまあまあ正確で、古いAPIの参照を修正しながらコードの品質を維持する能力を示してたんだ。

#InsertPromptからの結果

InsertPromptアプローチはパフォーマンスのばらつきがあったよ。いくつかのモデルはうまく機能したけど、他のモデルは挿入されたプロンプトを効果的に解釈するのに苦労したんだ。特に大きなモデルは追加指示に基づいて応答を適応させる能力が強かったよ。それにもかかわらず、すべてのモデルが新しいAPIを一貫して正しく使用できたわけではなく、プロンプト設計のさらなる改善が必要なことが浮き彫りになったんだ。

#結論

この評価研究は、特に非推奨APIの使用に関して、LLMがコード補完を提案する際に直面している課題を浮き彫りにしているんだ。我々の調査結果は、これらのモデルが古いコーディングデータと特定のプロンプトによって提供されたコンテキストのために古い関数を多く使用することを示しているよ。

この問題の背後にある原因を理解することで、より良いコード生成ツールを開発する方向に進むことができるんだ。我々が提案した戦略、ReplaceAPIとInsertPromptは、LLMにより最新のAPIを提案させる可能性を示していたよ。今後のステップは、これらのアプローチをさらに洗練させ、より信頼性の高いコーディングツールを作成するための追加の方法を探ることになるんだ。

プログラミングが進化し続ける中で、コードの提案が常に関連性と機能性を保てるようにすることは、開発者にとって重要なんだよ。非推奨APIの問題に積極的に取り組むことで、LLM駆動のコード補完の信頼性を高め、より効率的なソフトウェア開発の慣行に寄与できるんだ。