Leaner 開発チームの黒曜(@kokuyouwind)です。
いつのまにやら 12 月ですね。というわけで本記事は Leaner Technologies Advent Calendar 2023 の 3 日目です。
昨日の担当はガーシーさんの 今年、第一子が誕生し育休を取得をしてめちゃくちゃよかったのでお勧めしたい でした。
年末も間近ということで、今回は 2023 年に登壇したイベントを振り返りつつ、提出した CfP や発表構成などについてまとめます。
RubyKaigi 2023 LT: RBS meets LLMs - Type inference using LLM
5 月に開催された RubyKaigi 2023 では、 LT 枠で RBS meets LLMs - Type inference using LLM を採択いただき登壇しました。
どうしてこのネタを選んだのか
2023 年の 3 月に ChatGPT API が一般公開され、「これは今までとは違うレベルで自然言語での対話ができているのでは？」と大いに話題になったタイミングでした。
その流れで ChatGPT にコードを書かせるというのも盛り上がり始めたタイミングだったので、「もしかして Ruby コードから RBS の型を推論するのもできるのでは？」と試してみたら思いのほかそれっぽい出力が得られました。
なにしろ話題になりまくっていた時期でウケが良さそうだったことと、調べた限りでは型推論に ChatGPT を試している人はほとんどいなかったのでネタ被りもなさそうなことから、LT 枠くらいなら狙えそうと思い立ち CfP を提出しました。
ちなみに、 CfP 提出時点ではものすごく簡単なパターンしか試しておらず、実際どこまでできるのかは未知数でした。
提出した CfP
以下、提出した CfP をほぼそのまま転載します。
Abstract
Recently, Large Language Models (LLMs), such as ChatGPT, have been rapidly evolving.
LLMs are characterized by their ability to interpret word meanings and contexts, and by their very wide range of applications.
By the way, common static analyzers and execution systems treat class and variable names as mere labels, but they are important clues when humans read code.
By using LLMs, we can interpret those intentions and use them for type inference.
Also, static analysis is not good at dynamic definitions such as define_method, which cannot be distinguished from a simple method call in Ruby syntax.
LLMs may be able to successfully generate type definitions in these cases.
In this session, we will introduce our efforts to use ChatGPT for RBS generation and discuss the possibility of incorporating LLMs into development tools.
For Review Committee: Details
本セッションでは LLMs の話題性に触れた上でその特徴を簡潔に紹介し、クラス名や変数名を用いた型の推測の可能性を示唆します。
次に具体例な Ruby コード片をいくつか取り上げ、 ChatGPT に与えるプロンプトとその出力を比較します。典型的な Zero Shot, Few Shot に加えて、 rbs prototype で生成した RBS をセットで渡す方法やファインチューニングを行ったモデルでの出力も取り上げる予定です。
最後に、今後の展望として「llama.cpp や RWKV などローカル実行可能な LLMs と組み合わせてローカル環境のみで実行可能な LLMs ツール」「LangChain のようなツールを用いた自己計画的なツール」「既存コードを元に推奨 Rubocop ルールを提案するなど、ヒューリスティックな性質を持つツール」など、 Ruby の周辺ツールとして LLMs が活用できる可能性を提案します。
具体的な成果として、ある程度それらしい型定義が得られることを確認しています。
例えば user = UserBuilder.new.name('kokuyouwind').build というコードを Act as a Ruby type inferrer; only output RBS when Ruby code is input. Use class names, variable names, etc. to infer type という命令と共に ChatGPT(gpt-3.5)に送ると、以下のコードを出力します。
class User
attr_reader name: String
end
class UserBuilder
def name(name: String) -> UserBuilder
end
def build -> User
end
end
また構文上同じ構造となる company = CompanyRepository.new.find(1).name では以下のようになります。
# CompanyRepository: a class that provides access to company records
class CompanyRepository
def find: (Integer) -> Company
end
# Company: a class that represents a company
class Company
attr_reader name: String
end
# company: a variable that holds the name of a company
company: String
別の例として、 define_method を含む単純な例では以下のように正しく型を推測できました。
class Test
define_method :hello, -> { puts 'hello, world' }
end
class Test
def hello: () -> nil
end
これらの例から、 ChatGPT では正しく変数名・メソッド名の意味や動的なメソッド定義を解釈し、「人間が読むように」型を推測する能力があると考えられます。
一方で RBS として適切でないコードが一部混じっており、 Ruby と RBS を正しく区別せず学習してしまっているように見受けられます。
こうした出力を Zero Shot Prompt や Fine Tuning などの手法で改善していくとともに、 rbs check の結果や周辺コードの情報を提供するレイヤーをツール側から提供することが今後の課題になると考えています。( LT 当日までに改善できた点については発表に盛り込む予定です)
本セッションの想定聴講者は RBS の概要を知っており型推論に興味のある(他の RBS セッションを聞いている)参加者です。また RBS をほとんど知らなくとも、 LLMs に関心を持っている人であれば応用例として興味を持ってもらえるはずです。
For Review Committee: Pitch
本セッションには「LLMs を Ruby の型推論に利用するというアイディア」「クラス名や変数名を型推論に活用できる可能性」の 2 点で新規性があります。
また ChatGPT API が今年 3 月に一般公開されたばかりで発展途上であることから、 Ruby に限らない応用の 1 つとして示唆的なものになるはずです。
筆者は Ruby の型システムについて RubyKaigi 2016 基調講演の「Ruby3 Typing」のころから興味を持って追いかけています。また AI については 3 月から ChatGPT を含めた LLMs のサーベイを行っており、両者を組み合わせた本テーマの発表に適していると考えています。
発表構成
LT 枠で 5 分しかないため、とにかく極力内容を圧縮して「最低限の ChatGPT の紹介」→「ワンアイディアの紹介」→「実験・結果・改善案の流れを書けるだけ」という構成にしました。
最初に殴り書きしたアウトラインは以下のとおりです。
- LLM すごい話題だよね
- Ruby 関連でもなんか試してみたい
- 型推論の取り組みが色々あるが、基本的には実行時情報を使うものが主流
- LLM を使って「この単語名ならこの型だろう」という人間的な角度の推論がワンチャンできるのでは？
- ChatGPT に推論してもらう
- とりあえず素直に推論する命令を入れる
- → 多分あんまりいい出力にならないはず
- One-Shot Prompt に改善
- → ちょっとは良くなるはず？(予想)
- 既存の型推論結果を更に補完してもらうのはどうか
- コードと
rbs prototype結果をセットで渡して、名前を元に推論を進めた RBS を出してもらうプロンプトにしてみる - → 試してみないとうまくいくかわからないので、微妙な場合は節ごと落とす
- コードと
- とりあえず素直に推論する命令を入れる
- fine-tuning してみよう
- データセットの準備(いいデータセットをなんとか見つけてくる)
- ファインチューニングした結果を示す
- (めっちゃよい or ダメダメのどっちでも面白いはず)
- まとめ
- (感想を書く)
結果的には Fine Tuning を試す余裕は全くなく、時間的にも 3 節目はまるごとカットになりました。
発表しての感想
なんといっても、 Matz の基調講演で「ChatGPT に型推論してみてもらった」という話が出てきて完全にネタ被ったのがやばかったです。
他の LT とはかぶらんやろと思ってましたが、まさか基調講演と被るとは思わなかったですね。
結果的にはそれ自体もネタにできてよかったです。
関連記事
再掲ですが、発表内容は補足も含めて以下記事にまとめています。
今回の RubyKaigi はチームで初めて行く人も多かったので、社内で予習会を開催しました。そのときの資料が以下です。
また初スポンサーかつ DrinkUp も開催していろいろなことがあったので、各個人の振り返りとスポンサー企業としての振り返りをそれぞれ記事にまとめています。
Kaigi on Rails 2023 Talks: APMをちゃんと使おうとしたら、いつのまにか独自gemを作っていた話
10 月に開催された Kaigi on Rails 2023 では、 15 分枠で APMをちゃんと使おうとしたら、いつのまにか独自gemを作っていた話 を採択いただき登壇しました。
どうしてこのネタを選んだのか
社内で CfP ネタ出し会をした際、他薦で「Datadog のプロファイリングを仕込みやすくした話」を提案してもらいました。昨年書いた以下の記事の内容ですね。
2020 年の Kaigi on Rails STAY HOME Edition で Railsパフォーマンス・チューニング入門 の登壇をしていたこともあり、 APM の使い方全般から話を繋げる形にすればちょうどいい構成になりそうかな？ と考えこのネタを採用しました。
またこの際、サボっていた gem 切り出しも CfP に盛り込んで、採択されたら発表までに頑張って切り出すことにしました。 CfP 駆動開発ですね。
提出した CfP
以下、提出した CfP をほぼそのまま転載します。
Abstract
Active Record は必要な処理が簡単に書ける一方で、 N+1 クエリやスロークエリなどパフォーマンスの問題が発生しやすい一面も持っています。 特にデータ量に依存する問題では、本番環境でしか再現しない問題も珍しくありません。 APM ツールを使うことで、こうしたパフォーマンスの追跡や原因の調査をしやすくなります。
しかし、 APM ツールの導入自体は比較的簡単なものの、うまく活用するのは意外と難しいものです。「APM を導入しただけで放置してしまっている」という方も多いのではないでしょうか？
弊社では APM として Datadog を導入し、定期的な状況の確認とパフォーマンスチューニングに役立てています。
本セッションでは弊社で APM をどのように使っているかを紹介し、より使いやすくするために独自の gem を作った話をします。
For Review Committee: Details
本セッションでは APM を使った Web アプリケーションのパフォーマンス監視と問題特定の手法について概説します。
APM ツールとしては主に Datadog を取り扱いますが、他の APM でも共通するレスポンスタイム・スパンなどを中心に扱います。
発表の大まかな構成として、はじめに Web アプリケーションにおけるパフォーマンスの重要性を紹介し、特定データが存在する状況でのみ発生する N+1 クエリやデータ量に依存するスロークエリなど、 Rails 本番環境で起こりやすいパフォーマンス上の問題を紹介します。
次に、本番環境のパフォーマンスを監視し、原因特定・修正するためのツールとして APM を紹介します。導入手順などごく初歩的な手順については割愛します。
続けて、実務のなかでどのように APM を利用しているか、週次での確認項目や問題発見時の対応などを紹介します。
具体的には p50 レイテンシー・ p99 レイテンシーに注目し、アプリケーション全体での数値が悪化していないかや、エンドポイントごとで極端に悪化しているものがないかを確認しています。
もし極端に悪化しているエンドポイントが存在する場合は、リクエストごとのトレースを確認しなんの処理に時間がかかっているかを特定します。
この際、 APM のデフォルトでは発行されたデータベースクエリはわかるものの、そのクエリがソースコードのどこで発行されているかは追うことができません。
これを特定しやすくするため、 DatadogTraceable というモジュールを自作し、 trace_methods :method_a, :method_b といった記述で該当メソッド呼び出しがトレース上にスパンとして表示されるようにした話を合わせて紹介します。
(実装内容は https://zenn.dev/leaner_dev/articles/20221220-datadog-manual-trace に示した通りです。現在はプロジェクト内に置いていますが発表までには公開 Gem として publish する予定です)
このセッションは、主にパフォーマンス監視をまだ行っていない、もしくは APM を導入したものの活用できていないような、監視関連の知識が少ないアプリケーション開発者を対象とします。
扱っている題材は Kaigi on Rails 2020 で発表した「Rails パフォーマンス・チューニング入門」と近しいですが、本セッションでは APM を使った監視と問題解決を特化して扱い、パフォーマンス問題全般の話は割愛することで差別化する予定です。
For Review Committee: Pitch
近年の潮流ではフロントエンドフレームワークの隆盛に伴い、 SSR・CSR などパフォーマンスを改善する取り組みが盛んです。また UX の観点から、「1 秒を超える応答はユーザーの関心を低下させる」など、パフォーマンスがユーザー体験に与える影響も多く取り上げられています。
一方で Rails では深く考えずに記述するとパフォーマンスの問題を発生させることがあり、本番環境の特定条件やデータ量に依存して起こる問題の追跡・解決はノウハウがないと難しいものになります。
APM は比較的導入しやすく、正しく使うことでパフォーマンスの改善に大きく役立てることができます。しかしながら、 APM を用いた監視には Rails 開発自体とは異なるノウハウが必要で、あまり詳しくない開発者も多いのではないでしょうか。
実務で APM がどう使われているかのセッションは、Kaigi on Rails の参加者に多いであろうアプリケーション監視初学者にとって実務に役立てやすいものであり、すでに APM を活用している中級者にとってもトレースを取りやすくする工夫は面白い話になるのではなるはずです。
発表者は Kaigi on Rails 2020 で Rails 全体のパフォーマンス・チューニングの発表をしており、今回はより APM に特化した内容となります。
SRE・DevOps 領域の実務を行っており、職をまたいで 5 年ほどクエリチューニングやパフォーマンスチューニングに関わってきたことから、この題材で講演するバックグラウンドがあると考えています。
発表構成
CfP の For Review Committee: Details に大まかな構成を書いていたため、箇条書きでのアウトラインはつくらず CfP どおりに組み立てて作っていきました。
…が、意外と話の流れが悪く、スライドを組み替えたり潤滑油になるスライドを足したりしているうちに構成が全然変わってしまいました。結果、 15 分枠に対してリハーサルで 19 分かかってしまい大幅に時間超過。導入はごく最低限に削り、各節のまとめスライドも省いたりと大工事を当日まで行うハメに。
最初にもう少し詳細まで含めたアウトラインを箇条書きで作っておけば、その時点で話の流れが悪いことやボリュームが多すぎることに気づけたはずなので、最初にサボったのがよくありませんでした。あともっと余裕をもって準備するべきですね。反省。
発表しての感想
なんだかんだありましたが、結果的にちゃんと外部 gem への切り出しもでき、発表自体も好評いただいたようで良かったです。
また発表したあとに APM を使ってる人たちが前に集まってきて色々情報交換をできたり、懇親会でも色々話しかけていただいたりと、登壇したことで密な交流に繋がりました。
関連記事
再掲ですが、発表内容は補足も含めて以下記事にまとめています。
各スポンサーブースの写真を撮影させていただき、まとめた記事を作りました。
また gihyo.jp 様のイベントレポーターのお仕事をいただいたため、ガーシーさんと一緒にイベントレポート記事を出しました。
まとめ
今年は RubyKaigi と Kaigi on Rails という、規模の大きい Ruby 系カンファレンス 2 つに登壇させていただき、印象深い年になりました。
来年もいろんなカンファレンスの登壇を目指し、登壇ネタにできるような開発実績を積んでいけるよう頑張ります。
というわけで、本記事は Leaner Technologies Advent Calendar 2023 の 3 日目でした。明日の担当は glico さんです。お楽しみにー！
Discussion