AIエージェントは断片ではなく全文書が必要

コードを書くか、ワークフローを管理するAIエージェントは、本番環境の現実に対応するためにウェブに問い合わせる必要があることが多い。市場は動き、人々は職を変え、ニュースが流れ、エージェントの有用性はウェブをどの程度よく読むかに依存する。今日の標準的なアプローチは検索ツールをエージェントにボルトオンして、ウェブを読めると想定するが、トークン監査は その想定が高コストであることを明らかにする。

典型的な検索APIはリンクと30語のスニペットを返す。エージェントは次に生HTMLを取得し、マークアップを除去し、推論を始める前に使用可能なテキストを抽出する必要がある。単一クエリでは、オーバーヘッドは小さい。しかし複数の検索が必要なタスク（調査実行、説明資料パイプライン、市場監視ループ）では、エージェントはすべてのホップで「検索税」を支払う。記事はこれを「検索税」と呼び、推論前にコンテンツを準備する際に消費されるトークンのことである。

コストを測定するため、分析は同じ質問（「Y2K とは何か」）を3つの検索セットアップで実行し、課金されたトークンを数えた。モデルは既に訓練からこの答えを知っていたため、ベースラインを超えるトークンはすべて検索からのみ来ていた。メモリのみからの答えは約600トークンかかった。事前にページを爬行して清掃し、処理されたコピーを保存する独自のインデックスを通じては、約6,900トークンかかった。しかし単一のウェブ検索ホップは約3,750トークンかかり、スニペットはしばしば答えるには薄すぎるため、エージェントは再取得して精密化した。3番目のホップまでに、合計は約28,700トークンに上昇し、独自のインデックスの4倍以上である。ループとインデックス間のギャップは可視化された検索税である。3回目のパスまでに、エージェントはほぼすべてを既に読んだページを運ぶために支払っていた。

記事は3つの検索形状を比較する。SERP（検索APIが返す結果の単純なリスト）はURLを与え、エージェントにウェブを読むことを求める。スクレーパーファースト型ツールは生HTMLやマークダウンを返すが、エージェントはそれでも清掃する必要がある。独自のインデックスはクエリが到着する前にすべての作業を行うため、戻ってくるものは既に読可能である。Interpretable Machine Learning著者のChristoph Molnarの検索では、SERPはタブのリストを返し答えはなかった。ニューラル検索ツールは正しい人物を発見ハイライト断片として見つけたが、完全なレコードを取得するには別の呼び出しが必要だった。独自のインデックスは1つの呼び出しで完全なレコードを返し、エージェントは推論に直行した。

Seltzはエージェント向けに構築されたウェブインデックスとして説明され、事前にウェブを爬行し、すべてのページを構造化ドキュメントに処理し、単一のAPI呼び出しを通じて完成したコンテンツを返す。3つのスコープを備えている。People Scopeは職務日付、教育、ウェブサイト、組織を含む完全に構造化されたプロフィールを返す。News Scopeは完全な記事テキストと日付ウィンドウを返す。Wiki Scopeはクリーンなウィキペディアドキュメントを返す。1つの注意点は、People Scopeはディレクターと地域リーダーレイヤーで最も効果的に機能すること。最も上級の幹部の場合、記事はオープンウェブ検索で開始し、Seltzを使用して彼ら以下のすべての人を充実させることを推奨している。

完全なドキュメントは検索税を削減する以上の能力を解放する。単一の検索結果に存在しない質問を可能にする。Go-to-marketチームが実際に実行する質問を考える。過去四半期にデータやAIのリーダーシップ職に雇用されたすべてのターゲットアカウントを見つけることである。答えは2つのものが一緒に必要。誰が新しい職に就きいつかを見つけるための完全な職務経歴と、タイミングを確認してトリガーイベントを表示するための最近のニュース。People Scopeのクエリは最近適切な職に移った人を見つけ、News Scopeをクロスリファレンスするとトリガーイベントを表示する。結果は十分なコンテキストで関連するアウトリーチを書くための適切なアカウントのランク付きリストである。その答えはウェブのどこにも単一ページとして存在しない。レコードを結合したときにのみ存在し、結合は最初からレコード全体を持つときのみ機能する。

記事は、Seltzがオープンウェブ検索の代替ではないことで締めくくる。オープンウェブ検索は発見をうまく処理する。誰が現在タイトルを保持しているかを見つけ、何かが先週始まったことを確認し、今朝ゴーライブしたページを読む。しかし探しているものが分かったら、Seltzは見出しとリンクではなく1ホップで完全なレコードを返す。多くのパイプラインはすべてのクエリに同じ検索ツールを使用し、質問が何を必要とするかに関係なく、発見クエリとディープダイブ検索は同じ呼び出しを通じて進み、両方で検索税を支払う。代わりにチェーンして（発見にオープンウェブ検索を使用し、ディープダイブに索引付きサービスを使用）、各ループ反復が実際に何をしようとしているかに対して正しい検索形状を取得できる。

この記事は、AIエージェントがウェブと相互作用する方法における構造的なミスマッチを示唆している。コーディングエージェントはソフトウェア生成のコストを劇的に削減したが、検証能力（本番環境前に障害を検出する能力）はそれに追いついていない。AI生成コードは、人間がコードを書くときに思考モデルを形成していないため未知の未知数に失敗し、検証を実際のトラフィックで行わざるを得ない。同じ課題はプロンプト変更と検索増強生成（RAG）にも適用される。オフラインテストは本番環境の障害を予測することはできない。この本番環境優先の検証へのシフトは、オペレーターが必要とするあらゆる属性で事後的にスライスできる生の高カーディナリティテレメトリーを必要とする。

このフレーム内では、ウェブ検索は現在のデータを扱うエージェントにとって重大なボトルネックとして浮かび上がる。市場の変化、新規採用、公開されたニュース、価格更新である。この記事は隠れたコストを定量化する。スニペットではなく全文書を返すすべての検索呼び出しにより、エージェントはHTMLを取得、解析、清掃するよう強要され、ループの反復ごとにこのコストを支払う。トークン監査（スニペットを3ホップで28,700トークン対インデックス付き文書の単一クエリで6,900トークン）は、コンテキストウィンドウサイズに対する複合税を可視化する。この記事は、修正はより賢いモデルやプロンプトではなく、検索インターフェイス自体の変更（完成した構造化ドキュメントを返してエージェントに推論させ、前処理をさせない）であると主張している。

まだコメントがありません。最初のコメントを投稿しましょう！