Code review as Attention
AIコーディングの台頭によって、ソフトウェアエンジニア界隈で「レビュープロセスのあり方」が改めて議論の的になっています。そんな流れの中で、ふと、ソフトウェア開発におけるレビューと、LLMの注意ヘッド(Attention Head)の役割が、似ているのではないかという考えに至りました。
私は最近オライリーの『直感 LLM』を読んだ程度の、LLMの仕組みの概念を掴み始めたくらいの入門者です。なので、以下は非専門家のただの思いつきの内容として捉えてください。
そもそもアテンションヘッドとは、Transformerモデルにおいて、入力されたデータの「どこ」に注目すべきかを判断する仕組みのことです。一つのヘッドがすべての関係性を追うのではなく、複数のヘッドが並列で動き、それぞれが「主語と述語の関係」「代名詞が指す対象」「特定の技術用語」など、異なる視点から情報の重み付けを行います。これによって、単なる文字列の羅列から、文脈(コンテキスト)という深い意味を抽出できるわけです。
この仕組みをレビューに当てはめると、案外しっくりきます。
私たちがレビューを行うとき、ただ目の前のコードを一行ずつ読んでいるわけではありません。過去の学習や経験、あるいは直接コードには書かれていない過去の設計判断や将来の拡張性といった、時間軸の離れたコンテキストまで遡って情報を拾ってきます。その上で、今の成果物が適切かどうかを評価し、必要であれば修正を担保する。これはまさに、今のトークンを処理するために過去のコンテキストにアテンションを飛ばす、LLMの内部プロセスそのものだと言える、と思えてきます。
さらに言えば、プロダクトデザインから実装までの流れ全体も、一つの大きな、もしくは多層のトランスフォーマーのように捉えることができます。
プロジェクトには、PdM、デザイナー、セキュリティ、カスタマーサクセスなど、多くのステークホルダーが関わります。彼らをそれぞれ独立した注意ヘッドに見立ててみる。あるヘッドはビジネスの妥当性に強い重みを置き、別のヘッドはユーザー体験に、また別のヘッドは堅牢性にアテンションを向ける。
こうした多角的な注意が重なり合うことで、ただの機能要件という入力値が、整合性の取れたプロダクトへと変換(エンコード・デコード)されていく。そう考えると、どこかのヘッドがうまく機能しなかったり、ノイズに過剰に反応してしまったりしたときにプロダクトの品質が落ちるのも、モデルの推論が失敗するのと似た構造に思えてきます。
もちろん、これは一つのアナロジーに過ぎません。ですが、日々の泥臭いレビューや調整のプロセスを「コンテキストを適切に拾い上げ、重み付けを行うための高度な推論プロセス」だと捉え直してみる。それだけで、AI時代のプロダクト開発に関わる人々が担うべき役割が、少しだけクリアに見えてくるような気がしています。
参考
- オライリー『直感LLM』 https://www.oreilly.co.jp/books/9784814401154/
- ジョイジョイジョイ 『LLM のアテンションと外挿』https://joisino.hatenablog.com/entry/heads