RBS Goose の現状とやりたいことまとめ
黒曜どこかにまとめておかないと忘れそうなので、RBS Gooseの現状とやろうかなと思っていることをまとめておきます。
黒曜現状1: 小規模で簡単なコードであれば、メタプログラミングを含んでいても一発で steep check に通るレベルのRBSが生成できる。
黒曜現状その2: RBS Goose自身くらいの規模のコードになると、それっぽい RBS は生成されるが steep check では結構エラーが出るくらいの RBS が生成される
黒曜現状わかっている問題点1: LLM が RBS の文法を正しく把握できていない
LLMの学習データには多種のプログラミング言語が含まれるので、型の概念はジェネリクスなども含めてかなり正確に理解している。
一方で RBS コードはほとんど含まれていないため、RBSとして不正確な出力をすることがある。
特に他言語であまり見られず記号の使い方もRubyと類似性の低いブロック渡しや self type bindingなどが不正確になりやすい。他に、attr_xxxが利用可能なことでdef_delegateのような類似記法もそのままRBS二出力してしまったりする。
黒曜現状わかっている問題点2: RubyクラスファイルとRBSシグネチャファイルが1:1対応していないと利用できない
RBSの型推測に対応するRubyファイルを渡す、といったツール設計にしてしまったので、Rubyファイルと同じパスにあるRBSファイルしか利用できない。
これは単純にツール設計を直せば良い。
黒曜現状わかっている問題点3: RBSファイルをマークダウンとしてLLMに渡す設計なので、Orthosesとうまく統合できない
Orthosesは内部状態をRBS::Environmentとして保持しているため、一度 OutputFile を挟んでからRBS Gooseを起動する必要がある。
一応Orthoses Middlewareとしてのインターフェイスも作ってあるが、実際にはファイルを読み書きしているだけなのでMiddlewareとして機能していない。
黒曜現状わかっている問題点4: 一定規模を超えると LLM の Output Window に引っかかる
Input Window は 200K~2M と大きくなったので大規模プロジェクトも扱えるが、出力長は 4k~8k に留まっているため1度にすべてのRBSを出力する戦略だと Output Window に引っかかる可能性がある。
これはstop wordを適切に設定したうえで、出力終端になっていない場合はそこまでの出力を含めて再度LLMを呼び出し続きを生成させるようツールを直せば良さそう。
黒曜現状わかっている問題点5: 外部gemの型情報を一切利用できていない
プロジェクトのソースコードとそのRBSのみを渡しているため、rbs collectionなどで型情報を落としていても外部gemの情報をLLMが一切参照できていない。
黒曜試したいこと1: プロンプトに各種ドキュメントを埋め込めるようにする
Input Window が長大になっているので、プロジェクトのRubyコードだけでなく「RBSの文法定義」「プロジェクト全体のREADME」「specコード」「外部gemのsig」などあらゆるものを任意でプロンプトに埋め込めるようにして、何を渡すと精度が出るかを試したい。
黒曜試したいこと2: RBS::Environment をLLMに渡すようにする
RBSをコードとして渡すと、文字数は少ないが記号の使い方でうまく推測できなかったり結合規則を間違えたりと本質的でないところに問題が出やすい。
RBS::Environmentのシリアライズ表現(Rubyのinspect表現か、S式か、JSONあたり)をLLMに渡すようにすることで、冗長になるが曖昧性のない木構造でLLMが正確に出力しやすくならないかを試してみたい。
この方針がうまくいくと Orthoses との統合もやりやすくなる。
黒曜試したいこと3: steep check のエラーを元にした型の修正
一括生成されたあとにsteep check に引っかかってもどこが間違ってるか探すのが(なまじ自分で書いていないだけに)大変なので、エラー修正もLLMでできるようにしたい。
一応プロトタイプ実装はできているが数回流しただけではうまく動かないので、プロンプトの調整やエラー原因をscratchpadに推測させたうえで修正結果を出力するなど、精度を上げていきたい。
黒曜試したいこと4: rbs_gem_collection で使えるよう、public範囲のsigのみ生成するオプションをつける
rbs_gem_collection で小さな gem から実用に乗せていけると良さそうだが、内部の型まで推測する必要はなく、利用者が使う部分の型だけが入っていれば良い。(内部まで細かく型を生成してしまうと、gem側の更新で型が合わなくなってしまいやすくなる)
利用される範囲をREADMEなどのドキュメントから推測して生成範囲を絞るか、生成対象クラスを指定するようなオプションを付けるかして利用しやすいようにしたい。
黒曜試したいこと5: RBS品質の評価ツールの作成
出力品質が高くなるようプロンプトを調整したいが、steep checkの結果だけだと0, 1でしか判断できず、エラー数はあまり品質の指標にならない。かといって目視確認はコストが高すぎる。
目標RBSに対して、nallowなもの/wideなものがあるたびにscore -1, 足りないもの/余分なものがあるたびにscore -5, といった感じでRBS Declarationを評価するツールがあれば、このあたりの判定を数値化・自動評価できるようになりそう。