Sourcery

Sourcery は AI コードレビューツールである。AI 支援型ソフトウェアエンジニアリングに関する Phodal の書籍は、コードレビューの章で、LLM ベースのレビュアーがどのように設計されるかを示す実例としてこのツールを取り上げ、Sourcery 自身が公開している複数の記事を要約している。その内容は、変更に不要な複雑さがないかをどのようにチェックするか、どのようにプロンプトを書くか、LLM の出力をどのようにテストするか、そして生成するコメントの有用性をどのように高めるか、である。

機能

レビューにおける複雑さへのアプローチは、難しい問題に内在する本質的な複雑さではなく、偶有的な複雑さ ― タスクが必要としないのにコードに持ち込まれた複雑さ ― を対象としている。章が依拠する Sourcery の記事は、レビュアーが注目すべき 4 つの兆候を挙げている。既存の機能を作り直していたりコードを重複させていたりするコード、1 つの単位があまりに多くのことをしようとする分離の欠如、深いネストや高い認知的複雑度・循環的複雑度、そして将来の機能や起こりそうもないエッジケースを不必要に先取りするといった過剰設計である。

レビューのパイプラインは、LLM に単により多くのコンテキストを与えることは収穫逓減をもたらし、誤検知やハルシネーションを生んで精度を損なうおそれがあり、コストもかかる、という見方を軸に構築されている。そのため処理は段階的に進む。まず差分を、同じ関数やクラス内の変更など、関連する変更からなるアトミックなチャンクに分割する。次に、新しい import やごく小さな変更など、ヒューリスティックなチェックによって複雑さに影響しえないと分かるチャンクを、LLM を介さずに除外する。残った各チャンクを、必要な周辺の行で拡張する。LLM にその推論を開発者にとって有用なコメントへと変換させる。そして最後に、各コメントを別の LLM リクエストに送り、一般的すぎる場合は破棄させる。章によれば、Sourcery の実験ではこの最後のフィルタによって誤検知の大半が取り除かれ、また章が説明する実例では、この多段階の設計は、拡張したコンテキストを用いる単一のリクエストよりもはるかに少ないトークンしか使わなかった。

章の Sourcery の例は、差分によってどの docstring の更新が必要になるかを判断するためのプロンプトを用いて、専門家パネル・プロンプティングの手法も示している。Sourcery の LLM 出力は、通常のユニットテストとほぼ同じように pytest でユニットテストされる。テストはコメントの正確な文言をチェックするのではなく、LLM が固定の選択肢の中からコメントに割り当てた種類がその差分に期待される種類と一致するかを確認し、期待されるキーワードやテーマを探し、称賛のような無関係なフィードバックが含まれていないことを確かめ、コメントが正しい行に付けられているかをチェックする。LLM の出力はばらつくため、CI はある程度の失敗を許容し、LLM テストの 95% が合格することを要件としている。

生成されるレビューコメントを改善するにあたっては、正確さよりも、プルリクエストの作成者にとっての有用性 ― 生成されたコメントのうち有用と判断されたものの割合として測定される ― をより重視している。プロンプトを調整したり、LLM にコメントの有用性を説明させたりすることの効果は限られていた。モデルは自身の出力が有用であると確信しがちだからである。効果があったのは、各コメントをいくつかの基準 ― コードとの関連性、実行可能性、具体性、作成者にとっての価値 ― に照らして検証し、それらを組み合わせてコメントをフィルタリングすることだった。

採用とエコシステム

Sourcery は、独自の実例セクションに加えて、章の「その他の AI コードレビューツール」の一覧にも、Greptile、Codeant AI、Bito、Sweep AI といった製品と並んで登場する。章は CodeRabbit と PR-Agent については、それぞれ独立したセクションで取り上げている。