AIエージェント向けのWeb検索APIで、チームは何を作りますか？

これら4つの作業に共通するものは何でしょう?

いずれもページ上の言葉そのものが必要で、リンクの一覧だけでは足りません。160文字のスニペットには、モデルが引用すべき数値や日付、条件がほとんど収まりません。そのため、多くの構成では検索APIでURLを見つけ、リーダーで取得するという2つのサービスに行き着きます。

LLMWebSearchはこの2つのステップを統合します。1回の呼び出しでライブWeb検索を実行し、見つけた最初のページを読み取ります。各結果には、順位、タイトル、URL、ホスト、スニペット、および本文抽出された場合はページの主要コンテンツがMarkdownまたはプレーンテキストで、ワード数と判明していれば公開日も付きます。エージェントは同じラウンドトリップで引用できるテキストを取得でき、請求は1つにまとまります。

もう一つの共通のニーズは制御です。返す結果の件数(max_results)、読み取るページ数(read)、各ページの最大長(max_chars)をあなたが決めます。この3つの数値が、モデル側のトークンコストと当社側のクレジットコストの両方を決めます。

各ユースケースにはどの設定が合いますか?

デフォルトから始めて、一度に1つずつ変更してください。

• エージェントツール。 max_results=5とread=3を維持し、ページを3,000〜5,000文字に制限します。エージェントはツールを頻繁に呼び出すため、短い回答がコンテキストをきれいに保ちます。
• ディープリサーチ。 大きな検索を少数行うより、小さな検索を多く行う方が有利です。検索クエリごとにread=3を使い、クエリの回数を増やします。readを上げるのは、1つのクエリで狭い主題を深く掘り下げる必要がある場合だけです。
• RAG。 より長いページ(max_charsを12,000前後)を要求し、自分でチャンク分割します。回答が既知のソースから得られる必要がある場合はinclude_domainsを追加します。
• ニュース監視。 topic=newsとtime_range=dayを設定し、すでに見たURLを除外します。何が変わったかを要約するために、検索クエリごとに3記事を読みます。

すべてのフィルターは検索リファレンスに記載されています。

最初のパックのサイズはどう決めますか?

1日あたりのタスク数にタスクあたりの検索数を掛け、さらに30を掛けます。1日に100の質問へ各4検索で答えるアシスタントなら、月に約12,000検索が必要です。これは25,000検索に収まり、2か月分の余裕もあります。

クレジットは請求サイクルの終わりに失効しません。検索クレジットに有効期限はありません。今月使わなかった分は来年も残ります。プロトタイプ用に買った小さなパックは、プロジェクトが成長するまで価値を保ちます。コストガイドでは、より大きな3つのケースを検討し、他のAPIやモデルに組み込まれた検索ツールと比較しています。