Perplexity pplx-embed-v2-late、マルチモーダル検索を9Bのインデックス作成と0.6Bのクエリに分離

Perplexityは、注目すべき役割分担を持つ2つのpplx-embed-v2-lateモデルを公開した。9Bモデルがよりリッチなインデックスを構築し、0.6Bモデルが高速なクエリを処理する。両モデルは、テキスト、画像、レンダリング済みの文書ページを同一の埋め込み空間で検索する。

この組み合わせで重要なのは、パラメータ数以上の点にある。検索システムのチームは通常、1つの埋め込みモデルを選び、品質、レイテンシー、インフラコストをすべての処理で受け入れる。これに対しPerplexityは、文書をインデックスに投入する際により多くの計算資源を使い、リクエスト経路では小型のエンコーダーを使う方式を提案している。

これらのモデルは、視覚的に複雑なPDFを検索する標準的なパイプラインにも異議を唱える。OCRでテキストを抽出する代わりに、開発者はレンダリング済みページをエンコードし、テキストクエリで検索できる。ただし、この手法は一部の解析コストを、より大きなインデックスと高コストなスコアリングに置き換える。

Perplexity、1つの検索システムとして機能する2モデルを公開

このリリースの中核は、単なるチェックポイントの組み合わせではない。共有埋め込み空間を中心に設計された、非対称な検索アーキテクチャだ。

Perplexityは、MITライセンスの下でpplx-embed-v2-lateの0.6B版と9B版を公開した。重みは、それぞれのHugging Faceモデルリポジトリで提供されており、0.6B modelと、そのより大きな9B版を含む。

両モデルは、マルチモーダルのレイトインタラクション型リトリーバーである。レイトインタラクションとは、文書とクエリを別々にエンコードしつつ、それぞれのトークンベクトルをスコアリング時に相互作用させる方式を指す。通常、各入力を1つのベクトルに縮約する密ベクトル検索とは異なる。

各モデルは、トークンごとに1つの128次元ベクトルを出力する。MaxSimスコアリングでは、各クエリトークンについて最も強い文書トークンとの一致を見つけ、それらの最大類似度を合計する。そのため、異なるクエリ語がページ内の異なる領域に一致し得る。

Perplexityは、このモデル群を双方向アテンションを備えたQwen3.5バックボーン上に構築した。モデルカードによれば、公開された両モデルは内部の18B ColBERT教師モデルから蒸留された。ColBERTは、後段で比較するためにトークンレベルの表現を保持する検索アーキテクチャである。

同社は小型モデルを完全にファインチューニングした。9B版では、最終8層のTransformerレイヤーを完全にチューニングし、それ以外のレイヤーとビジョンエンコーダーをLoRAで適応させた。

公表されているサイズには補足が必要だ。小型チェックポイントは総計約5億9400万パラメータを含むが、Perplexityはアクティブなパラメータ数を3億4000万と報告している。テキストエンコードでは約2億4000万パラメータが有効化され、画像エンコードでは約3億4000万が有効化される。

Perplexityによれば、小型のテキストタワーは24層のQwen3.5-0.8Bタワーを12層へプルーニングして作られた。トークン埋め込みテーブルも、さらに2億5400万パラメータを占めるという。

この構成は、クエリ時の経済性を狙っている。インデックス作成はオフラインで、並列ハードウェア全体に分散して実行でき、文書が変わったときだけ実行すればよい。クエリエンコードはライブのリクエスト経路にあり、数ミリ秒の追加でもユーザー体験に影響する。

共有空間が、この2つのワークロードを結び付ける。企業は9Bモデルで文書をエンコードし、0.6Bモデルでエンコードしたクエリで得られたインデックスを検索できる。クエリエンコーダーを置き換えても、インデックスを再構築する必要はない。

Perplexityは、ローカルとクラウドを組み合わせた構成も説明している。デバイスは小型モデルでプライベートなクエリやローカル文書をエンコードし、その表現をクラウド上の9Bインデックスから得られる結果と比較できる。

この柔軟性は、現時点ではマネージド製品の約束ではなく、技術的な提案にとどまる。モデルカードでは、チェックポイントが最近のSentence TransformersおよびTransformersリリースで動作するとしている。また、現在は小型チェックポイントを提供する推論プロバイダーがないとも記している。

Perplexityは、レイトインタラクション、密ベクトル、コンテキスト埋め込みを段階的にAPIプラットフォームへ提供するとしている。それまでは、pplx-embed-v2-lateを評価するチームは、モデルと検索インフラを自ら運用する必要があると考えるべきだ。

