【RubyKaigi 2024】型特集！型の最新情報についてセッションレポート #rubykaigi

内容

こんにちは！RubyKaigi 2024でHydration Sponsorをしているスマートバンクです！

最終日のレポートでは、RubyKaigi 2024でホットな話題となっていたRubyの「型」をテーマにしたセッションのレポートをお送りします！ Rubyの型にまつわる最新動向をお楽しみください！！

Day1

Let's use LLMs from Ruby 〜 Refine RBS codes using LLM 〜

黒曜さんのセッションでは、Rubyコードから RBS型を推測するツール「Ruby Goose」を作った経緯や、その仕組について説明されました。

以下に、その内容を簡単にまとめさせていただきました。詳細については、発表資料をご覧ください。

このあとB会場で発表する「Let's use LLMs from Ruby 〜 Refine RBS type definitions using LLMs」のスライドです！見づらかったりリンク踏みたいときにご利用ください！ https://t.co/3vkwC369l9 #rubykaigi #rubykaigiB
— 黒曜@Leaner Technologies (@kokuyouwind) 2024年5月15日

RBSはRubyの型構造を定義するための言語で、型検査による安全な開発や補完による開発体験の向上が期待できます。RubyからRBSを生成する既存手法には以下のものがあります。

静的構文解析（例: rbs prototype rb config.rb）
動的ロード（例: rbs prototype runtime -R config.rb Config）
型レベル実行（例: typeprof config.rb）

しかし、これらの手法にはそれぞれ一長一短があり、一発で完璧なRBSを生成するのは難しいです。特に、untypedを直したり、足りないものを補うのは大変です。

RBS Gooseは、先述のいずれかの方法で生成したRBSファイルの雛形を入力として使用します。RubyとRBSファイルを入力・出力例として与え、すべてのRubyファイルをまとめて一度に推論させます。しかし、一発では上手く行かないことが多く、steep checkにかけるとエラーが発生します。これもLLMで解決できるか試しているところです。

LLMフレームワーク（Langchain.rb）を使用し、ユーザーがどのLLMを使うか選択できます。LLM APIは費用が高く応答も遅いため、CIとの相性が悪いです。VCR gemなどのWebモックを利用すると良いです。再現性のためにtemperatureは0に設定します。

RBSファイルとLLMの複数の組み合わせで性能評価を行い、steep checkと目視で品質を確認しました。結果として、OpenAIの出力がほぼ完璧で、特にGPT-4 Omniが速くて賢いことがわかりました。元となるRBS生成手法はいずれも性能に大差はなく、実行が手軽で速いrbs prototype rbが良さそうです。

また、セッションの最後には、黒曜さんが気になっていることとして、soutaro さんの RBS::Inline のセッションを挙げられていました。

個人的には、どのモデルでプロンプトチューニングしたのかによって、LLM の性能評価に影響はないのか、気になりました。もしかすると、RBS Goose の仕組みとしては、プロンプトチューニングというより、インプットとなる Ruby や RBS ファイルの渡し方などに注力されているのかもしれません。

いずれにせよ、型定義ファイルの生成は LLM と相性が良さそうで、非常に興味深いセッションでした！

Day2

Community-driven RBS repository

今まではRBS core teamのレビュー負荷が高くメンテナンスに課題があったgem_rbs_collectionのレビュー運用を改善したことについてのセッションでした。

当初は全てご自身でレビューをしてマージをする従来の基本的なオープンソースの手法を取っていたようですがそれには限界があり、途中からGitHubのCODEOWNERS制を取られたそうです。しかし、このCODEOWNERS制がうまくワークしきらずOwnerのいないものは結局core teamがレビューとマージをし続けないといけない問題は残り続けたようです。それらを解決するために、現在はgem reviewersという新たな仕組みを構築されたそうです。

gem_reviewersはgem_rbs_collectionレポジトリのgems/GEM_NAME/_reviewers.yamlで管理されています。コントリビュータがgem_reviewersに含まれている場合、PR内で/mergeとGitHubコメントを残せばPRを自動マージできるようGitHub Workflowsを活用して実現されていました。この方式によりgem_rbs_collectionはコミュニティドリブンのメンテナンスを整備できたとのことです！一方で、この仕組みによってRBS core teamのレビューコストを下げることができましたが、CIでのみチェックされたコードがmainにマージされてしまう等のセキュリティ面のトレードオフがありそこのバランスをどう取るかの意思決定にかかわるパートも聞いていて面白かったです。

gem_rbs_collectionには複数のgemのRBSファイルが入ってくる特色があるため、徐々に委譲していくこの方式は利に叶っているなとセッションを聞いていて感じました。

セッションの最後にはリアルタイムでgem_rbs_collectionへセッション内で紹介された仕組みでPRがマージされるまでの実演が行われ、会場からは大きな拍手が巻き起こりセッションは終了しました。

Embedding it into Ruby code

RBSをインラインで書けるようにしたrbs-inlineについてのセッションです。

セッションの初めではリアルタイムでインラインRBSを記述しながら、# @rbs やattr_reader :date #:: Date などの記法が紹介されていました。

次に、なぜ現在のRBSが2ファイルに分かれているかについて解説がされました。確かにTypeScriptやPHPなど多くの言語はソースコード内に型を書くのが主流のため気になる部分でした。セッション内では2つの理由を挙げられており、「型のためにRubyの文法を拡張するのをMatzが望まなかった」「互換性を壊さずに追加できるか不明瞭だった」とのことでした。また、本セッション内ではない余談ですが、Day3のRuby Committers and the WorldにてMatzご自身から「型は書きたくない派だが現状の仕組みの中で現実的な型推論を構築できていないのでコメントで書く分には黙認している笑」とコメントがありましたね。

話を本セッションに戻します。インラインRBSの詳細な話に入る前に、現在のRBSファイルで型宣言をするデメリットについてもお話されていました。現状の課題は主に2ファイルに跨っていることが起因で発生しているもので、「型を変更した際に2つのファイルを編集する必要があること」と「型を変更しないといけないにも関わらずPRでは差分に出てこない(RBSファイルを修正する必要があるのかわからない)ためレビューがしづらく修正が漏れやすい」とのことでした。これらのことからより統合的な仕組みへのモチベーションが上がりインラインRBSの開発をされているそうです。

感想として、YARDライクにRBSを書け静的解析をできるのはコードとの距離が近く非常に良いなと感じました。一方で分離されていた頃より圧倒的にメンテナンスがしやすくなったとはいえ、コメントを人の手でどこまでメンテナンスをしていけるのかは利用者側で工夫がいるポイントでもあるなと同時に感じました。Rubyで型宣言を明示的にせず型の恩恵をどこまで受けていけるかにも注目していきたいですね。

登壇資料は公開されているためご興味がある方はぜひ一読ください！

speakerdeck.com