e4exp / paper_manager_abstract

0 stars 0 forks source link

Retrieval Augmented Code Generation and Summarization #627

Open e4exp opened 3 years ago

e4exp commented 3 years ago

ソフトウェア開発者は、ソフトウェアの開発中に多くのソースコードやドキュメントを書きます。 開発者は、ソフトウェアを実装したり、ドキュメントを作成したりする際に、過去に書いたソースコードの一部やコードサマリーを思い出すことが多いのが本質である。 このような開発者のコードや要約の生成行動を模倣するために、我々は検索データベースから関連するコードや要約を検索し、コード生成モデルや要約モデルの補助として提供する検索拡張フレームワークであるREDCODERを提案する。 このフレームワークは、いくつかのユニークな特徴を持っている。 第一に、このツールは最新の高密度検索技術を拡張し、関連するコードや要約を検索する。 第二に、一峰性(コードまたは自然言語の記述のみ)または二峰性(コードと記述のペア)のインスタンスを含む検索データベースを扱うことができる。 我々は、JavaとPythonのコード生成と要約の2つのベンチマークデータセットで実験と広範な分析を行い、有望な結果が我々の提案する検索拡張フレームワークの有効性を裏付けた。

e4exp commented 3 years ago

1 はじめに

近年、ソースコードの生成と要約の自動化は、プログラマーの生産性を向上させ、開発者の面倒な作業を軽減する可能性があるため、大きな注目を集めています。 その結果、コード生成(Yin and Neubig, 2017; Gu et al., 2016)やコードの文書化/要約(Ahmad et al., 2020; Wei et al., 2019; Allamanis et al., 2018)を容易にするための様々なアプローチが文献で検討されています。 初期の成功にもかかわらず、生成されたコードのほとんどは依然としてコード品質の低さに悩まされています(Xu et al.、2021)。 そのため、与えられた要約からより良いコードを生成したり、その逆を行ったりするにはどうすればよいかという疑問が残っています。 しかし、ソースコードの生成と要約は、本質的に複雑で困難な作業です。 それらは、異なる変数、演算子、キーワード、クラス、メソッド名などの多様なトークンシーケンスを生成することを含んでおり(Parvez et al.、2018)、そのためには、語彙、構文、セマンティクスのレベルでプログラミング言語を理解する必要がある。 これらの問題に対処するために、最近の研究(例えば、Ahmadら(2021)、Guoら(2021)、Xuら(2020)、Fengら(2020a)、Xuら(2020))では、学習ベースのアプローチを採用している。 すなわち、GitHubやStack Overflowなどのオープンソースリポジトリや質問応答フォーラムで利用可能な既存の高品質なソースコードと短いテキスト記述を活用して、コードと関連するテキストの表現を学習する。 そして、下流のタスクで表現モデルを微調整します。 これらのデータセットには高品質の人間が書いたコードやテキストが含まれていますが、既存のアプローチでは生成プロセス中にそれらを直接利用していないため、特にソースコードが長い場合には、これらのアプローチで得られる利益はまだ限られています。 この問題を解決するために、我々は、情報検索技術を用いて検索された既存の高品質なソースコードとその記述を生成プロセスに直接含めることで、その利点を活用する。

本研究では、REDCODER(Retrieval augmentED CODe gEneration and summaRization framework)を発表する。 REDCODERを設計するにあたり、我々は開発者が既存のリソースをどのように活用するかということをモチベーションにしている。 例えば、開発者はしばしばコードリポジトリから関連するコードを検索し、見つかった場合は検索したコードを自分のコンテキストに合わせて適応させる。 同様に、APIの使用方法が不明瞭な場合、開発者は質問応答フォーラム(StackOverflowなど)で検索します(Brandt et al.2010; Sadowski et al.2015)。 このような追加のリソースは、開発者が開発の生産性を向上させるのに役立つ(Li et al., 2013)。