Perplexity pplx-embed-v2-lateの仕組みはページの詳細を保持する

Perplexityは、トークンレベルの照合によって、単一の文書ベクトルでは圧縮されて失われがちな証拠を保持できると見込んでいる。

密ベクトル埋め込みモデルは、クエリと文書をそれぞれ1つのベクトルで表現する。検索は効率的な近傍探索となり、非常に大規模なコレクションでもうまく機能する。しかし、そのベクトルは関連し得るすべての詳細を要約しなければならない。

この圧縮は、文書が長くなったり、無関係なセクションを含んだりすると難しくなる。ページにグラフ、表、図、キャプション、レイアウトに依存する意味が含まれる場合には、さらに難しくなる。単一の表現には、そうしたすべてのシグナルを収める余地が限られている。

チャンク化は、各ベクトルに入れる情報量を減らす。しかし、表とそのラベル、グラフと凡例、条項と重要な限定事項を分断する可能性がある。解析ルールも文書形式ごとに異なる。

クロスエンコーダーは、クエリと候補をまとめて処理することで、この問題の一部に対応する。この共同アテンションは詳細な比較を可能にするが、モデルはクエリと候補の組み合わせごとに再実行する必要がある。通常は、少数の候補リストを再ランキングする場合にしか実用的ではない。

レイトインタラクションはその中間に位置する。文書はクエリが到着する前に表現を取得する一方、検索システムは候補ごとに1つの内積を計算する代わりに、複数のトークンレベル比較を実行する。

Perplexityのtechnical explanationは、MaxSimを用いてこの手法を示している。各クエリトークンは最適な文書トークンとの一致を選択し、システムはその類似度を文書スコアに加算する。

法律、期限、例外についてのクエリを考えてみよう。単一のクエリベクトルでは、これらの概念が混ざり合う。MaxSimなら、各概念を同じページ内の別々の文章、ラベル、視覚領域に対応付けられる。

同じ仕組みは画像にも適用される。レンダリング済みPDFページは、まずOCRを通すのではなく、画像としてビジョンエンコーダーに入力される。テキストクエリは、その視覚表現を直接検索できる。

これは、モデルが準備なしにPDFファイルを「読める」ことを意味しない。アプリケーションは、関連する各ページを画像としてレンダリングし、その画像をエンコードする必要がある。違いは、検索可能な表現をどのように生成するかにある。

OCRを省略することで、テキスト抽出で失われるレイアウトや視覚的関係を保持できる可能性がある。財務表では、行と列の位置が本質的な意味を持つ場合がある。図は、キャプションが部分的にしか説明しない関係を伝えることがある。

OCRを使わない検索は、スキャン、特殊なフォント、複雑なページ構造における認識エラーも回避できる。ただし、ハイライト、引用、アクセス制御、下流の言語モデルのコンテキストに必要な抽出テキストを自動的に提供するわけではない。

そのため多くのアプリケーションでは、視覚検索と並行して解析処理を維持するだろう。視覚埋め込みで有望なページを特定し、その後にOCRまたはネイティブPDFテキストから正確な文章を取得できる。両技術は補完し合える。

Perplexityは、594のデータセットと46言語から収集した1億8600万のクエリ・文書ペアで2モデルを学習させた。報告によれば、そのうち88.3%がテキスト対テキスト、8.3%がテキスト対画像、3.4%がテキスト対視覚文書のペアだった。

サンプリングの混合により、視覚データの相対的な比率は引き上げられた。Perplexityによると、最終的なサンプリング重みでは、テキスト対テキストが56.5%、テキスト対画像が30.9%、テキスト対視覚文書が12.6%となった。

「マルチモーダル」が複数の異なる問題を含むため、これらの詳細は重要だ。写真を検索することと、密度の高い年次報告書のページ内で証拠を見つけることは同一ではない。学習時のバランスは、どのユースケースで最も強い表現が得られるかに影響する。

公開されたモデルカードは、実装上の制約も明記している。テキストのみの項目と画像のみの項目は別々にエンコードする必要があり、テキストと画像を混在させた入力は1項目内ではサポートされない。アプリケーション側は、それに応じて取り込み処理を設計する必要がある。

共有埋め込みが単一モデルの検索パイプラインに圧力をかける

