コホートでPerplexityの“1つの問い合わせ”を全スタックにわたって追跡した—実際に3秒で何が起きているのか

セッション開始から約90分が経ったところでした。私たちはちょうど、PythonからRAGパイプラインをゼロから組み上げ終えたばかりでした。FAISSのインデックスや埋め込みをにらみながら、これを本当に本番でデプロイできるのだろうかと不安になるようなタイプです。

講師はコードをスクロールするのをやめて、顔を上げました。

「よし」と彼は言いました。「“検索を作ってるんだ”っていうふりはやめよう。Perplexityを通して、ライブの1クエリを追跡してみよう。あなたがenterを押してから、答えを読むまでの3秒の間に実際に何が起きているのか見てみて。」

部屋が静まり返りました。誰かが質問を入力しました。

First, the Simple RAG Pattern (So We Have a Baseline)

どんなRAGシステムでも作ったことがある人なら分かる、あの流れがあります：

1. Ingest — ドキュメントをチャンク化し、埋め込みを作り、ベクタDBに保存
2. Retrieve — クエリを埋め込み、最も近いチャンクを探す
3. Augment — それらのチャンクをプロンプトに注入する
4. Generate — LLMが回答を生成し、ドキュメントに根拠を置く

これが40行のPython版です。きれいで、予測可能で、ポリシーPDFを少し扱う程度ならうまく動きます。

でもPerplexityは10本のPDF相手に、それをやっているわけではありません。インターネット全体を、リアルタイムで相手にしています。さらに、初心者向けチュートリアルでは見つからないリランキング手順まで入っています。

私たちが実際に見たのはこうです。

The Live Trace: One Query, Five Layers, Three Seconds

使ったクエリはこれです：

“What are the best practices for deploying LLMs in production?”

おもちゃの質問じゃありません。現実のものです。しかも、曖昧さも十分にあって、素朴な検索なら矛盾する助言を含むブログ記事が50本も引っかかってしまうようなタイプです。

Layer 1 — Data Ingestion

最初に起きるのは埋め込みではありません。クロールです。PerplexityのWebクローラは常時稼働していますが、このクエリではさらに、Bingや他のインデックスに対してリアルタイム検索も投げました。数ミリ秒のうちに、10〜20の候補となるWebページが用意されたのです。

画面上でソースがちらっと見えました。Anthropicの論文、UberやDoorDashのエンジニアリングチームによるブログ記事、そして先週のものと思われる意外と役立つHacker Newsのスレッド。

最後のそれが重要です。Perplexityは静的な学習データを使っていません。今週の情報を引いています。

Layer 2 — Embeddings

ここからがややこしくなります。これらの10〜20ページは、それぞれ（300〜500語の）段落にチャンク化されます。各段落が埋め込み化され、クエリも埋め込み化されます。

この部分は多くの人が理解しています。ですが、ここが単純なRAGチュートリアルと分岐するところです：

Layer 3 — Vector Search + Re-ranking

FAISS（あるいは彼らが使っている何らかのベクタインデックス）が、コサイン類似度にもとづいて上位20〜50のチャンクを見つけます。これは安価で高速な最初の通過です。

そして、これは受講者のみんなが驚いた点です。彼らはもう一度、専用のリランキングモデルで再検索を実行します。同じ埋め込みモデルではありません。関連性をより正確にスコアするために、別途訓練されたモデルです。

なぜでしょう？ベクタ検索だけだと、意味的には近いけれど、実務上は役に立たないものが見えてしまうからです。リランキングがそれを直します。

結果として、上位結果が入れ替わっていくのを見ました。Googleのエンジニアリングブログにあるデプロイ戦略に関する段落が、12位から3位へジャンプしました。適当なフォーラム投稿は、完全に圏外へ落ちました。

結果：非常に関連性の高い段落が5〜8。50本ではありません。

Layer 4 — Orchestration

ここはプロンプトエンジニアリングが行われる場所ですが、あなたが自分で打ち込むような種類のものではありません。Perplexityは、次を含むプロンプトを組み立てます：

• 引用の書式に関するシステム指示
• 取得した段落（それぞれソースURLが付与されている）
• あなたの元のクエリ

引用は“おまけ”ではありません。最終回答がソースにリンクできるように、オーケストレーション層全体を通して追跡されます。

Layer 5 — LLM Generation

最後にモデルが生成します。私たちのトレースではGPT-4oでした（ただしPerplexityはクエリのタイプに応じてモデルを切り替えます）。出力はインライン引用付きで返ってきて、主要な実践の要約と、元ソースへのリンクが含まれていました。

経過時間の合計：たぶん4秒。体感は一瞬でした。

What Surprised Us

私たちの前提を崩したのは2つでした。

第一：リランキング手順。

その場にいた全員が、Perplexityは単にベクタ検索＋LLMをやっているだけだと思っていました。専用のリランキングモデルが使われているとは、誰も想像していませんでした。実際に見てみると納得できます。ベクタ検索だけでは、本番レベルの回答に耐えるにはノイズが多すぎるからです。でも、それは「自作RAGを作ろう」系のチュートリアルでは見かけないものです。

第二：引用のトラッキング。

これは単に「モデルが出典を引用する」だけではありません。オーケストレーション層は、LLMが必ず引用を含めるように慎重に組み立てられています。取得したチャンクにはメタデータが付いており、プロンプトがモデルにそれを参照するよう指示しています。欲しいときに入れられる便利機能ではありません。アーキテクチャに埋め込まれた制約です。

受講者の一人が一番うまく言っていました。「ああ、つまりこれはRAGで、データソースがインターネット全体で、そして検索（retrieval）が実際にちゃんと良いんだ。」

The Practical Lesson for Developers in 2026

私が得た学びはこれで、“自分でPerplexityを作りに行け”ではありません。

これらのパイプラインを、単に高レベルで「RAGは検索＋生成だ」と言うのではなく、実際のレイヤー単位で理解することが、いまや必須になっています。仮にベクタDBをデプロイしたりリランキングモデルを訓練したりしないとしても、知っておく必要があります：

• 素朴なRAGプロトタイプが失敗する理由（検索がノイズっぽく、リランキングがないから）
• Perplexityの回答がChatGPTのWeb検索付きよりも良く感じる理由（オーケストレーション層が、あなたが思っている以上に10倍の仕事をしているから）
• 引用トラッキングが、単なるコンプライアンスではなく信頼にとって重要な理由

製品の価値はモデルそのものにはありません。取得（retrieval）、リランキング、プロンプト構築にあります。Perplexityは、あなたがアクセスできるのと同じモデルを使っています。うまく動くのは、LLMが走る前のすべてです。

それが、チャットインターフェースからは見えない部分です。そして、理解する価値がある部分でもあります。

P.S. — 気になっているなら、セッションを終えるときに私たちがまとめた5レイヤーの内訳は以下です：

これが3秒の間に起きていることです。これで分かりましたね。