言語処理学会 第30回年次大会 発表論文集（2024年3月）

コード生成のための大規模言語モデルを用いた検索手法
中原 康宏 宮下 大輔 出口 淳
キオクシア株式会社yasuhiro1.nakahara@kioxia.com

概要
Large Language Model によるプログラムコード生成は有用であるが，LLM が持つ情報の更新には膨大なコストが必要である．この課題に対応するために，関連する情報を検索し LLM への入力に追加する手法が提唱されており，コード生成の分野ではBM25 などのベクトル検索を用いた手法が成果を挙げている．しかし，GitHub のような Web サイトをデータベースとする場合，全データを手元に置く必要のあるベクトル検索はデータ収集に膨大なコストを必要とし，常に情報を最新に保つことは困難である．よって，本論文では GitHub API がサポートしている既存の Web 検索と LLM を用いた検索手法を提案する．これにより，提案する手法は低コストで常に最新の情報にアクセスすることができる．本手法
は Web 検索と LLM を組み合わせる際に生じるいく
つかの典型的な課題にも対応している．提案手法を評価した結果, 有用なリポジトリを見つけ出すことができたことを確認した．

1

はじめに

近年，Large Language Model (LLM) によるプログ
ラムコード生成が大きな注目を集めている [1]．そのため，コード生成に向けた LLM が多数リリースされている [2, 3, 4]．しかし，これらのコード生成用
LLM は情報更新のために高いコストを必要とする点が課題である．プログラミングの世界では日々新規ライブラリの提案やライブラリの更新がなされている．コード生成用 LLM がこれらの更新を取り入れるためには，一般的には学習と呼ばれる時間的，電力的に高コストな処理が必要である [5]．よって，最新のライブラリに対応するために頻繁に LLM を更新することは難しい．
この課題を解決するために，LLM と検索を組み合わせた Retrieval Augmented Generation (RAG)[6] という手法が提唱されている．RAG は LLM の処理に関連する情報を検索し，その検索結果を LLM への入力に含めることで LLM に追加の情報を与える手法である．これにより，LLM は学習することなく最新の情報を反映したコードを生成することができる．先行研究 [7, 8, 9] では検索に BM25[10] や Dense
Passage Retrieval (DPR)[11] などのベクトル検索を用いた RAG によってコード生成の性能向上を達成している．しかし，これらの手法では Web サイトをデータベースにすることは難しい．なぜなら，DPR
や BM25 を実行するためにはデータベースの全情報を参照する必要があるためである．そのため，Web
サイトをデータベースとする場合は検索のために全ての情報を一度ダウンロードしなければならない．
これは多大な時間的コストを必要とし，情報を最新に保つために頻繁に行うことは現実的ではない．また，本行為は Web サイトの利用規約により禁止されている場合もある．GitHub や StackOverﬂow などプ
ログラマにとって有用な情報源となる Web サイト
は多くあるため，これは重要な課題である．
これを回避するための手法の一つとして，Web
サイト側が提供している検索機能を利用する手法が挙げられる．例えば，GitHub は「LLM chat」などとキーワードを用いて検索するキーワード検索をApplication Programming Interface (API) で提供している．キーワード検索を活用することで，最新の情報を低コストで取得できる．だが，キーワード検索にも大きく 2 つの課題が存在する．1 つは検索結果からデータを更に絞り込む必要がある点である．ベク
トル検索では最も類似度の高いデータを選択すればよいが，キーワード検索では複数の検索結果から1 つを選ぶ必要がある．この際，正しく有用な情報を選べなければ，生成コードの品質を向上させることはできない [12]．本論文ではこの課題に対してLLM を用いて有用なデータの絞り込みを行うことで対応する．この際に生じる 2 つ目の課題が，LLMに入力可能な文字数が限られている点である．この課題に対しては，絞り込みの際に以下の 3 つの工夫

― 3309 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).

図 1 提案手法の処理の流れ点をツールに組み込み，LLM に一度に入力する文

良い．そのため，本手法ではリポジトリの絞り込み

字列の長さを削減することで対応する．

とファイルの絞り込みの 2 段階に分割して絞り込みを行う．

• 絞り込みを 2 段階に分割• LLM で README.md を要約してから比較

2 点目は LLM でリポジトリの絞り込みを行う際• コードをプロンプトに含めずに絞り込むに，README.md 本体でなくその要約を入力に使用