競争圧力がかかるのは、オフラインのインデックス作成とレイテンシーに敏感なクエリの両方に、同じエンコーダーサイズを使う検索システムだ。

大半の埋め込み導入では、モデルを均一なコンポーネントとして扱う。同じチェックポイントでコーパスとすべての受信クエリを埋め込む。この対称性は運用を簡素化するが、両処理の異なる経済性を無視している。

文書エンコードは通常、償却可能な支出だ。企業はページを一度処理し、その保存済み表現に対して何千回もの検索に応答できる。インデックス作成はより大型のハードウェアでスケジュールしたり、バッチ処理したりできる。

クエリエンコードは検索のたびに繰り返される。応答時間、同時実行性、デバイス上での実現可能性に影響する。リクエストごとに大型のビジョン言語エンコーダーを実行すれば、オフラインのインデックス作成で得た利点を失いかねない。

Perplexityの共有空間は、これらの選択を切り分ける。9Bモデルは文書情報の取得に追加の計算資源を使える一方、0.6Bモデルは互換性のあるクエリを生成する。インデックスは、より大きな文書エンコーダーの利点を一部保持する。

Perplexityによる72のドメイン特化検索タスクでの評価では、この非対称構成は、両側で0.6Bを使用する場合と比べて平均1.6ポイント向上した。クエリエンコーダーは変わっていない。

ViDoRe v3の画像検索では、0.6Bクエリと9B文書の構成は63.5%のnDCG@10を記録した。対称的な0.6B構成は62.3%で、差は1.2ポイントだった。

クエリと文書の両方に9Bモデルを使う構成は、依然として報告されたドメイン平均で最高の81.3%を記録した。Perplexityによれば、非対称構成はクエリ時のエンコードを大型化せずに、テキスト品質の差のおよそ半分を回復した。

これが、このリリースにおける最も実用的な主張だ。小型モデルは、単独で9Bのあらゆる結果に匹敵する必要はない。より厳しい提供制約の下でも、高品質な9Bインデックスを有用にできればよい。

このアプローチは標準的な密ベクトルモデルに圧力をかける一方で、他のマルチベクトル型リトリーバーとも競合する。Perplexityは自社モデルを、Qwen3-VL-Embedding、EVIE、TopK Embed、NvidiaのNemotron ColEmbedファミリーと比較している。

ViDoRe v3の公開画像部分では、Perplexityは9Bモデルで65.2%のnDCG@10、0.6Bモデルで62.3%と報告している。対応するMarkdownのスコアは64.7%と61.2%だった。

Perplexityによれば、0.6Bモデルは画像検索でNemotron ColEmbed V2 8Bとの差を1.2ポイント以内に抑えた。また、出力がトークン当たり128次元である点も強調している。

この次元数の比較は、インデックスの実現可能性に直接関わる。Perplexityは、EVIE-4.5Bの出力次元を2,048、より大きなEVIEおよびNemotronモデルを4,096と記載している。次元数が少なければ、保存する各トークンベクトルを小さくできる。

ただし、次元数だけで本番コストは決まらない。保持するトークン数、数値精度、圧縮方式、インデックス構造、候補生成戦略も重要となる。Perplexityは、代表的なコーパスに対する完全なストレージ計算を公開していない。

代替手法が消えるわけではない。密ベクトル検索は、非常に大規模なスケールでもインデックス作成と検索が容易であり続ける。クロスエンコーダーは再ランキングで依然として魅力的だ。ハイブリッドな語彙検索は、正確な識別子、名称、希少な技術用語を引き続き保護する。

したがって、Pplx-embed-v2-lateは万能な置き換えではなく、検索スタックの一段階として採用される可能性が高い。Perplexity自身も、late interactionを、より高度な第1段階の検索、あるいはウェブ規模システムにおける後段の処理として位置づけている。

検索可能なナレッジベースを構築するチームにとって、設計上の問いはより具体的になる。どの文書に視覚的なマルチベクトル索引を用いる価値があり、どの文書はテキスト検索で効率を維持できるのかを判断しなければならない。

ベンチマーク結果は強力だが、依然として企業報告にとどまる

公表されたスコアは本格的な検証を正当化する一方、実運用におけるレイテンシ、ストレージ、検索品質を決着させるものではない。

Perplexityは、BrowseComp+において9Bモデルが64.0%の回答精度を記録したと報告している。この結果は、次点のColBERTモデルを4.9ポイント、次点のdenseモデルを8.7ポイント上回った。

