原典: Increase web search accuracy and efficiency with dynamic filtering

一行要約

web search / web fetch が、結果を context window に載せる前にコードを書いて絞り込むようになった。harnessing-claudes-intelligence の「オーケストレーションを Claude に返す」を検索に適用したもので、その数値の出典。

要点

何が変わったか

Instead of reasoning over full HTML files, Claude can dynamically filter the search results before loading them into context, keeping only what’s relevant and discarding the rest.

完全な HTML ファイルの上で推論する代わりに、Claude は検索結果を context に読み込む前に動的に絞り込み、関連するものだけを保持して残りを捨てられる。

原典は、これが新しい発想ではなく既存技法の移植であることを明示している。

We’ve previously found this technique to be effective across other agentic workflows, and we’ve added tools such as code execution and programmatic tool calling for native support on our API. We’re now bringing these same techniques to web search and web fetch.

この技法が他のエージェント的ワークフローで有効であることは以前から分かっており、API でのネイティブ対応として code execution や programmatic tool calling といったツールを追加してきた。今回は同じ技法を web search と web fetch に持ち込む。

数値

Across two benchmarks, BrowseComp and DeepsearchQA, dynamic filtering improved performance by an average of 11% while using 24% fewer input tokens.

2つのベンチマーク BrowseComp と DeepsearchQA を通じて、dynamic filtering は性能を平均 11% 改善しつつ、入力トークンを 24% 削減した。

ベンチ指標Sonnet 4.6Opus 4.6
BrowseComp正答率33.3% → 46.6%45.3% → 61.6%
DeepsearchQAF152.6% → 59.4%69.8% → 77.3%

BrowseComp は「意図的に見つけにくくした1つの情報」を多数のサイトを渡って探す課題。DeepsearchQA は「正答が多数あり、そのすべてを検索で見つけねばならない」課題で、多段の検索を体系的に計画・実行して取りこぼさないかを測る(だから precision と recall を均衡させる F1 で測る)。

原典自身が付けている留保

ここは素直に読むべき箇所で、トークンが常に減るとは書いていない。

Token costs will vary depending on how much code the model needs to write to filter context. Price-weighted tokens decreased for Sonnet 4.6 on both benchmarks but increased for Opus 4.6. To better understand your own costs, we recommend evaluating this tool against a representative set of web search queries your agent is likely to encounter in production.

トークンコストは、context を絞るためにモデルがどれだけコードを書く必要があるかで変わる。価格加重トークンは Sonnet 4.6 では両ベンチで減ったが、Opus 4.6 では増えた。自分のコストを理解するには、本番でエージェントが遭遇しそうな代表的な web 検索クエリの集合に対してこのツールを評価することを勧める。

つまり「入力トークン -24%」と「価格加重トークンが増える場合がある」は両立する。削減幅を自分のワークロードで測り直せというのが原典の指示。

外部からの観察

Quora(Poe)の Product and Research Lead の言。

The model behaves like an actual researcher, writing Python to parse, filter, and cross-reference results rather than reasoning over raw HTML in context.

モデルは実際の研究者のように振る舞う。context 内で生の HTML を推論するのではなく、結果を解析・絞り込み・相互参照するために Python を書く。

そのまま使える具体例

適用が効くと明示されている場面:

  • 技術文書をふるいにかける
  • 引用の検証

いずれも、結果が多く、かつ大半が無関係になるクエリである。

Sonnet 4.6 / Opus 4.6 で新しい web search / web fetch ツールを使う場合、dynamic filtering は既定で有効。

原典で言及されている関連文書