RAG の有効性は先行研究 [7, 8] によって既に明らかにされているため，本稿では検索手法に注目して議論を行う．データベースとする Web サイトは最新のライブラリやコード例が多数投稿されている
GitHub とする．LLM で生成した 10 個の要望対して本手法を用いて検索を行った結果，8 個の要望について有用なリポジトリを選択でき，6 個の要望について有用なコードを選択することができた．

トリごとに大きく異なる．よって，比較のために複数の README.md を読み込んだ場合，リポジトリによってはトークン数の制限を超えてしまう可能性がある．したがって，LLM を用いて README.md を短く要約することで，トークン数を削減している．
3 点目はプログラムコードを LLM に読み込ませないという点である．プログラムの規模はリポジト

提案手法

2

する点である．リポジトリの内容を理解するために
README.md は有用であるが，その大きさはリポジ

リによって大きく異なるため，大規模なリポジトリのコードを LLM に読み込ませるとトークン数の制

2.1

概要

限を超えてしまう可能性がある．よって，本手法で本手法は GitHub API を用いて Web 検索を行った
後に検索結果を絞り込み，コード生成に有用ないく
つかの python ファイルを提案する手法である．Web
検索で使用するキーワードの生成や検索結果の絞り込みには LLM を用いる．python ファイルの提案までの工程は全自動で実行され，ユーザは要望を入力するだけで良い．
LLM に入力できるトークンの数には限りがある
ため，本手法では絞り込みの際に以下に示す 3 点を考慮して絞り込みのアルゴリズムを構築している．
1 点目は絞り込みを 2 段階に分けている点である．
全ての情報を加味して一度に必要なデータを判断することが，判断の正確性という点では良い手法であると考えられる．しかし，トークン数の制限を考慮
すると LLM に一度に与えるデータは少ないほうがはコード本体ではなく README.md やファイル名などを絞り込みのための指標としている．

2.2

処理の流れ

本節では，提案手法の処理の流れを具体例を用いて述べる．例で用いるユーザの要望は「OpenCALMを用いたチャットボット」とする．要望の詳細は付録 A に示す．提案手法の処理の流れを図 1 に表す．
ま ず，提 案 ツ ー ル は LLM を 用 い て 要 望 か ら
シ ン プ ル な 3 つ の 検 索 キ ー ワ ー ド を 作 成 す る．
チャットボットの例では “chatbot”，“OpenCALM”，“log” の 3 つのキーワードが生成された．その後，GitHub API を用いてこれらのキーワードを組み合わ せ た 6 パ タ ー ン の 検 索 を 行 う．チ ャ ッ ト ボ ットの例では “chatbot”，“OpenCALM”，“log”，“chatbot― 3310 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).

OpenCALM”，“chatbot log”，“OpenCALM log” を検索python コード，リポジトリ内に存在する python ファに用いる．キーワードを組み合わせるのは “app”，

イルのリストについてのトークン数を評価する．

“list”，“log” など単体では意味をなさないキーワー

次に，提案ツールがどの程度要望から適切なコードを生成する場合があるためである．これらのキードを検索できるのかについて評価を行う．コード生

ワードで検索した結果からそれぞれ指定した件数の成に対する RAG の有効性は既に示されているため

リポジトリを手元にダウンロードする．検索の際，[7, 8]，本評価では検索にのみ注目して評価を行う．

リポジトリは python を使用言語としているものを

トークン数の評価で使用した 10 個の要望に対して，指定して検索している．

有用なリポジトリをいくつ検索できたかを評価す

次 に，検 索 結 果 か ら 有 用 な リ ポ ジ ト リ を 絞 りる．提案システムが選択したリポジトリ，ファイル

込む．最初に各リポジトリの README.md を 200

についてそれらが要望を達成するために有用である

単語程度に LLM を用いて要約する．要約の際にかを人間1）が有用，一部有用，使用不可の 3 段階でREADME.md が LLM に入力可能なトークン数の上評価する．少しのコード修正で要望を達成可能なも限を超える場合，トークン数が収まるように文末かのを有用，要望達成のためにある程度機能の追加がら文字列を削ることで対応する．その後，LLM を用いて有用なリポジトリを絞り込む．この際，LLM

必要なものを一部有用，要望の達成に使用できないものを使用不可とする．リポジトリとファイルの絞に入力する情報はリポジトリのタイトル及び要約のり込みにおいて，それぞれ最小 1 つ，最大 3 つのもリストである．チャットボットの例では 3 つのリポのを提案するように LLM に指示する．提案システ