BrowseComp+はライブのウェブ検索ではなく、固定コーパスを使用する。そのベンチマーク設計には、830件の難問クエリと、人手で検証された裏付け証拠を持つ約10万件のキュレーション済みウェブ文書が含まれる。

固定コレクションは再現性を高める。研究者は、商用検索エンジンやオープンウェブの変化から検索品質を切り分けられる。その一方で、継続的に変化するライブのウェブ索引を運用する場合よりも、ベンチマークの対象は狭くなる。

Perplexityは、このリトリーバーを高い推論強度のGPT-OSS-120Bと組み合わせた。別の言語モデルが、生成された回答が参照回答と一致するかを判定した。したがって、報告された64.0%は単独の埋め込みスコアではなく、エージェントとリトリーバーから成るシステムの指標である。

同社によると、0.6Bモデルもpplx-embed-v2-lateファミリー以外のすべてのモデルを上回った。ただし、発表では基礎となる各スコアがすべて検索可能なテキストとして提供されているわけではない。完全な技術報告書は後日公開される予定だ。

MADQAでは、Perplexityは9Bリトリーバーの回答精度を92.4%、0.6Bモデルを90.1%と報告している。いずれもGemini 3.5 Flashと組み合わせて評価された。

MADQAは、異種PDFをまたぐエージェント型検索を評価する。元となるMADQA論文では、800文書に根拠を置く2,250件の人手作成質問が説明されている一方、報告された評価では500問のサブセットが使われている。

Perplexityによると、そのサブセットは18,000ページ超にまたがる。質問は一般知識だけでは答えられないため、エージェントは文書コレクションから証拠を検索しなければならない。

9Bモデルの結果は、同じエージェントを用いた標準的なMixedbreadリトリーバーを3.5ポイント上回った。Mixedbread Agentic Searchは93.4%に達し、Perplexityによればこれはその信頼区間内に収まった。

この違いは重要である。Mixedbread Agentic Searchには、外側の呼び出しごとに複数回の検索を計画・実行できる検索サブエージェントが含まれる。Pplx-embed-v2-lateは、完全なエージェント型検索サービスではなく、エージェント内部のリトリーバーとして機能する。

MADQAの著者らも、文書エージェントにおけるより広い限界を指摘している。その研究では、強力なシステムは人間に近い精度に達し得る一方で、異なる質問で成功することが示された。エージェントは、検索を繰り返すことで弱い戦略を補うことが多い。

より優れたリトリーバーはこうした無駄を減らせるが、良い検索計画や証拠の統合を保証することはできない。検索精度、回答精度、ページ単位の証拠品質、レイテンシ、ツール呼び出し回数は、すべて別個に評価すべきだ。

Perplexityは、ViDoRe v3でも強力な結果を報告している。この公開ベンチマークは、回答生成テストよりもページ検索を直接的に把握できる。しかし、ベンチマーク用コレクションでは、あらゆる企業文書形式を再現できない。

実際のコーパスには、重複、アクセス制限、改訂版、手書き注釈、低解像度スキャン、ほぼ同一のレイアウトを持つページが含まれる。また、一般的な学習データの混合には存在しない可能性がある、分野固有の略語も含まれる。

内部ベンチマークであるPPLX-Q2Iは、別の検証上の隔たりをもたらす。Perplexityは本番の画像検索ログからこれを構築し、10万枚の画像に対して1万件のクエリを評価した。外部の研究者は、現時点でこの非公開テストを再現できない。

Perplexityによると、両モデルはPPLX-Q2IでQwen3-VL-Embedding-8Bを9ポイント超上回った。また、9BモデルはGemini Embedding 2を約2ポイント下回ったとしている。これらの知見は、企業による報告として扱い続けるべきだ。

このリリースが注目に値するのは、重みと公開ベンチマークのチェックポイントにより、独立した検証が可能になるからだ。あらゆるコーパスにとって最良の選択肢だと自動的に受け入れるべきではない。

開発者は、自社の文書と実際のクエリから評価セットを構築すべきだ。正確な検索、ページをまたぐ証拠、視覚的な表、珍しい専門用語、意図的に難しくしたネガティブ例を含める必要がある。

また、同等のエンドツーエンドシステムを比較すべきだ。一方の構成だけが、より優れたOCR、より多くの検索ラウンド、より強力なリランカーを利用してはならない。ただし、それらの差異が意図した本番設計を表す場合はこの限りではない。

マルチベクトル検索はコストをなくすのではなく、移し替える

