AIファーストの検索APIのアーキテクチャ設計と評価

スケーラブルかつAI主導型の検索APIの構築は、情報検索、AI、システム設計の交差領域において、独自の研究課題を提示します。限定的なデータで動作する従来のサービスとは異なり、検索APIは、何十億もの文書を継続的にインデックス化し、言語やドメインを問わずクエリの意図を理解し、ミリ秒単位で関連性の高い結果を表示しなければなりません。AIエージェントの世界において、検索APIは、モデルが最適に動作し、最大限に正確な情報を取り込めるよう、開発者のモデルに提供されるコンテキストを慎重にキュレーションする必要があります。効果的なコンテキストエンジニアリングには、APIが文書レベルの関連性を捉えるだけでなく、個々のセクションや文書の範囲をそれ自体で第一級のユニットとして扱うことが求められます。

本稿では、Perplexity Search APIの設計と評価について提示します。まず、1日あたり2億件のクエリを処理する当社のプロダクション検索インフラストラクチャを支えるアーキテクチャと、主要な技術的決定事項について解説します。当社のアーキテクチャは、ハイブリッドな検索メカニズム、多段階のランキングパイプライン、分散型インデックス化、そして自己改善型のコンテンツ理解モジュールによる動的な解析を組み合わせています。

次に、新たにオープンソース化した評価フレームワークを通じて、検索APIのパフォーマンスを実証的に評価する当社のアプローチを説明します。既存の商用APIと比較した包括的なベンチマークにより、品質とレイテンシの両面で最先端のパフォーマンスを実証します。Perplexity Search APIは、本日より世界中の開発者にご利用いただけます。

[Find search_evals on GitHub]

AIモデル向けに最適化された検索システムの構築

創業以来、当社は、実現したいカテゴリーを定義するAI製品をリリースするためには、堅牢な検索機能が不可欠であると理解していました。当初、私たちはこうした機能がすでに一般公開されていることを期待していました。2022年後半に利用可能な検索APIのポートフォリオを試用し、実際にPerplexityの回答エンジンの最初のバージョンには、それらの一部が組み込まれていました。具体的には、ユーザーのクエリを分析し、これらのAPIへのリクエストを生成・送信し、その結果を後続の生成パイプラインのコンテキストとして収集していました。

しかし、ユーザーがPerplexityに押し寄せるにつれ、これらのAPIでは当社の成長に対応できないことがすぐに判明しました。私たちが直面した価格は法外なもので、ある主要なAPIプロバイダーは1,000クエリあたり200ドルを請求していました。しかし、より致命的だったのは、これらのレガシーAPIが、最先端のAIシステムによって導入された新しい検索パラダイム向けに設計されていなかった点です。

拡大

まず、これらのレガシーAPIのリクエストおよびレスポンス形式は、人間が検索結果の唯一の消費者である世界を想定して設計されていました。その結果、これらのAPIは文書レベルの結果を優先し、サブ文書単位によって明らかにされるよりきめ細かい情報は排除されていました。AIモデルの成功は、提供されるコンテキストの品質と簡潔さに左右されます。検索された文書全体としては関連性が高いように見えても、広すぎる検索範囲がAIモデルの妨げになることを私たちは身をもって経験しました。不正確な結果に対して精度を無理に押し付けようとする私たちの試みは、限られた成功しか得られませんでした。

また、レガシーAPIは古すぎるか、遅すぎるかのいずれかであることにも気づきました。独自に開発された検索APIは、不完全で更新頻度が低いインデックスに依存していました。Google検索の様々な非公式SERP APIのようなスクレイピングベースのAPIは、より包括的なインデックスを活用できましたが、サードパーティの検索エンジンへの問い合わせに起因する非効率性により、許容できないほど高いレイテンシを示しました。高いレイテンシはユーザー向けのアプリケーションに適さず、情報の鮮度の欠如は、正確かつ信頼性の高いAIシステムを目指す上で、結果セットを使用不能なものにしていました。

最後に、AIエコシステムが語彙検索とセマンティック検索に分断されており、一方のモダリティに過度に最適化されたシステムが登場していることを観察しました。単純なブールフィルタさえ十分にサポートできないベクトルデータベースの台頭も目にしました。従来の検索バックエンドも、AIによって解き放たれるセマンティックランキングや検索機会に対するサポートが初歩的であり、状況はそれほど変わりませんでした。