ジトリ [13, 14, 15] に絞り込まれた．これらのリポジ

ムが一つの要望に対して複数のリポジトリやファトリはいずれも OpenCALM をダウンロードして推イルを提案した場合，最も良い結果を最終結果とす論までを実行するコードを含むリポジトリであるた

る．LLM は GPT-3.5 turbo（ver. 0613）を使用する．

め，コード生成に有用である．コード生成は絞り込
んだリポジトリそれぞれに対して行い，その中から3.2

評価結果と考察

リポジトリがもつデータ量についての評価結果

最も要望に近い物を採用する．
最後に，それぞれのリポジトリについて有用なを表 1 に表す．表 1 より，python ファイルのトーファイルを絞り込む．はじめに，各リポジトリか

クン数の中央値は 10,045 であった．今回使用する

ら python ファイルを抽出し，それらの名称をリス

GPT-3.5 turbo が扱えるトークン数は 4,096 であるた

トアップする．リストアップの際は，[src/xxx/aaa.py,

め，半数以上のリポジトリでコードを扱うことがexamples/bbb.ipynb] の よ う に リ ス ト 形 式 で フ ァ イ
ル の パ ス を 列 挙 す る．そ の 後，リ ポ ジ ト リ 名，できない．詳細を確認した結果，入力トークン数
が 4,096 以下のリポジトリは約 34%であった．出力

README.md ファイル，リストアップしたファイル

トークン数も加味すると，python ファイルを処理

名を LLM に入力し，最良のファイルを選択する．

可能なリポジトリの割合は更に減少すると考えら以上の手順により絞り込んだファイルを要望とともれる．よって，絞り込みのために python コードをに LLM に入力することで，リポジトリの情報を加LLM に入力することは難しいと言える．
また，README.md のトークン数は中央値で 583

味したコード生成を行うことができる．

3

評価

3.1

評価条件

であった．仮に中央値である 25 個のリポジトリ間での比較を行った場合，トークン数は 14,575 となり上限を大きく超える．対して要約のトークン数は中央値で 100 と大きく削減されており，同様の比較をまず，先に述べたトークン数を削減するための 3行った場合トークン数は 2,500 と処理可能な範囲内

つの工夫点について，それらの有効性について評価に収まる．このように，README.md を要約する手する．評価のためのユーザの要望は LLM を用いて法はトークン数削減に有効であることが分かる．

作成した．この時，恣意的な評価とならないよう要

次に，ファイルリストのトークン数に注目すると，中央値が 72 と少ない．しかし，リポジトリの絞

望の具体的な内容は指定しない．要望の詳細は付録
B に示す．この要望について検索までを行い，絞り込みの対象となったリポジトリの README.md やり込みとファイルの絞り込みを一度に行おうとする
1） 判定は筆頭著者の中原康宏が行った．

― 3311 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).

表1

リポジトリがもつデータ量についての評価結果

最小平均
要望当たりのリポジトリ数
1825
リポジトリ当たりの python ファイル数
0121
README.md のトークン数（文字数）0 (0)1,982 (6,578)
要約のトークン数（文字数）
7 (36)a100 (524)
リポジトリ当たりの0 (0)b 205,736 (826,109)
python コードのトークン数（文字数）
ファイルリストのトークン数（文字数） 2 (1)c
1,679 (5,876)

最大

中央値

30
4,727
79,185 (190,638)
285 (1,362)25
11583 (2,026)
113 (588)

8,069,997 (33,260,608)

11,045 (40,469)

94,556 (1,451,410)

72 (261)

a README.md が無い場合，要約でその旨を記述するため文字数が 0 ではない．
b 検索結果に python ファイルを持たないリポジトリが存在したため．
c python ファイルが存在しない場合，ファイルリストは [] と記述するため．

例を示したコードを選択せず，func.py などプログラ

表2

検索結果の有用性についての評価結果
アプリ名
リポジトリ
コード
記事推薦
一部有用
一部有用
時計
一部有用
一部有用
音楽
有用
使用不可
ニュース
有用
一部有用
料理レシピ
一部有用
使用不可
買い物リスト
使用不可
使用不可
予定管理
有用
一部有用
交通状況
使用不可
使用不可
翻訳
一部有用
一部有用
天気予報
有用
有用

