mcpField
G
gaia-architecture-comparison

gaia-architecture-comparison

github.com/ruvnetエージェントワークフロー80.0k432 回インストール今日更新
リポジトリ

gaia-architecture-comparison について

ruflo の GAIA ベンチマークハーネスを Princeton HAL などと比較するスキルです。貢献者が能力差を把握し、評価の改善点を優先付けできます。

主な機能

  1. 01アーキテクチャ比較
  2. 02能力差の分析
  3. 03改善項目の優先付け
  4. 04ベンチマーク評価の指針

活用シーン

  1. 01次の GAIA 作業の計画
  2. 02効果の高い設計変更の選定
  3. 03ベンチマーク貢献者のオンボーディング

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ruvnet/ruflo --skill gaia-architecture-comparison

インストール後、Claude Code で/gaia-architecture-comparisonを入力して読み込まれたか確認します。

詳細

GAIA アーキテクチャ比較スキル

ruflo の GAIA ベンチマークハーネスを、Princeton HAL のリファレンス実装やその他のオープンソースハーネスと比較し、機能の不足を把握して改善の優先順位を決めます。

使用するタイミング

  • GAIA 作業の次のイテレーションを計画するとき
  • どのアーキテクチャ変更が最も高い合格率の投資対効果をもたらすか評価するとき
  • ベンチマークのコードベースに新しいコントリビューターを迎えるとき

アーキテクチャの概要

ruflo ハーネス（現行）
gaia-bench run
  └─ gaia-loader.ts      — HF dataset download + cache
  └─ gaia-agent.ts       — multi-turn Anthropic Messages loop
       └─ gaia-tools/    — web_search, file_read, web_browse,
                           image_describe, python_exec
  └─ gaia-voting.ts      — Track A self-consistency (N attempts → majority vote)
  └─ gaia-hardness/      — Track Q difficulty predictor (ADR-136)
  └─ gaia-judge.ts       — two-stage LLM-as-judge scorer
HAL リファレンス（Princeton）

HAL は似たループを使用しますが、次の点が異なります。

  • ツールインターフェースに OpenAI の関数呼び出しを使用
  • 実際のブラウザー自動化に BrowserBase / Playwright を使用
  • コードインタープリターのサンドボックス（Jupyter カーネル）
  • ターンあたりのトークン予算が大きい（4096 以上）
  • 全 300 問の評価セット
主な違い
項目rufloHAL リファレンス差分
問題数53（L1 の一部）300（L1 全体）L1 全体には --limit 165 を使用
ウェブ検索DuckDuckGo / Google CSEBrowserBase のライブ検索Playwright または Browserless を追加
コード実行python_exec のスタブ実際の Jupyter カーネル実際のサンドボックスを実装
画像 OCRimage_describe（Gemini）GPT-4V / Gemini機能的に同等
ファイル処理file_readPDF/XLSX/ZIP の完全なパーサーfile_read を拡張
自己整合性voting.ts（Track A）リファレンスにはなしruflo の優位点
難易度ルーティングpredictor.ts（Track Q）リファレンスにはなしruflo の優位点
メモリAgentDB HNSWなしruflo の優位点
L1 合格率約 20.8%（iter 23）74.6%（HAL Sonnet 4.5）約 54 パーセントポイントの差

差分分析

主な差分（影響大）

  1. 実際のコード実行 — L2/L3 の多くの問題では、数値解を計算するために Python の実行が必要です。現在の python_exec ツールはスタブです。実際のサンドボックス（E2B、Pyodide、または subprocess）の実装が、最も高い投資対効果をもたらす単独の変更です。

  2. 問題セット全体 — L1 の 300 問中 53 問を実行するだけでは、最初の 53 問の難易度が低めに偏っているため、実際の合格率を過小評価します。HAL と比較可能なスコアを得るには、--limit 165（L1 全体）を実行します。

  3. 実際のブラウザー — web_browse は現在、生の HTML を取得します。JavaScript で描画されるページに対応するため Playwright/Browserless に置き換えると、多くのウェブナビゲーション問題に対応できるようになります。

副次的な差分（影響中）

  1. 構造化ファイルの解析 — PDF、XLSX、ZIP の添付ファイルには専用のパーサーが必要です。現在の file_read が対応しているのはプレーンテキストと画像のみです。

  2. ターン予算 — 複雑な複数ステップの問題では、12 ターンでは不十分な場合があります。HAL は L3 に最大 20 ターンを使用します。

  3. システムプロンプトの調整 — HAL のシステムプロンプトはより詳細で、回答する前にツールを使うよう明示的にモデルに指示します。

ruflo の優位点

  1. 自己整合性投票（Track A）— 問題ごとに N 回試行し、最多の回答を採用することで、正解が拮抗する問題のばらつきを抑えます。HAL はこれを実装していません。

  2. 難易度ルーティング（Track Q）— 予測した難易度に基づき、各問題を適切なモデルとターン予算にルーティングします。難しい問題により多くのリソースを割り当てながら、簡単な問題のコストを抑えられます。

  3. AgentDB メモリ— 実行をまたいでパターンを保存することで、類似した問題タイプに対する有効な戦略をエージェントが思い出せるようになります。

改善ロードマップ

優先度変更期待される向上幅工数
P0実際の python_exec サンドボックス（E2B）+15～25 パーセントポイント大
P0L1 の全 165 問で評価正確なベースライン小
P1Playwright ベースの web_browse+5～10 パーセントポイント中
P1PDF/XLSX ファイルパーサー+3～8 パーセントポイント中
P2L2/L3 の最大ターン数を 20 に増加+2～5 パーセントポイント小
P2システムプロンプトの調整（iter 30 の調査）+2～5 パーセントポイント小
P3Gemini 経由の Google Grounding（iter 32）+3～7 パーセントポイント中
P3複数プロバイダーへのルーティング（低コストの問題に Gemini Flash を使用）コスト削減中

過去の調査からコンテキストを読み込む

npx @claude-flow/cli@latest memory search \
  --namespace gaia-patterns \
  --query "architecture comparison HAL benchmark"

比較結果を保存する

npx @claude-flow/cli@latest memory store \
  --namespace gaia-patterns \
  --key "architecture-comparison-$(date +%Y%m%d)" \
  --value "HAL gap: 54pp. Primary: python_exec stub. Secondary: browser, file parsing."

コメント

Markdown 対応