Perplexityをさらに良くするためには、独自の専用検索インフラストラクチャを構築する必要があると気づいた私たちは、観察結果を3つの主要な基準に絞り込みました。

完全性、鮮度、速度: 検索インデックスは包括的かつ常に更新され、リアルタイムのレイテンシを実現するように設計されている必要があります。

きめ細かいコンテンツ理解: AIモデルの脆さと限られたコンテキストウィンドウのため、検索結果は可能な限り粒度の細かいレベルで提示およびランキングされる必要があります。

ハイブリッド検索とランキング: 検索およびランキングの両パイプラインは、AIにとって結果が有用となるよう、語彙的およびセマンティックな信号を取り入れる必要があります。

拡大

クロールおよびインデックス化インフラストラクチャ

Perplexity規模で運用するには、Webを包括的にマッピングし、絶えず進化するWebに対応できるインフラストラクチャが必要です。当社の検索インデックスは2,000億以上のユニークなURLを追跡しており、さらに数千億ものURLを追跡する能力を備えています。

インデックスがインターネットの十分に包括的な範囲をカバーし、各文書が最新の状態を反映していることを保証することは困難な偉業です。完全性と鮮度の間には固有の緊張関係が存在します。固定されたインデックス予算に対して、既存ページのリフレッシュ操作と、未訪問の新規ページのインデックス操作が競合するためです。私たちは、スケーリング（インデックス予算を増やすことで最適化の制約を緩和する）と、ML主導の優先順位付け（各インデックス操作がインデックス全体にとって最大限に価値があることを保証する）を組み合わせることで、この緊張のバランスを取っています。

私たちは、サイズとクエリ量の両方で水平方向にスケーリングする、エクサバイト規模のインデックスおよびクロール装置を構築しました。Perplexityのクローラーおよびインデックス化艦隊は、合計で数万のCPUと数百テラバイトのRAMで構成されており、さらなるスケーリングのためのかなりの余裕があります。この計算インフラストラクチャと、コールドストレージとウォームストレージのバランスを組み合わせています。学習済みモデルと調整されたヒューリスティックの両方を使用して、どの文書をホットに保つかを決定し、権威あるドメインからの文書、対象範囲が不十分なトピックに関連する文書、およびインデックスを充実させる潜在能力が極めて高いその他のカテゴリを優先しています。

このインフラストラクチャにより、Perplexityは1秒間に数万件のインデックス操作を処理できます。しかし、この比較的寛大な予算をもってしても、インターネットの規模は広大すぎて、すべてのURLを頻繁に繰り返しインデックス化することは不可能です。ここでMLの出番です。私たちは、特定の候補URLをインデックス化する必要があるかどうかを予測するMLモデルを学習させています。学習の目的は、インデックス化の決定を、そのURLの重要性と予想される更新頻度の両方に適合させるよう設計されています。また、インデックス化操作をいつスケジュールすべきかを正確に判断するためにもMLに頼っています。日常的な公開およびリフレッシュの周期を持つサイトについては、操作を最も有用である可能性が高い時点まで延期できます。これらのMLモデルの継続的な改良を通じて、完全性と鮮度の両面で基準を満たすインデックスを維持できています。

当社のクロールインフラストラクチャは水平方向に容易にスケーリングしますが、Webサイト運営者が異なる技術的制約に直面していることは認識しています。特定のドメインへのリクエストレートを予測可能かつ管理可能なレベルに保つよう注意を払っています。当社の検索クローラーであるPerplexityBotは、robots.txtファイルで定められた明示的な制限、またはドメイン指定の制限がない場合はリクエストレートに関する業界標準の規範を遵守しています。また、サイトの利用不可を検出した際には、クロール動作を調整します。当社の分散システムは、数万件の同時実行操作にわたってもこれらの制限を強制できるように設計されています。

インターネット規模における自己改善型のコンテンツ理解

地球上で最大かつ最も新鮮な検索インデックスの1つを持っていても、各クエリの結果品質は、各文書の内容に対する当社のシステムの理解に依存します。ここで、私たちは根本的な課題に直面します。Webは複雑な場所です。固定された解析ルールセットでは、インターネット全体で見られる無限に多様なレイアウト、構造、スタイルを処理することはできません。