Pplx-embed-v2-lateは、より大きな表現とより複雑な候補スコアリングを受け入れることで、ある圧縮上のボトルネックを回避している。

dense検索では、文書またはチャンクごとに1つのベクトルを保存する。Late interactionでは複数のベクトルを保持し、多くの場合、枝刈りされていないトークンごとに1つのベクトルを保持する。そのため、長いページでは検索可能な表現が多数生成される可能性がある。

128次元であっても、こうしたベクトルは積み重なる。索引ストレージは、トークン数、数値フォーマット、圧縮方式、メタデータ、検索エンジンに依存する。ページレベルの視覚表現は、この計算をさらに変え得る。

MaxSimも、単一のクエリ・文書内積より多くの処理を必要とする。各クエリトークンは、文書トークンの中から最も強い一致を見つけなければならない。効率的な提供には、特化した索引、枝刈り、または段階的な検索が必要となる。

Perplexityは発表の中で、このトレードオフを認めている。Late interactionには、単一ベクトルの近似最近傍検索とは異なる索引化と提供の選択が必要であり、長い文書ほどコストが増すとしている。

共有モデル空間はクエリのエンコードに役立つが、候補スコアリングのコストを消し去るものではない。軽量なクエリエンコーダーであっても、数百万のトークンベクトルとの照合に高いコストがかかるリクエストを生成し得る。

したがってチームは、クエリのエンコード、候補生成、MaxSimスコアリング、後段のリランキングまたは生成という4つのレイテンシ要素を個別に測定すべきだ。モデル推論時間だけを報告しても、ユーザー体験の大部分は見えない。

メモリ使用量にも慎重な測定が必要だ。9Bチェックポイントはオフライン要素になり得るが、頻繁に変化するコーパスの索引化には、継続的なGPU容量が必要になる可能性がある。文書改訂版の再エンコードも運用作業を増やす。

視覚文書パイプラインでは、モデル推論の前にページをレンダリングする必要がある。大規模PDFには、ページ分割、画像正規化、失敗処理、メタデータのマッピング、削除ワークフローが必要になる。OCRが検索から姿を消しても、取り込みは依然としてシステム上の問題である。

OCRにも利点は残る。抽出テキストは、キーワード検索、ハイライト、引用、コンプライアンスレビュー、言語モデルへの直接的なコンテキスト提供を支える。レンダリング済みページの埋め込みだけでは、これらの機能を再現できない。

有力な本番設計はハイブリッド型だろう。システムは正確な検索のためにネイティブテキストを索引化し、レイアウトに敏感なページには視覚埋め込みを保持し、限定された候補セットにリランカーを使える。

アクセス制御にも同等の注意が必要だ。検索索引は、結果がエージェントに届く前に、権限のない資料を除外しなければならない。共有されたローカル・クラウドの埋め込み空間が、文書の権限管理やプライバシー保証を自動的に提供するわけではない。

提案されているオンデバイスのクエリ経路には、さらに疑問がある。Perplexityは0.6Bモデルをエッジデバイス向けに適しているとしているが、デバイスの種類は大きく異なる。メモリ制限、アクセラレーション対応、量子化、バッテリー使用量が、実際の実現可能性を左右する。

公開されたチェックポイントは、Hugging FaceページでF32テンソルを使用している。開発者は低精度版やプラットフォーム固有のバリアントを試す可能性が高いが、こうした変換には品質検証が必要だ。量子化は検索ランキングを変化させる可能性がある。

互換性も初期段階の懸念事項だ。モデルカードはSentence Transformers 6.0以降およびTransformers 5.4以降を要求している。また、PyLateはクエリと文書のマーカーを異なる位置に挿入すると警告している。

エクスポートにはネイティブのSentence Transformersモジュールが使用され、カスタムPythonコードは必要ない。これにより統合の摩擦は減るが、完全な本番用索引やマネージドエンドポイントを提供するわけではない。

ライセンスは比較的明快だ。MITライセンスは幅広い利用と改変を認めている。それでも導入者は、モデルの依存関係、学習データに関する考慮事項、自身による機密文書の取り扱いを確認する必要がある。

「オープンソース」という言葉も、重要な違いを覆い隠し得る。Perplexityはオープンな重みと実装手順を公開したが、完全な学習コーパスや内部の18B教師モデルは公開していない。