ムの一部を指定した．このようなファイルは有用である場合もあるが使用例などよりは有用度は低い．
また，有用な情報を取得できないケースとして，大規模なリポジトリを選択したというケースもあった．プログラムが大規模である場合，一部のファイルを参考にしてもその活用に別のファイルの情報を必要とする場合が多い．よって，どのファイルを選択してもコード生成の参考にはならない．
これらの絞り込みに失敗したケースについては，要望と合致するリポジトリが検索結果に存在しないと（README.md 要約＋ファイルリスト）×（リポケースを除き，検索する範囲，LLM に与える情報，

ジトリ数）のデータが必要となるため中央値で計算

LLM へ入力するプロンプトの文言などを調整する

してもトークン数の上限に達してしまう．対して絞ことで対応可能であると考えられる．

り込みを分けた場合，要約の代わりに README.md

以上より，提案手法は 3 つの工夫点により LLM

本体を使用したとしてもトークン数に十分な余裕がのトークン数制限を回避しながら情報の絞り込みが生まれる．加えて，README.md にはファイルの絞できる事が分かった．また，本手法は要望に合致す

り込みに有用なデータが含まれていることも多くあるリポジトリが多く存在する場合には，有用な情報

り，README.md 本体を使用することによる精度向にアクセスできると言える．

上も見込める．そのため，絞り込みを 2 段階にする
ことはツールの安定実行に貢献すると考えられる．
本稿で提案した検索の有用性についての評価結

おわりに

4

本稿では RAG のための新たな検索手法を提案し果を表 2 に表す．リポジトリでは 8/10，コードではた．本手法は Web 検索と LLM を組み合わせた検索

6/10 の割合でコード生成に有用な情報を取得することができた．一方で，一部の要望については有手法であり，先行研究の課題である情報を最新に保つことが困難であるという点を解決している．ま用な情報を取得することができなかった．これは，た，提案手法は Web 検索導入に伴ういくつかの課題

GitHub 上に求めるリポジトリが少ないことが原因に対応している．LLM を用いて生成した 10 種の問の一つだと考えられる．例えば買い物リストアプリ

題に対して本手法を適用した結果，8/10 で適切なリの場合，生成された検索キーワードは “shopping”，

ポジトリを，6/10 で適切な python ファイルを選択す“list”，“application” と妥当なものであるが，検索結ることができた．よって，本手法は要望と合致した

果はショッピングサイト向けのカートの実装が殆ど

リポジトリが多く存在する場合において有望であるであり求めるリポジトリは存在しない．交通状況アと言える．また，今後取り組むべき課題として絞りプリについても同様であった．

込みが失敗するケースにいくつかのパターンがある

また，コード選択で誤ったものを選択していることが確認できた．

ケースもあった．本ケースでは example.py など使用

― 3312 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).

参考文献[1] Bei Chen, Daoguang Zan, Fengji Zhang, Dianjie Lu,
Bingchao Wu, Bei Guan, Yongji Wang, and Jian-Guang
Lou. Large language models meet nl2code: A survey. In
ACL 2023, June 2023.
[2] Yue Wang, Hung Le, Akhilesh Deepak Gotmare,Nghi D.Q. Bui, Junnan Li, and Steven C. H. Hoi. Codet5+:Open code large language models for code understanding
and generation. arXiv preprint, 2023.
[3] Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo
Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei
Lin, and Daxin Jiang. Wizardcoder: Empowering codelarge language models with evol-instruct. arXiv preprint
arXiv:2306.08568, 2023.
[4] Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten
Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu
Liu, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov,
Ivan Evtimov, Joanna Bitton, Manish Bhatt, Cristian Canton Ferrer, Aaron Grattaﬁori, Wenhan Xiong, AlexandreDéfossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis
Martin, Nicolas Usunier, Thomas Scialom, and Gabriel
Synnaeve. Code llama: Open foundation models for code,
2023.
[5] Or Sharir, Barak Peleg, and Yoav Shoham. The cost of
training nlp models: A concise overview, 2020.
[6] Linmei Hu, Zeyi Liu, Ziwang Zhao, Lei Hou, Liqiang Nie,and Juanzi Li. A survey of knowledge enhanced pre-trained
language models. IEEE Transactions on Knowledge
and Data Engineering, pp. 1–19, 2023.
[7] Md Rizwan Parvez, Wasi Uddin Ahmad, Saikat
Chakraborty, Baishakhi Ray, and Kai-Wei Chang. Retrieval augmented code generation and summarization. In[13] Github:naltoma/open-calm-ﬁnetuning,（202312 閲 覧）.
https://github.com/naltoma/
open-calm-finetuning.
[14] Github: miyakei1225/OpenCALM-7B-SandBox, （202312 閲 覧）.
https://github.com/miyakei1225/
OpenCALM-7B-SandBox.
[15] Github: hirok-to-i/CALM CA LLM CPU API, （202312 閲 覧）. https://github.com/hirok-to-i/CALM
CA LLM CPU API.