私たちは、動的なルールセットを使用してWebサイトを解析し、セマンティックに意味のあるコンテンツを抽出するコンテンツ理解モジュールを開発することで、この課題を解決しました。リストや表形式で構造化されたデータが豊富なWebサイトは、定型的な解析および抽出ルールから恩恵を受ける可能性がありますが、自由形式のユーザー生成コンテンツが主体となる別のWebサイトでは、より緩やかなルールセットが必要になる場合があります。Webは短期間ではほとんど静的であるため、特定のルールの寿命は比較的長いことがわかっています。しかし、サイトが時間の経過とともに進化し、情報を抽出するための最良の方法について私たちが学ぶにつれて、ルールセットも継続的な手入れが必要になります。

この動的な適応を促進するために、私たちは（当然ながら）AIを活用します。Perplexityの規模では、1時間ごとに数百万件のユーザークエリを処理する過程で、Webの非常に豊かな断面を観察しています。これが、反復的な自己改善ループの基盤となります。クエリの世界全体を通して、現在のルールセットの解析動作と抽出出力を観察します。その後、最先端のLLMを使用して、以下の2つの主要な次元にわたるパフォーマンスを評価します。

完全性: インデックスは、意味のないまたはナンセンスな事項の誤った抽出を避けつつ、セマンティックに意味のあるコンテンツを可能な限り多く受け取るべきです。

品質: インデックスは、実体と形式の両面で高品質なコンテンツに依存しています。情報は、元のコンテンツの構造とレイアウトを維持する方法でキャプチャされるべきです。

完全性と品質には別の固有の緊張関係があることに留意してください。品質のために手動で最適化することは可能ですが、結果として得られる解析ルールは重要なコンテンツをキャプチャできない可能性があります。同様に、生のコンテンツに対して最小限のフィルタリングを適用する許容的なルールを手動でコーディングすることもできますが、これは完全性を向上させる可能性がある一方で、品質を犠牲にする可能性があります。そのため、私たちはAI主導の自己改善に目を向け、ドメイン適応的な方法で両方を一度に最適化できるようにルールセットを進化させています。

具体的には、各LLM主導の解析パフォーマンス評価の後、システムは最も重大なエラークラスに対処するためのルールセットの変更案を策定します。これらのルールセットはさらなる検証を受け、その後、新しいバージョンをインデクサーにデプロイします。解析および抽出ロジックの改善は将来のインデックス操作にのみ利益をもたらすため、MLで最適化された再インデックス化への投資は特に重要です。このロジックの最新バージョンを使用して高トラフィックの文書を継続的に更新することで、緊密な自己改善ループが確保されます。

これらのルールは、ベースラインの解析パフォーマンスだけでなく、サブ文書単位へのセグメンテーションにとっても重要です。最先端のLLMに関しては、コンテキストの各トークンが貴重です。コンテキストサイズの増加と、関連のない情報によるコンテキストの汚染によってLLMのパフォーマンスがどのように低下するかについては、多数の先行研究が文書化しています。十分に構造化された包括的な解析を行うことで、文書を自己完結型のスパンに分解し、クエリ時に個別に検索およびランキングすることが可能になります。

検索およびランキングパイプライン

現代の検索では、厳しいレイテンシ予算の下で、完全性と関連性の両方を確保する必要があります。Perplexityの検索およびランキングパイプラインは、一連の高度なモジュールで段階的に結果を洗練させる多段階アーキテクチャを通じてこれを達成しています。潜在的なボトルネックは、考えられるすべての詰まりポイントを可能な限り水平方向にスケーリングすることで解決しています。

パイプラインは、インデックスからの検索で始まります。私たちは、語彙的検索とセマンティック検索のどちらかを選択することを強制しません。むしろ、両方のモダリティを通じて検索インデックスをクエリし、結果をハイブリッドな候補セットに統合します。この段階では、優先順位は精度よりも包括性に置かれています。パイプラインの後続の段階で精度を最適化します。

パイプラインはプリフィルタリング段階へと続き、ここで基本的なヒューリスティックと最初のフィルタを適用して、明らかに非応答的または古いコンテンツを候補セットから削除します。

その後、段階的に高度なランキングを複数回行います。初期の段階では、速度に最適化された語彙的および埋め込みベースのスコアラーに依存します。候補セットが徐々に絞り込まれるにつれて、より強力なクロスエンコーダー再ランキングモデルを使用して、結果セットの最終的な形成を行います。推論パフォーマンスへの数多くの投資のおかげで、全体的なランキングレイテンシを低く抑えつつ、後の段階で最先端のモデルアーキテクチャを活用できます。

