Photon：ゼロからの取得・ランキングエンジンの構築

はじめに

PerplexityのAIネイティブ検索スタックは、候補ページを取得してランク付けし、モデルが回答の根拠とする最も関連性の高いコンテンツを表面化させます。もともと、このステージは私たちのシステムに適応させたオープンソースエンジンで実行されていました。しかし、インデックスとワークフローが成長するにつれて、既存のサードパーティプラットフォーム内では解決できないコスト、テールレイテンシ、ノード復旧時間の厳しい制限に直面しました。

これらの課題を克服するために、新しい社内向け取得・ランキングエンジンであるPhotonを構築しました。これは、ページレコードを提供するための分散キーバリューストアであるCobbleDBやSearch APIと同様に、AIファーストの検索インフラストラクチャをゼロから構築するという当社のアプローチを引き継ぐものです。

Photonは、コンパクトなデータ形式を使用して、各クエリに必要なデータのみを読み取ってデコードします。また、バッチアウェアなキャッシュと非同期読み取りを活用してディスクアクセスを削減し、待機時間をオーバーラップさせます。インデックス構築はクエリの提供とは別個に実行され、一度に1つの提供グループを更新し、ライブクエリをルーティングする前にそのキャッシュをウォームアップします。

Photonは現在、検索パイプラインを動かしており、Search API向けの新しい高速プリセットの基盤でもあります。単一検索呼び出しのレイテンシは、p50で160 ms、p95で230 msです。6つの公開ベンチマークにおいて、高速プリセットは、デフォルトプリセットと同等の集計タスク品質を維持しながら、タスクあたりの推定モデル・検索コストを68%削減しました。開発者がこれらの改善にアクセスできるように、本日リリースいたします。

拡大

拡大

取得およびランキングエンジンに必要なもの

各クエリについて、取得およびランキングエンジンは、大規模で分散されたインデックスを検索して、検索スタックのレイテンシ予算内で関連するページの小さなセットを選択して順序付けます。システムはまた、ワークがライブクエリを遅くすることなく、新しいページの到着や既存のページの変更に合わせてインデックスを最新の状態に保つ必要があります。

いくつかのオープンソースの選択肢を評価し、初期のニーズを満たす成熟した汎用の取得およびランキングエンジンを選択しました。その後、それをアーキテクチャとワークフローに適応させ、本番スケールで安定したレイテンシとスループットを維持しました。

以前のシステムが不足していた点

増大するインデックスに合わせてエンジンを適応させるために独自のフォークを維持していましたが、主要な制限に対処するには、プラットフォームの大部分を再設計する必要性がますます高まりました。いくつかの制約は、根本的なアーキテクチャの変更なしでは解決することが困難であることが判明しました：

1. スケーリングコスト。保存するドキュメントの数と、取得およびランク付けする必要があるドキュメントごとのデータの量の両方が時間の経過とともに増加しています。このスケーリングにより、ハードウェア、特に利用可能なRAMの量に負荷がかかりました。コストを制御するために、よりコンパクトなデータ表現と、メモリに保持するものとオンデマンドでディスクから読み取るものをより細かく制御する必要がありました。

2. 遅いテールレイテンシ。本番トラフィックでは、古いシステムのp99応答時間は約800 msでした。データセットが利用可能なRAMを超えていたため、mlockを使用してメモリ内に完全に保持することができませんでした。非常駐データへのアクセスはメジャーページフォルトを引き起こす可能性があり、オペレーティングシステムがディスクから読み取っている間、クエリの実行が停止しました。

エンジンはまた、メインのディスクインデックスをメモリからフラッシュされた小さなインデックスと定期的にマージしました。このディスクインデックスの融合プロセス中、ページフォルトの数はさらに増加し、p99レイテンシは10〜15分間約1.2 sに達しました。キャッシュがウォームアップされるにつれて、ページフォルトの頻度とレイテンシの両方が低下し、コールド読み取りがスパイクの大きな原因であったことが示唆されました。データの事前ロードとインデックスのウォームアップによりスパイクは削減されましたが、高いテールレイテンシには十分に対処できませんでした。