Findings of the Association for Computational Linguistics: EMNLP 2021, pp. 2719–2734, 2021.

[8] Shuyan Zhou, Uri Alon, Frank F. Xu, Zhiruo Wang, Zhengbao Jiang, and Graham Neubig. Docprompting: Generating code by retrieving the docs. In International Conference on Learning Representations (ICLR), Kigali,
Rwanda, May 2023.
[9] Shuai Lu, Nan Duan, Hojae Han, Daya Guo, Seung won
Hwang, and Alexey Svyatkovskiy. Reacc: A retrievalaugmented code completion framework, 2022.
[10] Stephen Robertson and Hugo Zaragoza. The probabilistic
relevance framework: Bm25 and beyond. Found. Trends
Inf. Retr., Vol. 3, No. 4, p. 333–389, apr 2009.
[11] Vladimir Karpukhin, Barlas Oğuz, Sewon Min, Patrick
Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen
tau Yih. Dense passage retrieval for open-domain question
answering, 2020.
[12] Shangwen Wang, Mingyang Geng, Bo Lin, Zhensu Sun,
Ming Wen, Yepang Liu, Li Li, Tegawendé F. Bissyandé,and Xiaoguang Mao. Natural language to code: How far
are we? In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering,

ESEC/FSE 2023, p. 375–387, New York, NY, USA, 2023.
Association for Computing Machinery.

― 3313 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).

A

処理の流れで用いた要望
2.2 節で例として使用した要望を以下に示す．

Create a chatbot using OpenCALM.
OpenCALM is a large language model.
The program ﬂow is as follows
1. wait for input from the user.
2. input the user input to OpenCALM and print the OpenCALM’s answer.
3. return to 1.
Add the previous conversation to the input from the user before entering it into OpenCALM so that OpenCALM canremember the previous conversation. Save the conversation in log.txt.

B

評価に用いた要望
評価で用いた 10 個の要望は GPT-3.5 turbo（ver. 0613）に以下のプロンプトを与えて作成した．“生徒にプログラムを作成させる問題を作りたい。ユーザがこういうプログラムを作りたいと要望している風の問題をいくつか作ってほしい。解かせるためだけのプログラムではなく実用的なプログラムが良い。”
作成した 10 個の要望を表 3 に示す．生成された要望は日本語であったが，トークン数削減のため英語に翻訳している．
表 3 LLM を用いて生成したユーザの要望

アプリ名

本文

記事推薦

Article recommendation application: Create an application that uses the API to present articles
of interest to the user. Allow users to select topics and genres of interest.

時計

Clock app: Create an app with the basic functions required for a clock app, such as digitalclock, alarm, stopwatch, timer, etc.

音楽

Music Player: Create a player application that allows users to play, stop, skip, and create
playlists of music. If necessary, artist information and album art will also be displayed.

ニュース

News App: Create an app that uses RSS feeds to provide users with the latest news articles.

料理レシピ

Recipe App: Create an app that allows users to register their own recipes and upload names,
ingredients, processes, and photos.

買い物リスト Shopping List: Create an application that allows users to create a list of products to bepurchased and add prices and quantities.
予定管理

Task Manager: Create an application that can track tasks created by the user. Task priorities,
due dates, status, etc. will be displayed.”

交通状況

Traﬃc jam forecasting application: Create an application that acquires real-time traﬃc information and provides users with locations and times when traﬃc jams are expected.

翻訳Translation App: Create an application that provides online translation services to users. The
text entered by the user can be translated into the speciﬁed language.

天気予報

Weather apps: Create apps that provide weather information. This includes today’s weather
forecast, weekly weather, local weather, etc.

記載されている社名・商品名・サービス名などは，それぞれ各社が商標として使用している場合があります．

― 3314 ―This work is licensed by the author(s) under CC BY 4.0(https://creativecommons.org/licenses/by/4.0/).