このパイプライン全体を通じて、文書レベルとサブ文書レベルの両方で結果を検索およびスコアリングします。前述のとおり、AIには慎重なコンテキストエンジニアリングが必要です。当社のパイプラインは、ソース文書内の他の場所から無関係なコンテキストを引き出すことなく、後続の消費者がそれらの正確なユニットを取り込めるよう、モデルに対して可能な限り原子的なユニットを提示するように設計されています。

このパイプラインの各段階で高品質を確保できるのは、Perplexityの製品ポートフォリオとの共同設計があってこそです。ランキングスタックのあらゆる詳細は、1日あたり数百万件のユーザーリクエストから生成される豊かな信号を活用するように設計されています。この信号の大部分は自動化されており、生成された各Perplexityの回答は、ライブのエージェント型ワークフローで使用される検索品質に関する実証的なデータポイントを提供します。AI主導の評価とライブの人間のフィードバックを組み合わせることで、埋め込みモデルやランキングモデルのトレーニングデータを、手動で構築されたデータセットが提供できるものをはるかに超えて充実させています。

この検索と製品の相乗効果は、Perplexity独自のものです。レガシー検索エンジンは、ブルーリンクのテレメトリによって提供される粗い信号に限定されています。新しい検索サービスもこれらのAI主導の概念の一部を実装しようとしましたが、検索品質を検証し、迅速な改善ループに必要な信号の豊かさを提供できる実世界の環境を欠いています。幸いにも、私たちは欠けていた要素を持っています。最先端のLLMによって強化され、世界中の何百万人もの好奇心旺盛なユーザーによって継続的にテストされる、検索品質のためのライブの実験場です。

品質とパフォーマンスの新たなフロンティアの確立

当社の検索インフラストラクチャを世界中の開発者が利用できるようにPerplexity Search APIとSDKを構築した後、私たちは様々な商用APIが実際のAIユースケースでどのように評価されるかを理解したいと考えました。AIモデル自体を評価することは一般的になっていますが、私たちはこのパターンにひねりを加える必要がありました。AIモデルによって呼び出された際の検索APIの品質を評価することです。

まず、先行技術を理解するためにオープンソースのエコシステムに目を向けました。厳密な評価に必要な主要な要素の多くを見つけましたが、これらの要素をプラグアンドプレイのベンチマークソリューションに統合するフレームワークはありませんでした。そのため、Perplexityだけでなく、検索APIをベンチマークしようとするあらゆる研究者や開発者が使用できる評価フレームワークを開発することに着手しました。

この評価フレームワークを使用して、Perplexity Search APIを他のサービスと比較して厳密にベンチマークしました。検索パフォーマンスの最適化は複雑で、品質と速度の間に多くの微妙なトレードオフがあります。開発者にとっての利点として、Perplexity Search APIが品質とレイテンシの両面で新しい最先端を実現していることがわかりました。開発者は、超高速のアプリケーションを構築することと、高品質な結果を確保することの間で選択する必要はもうありません。Perplexityを使えば、その両方を手に入れることができます。

拡大

エージェント型検索ワークフローのための信頼性の高い評価の設計

まず、私たちの評価フレームワークの3つの指導原則を定義することから始めました。

複雑さのスペクトル: 評価フレームワークは、単純なユースケースと複雑なエージェント型AIユースケースの両方でパフォーマンスを測定する必要があります。

中立性: 評価フレームワークは、すべてのAPIを対等な立場で評価する必要があります。

単純さ: 特定のユースケースは複雑になる可能性がありますが、フレームワーク自体は、他の人が理解し、結果を再現し、最小限の労力で拡張できるように、可能な限り単純である必要があります。

私たちの軽量な評価フレームワークであるsearch_evalsは、単純なモジュール設計を通じてこれらの目標を達成しています。古典的なシングルショット検索ユースケースと、高度なエージェント型ワークフロー（消費者市場で広く利用されている様々な「深い研究」製品によって例示される）の両方を捉えるために、2つのAIエージェントハーネスを開発しました。どちらのハーネスも、隠れた利点の余地をほとんど残さない単純な方法で実装されました。

評価を推進するために、4つのベンチマークを採用しました。シングルステップ検索用のSimpleQAとFRAMES、そして深い研究用のBrowseCompとHLEです。これらを総称して、知識エージェントのための広く受け入れられている尺度を提供します。確立された慣例に従い、元の研究で使用されたものと同じプロンプト分類器の手法を使用して、すべてのベンチマークを評価します。正確なベンチマークの実装（グレーダーロジックを含む）は、当社のGitHubリポジトリで確認できます。

