オープンソース AI 研究エージェントの評価方法

オープンソースの AI 研究エージェントは、閉じた回答サービスより多くの制御を約束しますが、ソースが利用可能であることは有用な評価の始まりにすぎません。リポジトリはコードを公開していても、どの証拠が結果を生んだか、どのデータがネットワーク境界を越えたか、別の研究者がワークフローを再実行できるか、機関がどれだけの運用作業を負担しなければならないかという重要な問いを未解決のままにし得ます。

したがって、健全な評価は機能数ではなく研究実践から始まります。目的は、エージェントが実際のワークフローを検査、反復、統治、保守しやすくするかを判断することです。AIPOCH Open Science は、ローカルファーストのデスクトップアプリケーションに文献管理、エージェント、ノートブック、科学コネクタ、プロジェクトファイル、リモート計算を組み合わせているため、有用な事例です。その設計は、検査可能なワークスペースの可能性と、記録された活動と再現可能な科学の隔たりの両方を示しています。

評価単位を定義する

研究エージェントを、難しい質問に答えられるかだけで評価してはいけません。まず完全な作業単位を定義します。そこには、論文の発見、出典レコードの添付、コードの準備、データの選択、ノートブックの実行、クラスタジョブの送信、結果の収集、図の作成、改訂の記録が含まれる場合があります。流暢なレポートはその連鎖の一つの出力であり、連鎖そのものではありません。

適格なレビュー担当者が調べる必要のある成果物と判断を列挙します。通常は、元の入力、引用、生成されたスクリプト、ノートブックの状態、実行ログ、環境の詳細、モデル選択、外部呼び出し、中間ファイル、最終出力、レビュー担当者の所見が含まれます。次に、製品がそれらの関係を保持しているかを確認します。ファイルでいっぱいのフォルダよりも、どの入力、コード、実行が結果の特定バージョンを生成したかを示す記録の方が有用です。

AIPOCH の技術文書は、会話、ファイル、Python と R のノートブック、実行記録、プレビュー、成果物の来歴を含む永続的なプロジェクトを説明しています。バージョン 0.26.0 では、参考文献ライブラリを、登録済みリモートコンピュータ上での直接 SSH または Slurm 実行にも接続します。この広がりが意味を持つのは、改訂されたプロンプト、代替分析、中断されたジョブ、置き換えられた出典、更新された出力といった通常の研究変更にリンクが耐えられる場合だけです。

実際の制御境界をマッピングする

「ローカルファースト」は、完全なプライバシー上の結論ではなく、調査すべき問いとして扱うべきです。プロジェクトの状態はローカルコンピュータに残っていても、プロンプト、コンテキスト、検索クエリ、タスクパラメータは、選択されたモデルプロバイダー、科学データベース、リポジトリ、リモートクラスタに移動する可能性があります。意味のある制御境界は、情報がたどる完全な経路です。

各ワークフローについて、データがどこで始まり、どのコンポーネントが受け取り、どの資格情報を使い、何がデバイスを離れ、結果がどこに保存されるかを図示します。拡張機能についても同じ作業を繰り返します。再利用可能なスキルはコードを実行する場合があり、コネクタは外部サービスへパラメータを送る場合があります。オープンソースは検査を可能にしますが、ユーザーに代わって検査を行うわけではありません。

AIPOCH は、モデル選択、コネクタ、リモートコンピュータ、コマンド、ファイル変更、ネットワーク呼び出しなどの操作に対する承認ポリシーを公開しています。これは、機関がこのツールを自らのプロバイダーやインフラに合わせる助けになります。同時に機関へ作業を移します。誰かが設定をレビューし、エンドポイントを検証し、資格情報を保守し、拡張機能の挙動を理解し、どの操作に永続的な許可を与えるかを決めなければなりません。

評価にはプラットフォーム固有の制御を含めます。AIPOCH の v0.26.0 の注記では、ノートブックのネットワーク制御は macOS と Linux では既定で適用される一方、Windows では一度だけ管理者設定が必要であるとされています。同じリリース文書では、Windows インストーラーが Authenticode 署名されていないことも記されています。どちらの詳細もツールの適合性を決めるものではありませんが、展開ポリシーとサポート作業に影響する可能性があります。

主張から証拠へ一つの結果をさかのぼる

