RSI研究のためのインフラ：自己改善エージェントの実行と評価

研究用エージェントが自分の検索ツールを変更し、以前は失敗したタスクを解けたとします。別のタスクも解けるでしょうか。改良されたエージェントは、次の有用な変更も見つけられるでしょうか。確かめるには、プログラムの修正、実験、結果の比較を繰り返します。Beeuniは、あなたのコード、ツール、評価スクリプトを使ってエージェントがその作業を行うコンピューターを提供します。

再帰的自己改善（RSI）は、システムが自分を改良できるか、さらに改良を生み出す方法も改善できるかを調べる研究です。エージェントのコード、指示、ツールを変更してテストし、有効だったバージョンで次の改良を試す、といった実験があります。検索ツールを例に、Beeuniがこの過程をどう支えるかを説明します。

コードと、確かめたい具体的な問いを渡す

エージェントとテストが入ったリポジトリを接続します。インストール方法、評価を実行するコマンド、変更してよい部分をBeeuniに伝えてください。最初は「ファイル全体をモデルに送らず、必要な関数だけを返せるか」という小さな問いで十分です。

何を編集してよいかは研究の問いで決まります。指示を変えると計画が良くなるか、検索処理を変えると無駄な読み取りが減るか、記憶の扱いを変えると後のタスクに役立つか。それぞれを区別して実験してください。モデルの重みを変える実験には、別途、学習手法と計算資源が必要です。

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuniは実装を読み、インストールコマンドを実行し、ターミナルでテストを動かせます。依存パッケージが足りない場合やテストが異常終了した場合は、エラーを調べて原因を追えます。作業はセッションで確認でき、生成したファイルも開けます。

変更前のツールを動かしてから、改良版を試す

まず、変更していないエージェントをBeeuniに実行させます。成功したタスク、失敗したタスク、エラーを保存します。テストプログラムがモデル使用量、ツール呼び出し回数、所要時間を記録するなら、それも含めましょう。これが変更後と比べるための結果になります。

次に検索ツールを変更させ、同じコマンドを実行します。比較中はモデル、タスク一覧、実行上限を変えません。結果が変わった項目は、ログを示して説明させます。トークン数の減少は確認したい点ですが、検索結果を短くしたことで重要なコードが抜け、失敗したタスクにも注目してください。

これらは、あなたのスクリプトを使ってエージェントに作成させるファイルです。Beeuniが研究用ベンチマークを提供したり、何を改善とみなすか決めたりするわけではありません。タスクと採点コードはあなたが用意し、エージェントが実行と結果の調査を手伝います。

失敗したタスクから、次に直す部分を探す

改良版は小さなファイルでは動くのに、別ファイルの補助関数を呼ぶ場合に失敗するとします。Beeuniにそのタスクを調べさせ、足りない情報を特定して、修正案を出してもらえます。すべてのファイルを全文で返す代わりに、関連する関数名を検索結果に加える、といった変更が考えられます。

変更を採用する前にパッチとレポートを確認し、別のタスクでも試します。改良のきっかけになった例が通るだけでなく、調整に使っていないタスクでも成功するかを見ましょう。最終採点用のテストは、エージェントが編集できるファイルの外に置いてください。

ブラウザーエージェントでも同じ方法を使えます。テスト用アプリケーションを用意し、注文を探して配送メモを更新するようBeeuniに頼みます。ブラウザーを操作し、結果を確認し、失敗の証拠を保存できます。別のバージョンと比べる前にアプリケーションのテストデータを戻し、同じ注文状態から始めてください。

自分のプログラムで複数回の実験を組み立てる

複数回の実験を手配するプログラムをコントローラーと呼びます。エージェントの版を選び、変更を依頼し、テストを始め、次に試すことを決めます。その回でテストする改良版が候補です。コントローラーはAPIまたはTypeScript SDKでBeeuniセッションを開始して確認できます。選び方のルールはあなたの研究コードに残します。

各セッションには独立した実行環境があります。二つのツール実装を試しても、同じ作業ファイルや依存パッケージを上書きせずに済みます。実際に起動するプログラムが、指定したコードの版を使っているかも確認します。起動時だけコードを読むスクリプトなら、編集後に再起動してください。

少数の実験を並べるところから始めます。コントローラーで試行回数、同時セッション数、実行時間、モデル使用量を制限します。上限に達したら関連する作業を止め、プロセスが終了したか確認します。これにより、一つのバージョンを選ぶまでに使える探索の予算が決まります。

各バージョンを公平にテストする

正解を読めたりテストを書き換えられたりするエージェントは、能力が上がらなくても点数を上げられます。最終採点は別に実行してください。非公開の正解はアクセスできるファイルに置かず、採点コードも変更させません。Beeuniで開発用テストを実行して出力を集め、評価プログラムで別途採点できます。ブラウザー実験では、バージョンごとに共有アプリケーションのデータを戻します。コンピューターを変えても、外部アプリケーションに残った記録は見えるためです。

タスクの成功、エラー、所要時間、そして記録できる場合はツール呼び出しとモデル使用量を比べます。タスク集、モデル設定、実行上限をそろえ、判断の難しい結果は繰り返し確かめます。トークンが減っても補助関数を見落としている場合や、呼び出しを大幅に増やして成功数を上げている場合があります。レポートには両方を示します。

改良を見つける費用も数えます。変更案を作り、テストするために使った試行と、採用版を実行する費用は分けて記録します。最終版の一件当たりの費用が安くても、発見までに高額な探索が必要だったかもしれません。実験の判断には両方が必要です。

失敗した実験の理由を説明できる記録を残す

タスクの失敗とモデルAPIの停止では対応が違います。Beeuniに要約を頼む前に、元のエラーとログを保存させてください。回答の誤り、依存パッケージ不足、モデルリクエストの失敗、時間切れを区別します。すべての失敗を成功するまで黙って再実行せず、どの場合に再試行するかを決めます。

変更前後のコードの版、指示、起動コマンド、依存関係、テスト集と採点コードの版、タスク別結果を保存します。変更元のバージョンも記録してください。Beeuniはパッチやログと一緒に実験記録を作る作業を手伝えるので、採用や却下の理由を後から調べられます。

実験用コンピューターを削除する前に、有用なパッチとレポートを選んだリポジトリやストレージに保存します。採用しなかった試みも含め、どのコードとコマンドから結果が得られたかをたどれます。

次の改良を見つける力も良くなったか確かめる

バージョンを選んだら、修正の判断に使っていないタスクで評価します。続いて、その版に次の改良を試させ、元のエージェントの試みと比べます。同じ予算で、有用な変更を多く見つけられるか。試行回数や既存機能の悪化を減らせるか。多くのタスクを解くことに加え、後の改良を生み出す過程も良くなるかが、RSI研究で確かめる問いです。

Darwin Gödel Machineの論文は、エージェントが自分のコードを変更してテストする方法を扱います。Self-Refineは追加学習を行わず、フィードバックで回答を修正する研究です。一つの回答、エージェントの働き方、次の改良を見つける能力のどれを改善するのか。この違いを踏まえて実験を設計します。Beeuniはコード編集、コマンド実行、結果の確認を手伝います。研究手法はあなたが作ります。学習が必要ならファインチューニングの進め方を参照してください。

検索ツールの実験は、一つのリポジトリと、正常に動く一つのテストコマンドから始められます。Computerガイドでは、Beeuniの作業中に環境とプロセス出力を確認する方法を説明しています。