3. 長時間のリカバリと同期。以前のシステムでは、追加のクラスターをデプロイしてそのデータを同期するのに1週間以上かかることがありました。同期は、追加のデータコピーを保持するためにノードのグループを追加する場合や、ノード障害からリカバリする場合にも必要でした。リカバリ中、検索応答の部分的な割合が大きくなり、最終回答の品質スコアが低下しました。

最終的に、フォークの適応と維持を続けるよりも、最初から独自に構築する方がよりシンプルでコストがかからないという結論に至りました。以前のシステムを運用した経験を活かし、少数のエンジニアリングチームが永続的なコーディングエージェントの群れと協力してPhotonを構築しました。

検索スタックにおけるPhotonの位置づけ

Photonは、検索リクエストの提供と処理パイプラインからの更新の取り込みという2つの主要なワークフロー向けに設計されています。

上位の検索サービスからのリクエストは、ロードバランサーを介してPhotonブローカーに到達します。ブローカーはシャードグループを選択し、リクエストを各シャードに転送して、タイムアウトを監視し、必要に応じて追加のリクエストを発行します。

各シャードは、取得、初期ランキング、および第2ステージのランキングを実行し、ベストな候補をブローカーに返します。ブローカーはこれらの候補を単一のランク付けされたリストに結合し、関連するシャードから選択されたページのキーとなるドキュメントフィールドをフェッチします。その後、これらの結果を上位の検索サービスに返し、検索サービスがエージェントが根拠のある回答を生成するために必要なページコンテンツを集めます。

インデックスの更新は別のパスに従います。パブリッシングレイヤーであるPillarがデータを準備し、YTsaurusテーブルに保存します。インデクサーはこれらのテーブルを、シャードが検索のためにロードできるインデックス構造に変換します。コントローラーは、データの準備、インデックスの構築、および新しいインデックスバージョンの提供グループへのデプロイメントを調整します。ライブトラフィックを処理する前に、各シャードは実際の検索クエリを再生してキャッシュをウォームアップします。

拡大

ワークフローに合わせたPhotonの設計

3つの設計上の選択により、Photonは私たちのワークフローに非常によく適したものとなっています。コンパクトなデータ表現、キャッシュと非同期ディスク読み取り、そしてインデックス更新とクエリ提供の分離です。

取得およびランキングのためのデータ表現

取得とランキングではドキュメントデータへのアクセス方法が異なります。字句的取得はクエリ用語から始まり、それらを含むドキュメントを見つけます。その後、ランキングには、用語の頻度や位置など、選択された各ドキュメントに関する詳細情報が必要になります。

Photonは、これらのアクセスパターンをサポートするために2つの補完的な表現を使用します。転置インデックスは、候補の選択をサポートするために、ポスティングリストと呼ばれる、各用語の一致するドキュメントのリストを格納します。個別のドキュメントごとのレコードは、ランキングに必要なデータを提供します。また、固定された作業予算内で選択を改善するために、ポスティングリストの保存方法とトラバース方法も最適化しています。

専門的なデータ表現により、キーデータをより効率的に保存できます。よりコンパクトな転置インデックスにより、クエリごとに読み取られるまたは移動されるデータの量が削減され、不要なI/O操作が排除されてレイテンシが向上します。これらの形式により、ドキュメントがリストに表示されるかどうかを完全にデコードせずに確認することも可能になります。これは、クエリが固定予算の下で行う作業の量を制御するためにトラバーサルロジックが依存する特性です。ドキュメントごとのレコードを最適化することで、ランキングのためにドキュメントあたりより多くのデータを保存できるようになり、同時に以前のシステムに関連するスケーリングコストが削減されます。

転置インデックス