有用な研究エージェントは、レビュー担当者が結論から、その背後にある証拠と操作へ後向きにたどれるようにすべきです。分析から得られた表や複数の論文から得られた主張など、代表的な結果を選び、元の操作者の記憶に頼らずにその系譜を再構築してみます。

AIPOCH はこのテストの具体的なモデルを提供します。その成果物システムは不変のバージョンとチェックサムを保持でき、来歴ビューは出力を、利用可能な入力、コード、実行記録、環境情報、会話コンテキスト、レビュー所見と関連付けられます。以前のバージョン 0.8.0 のリリースでは、代替の会話経路のための分岐も導入されました。これらの機能を合わせると、以前の状態を黙って置き換えるのではなく、変更を可視化できます。

評価では依然として、証拠の保持と科学的妥当性を分けなければなりません。チェックサムはファイルが変更されたかどうかを示せますが、手法が適切だったことは示せません。実行ログはどのコードが実行されたかを示せますが、統計的仮定が健全だったことを確立できません。引用記録は論文を特定できますが、エージェントが正しく解釈したことは証明できません。検査可能性は専門家レビューにより良い表面を作るのであって、自動化された真実を作るのではありません。

失敗志向の質問をいくつか使います。レビュー担当者は、公開済み成果物を生んだ分岐を特定できるか。出典が置き換えられたかを確認できるか。生成されたコードと実行されたコードを区別できるか。どの結果がリモートジョブから来たかを判断できるか。元の出力を消さずにレビュー担当者の修正を保持できるか。洗練されたデモよりも、弱い回答の方が来歴の欠落を確実に明らかにします。

監査可能性と再現性を分ける

監査可能性は、プロセスを調べられるかを問います。再現性は、再び実行して比較可能な結果を得るのに十分な状態が捕捉されたかを問います。エージェントは前者では優れていても、後者では不完全なままであり得ます。

再現性レビューでは、特定された入力、依存関係のロック、パッケージとオペレーティングシステムの詳細、乱数状態、実行順序、モデルとプロバイダーの情報、リモート設定、外部データセットの識別情報を探すべきです。また、固定できないものも記録すべきです。モデルプロバイダーはルーティングや実装を変えることがあり、科学データベースは更新され、リモートクラスタはハードウェアやライブラリが異なる場合があります。モデル名や会話記録だけを記録しても、これらの変数はなくなりません。

AIPOCH は、ポータブルな環境復元と完全なセッション再生を未完了の作業として明示しています。これは小さな欠落ではなく重要な境界です。保持された成果物と来歴は今日の調査を支援できますが、決定論的な再構築の証拠として説明すべきではありません。評価は、この違いを決定そのものに記録し、どのワークフローがなお外部の環境管理を必要とするかをユーザーに知らせるべきです。

非機微データで制御された再実行を行います。保持されたプロジェクト記録を二人目の適格者に渡し、非公式な知識を取り除き、成果物を再現するよう求めます。不足している依存関係、文書化されていない承認、利用不能なサービス、手動のファイル移動、曖昧な指示をすべて記録します。得られたギャップ一覧は、ワークフローが再現可能だという一般的な主張より実行可能です。

ベンチマークを有界な証拠として読む

ベンチマークは定義された条件下でシステムを比較できますが、分野をまたぐ研究品質を認証するものではありません。スコアを受け入れる前に、タスクの出典、公開・非公開の分割、選択モデル、判定方法、実行予算、ベースライン設定、トレースの可用性を調べます。外部チームが設定を再現できるか、報告された指標が重大な失敗モードを明らかにするかを問います。

AIPOCH は、特定のモデルと二つの自動判定者を使い、BiomniBench-DA の公開部分で 79.05 の結果を報告しています。このベンチマークのデータセットカードは、出版物から導かれた生物医学データ分析タスク 100 件を説明しており、公開タスク 50 件と非公開タスク 50 件があります。これは複数段階の分析軌跡に関する有用で有界な証拠です。すべての研究分野、モデル、機関、未公開データセットにわたる検証ではありません。

単一の平均値より、独立した再現と詳細な失敗分析を重視します。引用ミス、単位の誤り、不適切な統計的選択、捏造された解釈、回復の失敗は、集約スコアに隠れる場合があります。検査可能なエージェントが優位になるのは、その記録が実際にレビュー担当者によるこれらの失敗の発見と修正を助ける場合だけです。