同社は、評価対象ベンチマークに関連するデータセットを学習から除外したとしている。これは有用な方法論上の主張だが、独立研究者がデータ汚染の管理と評価詳細を検討するには、約束された技術報告書が必要である。

慎重な結論は、late interactionのコストが高すぎるということではない。コストの所在が移るということだ。チームは、OCRへの依存や単一ベクトル圧縮と引き換えに、より豊かな索引、トークンレベルのスコアリング、より特化したインフラを受け入れる。

設計がベンチマークを超えて通用するかを示す3つのシグナル

次の試験は、独立した導入事例が、許容できないストレージ、レイテンシ、運用上の複雑さを伴わずに品質向上を再現できるかどうかだ。

第1のシグナルは、公開された重みの独立評価である。研究者や検索ベンダーは現在、両モデルを公開の視覚文書タスクおよび非公開の業界コーパスで比較できる。

再現検証では、対称的な0.6Bおよび9Bのテストだけでなく、非対称構成も対象にすべきだ。このリリースの中心的な主張は、小型モデルのクエリが大型モデルの索引に対しても価値を維持することに依存している。

独立した結果が、法律、金融、技術、スキャン文書にわたって報告された改善を維持するなら、Perplexityの設計は信頼できる導入パターンとなる。大幅な品質低下があれば、共有空間の主張は弱まる。

第2のシグナルは、索引の測定値を含む完全な技術報告書である。Perplexityは、その報告書を今年後半に公開するとしている。そこでは、検索設定、圧縮、ハードウェア、レイテンシ、文書トークン当たりのストレージを開示すべきだ。

報告書では、信頼区間、学習データのフィルタリング、ベンチマーク構成も説明すべきである。これらの詳細により、報告された精度向上が同等のリソース制約下でも維持されるかが分かる。

出力次元は変数の一つにすぎないため、ストレージは特に重要である。128次元のトークンベクトルは4,096次元の代替案と比べてコンパクトに聞こえるが、索引全体のサイズは保持されるトークン数に依存する。

第3のシグナルは製品サポートだ。Perplexityは、late-interaction、dense、contextual embeddingsをAPIプラットフォームに段階的に追加するとしている。マネージドエンドポイントがあれば、同社が索引化と提供のトレードオフをどのようにパッケージ化するかが明らかになる。

APIサポートは、カスタムGPUインフラを運用できるチーム以外にもテストの裾野を広げる。ユーザーがレンダリング、索引化、MaxSim検索、スケーリングをすべて自前で組み立てなければならない場合、導入はより限定的なままとなる。

この展開では、顧客が1つのマネージドサービスを通じて9Bの文書索引と0.6Bのクエリを組み合わせられるかも明確にすべきだ。この構成は、このリリースにおける最も強力な運用上のアイデアである。

価格はまだ有用な比較材料ではなく、Perplexityの従来の埋め込みサービスから数値を推測すべきではない。マルチベクトルのストレージとスコアリングは、単一ベクトルのテキスト埋め込みとは大きく異なる。

競合各社の動きも重要だが、それらは主たる検証対象というより補強材料だ。Qwen、Nvidia、Google、Mixedbreadなどの検索プロバイダーは、品質の向上、次元数の削減、より扱いやすいマネージドシステムの提供を実現できる。

Perplexityの優位性は、単一のリーダーボードの結果だけで決まるものではない。共有空間によって、より大規模なインデクサーの検索品質を十分に維持しながら、実運用のクエリコストを下げられるかにかかっている。

開発者が直ちに取るべき行動は、範囲を限定した評価だ。代表性のあるコーパスを構築し、視覚的に複雑なページをレンダリングし、テキストのベースラインを保持する。そのうえで、同じ検索予算の下で対称構成と非対称構成を比較する。

回答精度、根拠ページの再現率、インデックスサイズ、取り込みスループット、クエリレイテンシ、失敗ケースを測定する。視覚検索によってテキスト解析が必要な理由がすべてなくなるわけではないため、OCRとハイブリッドパイプラインも含めるべきだ。

Perplexity pplx-embed-v2-lateは明確な仮説を提示している。文書エンコーディングとクエリエンコーディングで、同じ計算予算を共有すべきではないというものだ。オープンな重み付けにより、この仮説は検証可能になっている。

残る問いは、概念上のものではなく運用上のものだ。ストレージ、スコアリング、更新、権限、下流での根拠抽出をすべて考慮した場合、9Bのインデックスと0.6Bのクエリ経路は、より単純な検索手法を上回れるのだろうか。