各用語について、転置インデックスはポスティングリストを格納します。これらのリストは、一握りのドキュメントから数百万に及ぶため、すべてのリストにうまく機能する単一の形式はありません。Photonは、その用語を含むドキュメントの数に基づいて形式を選択します。

短いリストには、単一のページ内に収まり、ブロックテーブルを必要としないインライン表現が使用されます。インライン形式に収まらない長いリストは、ドキュメント識別子の固定範囲をカバーするブロックに分割されます。各ブロックの表現はその密度に依存します。スパースブロックはソートされたドキュメントIDオフセットの配列を格納し、デンスブロックはビットマップを使用します。スパースブロックはギャロッピング検索を使用し、ますます大きなステップで前進してリストの領域をスキップします。デンスブロックでは、ドキュメントに対応するビットをルックアップすることでメンバーシップチェックを行うことができます。

用語のクエリ頻度によって、そのポスティングリストがディスク上のどこに配置されるかが決まります。頻繁にクエリされるリストは互いの近くに格納され、ホットデータをより小さなストレージ領域に集中させます。各リスト内では、ドキュメントは別々の有用性シグナルによって順序付けられ、より有望な候補が早期に見つかるようになります。

拡大

作業予算内でリストをトラバースする

候補の選択には、ポスティングリストをトラバースして潜在的に関連するドキュメントを見つける必要があります。すべてのリストを網羅的にスキャンすることはコストがかかるため、Photonは、他のリストの一致を考慮に入れながら一部のリストのみをトラバースするWANDライクなアルゴリズムを使用します。

アルゴリズムはリストを2つのグループに分割します。駆動リストはトラバーサルを進め、候補ドキュメントを提案します。プローブリストはそれらの候補のスコアに貢献しますが、それ自体で候補を生成することはありません。

候補のスコアリングは、重み付けされたクエリ用語のカバレッジと頻度の寄与を組み合わせ、ドキュメントの長さの正規化と、繰り返される用語からの利益に対する上限を設けます。Photonは、まず配列とビットマップ内の用語の存在を確認して、各候補の最大可能スコアを制限します。選択しきい値を満たすすべての候補についてのみ、正確な用語頻度を読み取ります。

選択は3つのステップで進行します：

• トラバーサル：厳格なクエリカバー要件から始めます。候補が少なすぎる場合は、緩和された要件で繰り返します。
• 保持：候補は、カバレッジと頻度を組み合わせたスコアを使用して、境界付きセットに保持されます。収集されたトップ候補が改善されるにつれて、許容なしきい値が上昇します。
• 最終選択：パスの最終結果は、頻度スコアに基づいて保持されたセットから選択されます。各フィールドは独自のパスを実行し、結果はフィールドの重みを使用してマージされます。

アルゴリズムは、さらなるランキングで使用される関連ドキュメントの候補セットを生成します。

拡大

Docblob

候補ページが選択された後、ランキングフェーズでは、用語の頻度、フィールドのカバレッジ、および出現箇所の位置と近接性が必要になります。転置インデックスを通じてこのデータを取得するには、多数の用語-ドキュメントペアにわたる散在するアクセスが必要になります。Photonでは、用語の頻度、用語が出現したフィールド、およびドキュメント内のどこに出現したかを含む、docblobと呼ばれるコンパクトなドキュメントごとのレコードを保存します。その結果、候補のランキングに必要なルックアップはドキュメントごとに1回のみになります。

この形式は、必要以上にデコードしないように構築されています。docblob内では、フィールドはテキストアナライザーによってグループ化されます。各グループはElias-Fanoでエンコードされたソート済み用語リストを格納するため、リスト全体を最初に展開することなく、クエリ用語を直接ルックアップできます。フィールドマスクは用語が出現した場所を示し、頻度カウントは頻度を追跡し、実際のポジションはポジションの差分としてエンコードされた用語-フィールドペアごとの個別のブロックに存在します。実際に一致した用語のブロックのみがデコードされ、レコード内の他のすべては圧縮された形式のままになります。