能力だけでなく運用適合性を試験する

統合は、参照ツール、チャットインターフェース、ノートブック、ターミナル、ファイルブラウザ間の引き渡しを減らせます。しかし、保守者が支えなければならない面も広げます。デスクトップパッケージング、データベース移行、資格情報、モデル API、ノートブック実行、科学プレビュー、コネクタ、クラスタスケジューラは、それぞれ独立して失敗し得ます。

AIPOCH の Slurm サポートは、統合と提供されるインフラの違いを示しています。デスクトップアプリケーションは、設定済みホスト上のジョブを送信、監視、回復、取り消し、クリーンアップし、結果を収集できます。ノートパソコンを高性能計算環境に変えることも、組み込みのクラウド GPU サービスを提供することもありません。研究室にはなお、動作する計算資源、アクセス制御、スケジューラポリシー、失敗を診断できる人が必要です。

権限にはタスクベースのユーザビリティテストが必要です。初期の AIPOCH バージョンの公開 issue は、コード作成作業中に認可プロンプトが繰り返し表示されると説明していました。この issue は後にクローズされ、その後のリリースには権限変更が含まれました。この履歴は現在の挙動を確立するものではありませんが、有益なテストを示します。プロンプトが理解可能なリスク境界で発生するか、それともユーザーが自動的に承認する日常的な中断になるかです。

インストールの労力、失敗したジョブの回復、アップグレード時の挙動、拡張機能のレビュー、ログの明瞭さ、二人目の操作者をオンボードするのに必要な時間を測定します。導入後に各タスクを誰が所有するかを記録します。ツールは価値ある制御を提供しても、組織がその周囲の制御プレーンを保守できなければ不適切であり得ます。

段階的な評価チェックリストを使う

代表的な非機微ワークフローと確立済みのベースラインから始めます。すべての手順を調べられるほど、パイロットを狭く保ちます。次にこのチェックリストを使います。

1. エージェントを実行する前に、研究課題、期待される成果物、許容できる証拠、専門レビュー担当者を定義する。
2. モデル、コネクタ、スキル、データベース、リポジトリ、リモートコンピュータを含む、すべてのローカルおよび外部コンポーネントを棚卸しする。
3. どのデータが各境界を越えるかを記録し、権限が機関のルールに合っていることを検証する。
4. 引用、入力、コード、実行、中間ファイル、成果物バージョンを通じて、一つの最終主張を後方へたどる。
5. 一つの仮定を変え、代替経路が元の経路と区別可能なままであることを確認する。
6. 保持された記録を二人目の操作者に渡し、ワークフロー再実行のあらゆる障壁を文書化する。
7. ベンチマーク条件とトレースを調べ、スコアは試験した構成だけの証拠として扱う。
8. 実行またはネットワークの失敗を導入し、回復、ログ、クリーンアップ、成果物の完全性を評価する。
9. 導入した拡張機能について、出典、ライセンス、スクリプト、ネットワーク挙動、バージョン、保守者をレビューする。
10. 出力品質、レビュー時間、セットアップ労力、失敗率、サポート負担を既存プロセスと比較する。
11. 未解決のギャップを科学的、セキュリティ、ユーザビリティ、運用上のリスクに分類し、所有者を割り当てる。
12. 証拠と制御が必要な標準を満たすワークフローだけを承認し、既定で製品により広い信頼を与えることを避ける。

最終決定は具体的であるべきです。エージェントが実行してよいタスク、アクセスしてよいデータ、承認が必要な操作、出力に添えるべき証拠、人間のレビューが必須となる時点を示します。評価が証明しなかったことも示します。

オープンソース研究エージェントが最も価値を持つのは、重要な作業を問い直しやすくするときです。AIPOCH は、文献記録、ノートブック、リモート実行、分岐、成果物来歴を検査可能なワークスペースに組み立てる方法を示しています。また、オープンなリポジトリ、ベンチマークスコア、可視のワークフローだけでは不十分である理由も示しています。永続する基準は、別の適格者が経路を理解し、手法に異議を唱え、再実行可能なものを再実行し、明確な機関境界の中でシステムを運用できるかどうかです。