我々はREDCODERを2つのステップのプロセスとして設計している(図1参照)。 第1ステップでは、入力(コード生成のためのnlテキスト、要約のためのコードスニペット)が与えられると、検索モジュールがデータベースから関連するソースコード(コード生成のため)または要約(コード要約のため)を検索する1。 このように、REDCODERは、検索によって入力を補強することで、生成能力を高めている。 この2段階のプロセスにより、ソースコードとサマリーの生成のためのモジュラーで設定可能なフレームワークを設計することができます。 このフレームワークには、様々なデザインのリトリーバーやジェネレータモデルを組み込むことができます。 既存のクロス・エンコーダー・コード・リトリーバーは計算量が多く、大規模なデータベースからの検索への適用は限られている(Humeau et al., 2020)。 自然な選択は、TF-IDFやBM25のようなスパースな用語ベースのレトリバーを使うことであろう(Robertson and Zaragoza, 2009)。 しかし、REDCODERの検索モジュールは、ソースコードとプログラマーの自然言語をよく理解していなければならない。 これは、ソースコードの構文と意味の構造のために、自明ではないタスクである(Guo et al., 2021; Ahmad et al., 2021)。 意味的に類似したコードと要約を検索するというそのような期待は、疎なトークンレベルのコード検索器(例えばBM25)では達成できないかもしれません。 そのため、プログラミング言語(PL)と自然言語(NL)の理解モデル(例えば、GraphCodeBERT(Guo et al.2021))に基づいて、REDCODERのretrieverモジュールを設計する。 このretrieverモジュールは、クエリとドキュメントをエンコードするために2つの異なるエンコーダーを使用して、最先端の密な検索技術(Karpukhin et al.を拡張した.

生成器に関しては、REDCODERは、ユニモーダル(コードまたは自然言語の記述のみ)とバイモーダル(コードと記述のペア)の両方のインスタンスからなる検索データベースを扱うことができ、利用可能なすべての補助的な情報を最大限に利用することができる。 しかし、情報を取り入れるためには、入力レベルでのみ検索された情報をaug mentする。 また、ジェネレーターモジュールの基本的なアーキテクチャには手を加えず、モデルに依存しない特性を維持しています。

REDCODERは、2つの一般的なプログラミング言語(JavaとPython)を用いて、コード生成とコード要約の両方のタスクにおいて、その有効性を評価した。 実証実験の結果、REDCODERの「検索拡張生成」というコンセプトは、検索されたコードや要約から対象候補を強制的に削除した場合でも、最先端のコード生成の正確一致スコアを18.6から23.4に、要約生成のBLUE-4スコアを18.45から22.95に向上させることができた。 今後の実験により、検索コードと検索結果の要約の両方が生成プロセスにおいて重要であることが明らかになりました。 今後の研究のために、コードを公開する予定です。

image

image

e4exp commented 3 years ago

2 背景

最初に問題の定式化を紹介し、REDCODERのレトリーバーとジェネレーターのコンポーネントの基礎を説明する。

2.1 問題の定式化

我々の目標は2つある。 (i)コード生成:コードサマリー、コードコメント、コードインテント(S)などの自然言語記述が与えられたソースコード(C)を生成する。 (ii) コード要約:ソースコードスニペットCから自然言語要約Sを生成する。

XとYを入力シーケンスと出力シーケンスの集合体とする コード生成時は(X = S1, ... ... , Sn, Y = C1, ... ..., Cn)。 コード要約は X = C1, ... , Cn, Y = S1, ... , Sn,を示す。 ここでは,ソースコード(GitHubやStack Overflowから集約されたものなど)やサマリー(docstringsやコードコメントなど)を広範囲に集めた検索データベース(YR)にアクセスできることを想定している. なお、検索データベース(YR)には、対象となる配列(Y )が存在する場合もあれば、存在しない場合もあります。 ここで、入力x∈Xが与えられると、検索者はデータベースから上位k個の関連する出力配列を検索する。 Y1, Y2, ... . , Yk ∈ YR.

次に、入力配列xは、検索された配列で補強され、x ′ = x⊕Y1⊕Y2 ...⊖Yk(⊕は連結操作を表す)となる。 最後に,ジェネレータは,x ′が与えられた目標出力y∈Yを生成する。

2.2 レトリバー DPR

情報検索 (IR) システムまたはリトリーバーモデルは、目的の情報を最もよく提供すると推定される上位k個の関連文書を検索するように設計されている (Manning et al., 2008)。 TF-IDFやBM25(Robertson and Zaragoza, 2009)のような用語ベースの検索手法は、疎なベクトル表現を用いて語彙のマッチングを行い、関連性スコアを計算してクエリに基づいて文書をランク付けするものである。 一方、密な検索手法は、文書を固定サイズの表現にエンコードし、最大内積検索によって文書を検索する(Sutskever et al., 2014; Guo et al., 2016)。

特に注目されているのは、Karpukhinら(2020)がオープンドメインの質問応答(QA)のためのDPR(Dense Passage Retriever)モデルを提案していることである。 このモデルは、クエリと通路をそれぞれエンコードする2つのエンコーダー(Q(.)とP(.))で構成されています。 クエリqと通路pの類似性は、それらのエンコードされたベクトルの内積sim(p, q) = Q(q) T P˙ (p)で定義されます。 DPR は、クエリ q、正の (関連性のある) パッセージ p + 、および n 個の無関係なパッセージ p - i が与えられたときに、分類損失を最適化する

image

Karpukhinら(2020)は、BM25を用いてキュレーションされた「ハード」ネガティブ(BM25スコアが高いが、ターゲットにマッチするサブストリングを含まない候補)を用いて、インバッチネガティブ(Gillickら(2019)、Yihら(2011))を用いてDPRを訓練することを提案している。 詳細はKarpukhin et al.(2020)を参照してください。

2.3 ジェネレーター PLBART

PLBARTはsequence-to-sequence Transformerモデル(Vaswani et al., 2017)であり、ソースコードと自然言語記述の膨大なコレクションに対して、ノイズ除去のオートエンコーディングによって事前に学習されています(Ahmad et al. PLBARTは、コード生成や要約を含むいくつかのソフトウェアエンジニアリングのアプリケーションで有望であるため、我々の提案するフレームワークであるREDCODERの生成モジュールとしてPLBARTを採用する。

e4exp commented 3 years ago

image

image

3 提案するフレームワーク。REDCODER

我々が提案するコード生成・要約フレームワークであるREDCODERは、入力xに関連するコードスニペットや要約を追加することで、ターゲットコードや要約を生成するものである。 REDCODERは、(1)検索エンジンと(2)シーケンス・ジェネレータという2つの独立したモデル・コンポーネントから構成されている。 リトリーバーは、関連するコードスニペットやサマリーを取得し、それらを元の入力と連結してジェネレータに渡す。 生成器は、補強された入力からターゲットシーケンスを自己回帰的にデコードする。 このセクションでは、モデルのコンポーネントを簡単に説明する。

3.1 レトリバー SCODE-Rアーキテクチャ

REDCODERのレトリバーモジュールは、DPRモデル(Karpukhin et al., 2020)に基づいて構築されており、SCODE-R(Summary and CODE Retriever)と呼んでいます。 SCODE-Rは、ソースコードと自然言語による要約をエンコードする2つのエンコーダーで構成されています。 ソースコードと自然言語のサマリーで事前に学習された双方向のTransformerエンコーダ(Vaswani et al., 2017)を使用します。 具体的には、SCODE-Rのコードとサマリーのエンコーダーとして、CodeBERT (Feng et al., 2020b) とGraphCodeBERT (Guo et al., 2021) を探索します。 入出力 SCODE-Rは、入力配列x(コードまたは要約)を受け取り、出力配列Yのデータベースから関連するドキュメントのセットを検索します(入力がコードの場合、出力は要約となり、その逆もあります)。 SCODE-Rは、上位k個の出力シーケンス{Y1, Y2, ... ... , Yk}を返します。 SCODE-R は、sim(x, Yi) ≥ sim(x, Yj)∀j > i となる上位 k 個の出力シーケンス {Y1, Y2, ... , Yk} を返します。 トレーニング コードとサマリーの並列例 (xi , yi ) を使って、SCODE-R を微調整します。 2.2 節で述べたように、DPR は当初、バッチ内の否定文と BM25 で取得したオープンドメイン QA 用の「ハード」な否定文を用いて学習することを提案していました。 しかし、オープンドメインQAとは異なり、DPRは、バッチ内ネガティブと、BM25で検索された文章の「ハード」ネガティブを用いて学習します。 しかし、オープンドメインQAとは異なり、検索されたコードや要約がターゲットではない場合でも、コード生成や要約に役立つ可能性があります(§6で検証)。 図3にその例を示すが、検索されたコードは目的のコードとは一致しないが、コード生成を容易にすることができる。 そこで、SCODE-Rを「難しい」否定語なしで学習させます。 具体的には、各学習インスタンス(xi , yi )について、対応する出力 yi を正とし、その他のバッチ内出力(すなわち、同じバッチ内の他のインスタンスの出力 - y1, ... ... , yi-1, yi+)を負とします。 図4は、コード生成タスクに対するSCODE-Rのファインチューニングの例を示しています。

3.2 Generator: SCODE-G

REDCODERのジェネレータモジュールとして、2.3節で述べたPLBARTを採用し、SCODE-G(Summary and CODE Generator)と呼ぶことにする。 入力配列xは、検索された上位k個の配列と連結され、拡張入力配列x ′ = x⊕Y1⊕Y2 ... .⊖Ykとなる。 増強された入力 x ′ は PLBART に供給され、pgen(y∣x ′ ) が推定されます。 ソースコードにはdocstringやコメントが含まれていることが多く、それらを抽出することでコードと要約のペアを形成することができます。 検索データベースでは,コードと要約は単一であるか(例えば,説明文のないコードやコードのない問題文など),並列であるかのどちらかです. そこで、生成器に別々のモデリングを考慮する必要がある2つの検索設定を考える。 ケース 1: 検索候補がシングルトンの場合 この場合、元の入力シーケンス x と上位 k 個の検索候補を特別なセパレータ・トークンで連結する。 x ′ = x [csep] Y1 [csep] Y2 . .. . [csep] Yk.

これは我々のデフォルトの設定であり、本稿ではこれを REDCODER と呼ぶ。

このケースでは,検索された候補はコードと自然言語(NL)の要約のペアである. x ′ = x [csep] Y1 [nsep] X1 [csep] Y2 [nsep] X2 ... ...となる。

[csep] Yk [nsep] Xk ここで、Xj と Yj はデータベースから取得した並列シーケンス(例えば、Yj はコードの一部で、Xj はコード生成タスクのためのその対応する要約)である。 我々は、追加情報Xjが入力配列xを補完すると推測し、実験でその有効性を検証する。 検索候補は,シングルトンとペアが混在している可能性があることに注意してください. シングルトンの候補の場合、XjまたはYjを空の文字列に置き換えるだけである。 この設定をREDCODER-EXTと呼ぶことにする。 REDCODER-EXTは、ケース1を含むより一般的な設定であるが、これらの2つの検索設定が、対象となるタスクにどのような利点をもたらすかを理解するために、別々に研究する。 図5は、コード生成の例を示したものである。 どちらの場合も、拡張された入力x ′は、(PLBARTの最大入力長に合わせて)最大512トークンを持つように切り詰められている

image