「なぜか行が重複してしまう現象が発生し、patchコマンドが成功しなかった。もっとぐちゃぐちゃになった例もあり、記号の有無や行の順番が誤っている、一部の行が抜けているなどの不完全な形式で出力されることが多くあった」
この失敗の原因について、山西さんは出力フォーマットが複雑すぎるのが原因では考察。しかし、他のアイデアも思い浮かばず、約2割の確率で成功することも場合もあることから、いったんこの形で妥協したという。
また、形式的には正しくてpatchが成功する場合でも、何も変化が起こらない様な意味をなさない差分が返される場合もあった。「変更対象のファイルを与えるだけでは、AIが十分に推測できず、苦し紛れの様な回答をするのでは」と考えた山西さんは、十分な事前情報をAIに与えることを思い付く。そこで今度は"型注釈をしたいメソッドの呼び出し元のコード"を与えることにした。しかし、AIは追加したコードを意図通りに活用してはくれず、この方法もうまくはいかなかった。
他にも、さまざまな試行錯誤をしたが、ほぼ全てが徒労に終わり、この時点での型注釈のタスク全体の成功率は体感約1割ほどだったという。その後も何度もリトライを続けていたが、らちが明かなかったため、一度失敗事例を整理することにした。そこで上がったのは、大きく3つの失敗要因だった。
1つ目の要因は「失敗率が高い」という点だ。例えば、先述のdiffの例では、注意点をプロンプトで指示しても失敗率が下がることはなかった。この点について、山西さんは「実は失敗率を大幅に改善する方法なんてないのでは?」という仮説に行き着く。それを踏まえ今度は、1つのタスクを“失敗率の低いタスクに分割する方法”を試してみることにした。
今まではファイル全体に型注釈をつけることを依頼していたが、それをメソッドごとにつけるような指示へ分解。5つのメソッドがあれば、5回AIとやりとりをして、順番に処理を進めると、この方法がうまくいき、失敗率が8割から2割程度まで改善できたという。
「なぜこれまで分割をやってこなかったかというと、従来のプログラミングでいうとリファクターに近いと思っていた。大きなメソッドを5つの小さなメソッドに分解しているのと同じで、これで動作が改善するとは考えていなかった。しかし、生成AIはその通りではないと実感できた」
2つ目の要因に挙げたのは「失敗のパターンが多い」ことだ。失敗率が2割まで改善できたものの、その中にはさまざまなパターンの失敗例が残っている。それら全ての失敗の仕方を事前に網羅していくのは無理があるため、失敗したときにフィードバックをできる方法を考えた。
Copyright © ITmedia, Inc. All Rights Reserved.