この選択的デコードにより、docblobは、コストの比例的な増加なしにより多くのデータをドキュメントごとに保存できるようになります。ランキングではレコード全体ではなく一致した用語に関連する部分のみに触れるため、レコードを大きくしてもルックアップあたりの作業が増えることはありません。

拡大

バッチ読み取りとメモリの処理

より効率的なデータ表現を用いても、他のリソースよりも先にRAMが枯渇するため、ディスクに保存されているデータに頻繁にアクセスする必要があります。Photonは、非同期ディスク読み取りとバッチ読み取り用に最適化されたキャッシュを使用してこれらのアクセスを高速化し、リクエストごとの待機時間を削減します。これにより、以前のシステムと比較してテールレイテンシが大幅に改善されます。

拡大

ディスク待機のオーバーラップ

ランキングでは、ファイルの異なる場所にある100個のドキュメントの特徴を取得する必要があります。以前のシステムでは、メモリポインタを通じて読み取ることができるように、mmapを使用してファイルを仮想アドレススペースにマッピングしていました。ただし、メモリに存在しないページにアクセスするには、依然としてディスク読み取りが必要でした。スレッドは計算を続行する前にデータを待つ必要があり、プロセスがコールドレコードを連続して読み取る必要がある場合、この待機時間が積み重なりました。

Photonは、レコードのオフセットが事前にわかっているという事実を利用しているため、複数の読み取りを一度に発行できます。これはリアクターによって管理されます。専用のワーカースレッドがio_uringを介してバッチを送信し、読み取ったデータを呼び出し側のコードに渡します。各スレッドは独自のio_uringを維持し、バッチは最も負荷の低いリアクターに送信されます。事前登録されたファイル記述子とバッファプールにより、繰り返し読み取りのオーバーヘッドが削減されます。この非同期実行により、複数の操作の待機をオーバーラップさせることが可能になり、テールレイテンシが削減されます。

ドライブアクセスの回数の削減

読み取りを送信する前に、Photonはインメモリキャッシュ内でバッチ全体を確認します。欠落しているレコードのリクエストのみがディスクに送られ、その後読み取られたデータがキャッシュに入ります。

キャッシュはバッチ読み取り用に設計されています。具体的には：

• ヒット時の別個の割り当てはありません。代わりに、データは呼び出し側のコードによって事前に準備されたバッファにコピーされます。
• リーダーによるロックの取得はありません。代わりに、データのバージョンを確認し、書き込みと競合する場合は再試行します。
• すべての読み取りで共有LRUリストの更新を要求するのではなく、CLOCKエビクションを使用します。
• CPUキャッシュプリフェッチを使用しており、次世代のレコードのメタデータとデータが事前に要求されます。

これらの最適化により、関心のあるワークロードのパフォーマンスを損なうことなくレイテンシが削減されます。

提供とは別個のインデックスの構築と更新

Photonでは、インデックスの構築とクエリの提供は異なるノードで実行されます。インデクサーはデータをすぐに提供できるストレージ構造に変換し、サービングノードはそれらを読み取って取得とランキングを実行します。その結果、インデックスの構築はCPUを求めて検索クエリと競合することがなく、これらのタスクのリソースは独立してスケーリングできます。

この分離により、以前の実装に存在していたリカバリと同期のボトルネックに対処できます。インデックスの構築がクエリを提供するのと同じクラスター内で実行されていたため、障害が発生したノードの復旧やデータの新しいコピーの追加には、ドキュメントのインプレース再インデックス化が必要になる場合があり、このプロセスには数日かかり、リカバリ中の部分的な応答が増加しました。Photonはその結合を排除します。インデクサーは、サービングノードとは独立してバージョン管理されたすぐに提供できるインデックス構造を生成する分散ジョブとして実行されるため、インデックスの次のバージョンの構築はライブトラフィックと競合しなくなります。

