LLM研究エージェントの評価

標準シナリオでは、研究エージェントは一回で答えを出す機械ではなく、管理された作業工程に近いものとして扱われる。アイデアを作る、テストを計画する、仮説を修正する、といった各段階で、見える形の欠陥が生まれうる。中心となる仕組みは、こうした欠陥を持続的な状態として保存することだ。そうすると後の実行は、毎回ゼロから始めるのではなく、前の実行から学べる。

1年目の重要な問いは、このフィードバックの輪が本当に良い成果を予測するかどうかになる。評価研究は、実現可能性の採点、ライフサイクル型ベンチマーク、監査可能な実行記録を、より完全なテスト環境へ結びつけるだろう。注目すべき兆候は、実現可能性や監査可能性の点数が、説明の上手さだけでなく実際の実行成功を予測するという公開された証拠である。応用側では主に、弱い提案を高コストな実行の前にふるい落とすための作業基盤として使われる。エージェントの実行基盤には、計画、ツール呼び出し、証拠を示すことも求められる。

2年目には、焦点は個別のベンチマークから共有された評価スタックへ移るはずだ。記録された失敗は、よりよい批評器の訓練に使える。よりよい批評器は、弱い試行を早い段階で止められる。この結果、きれいな試行がよい記録を生み、その記録が後の評価を改善するという累積的な循環ができる。ただし評価器そのものも保守が必要である。古い失敗だけで訓練された批評器は、エージェントが変わるにつれて古くなる可能性がある。

3年目ごろには、このシナリオの強い形として、再利用できる因果的な記憶断片が保存される。これは単に一度うまくいったというメモではなく、どの条件でなぜ計画がうまくいったかの記録である。組織は、エージェント支援のプロジェクトを確認するとき、実現可能性、監査可能性、資源利用を組み合わせたスコアカードを使うかもしれない。ただし、研究環境はいつも整った作業ラインではない。専門的なツールや一部しか観測できない課題では、再現しにくい失敗が起こりうる。厳しいコスト制限が、まれだが価値のある探索経路を止めてしまう危険もある。

対抗シナリオでは、研究エージェント評価はテレメトリとして捉えられる。ここでのテレメトリとは、エージェントが作業中に何をしているかを示す連続的な信号のことだ。エージェントは最終回答に到達したかどうかだけで判断されない。計画を立て、証拠を探し、仮説を更新する過程が観測される。仕組みは、計測器を備えたシステムに近い。見える信号があれば、実行全体が崩れる前に失敗を見つけやすくなる。

1年目には、どの信号を記録する価値があるかを研究が決めていくだろう。有用な信号には、仮説の更新、ツール結果、実現可能性スコアが含まれうる。評価スイートは、最終回答だけでなく実行過程の記録も求め始める。応用側のチームは、ダッシュボードや監督付きの停止機構を追加するだろう。証拠が現在の仮説と合わなくなったり、資源利用が増えても進展がない場合には、実行を一時停止する。

2年目には、分野の焦点は記録から再生へ移る。重要な対象は、長い実行がどのように失敗し、どのように回復したかを再構成できる構造化記録になる。これは、流暢だが壊れやすい経路と、安定した経路を分けて考える助けになる。チームはエージェントの版を比較し、失敗を再現し、いつ停止すべきかをより明確に決められる。必要なら人間に助けを求める規則も定めやすくなる。

3年目までには、テレメトリはより能動的になる。評価は、環境の中に問題を注入するようになる。たとえば、故障するツール、誤解を招く情報のまとまり、遅れて届く観測である。点数は、異常の早期発見、制御された回復、次の一手の明確な理由に依存する。強い監視指標は、移植しやすい実行記録の標準と、再生可能なログを必要とするベンチマークである。ただし、記録するだけで全てのエージェントが信頼できるようになるわけではない。中間状態を保存できない場合や、継続的な批評の費用が防げる失敗より大きい場合、このシナリオは弱まる。見える記録が実際の意思決定過程を反映していない場合も同じである。

可能性シナリオでは、実行に根ざした評価が、研究エージェントのための監査制度に近づく。仮説ツリーは単なる記憶構造ではなく、エージェントが何を検証する予定だったかの記録になる。実行ログは単なるデバッグ用データではなく、実際に何が起きたかの証拠になる。仕組みは、構造化された研究レビューに似ている。予定された過程を見えるようにし、結果が複雑でも報告を求める。

1年目には、こうした記録を比較できる程度に標準化することが研究の焦点になる。グループは、仮説台帳、結果ログ、評価基準と結びついた記録の設計を試すだろう。単純な正解がない場合に、評価器をどう検証するかも調べられる。応用プラットフォームは、監査用の出力、由来を示す台帳、ツール利用の会計的な記録を追加する。これにより、最終出力だけでなく失敗した試行も確認できる。

2年目には、共通の記録が、実行に根ざしたよりよい採点器の訓練データになりうる。多くのエージェント実行が似た形式で保存されれば、評価器は成功や失敗を予測するパターンを学べる。このことはレビューの負担を下げ、フィードバックをより一貫したものにする可能性がある。注目すべき兆候は、エージェント支援の作業を進める前に、登録された仮説台帳と実行結果レポートを求める試験的な取り組みである。

3年目までには、ライフサイクル評価は単なるベンチマークの形式ではなく、重要な研究エージェント作業の制御層になりうる。由来を意識した記憶が重要になるのは、再利用できる戦略断片が、どこから来てなぜ適用できるかを示す必要があるからだ。ごまかし対策も中心的な課題になる。エージェントは多数の実行を生成し、きれいなものだけを提示できるからである。ただし、開かれた探索は常に事前登録できるわけではない。スキーマが分裂したり、手間が大きくなりすぎたりすると、このシナリオは弱まる。エージェントがチェック項目を満たすだけで、実際の実行が改善しない場合も同じである。