再現性と拡張性を念頭に置いてフレームワークを設計しました。タスクレベルのスコアとエージェントの基礎となる出力の両方が、各実行とともに保存されます。追加のハーネス、ベンチマーク、検索APIサービスを容易に統合できます。研究者や開発者は、GitHubのドキュメントを読んで、正確なニーズに対処するためにフレームワークを拡張する方法についての詳細を確認できます。

評価結果

この評価フレームワークを武器に、当社のSearch APIを他のAPIサービスと比較して評価しました。テストされたすべてのベンチマークにおいて、Perplexityは市場で最も高速かつ最高品質のAPIとして位置付けられています。

拡大

インデックス、検索、ランキング効率に対する前述の投資が大きな成果を上げたことがわかりました。Perplexityの中央値レイテンシは358msで、2番目に高速なプロバイダーを150ms以上上回っています。95パーセンタイルのレイテンシも800msを大幅に下回っています。今日の最先端モデルの長いTTFT（最初のトークンまでの時間）メトリクスでは、楽しいユーザー体験を作成するためにミリ秒単位の時間が重要になります。私たちは過去2年間、自社ユーザーのためにレイテンシの最適化に費やしてきました。その同じ投資が今、開発者コミュニティにも利益をもたらすことを嬉しく思います。

検索APIのレイテンシ

（AWS us-east-1から開始されたリクエスト）

AWS us-east-1 から開始されたリクエストの Search API レイテンシのパーセンタイル。

* 多くの検索APIベンダーは、結果の基盤としてSERPスクレイピングを使用しています。このようなアプローチのパフォーマンスを捉えるために、Tavilyが提供する代表的なGoogle SERPベースのAPIを使用しています。

この速度の優位性は、品質を犠牲にして得られるものではありません。Perplexity Search APIは、シングルステップ検索と深い研究設定の両方で最先端のパフォーマンスを発揮します。テストされた各ベンチマークにおいて、Perplexityは、様々な複雑さのAIワークフローを強化できる高品質な結果を提供することにおいて先頭を走っています。Perplexityと最良の代替手段との差はSimpleQAとHLEで特に顕著であり、これらの結果がタスクの複雑さのスペクトル全体にわたって堅牢であることを示しています。

拡大

レイテンシと同様に、検索品質における私たちのリーダーシップは、楽しく高トラフィックなAI製品を構築することにおける私たちのリーダーシップから流れ出たものです。何百万人ものユーザーが、想像できるあらゆるトピックに対する好奇心を満たすためにPerplexityを使用しており、その結果として得られる品質と関連性の信号により、検索モデルは時が経つごとに改善されています。

検索API品質ベンチマーク

SimpleQA、FRAMES、BrowseComp、HLE における Search API の品質スコア。

私たちはまだAIネイティブ検索エンジンの黎明期にあり、測定の技術と科学は間違いなく進化するでしょう。私たちは、AIエージェントの時代において検索エンジンを評価するための厳密かつ創造的な方法を開発することで貢献するようコミュニティを招待します。

AIの次なる章のためのビルディングブロック

エージェント型システムとインテリジェントアシスタントの未来は、世界の集合知への豊かなプログラマティックインターフェースの可用性に左右されます。今日のレガシー検索エンジンは、1日あたり約10¹⁰クエリという使用量で飽和状態にあり、この数字はおそらくピークに達しています。次世代の検索・検索システムは、より多くのアクティブなAIエージェントが正確なリアルタイム情報を求めてそれらに依存するようになるため、桁違いに多くのリクエストを処理することになるでしょう。

これまでの私たちの努力により、私たちはAPI経由でアクセス可能な、最も高速で高性能な検索エンジンとしての地位を確立しました。しかし、AIの次なる章を加速させるためには、さらに野心的な革新が必要です。高まる需要に直面して、これらのシステムをどのように効率的にスケーリングすればよいでしょうか？コンテキストエンジニアリングとポストトレーニングの新しいアプローチを考慮して、これらの検索システムをどのように最適化できるでしょうか？そして、完全性、鮮度、レイテンシの間に常に存在する緊張関係をどのように乗り越えればよいでしょうか？これらは、Perplexityが製品フットプリント、規模、技術的才能を組み合わせて、独自の立場から取り組むことができる未解決の問題です。

引用

@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
  author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
  title = {{Architecting and evaluating an AI-first Search API}},
  date = {2025-09-25},
  url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}