拡大

準備と分散構築

ビルドは、アクティブなインデックスのドキュメントを選択し、ソースエクスポートを作成することから始まります。コントローラーは、ソースバージョン、入力テーブル、およびシャードの予想数を記録します。YTsaurusのMapReduceジョブは、テキスト、メタデータ、フラグメント、特徴、および事前計算された埋め込みを、シャードによってパーティション分割されたバージョン管理されたテーブルに準備します。各インデクサーは準備されたテーブルをストリーミングし、シャードの構造を構築し、テキストセグメントをマージします。準備が整ったインデックスは、そのコンポーネントの説明とともにオブジェクトストレージにアップロードされます。

シャードの数と並行して実行されるインデクサーの数は独立して設定されるため、ビルドを複数のウェーブで実行したり、より多くのマシンの割り当てによって並列処理を行うことができます。分散された準備と並列インデクサーにより、Webインデックス全体を1桁の時間で構築できるようになり、前システムに比べて大幅に改善されました。

新しいバージョンのデプロイ

デプロイ前に、コントローラーは新しいインデックスの準備ができていることを確認します。データが不完全な場合、デプロイメントは自動的にブロックされます。

複数の提供グループがある場合、コントローラーはそれらを1つずつ更新します。まずグループをブローカーのルーティングから外し、新しいインデックスバージョンで開始します。リクエストの提供を開始する前に、シャードは検索ログに基づいた個別のウォームアップステージを経由し、初期状態を事前に入力して実際のトラフィックへの移行をスムーズにします。ウォームアップ後、コントローラーはインデックスの状態と準備状況を確認し、グループをルーティングに戻します。この間、他のグループはリクエストの提供を続けます。操作の状態が永続化されているため、再起動によってビルドが最初からやり直されることはありません。コントローラーは、進行中の準備に再アタッチしたり、準備完了の結果を再利用したり、保存されたステップから中断されたローテーションを継続したりできます。

データ更新時間は検索の縦軸によって異なります。鮮度要件の高い縦軸の場合、ドキュメントの配信には1桁の分の時間がかかります。データの追加コピーは約30分でデプロイでき、準備されたインデックスはソースドキュメントを再インデックス化することなく、ロードされてシャードにアタッチされます。

拡大

検索スタック内の移行と検証

私たちの最初の目標は、応答時間を短縮しながら機能と検索品質を維持するエンジンに古いシステムを置き換えることでした。再現可能な負荷テストとオフライン品質評価から始め、ライブトラフィックに移行するまで、段階的にPhotonを検証しました。Photonは現在、本番検索スタックの取得とランキングを動かしており、古いシステムよりも大幅に応答時間が短縮されています。

負荷テストと評価

パフォーマンスのテストのために、設定可能な到着率で検索ログからクエリを再生する負荷テストツールを構築しました。実行間で結果を比較し、観測されたパフォーマンスの差が一貫しているかどうかを評価するために統計的テストを適用します。個別に、品質の回帰がないか確認するため、内部のオフライン評価システムで同じデータセットに対してPhotonと古いシステムを評価しました。

これらのチェックの後、シャドウトラフィックを使用して両方のエンジンに同時にライブクエリを送信しました。これにより、どのエンジンがユーザーにサービスを提供するかを変更する前に、本番ワークロードでのパフォーマンスと結果を比較することができました。その後、ユーザーの少数のサブセットに対してPhotonを有効にしてロールアウトを段階的に拡大し、全体を通じて品質とパフォーマンスを監視しました。最初のバージョンは品質の回帰なしに受け入れテストを通過し、Photonがすべての本番トラフィックにサービスを提供するまでロールアウトを続けました。

本番環境で測定された改善

本番ワークフローにおいて、p99応答時間は古いシステムの約800 msからPhotonの約65 msに低下しました。この測定にはPhoton内のすべてのステージが含まれますが、上位の検索スタック内の後続のステージは除外されます。また、インデックスバージョンの切り替えに関連していた以前のレイテンシスパイクも見られなくなりました。

