2026 年 9 月 24 日，Perplexity 發表了一項可能被 GEO 業界低估的基礎架構公告——Photon，一個由 Rust 編寫的全新檢索與排名引擎。對於大部分品牌營銷人員來說，基礎架構升級看起來與日常 SEO 工作無關。但 Photon 的設計變更直接改變了你的內容在 Perplexity 中被檢索、排名、引用的方式。
本文拆解 Photon 的核心技術變更，以及這對 GEO 策略的三個實際影響。
Photon 解決了什麼問題？
Perplexity 原本使用一個修改自開源引擎的檢索系統。隨著索引規模突破 2,000 億 URL，這個系統遇到了三個瓶頸：
1. 擴展成本失控。 每份文件需要儲存的數據量持續增長，RAM 容量成為硬約束。當索引超過物理記憶體容納範圍，系統必須頻繁讀取磁碟，導致性能急劇下降。
2. 尾延遲（tail latency）惡化。 p99 回應時間約為 800ms。在索引合併（fusion）期間，p99 甚至攀升至 1.2 秒並持續 10-15 分鐘。對於一次 AI 搜尋查詢而言，800ms 的尾延遲意味著每 100 次查詢中就有 1 次需要近一秒才能返回結果——這在對話式 AI 場景中是不可接受的。
3. 索引重建與查詢服務互相干擾。 「索引構建」和「查詢服務」運行在同一個集群中。當一個節點故障或需要新增副本時，必須在原地重新索引文件——這個過程耗時數天，期間還會增加部分回應的次數。
Photon 的三項關鍵設計
Perplexity 的工程團隊（輔以數百個 AI coding agents）從零開始建構了 Photon，核心設計決策有三：
1. 緊湊數據格式（docblob）
Photon 為每份文件儲存一個稱爲「docblob」的緊湊記錄，包含詞頻、詞項出現的欄位及位置資訊。排名只需要一次查詢就能取得所有需要的信息。這使得每份文件的排名數據量增加了 2.5 倍，但物理讀取量反而減少——因為數據格式經過針對性壓縮，避免了傳統倒排索引中的大量冗餘 I/O。
2. 異步批次磁碟讀取
即使採用緊湊格式，RAM 仍然不夠容納全部索引。Photon 使用異步磁碟讀取和專為批次讀取優化的快取機制，將磁碟訪問的等待時間重疊處理。這直接解決了原有系統中冷啟動頁面錯誤（page fault）導致的延遲尖峰問題。
3. 索引構建與查詢服務完全分離
索引構建（indexer）和查詢服務（serving node）運行在不同的節點上。索引構建成為分佈式批次任務——在單一位數小時內即可完整重建整個網路索引。新版索引準備完成後，逐個服務組進行熱切換，先預熱快取再路由正式流量。這消除了原本持續數天的索引切換中斷期。
性能數據
| 指標 | 舊系統 | Photon | 改善幅度 |
|---|---|---|---|
| p99 檢索延遲 | ~800 ms | ~65 ms | 12 倍 |
| 索引切換期間 p99 延遲 | ~1.2 s（10-15 分鐘） | 無 spike | 完全消除 |
| 每文件儲存數據量 | 基準 | 2.5 倍 | +150% |
| 服務器需求 | 基準 | ~20% 更少 | 硬體成本降低 |
| Fast Search API p50 | — | 160 ms | — |
| Fast Search API p95 | — | 230 ms | — |
| Agent 任務成本（6 項基準） | 基準 | -68% | 接近七成成本削減 |
對 GEO 策略的三個影響
1. 更快的檢索 = 更多的引用機會
聽起來很直接，但影響比表面看來更深遠。Perplexity 之前的 p99 800ms 延遲意味著每 100 次查詢中就有 1 次需要等待近 1 秒——在 AI 回答生成的時間預算中，這可能導致引擎跳過某些來源，轉而使用更容易取得的內容。Photon 將 p99 降至 65ms 後，尾延遲不再是一個限制因素。你的內容被完整檢索並納入候選集的可能性更高了。
對於你的內容策略，這意味著：Perplexity 現在比以往任何時候都更「願意」深入檢索你的頁面。 如果你過去因為頁面載入速度或內容結構而在 Perplexity 的檢索階段被淘汰，現在有了更公平的機會。
2. 每文件 2.5 倍數據量 = 排名信號更多元
Photon 的 docblob 格式讓排名器能夠存取更豐富的文件信息。這不僅僅是「更多數據」——它是不同的排名訊號權重分配。傳統檢索系統中，排名主要依賴錨文本、域名權威和連結結構。Photon 儲存詞頻、欄位位置和細顆粒度的詞項分佈——這意味著內容本身的語義結構在排名中的權重可能提高了。
實務建議：確保你的頁面有清晰的標題層級（H1 → H2 → H3）、關鍵概念在文中自然出現而非僅在列表中存在、以及每個段落的摘要有獨立可讀性。
3. Fast Search API 降低開發者門檻
Photon 催生了 Perplexity 的 Fast Search API——p50 160ms、p95 230ms 的搜尋 API，價格為每 1,000 次請求 $1 美元。在 6 項 agent 基準測試中，Fast Search 將任務成本降低了 68%，同時保持與默認 preset 相當的聚合質量。
這對 GEO 的間接影響是：更多開發者、更多 AI agent 會使用 Perplexity 作為後端搜尋引擎。當一個 AI agent 為用戶回答「香港最好的商業登記服務」時，它的檢索來源可能來自 Photon 驅動的 Perplexity——你的內容需要在這個新管線中被檢索到。
質量權衡：速度的代價
需要誠實指出的是，Photon 並非完美。Perplexity 自己的數據顯示，Fast Search preset 在相關性（DCG 指標）上下降了 0.24 分（從 2.45 到 2.21），答案可用性下降了約 3 個百分點（從 59.6% 到 56.7%）。速度提升伴隨著召回率的輕微下降。 如果你的內容屬於長尾、深度技術或高度特定領域，使用 Photon 的 Fast Search 可能不如使用完整 preset 被精準引用。
Perplexity 自己也建議：對於日常 agent 任務使用 Fast Search，對於更具挑戰性或模糊的查詢則使用默認 preset。
總結：Photon 的到來告訴我們什麼？
Perplexity Photon 是 AI 搜尋基礎架構的一次重要躍進。它沒有改變 GEO 的基本原則——寫好內容、建立權威、保持結構清晰——但它改變了內容被檢索到的機率分布。尾延遲障礙的消除使更多內容進入了檢索候選集，而豐富的文件格式使內容本身的品質在排名中更加重要。
對於香港企業，如果你希望品牌出現在 Perplexity 對「Hong Kong business setup」「香港 SEO 公司推薦」等查詢的回答中，現在是檢查 Perplexity 能否正確檢索你的頁面的最佳時機。
參考來源：Perplexity Blog “Photon: Building a Retrieval and Ranking Engine From Scratch”（Sep 24, 2026）、explainx.ai 分析、AlphaSignal 數據重建。