はじめに
大規模言語モデル(以下LLM)にコードレビューさせるシステムを設計する.
環境設定
- Pull RequestやMerge Requestの情報だけを使う
- branchをcheckoutしたりはしない
- ファイルパス指定でのコンテンツ取得はOK
- 検索系APIは使わない
LLMの特性
まず、LLMは確率の高い次の文を生成しているだけ, 本当にそれだけ.
コンテキストが少ないと妄想を始める
++ FILE* file = fopen(path, "rb");
-- FILE* file = fopen(path, "wb");
このようなdiffだけで, "レビューしてください"と投げると, なんとかレビューをしようと妄想を始める. 人間ならブチギレて突き返すか, 金輪際関わらないようにする. LLMはそれができないので, 妄想してでもレビューを書こうとする.
とにかく褒める
コードレビューで褒める意味は, 次の2点である. LLMに褒めさせる理由はひとつもない.
- コミュニケーション
- reviewerの気付き
- こんな良い方法があったのかという気付き
LLMは人間の評価を報酬に強化学習しているので, とにかく褒める. そのように学習されている.
言語モデルに褒めさせると何が起こるか?始めに褒める箇所が無くなるまで, 妄想してでも褒める. ポジティブ→ネガティブの流れの方が, 人間の印象が良いからだ.
褒める箇所が無くなると, やっと自分の責務に戻ろうとする. しかし, 絶賛の嵐から不具合の指摘へ遷移する確率は低い, ので, 捏造してでも不具合の指摘を始める.
タスクを増やすと、レビューの質が落ちる
よくある?のかは分からないが, ペルソナや語尾を指定すること. 女性のゲームキャラクターを指示している事例を知っているので, これを例にする.
先ず平均的な女性のイメージになることが多い(女性軽視とかではない, 原理的にLLMはそういう出力をする). 優しい, 柔和, 明るい等の性格付けをすると, さらに褒めちぎる、レビューと関係ないお喋りを挟む, など目的のレビューから離れていく傾向にある. さらに悪いことに, 鋭い指摘はしなくなる. 人間の評価が悪いからだ.
語尾を変えさせるのも良くない. 語尾がござるの日本語のレビューを見たことがあるか?学習データにないことをさせるのは余計なタスクだ. フロンティアモデルは余裕でこなすが, レビュー品質が良くなることは絶対にない.
それでも, やりたいなら, 二段階にする方がましだ. まず標準語で出力させて, 次に口調やキャラクターを変えさせる. これでも, 重要なニュアンスが壊れる可能性もあるし, やはりレビュー品質が良くなることはない.
出来得る限り大量に指摘する
LLMのベンチマークは整合性が取れた長い文章を評価する傾向にある. LLMにポン出しさせた記事は, 一行で済む内容を薄く薄く何段落もかけて説明するのを見たことがあると思う. コードレビューでも, 妄想・捏造してでも指摘を盛ろうとする.
システム設計
LLMの特性を踏まえて, システムを設計する.
- 褒めさせない.
<<SYS>>You are a strict and accurate code reviewer.<</SYS>>だけで止まる - タスクを少なくするために, 2段階にする
- 1段階目: インパクトを付けながら, 列挙させる
- 2段階目: インパクトでフィルターしながら, 文章を整形させる
- プロンプト設計
- DRY原則, KISS原則など, 常識的なことはLLMは知っているので, プロンプトに入れない
- 妄想させない
- 指摘が無ければ,
問題は見つかりませんでしただけ出力させる - コードが唯一の事実で, 事実を妄想させない
- 指摘が無ければ,
- コンテキスト拡張
- diffを前後のブロックまで広げる
-
include,import, シンボル一覧や関数呼び出し関係など, 情報を追加する
まとめ
簡単に止められるとは言え, 褒める傾向が結構な悪影響を及ぼすと思う. ペルソナを指示するのは論外だ.