Photonは、ドキュメントごとに約2.5倍のデータを保存しながら、古いシステムのコンテンツノードよりも約20%少ない同等のサービングマシンを使用します。移行後、この追加データを使用して、古いシステムを超えるランキング品質の向上を実現しました。

Photonは、メモリ内に保持する必要があるデータの量も削減します。mlockを使用して同じPhotonデータセットをRAMにピン留めする場合、Photonが現在使用しているメモリの約4.6倍の常駐メモリが必要になります。

高速Search APIプリセットの評価

また、レイテンシに敏感なワークフロー向けに設計された、Search API向けの新しい高速プリセットの基礎としてもPhotonを使用しました。私たちの測定によると、高速プリセットの単一検索呼び出しのレイテンシはp50で160 ms、p95で230 msであり、報告されたテールパーセンタイルは異なるものの、他のSearch APIプロバイダーの自己報告数値よりも低いか、同等です。

6つのエージェント型ベンチマーク（WideSearch、BrowseComp、DSQA、FRAMES、SEAL-0、SEAL-Hard）で高速プリセットを評価しました。これらの評価において、テストされた構成の中で最も低い推定合計モデル・検索コストと最も高い集計タスクスコアを記録しました。

高速プリセットは、Photonとエージェント型ワークフロー向けに最適化されたランキングを組み合わせることで、実質的に低いコストでデフォルトプリセットと同等のパフォーマンスを実現します。ただし、より幅広い検索品質においてトレードオフが生じます。高速プリセットは、デフォルトプリセットよりもランキングの計算量が少なくなります。テールクエリ、幅広いカバレッジ、結果の多様性をカバーする内部ベンチマークでは、関連性で0.24ポイント低く、回答可用性で約3パーセンテージポイント低くなります。モデル自体の推論と知識がその違いを補うのに役立つため、これはエージェント型ワークフローにとって合理的なトレードオフであると考えています。

拡大

日常的なエージェント型タスクには、高速プリセットをお勧めします。時間に対する敏感さが低く、より困難または曖昧な質問に対しては、デフォルトプリセットの方がより堅牢な品質を提供するため、より高いレイテンシとコストが正当化されます。

結論

検索スタックをRustベースの社内インフラストラクチャに着実に移行しています。オープンソースエンジンをカスタムの取得およびランキングエンジンであるPhotonに置き換えることは、最新のステップです。Photonにより、データ表現、読み取りの編成方法、新しいインデックスのデプロイ方法を完全に制御できるようになり、各レイヤーをワークフローに合わせて最適化できるようになります。

Photonは、Perplexityのプロダクト全体でより高速な検索を可能にし、Search APIにおける新しい高速プリセットの基盤を提供します。移行後、p99の取得およびランキングのレイテンシは、約800 msから65 msに低下しました。また、コンパクトなデータ形式により、ドキュメントごとに2.5倍のデータを保存できるようになり、取得およびランキングがより豊富なドキュメント情報にアクセスできるようになりました。

高速プリセットにより、p50で160 ms、p95で230 msの単一検索呼び出しレイテンシが実現します。評価された6つのエージェント型ベンチマークにおいて、デフォルトプリセットと比較してタスクあたりの推定モデル・検索コストが68%削減されつつ、同等の総合的なタスク品質が維持されました。これらの結果は、PerplexityのプロダクトおよびAPIを使用して構築を行う開発者の両方にとって、検索ワークロードを中心に設計されたインフラストラクチャの実際の利点を示しています。

Photonのパフォーマンスとストレージ効率の向上を続けています。私たちの目標は、ワークロードの増加に伴って検索を高速に保ちながら、同じハードウェアでより大きなインデックスとより豊富なドキュメントデータをサポートすることです。

引用

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://perplexity.coolkeypoint.com/hub/blog/photon}
}