10月2日、Skyvernが「Deleting RAG from our web agent made it 2.3x faster」と題した記事を公開した。この記事では、WebエージェントのアーキテクチャからRAGを取り除くことで処理速度を2.3倍に向上させた実装上の知見について詳しく紹介されている。
RAGを捨てたら、速くなって安くなった
ブラウザ自動化フレームワークSkyvernのチームが、アーキテクチャの全面刷新によって驚くべき結果を得た。処理速度2.3倍、コスト22.5%削減、そしてOdysseys benchmarkで90.5%のスコアを記録した。
「速度改善のためにコストが増える」という想定のもとで始めた実験が、真逆の結果を出した。その背景にある設計思想の転換が、このケーススタディの核心だ。
Skyvern旧設計の限界：RAGボトルネック問題
Webエージェントの文脈でRAGが広く使われてきたのには理由がある。LLMのコンテキストウィンドウには限りがあり、ページ全体のHTMLをそのまま渡せないケースが多い。そのため「必要な情報だけ抽出してLLMに渡す」という前段処理が定石とされてきた。
Skyvernの初期バージョンも、この典型的なRAG構成で動いていた。RAG（Retrieval-Augmented Generation）とは、LLMに判断させる前に外部情報を取得・加工して文脈として渡す手法だ。Skyvernの場合、具体的には以下のフローを取っていた：
- ウェブサイトをスクリーンショットしてアノテーション
- HTMLをパースしてインタラクション可能な要素を抽出
- 要素リストをLLMに渡して次のアクションを決定
問題は「全要素を正確に識別する」という前提が崩れると、エージェント全体が失敗することだ。Shadow DOM、iframe、select2ドロップダウン、Kendo UIウィジェット、Canvasといった複雑な要素への対応を追加するうちに、独自のDOMインタープリターを開発しているような状態になっていた。
さらに深刻だったのは、LLMの性能が上がっても精度が改善しないという現象だ。ボトルネックはモデルではなく、前段のDOM解析ロジックにあった。
設計の転換：「LLMに自由を与える」
チームが参考にしたのは、ミニマリスト志向のコーディングエージェントPiの設計思想だ（※元記事で言及されているPiの正確なURLは確認できなかったため、リンクは省略する）。PiはコードをRAGスタイルで埋め込み検索するのではなく、LLM自身がgrepのようなプリミティブなツールを使って必要な文脈を能動的に取りに行く。
この思想をブラウザエージェントに適用した。新アーキテクチャ（Skyvern 3.0）でLLMに与えたツールは4つだけだ：
- モデル生成のJavaScriptでHTMLをスキャン
- クリック、入力、スクロール、タブ切り替えなどのブラウザ操作（※編注：元記事ではブラウザ操作レイヤーとしてrustwriteが言及されている）
- スクリーンショットの取得
- タスク完了の宣言（成功または失敗理由付き）
事前にHTMLを全解析して渡すのをやめ、エージェントが自分で「何を見るか」を判断する構造にした。
本番A/Bテストの結果
約10万件の実運用リクエストで計測した結果が以下だ。
| 指標 | Skyvern 2.0 | Skyvern 3.0 | 変化 |
|---|---|---|---|
| 平均実行時間 | 593秒 | 262秒 | 2.3倍高速 |
| 1回あたりコスト | $0.039 | $0.0302 | -22.5% |
一見すると矛盾して見える数字がある。LLMコール回数は3.59倍（6.4回→23回）に増え、トークン総消費量も52%増加（188K→286K）しているにもかかわらず、コストが下がっている点だ。
コストが下がった理由は3点に分解できる：
- スクリーンショット利用率が90%減（全LLMコールの27%→2.7%）。画像を扱うビジョンエンコーダーはテキスト処理より約1.7倍遅いため、ここの削減が速度に直接効いた。
- プロンプトキャッシュのヒット率が195%向上（27%→79.7%）。毎ターンスクリーンショットやHTMLを丸ごと渡さなくなったことで、プロンプトの再利用可能な割合が大幅に増えた。AnthropicやOpenAIのAPIではキャッシュ済みトークンに最大70〜90%の割引が適用される仕組みがあり、コール回数・総トークン数が増えていても実コストが下がる要因となった。
- 1回あたりのトークン数は59%減（29K→12K）。大きなプロンプトを一度に渡す代わりに、小さなクエリを複数回発行する構造になったため、1コールあたりの単価が下がった。
Odysseys benchmarkでの精度
精度面でもOdysseys benchmarkでトップを記録。90.5%のPerfect Rubric成功率を達成しつつ、平均ステップ数は65.4回と効率的な動作を示した。
今後の課題
チームは「ブラウザエージェントは解決済みか？」という問いに対し、まだノーだと明言している。コスト・速度・精度のいずれも改善余地がある。
現在注目しているのがJevと呼ばれるアプローチだ。Jevは「システム1モデル」——推論ステップを積み重ねるのではなく、入力から即座に反応を返す直感的・反射的な処理モデル——のブラウザエージェントへの応用を指す概念だ。処理の高速化が期待できる反面、現状では64Kコンテキストウィンドウの制約や画像処理の非対応といった限界があり、精度への影響が課題として残っている。
詳細はDeleting RAG from our web agent made it 2.3x fasterを参照していただきたい。
