架構與評估 AI 優先的 Search API

建構具規模且具備 AI 前瞻性的「搜尋 API」，在資訊檢索、AI 與系統設計的交會點上帶來了獨特的研發挑戰。不同於針對特定資料運作的傳統服務，搜尋 API 必須持續為數十億份文件建立索引、跨語言與領域理解查詢意圖，並在幾毫秒內呈現相關結果。在 AI 代理的世界中，搜尋 API 還必須仔細策劃提供給開發者模型的上下文，以確保這些模型能發揮最佳效能，並納入最具準確性的資訊。有效的上下文工程要求 API 不僅要擷取文件層級的相關性，還要將文件的各個區段與文字片段視為獨立的一級單位。

在本文中，我們將介紹 Perplexity 搜尋 API 的設計與評估。我們首先探討支援每日處理 2.0 億次查詢之生產環境搜尋基礎架構背後的架構與關鍵技術決策。我們的架構結合了混合式檢索機制、多階段排序管線、分散式索引，以及透過自我改進內容理解模組進行的動態剖析。

接著，我們將說明透過全新開源評估框架來以實驗評估搜尋 API 效能的方法。透過與現有商業 API 進行全面效能評測，我們展現了在品質和延遲方面皆領先業界的效能。Perplexity 搜尋 API 即日起向全球開發者推出。

[在 GitHub 上尋找 search_evals]

建構針對 AI 模型進行優化的搜尋系統

自創立以來，我們便深知強大的搜尋能力，對於實現我們想要推出的具備產業定義性 AI 產品至關重要。最初，我們希望這些功能已經以公開可用的形式存在。我們在 2022 年底嘗試了各種現有的搜尋 API，而 Perplexity 答案引擎的最初版本實際上就納入了其中一些產品。具體來說，我們會分析使用者查詢，向這些 API 提出並發送請求，然後收集結果作為我們下游生成管線的上下文。

然而，隨著使用者蜂擁至 Perplexity，我們很快意識到這些 API 將無法隨著我們的業務成長而擴展。我們遇到的價格極其高昂，其中一家領先的 API 提供者收費高達每千次查詢 200 美元. 但更致命的是，這些傳統 API 根本不是為了前沿 AI 系統所引入的新檢索典範而設計的。

放大

首先，這些傳統 API 的請求與回應格式是為人類作為搜尋結果唯一消費者的世界所設計的。因此，這些 API 優先考慮文件層級的結果，而忽略了子文件單位所揭露的更精細資訊。AI 模型的成功取決於所提供上下文的品質與精簡度，我們親眼目睹了過度廣泛的檢索如何使 AI 模型偏離正軌，無論作為整體檢索到的文件看起來多麼相關。我們將精確性強加於不精確結果的嘗試，收效甚微。

我們也觀察到，傳統 API 要麼過於陳舊，要麼速度太慢。獨立開發的搜尋 API 依賴不完整且更新頻率過低的索引。基於網路爬蟲的 API（例如針對 Google 搜尋的各種非官方 SERP API）受益於更全面的索引，但由於查詢第三方搜尋引擎固有的低效率，導致延遲高到無法接受。高延遲使得 API 不適合面向使用者的應用程式，而資料過時則讓任何期望準確且可靠的 AI 系統無法使用這些結果集。

最後，我們觀察到 AI 生態系統在語意搜尋與詞彙搜尋之間分化，出現了對單一模態過度優化的系統。我們看到了向量資料庫的興起，它們甚至無法充分支援簡單的布林過濾器。傳統搜尋後端的情況也沒好多少，對 AI 解鎖的語意排序與檢索機會僅有原始的支援。

當我們意識到要讓 Perplexity 變得更好，就需要建構我們專屬的搜尋基礎架構時，我們將觀察結果歸納為三個關鍵準則：

完整性、即時性與速度：搜尋索引必須全面、不斷更新，並針對即時延遲進行工程設計。

細粒度內容理解：AI 模型的脆弱性與有限的上下文視窗，要求搜尋結果必須以盡可能最細緻的層級來呈現與排序。

混合式檢索與排序：檢索與排序管線都必須納入詞彙與語意訊號，才能讓結果對 AI 有用。

放大

網路爬蟲與索引基礎架構

以 Perplexity 的規模營運需要能夠全面對應網路並回應其持續演進的基礎架構。我們的搜尋索引追蹤超過 200 億個唯一的 URL，並具備追蹤更多數千億個 URL 的容量。

確保我們的索引涵蓋足夠全面的網際網路範圍，且每份文件都反映最新狀態，是一項艱巨的任務。完整性與即時性之間存在著內在的張力：在固定的索引預算下，現有頁面的重新整理作業必須與新造訪頁面的索引作業競爭。我們透過規模化（透過增加索引預算來放寬優化限制）與機器學習驅動的優先排序（確保每次索引作業對整個索引都具有最高價值）相結合來平衡這種張力。

我們建構了一個艾位元組（exabyte）規模的索引與爬蟲裝置，可隨規模和查詢量進行水平擴展。Perplexity 的爬蟲與索引叢集共同包含了數萬個 CPU 和數百太位元組（TB）的 RAM，並具有充足的餘裕可進一步擴展。我們將此運算基礎架構與冷熱儲存的平衡相結合。我們使用學習模型和調整過的啟發式方法來決定哪些文件應保持常駐，優先處理來自權威網域的文件、涉及未充分涵蓋主題的文件，以及其他具有超乎尋常潛力可豐富我們索引的類別。

這項基礎架構使 Perplexity 能夠每秒處理數萬次索引作業。但即使有這筆相對充裕的預算，網際網路的規模仍然太過龐大，無法頻繁且定期地為每一個單獨的 URL 建立索引。這就是機器學習派上用場的地方。我們訓練一個機器學習模型來預測任何給定的候選 URL 是否需要建立索引。訓練目標旨在確保我們的索引決策能夠針對特定 URL 的重要性與可能的更新頻率進行校準。我們也依賴機器學習來精確告知我們何時排程索引作業。對於具有常規發布和重新整理節奏的網站，這使我們能夠將操作延遲到最有可能發揮最大效用的時間點。透過對這些機器學習模型進行持續改進，我們能夠維護一個在完整性和即時性上皆符合標準的索引。

儘管我們的網路爬蟲基礎架構易於水平擴展，但我們深知網站營運商面臨著不同的技術限制。我們謹慎地維持對任何給定網域之請求的預測性且可管理的速率。PerplexityBot（我們的搜尋爬蟲）遵守 robots.txt 檔案中明確設定的限制，或者在沒有指定網域限制的情況下，遵守關於請求速率的業界標準規範。當我們偵測到網站無法使用時，我們也會調整我們的爬蟲行為。我們分散式系統的架構設計旨在即使在數萬個並行操作中也能強制執行這些限制。

在網際網路規模下的自我改進內容理解

即使擁有全球最大、最新鮮的搜尋索引之一，每次查詢的結果品質仍取決於我們的系統對每份文件內容的理解。在這裡，我們面臨著一個根本性的挑戰：網際網路是一個雜亂的地方。沒有任何一套固定的剖析規則能夠處理整個網路中無窮無盡的各種版面、結構與樣式。

我們透過開發一個內容理解模組來解決這個挑戰，該模組使用動態規則集剖析網站並擷取具有語意意義的內容。大量採用清單或表格形式之結構化資料的網站，可能會受益於較公式化的剖析與擷取規則，而另一個主要以自由格式使用者生成內容為特色的網站，則可能需要較為寬鬆的規則集。由於網路在短時間內多半是靜態的，我們發現給定規則的生命週期相對較長。但隨著網站隨時間演進，以及我們對擷取資訊的最佳方法有更多了解，我們的規則集也需要持續維護。

為了促進這種動態適應，我們（當然）轉向了 AI。在 Perplexity 的規模下，我們在每小時服務數百萬次使用者查詢的過程中，觀察到了極其豐富的網路橫截面。這形成了迭代自我改進循環的基礎。我們在整個查詢範圍內觀察現有規則集的剖析行為與擷取輸出。然後，我們使用前沿大型語言模型（LLM）從兩個主要維度評估效能：

完整性：我們的索引應接收盡可能多的具語意意義的內容，同時避免擷取無資訊或無意義的雜訊。

品質：我們的索引依賴於在實質和形式上都具備高品質的內容。資訊的擷取方式應能保留原始的內容結構與版面。

請注意，完整性和品質呈現了另一種內在張力：手動優化品質是可能的，但產生的剖析規則可能無法擷取關鍵內容。同樣地，我們可以手動編寫對原始內容施加極少過濾的寬鬆規則，這可能會提高完整性，但代價是犧牲品質。這就是為什麼我們轉向 AI 驅動的自我改良，以一種能夠以網域適應方式同時優化兩者的方式來演進我們的規則集。

具體來說，在每次透過 LLM 評估剖析效能後，我們的系統會制定一組建議的規則集變更，以解決最重大的錯誤類別。這些規則集會經過進一步驗證，之後我們將新版本部署到索引器。鑑於剖析和擷取邏輯的改進只能造福未來的索引作業，我們對機器學習優化重新索引的投入尤為重要：使用最新版本的邏輯持續更新高流量文件，確保了緊密的自我改進循環。

這些規則不僅對基準剖析效能至關重要，對子文件單位的分割也同樣重要。對於前沿 LLM 而言，每一個上下文詞元（token）都極其珍貴。大量先前的研究記錄了 LLM 效能如何隨著上下文大小的增加以及無關資訊對上下文的污染而下降。擁有結構良好、全面的剖析，使我們能夠將文件分解為自包含的文字片段，每個片段都可以在查詢時被個別檢索和排序。

檢索與排名管線

現代搜尋需要在嚴格的延遲預算下，同時確保完整性與關聯性。Perplexity 的檢索與排名管線透過多階段架構實現了這一目標，該架構透過一系列日益複雜的模組逐步精煉結果。我們透過將任何潛在瓶頸水平擴展到最大程度來解決潛在瓶頸問題。

管線從我們索引中的檢索開始。我們不強迫在詞彙檢索與語意檢索之間做出選擇。相反地，我們透過這兩種方式查詢搜尋索引，並將結果合併為混合候選集。在此階段，優先順序是全面性而非精確度 - 管線的後續階段將針對精確度進行最佳化。

管線隨後進入預先過濾階段，在此階段我們套用基本啟發法與第一輪過濾器，從候選集中移除明顯無回應或過期的內容。

然後，我們採用多個逐步進階的排名階段。早期階段依賴針對速度進行最佳化的詞彙與基於嵌入的評分器。隨著候選集逐漸縮減，我們接著使用更強大的跨編碼器重排模型來對結果集進行最終形塑。由於我們對推論效能進行了大量投資，我們能夠將最先進的模型架構運用於這些後續階段，同時保持整體的排名延遲處於低水準。

在此管線中，我們在文件與子文件層級檢索並對結果進行評分。如上所述，AI 需要謹慎的上下文工程。我們的管線旨在向模型呈現盡可能最原子的單位，以便下游消費者能夠納入這些精確的單位，而不會從來源文件的其他地方拉入不相關的上下文。

確保此管線每個階段的高品質，唯有透過與 Perplexity 的產品組合進行共同設計方能實現。排名堆疊的每個細節都旨在利用我們每天提供數百萬次使用者請求所產生的豐富訊號。絕大部分的訊號都是自動化的，每個產生的 Perplexity 解答都為搜尋品質提供了一個經驗資料點，正如在即時代理工作流程中所使用的那樣。我們將 AI 驅動的評估與即時人類回饋相結合，為我們的嵌入和排名模型豐富訓練資料，遠超任何手動建構的資料集所能提供的水準。

搜尋與產品之間的這種協同作用是 Perplexity 獨有的。傳統搜尋引擎受限於由藍色連結遙測提供的粗略訊號。較新推出的搜尋產品曾嘗試實作其中某些 AI 前瞻概念，但它們缺乏能夠驗證搜尋品質並提供快速改善迴圈所需豐富訊號的真實世界環境。我們很幸運擁有缺少的要素：一個由前沿 LLM 驅動、並由全球數百萬好奇使用者持續進行實戰測試的即時搜尋品質驗證場。

為品質與效能建立全新前沿

在建構 Perplexity Search API 與 SDK 以向全球開發人員提供我們的搜尋基礎設施後，我們希望了解各種商業 API 產品在真實世界 AI 使用情境中的表現。評估 AI 模型本身已變得司空見慣，但我們需要對這種模式進行調整：評估由 AI 模型呼叫時搜尋 API 的品質。

我們首先將目光投向開源生態系統以了解先前的技術。我們找到了嚴格評估的許多關鍵要素，但沒有一個框架將這些要素整合到即插即用的基準測試解決方案中。因此，我們著手開發一個評估框架，不僅可供 Perplexity 使用，也可供任何尋求對搜尋 API 進行基準測試的研究人員或開發人員使用。

使用此評估框架，我們對 Perplexity Search API 以及其他產品進行了嚴格的基準測試。最佳化搜尋效能相當複雜，在品質與速度之間有許多細微的權衡。對開發人員而言是一大福音，我們發現 Perplexity Search API 為品質和延遲設定了全新業界水準。開發人員不再需要在建構極速應用程式與確保高品質結果之間做出抉擇：有了 Perplexity，兩者兼得。

放大

為代理式搜尋工作流程設計可靠的評估

我們首先為我們的評估框架定義了三個指導原則：

複雜度光譜：評估框架應衡量在簡單與複雜代理式 AI 使用情境上的效能。

中立性：評估框架應在平等的基礎上評估所有 API。

簡潔性：儘管某些使用情境可能很複雜，但框架本身應盡可能簡單，以便其他人能夠理解、重現結果，並以最少的繁瑣工作擴展框架。

我們的輕量級評估框架 search_evals 透過簡單的模組化設計實現了這些目標。我們開發了兩個 AI 代理工具組，以擷取傳統單次搜尋使用情境與進階代理工作流程（以消費市場中廣泛提供的各種「深入研究」產品為例）。這兩個工具組均以直接的方式實作，幾乎沒有留下隱藏優勢的空間。

為了推動我們的評估，我們採用了四個基準測試：用於單步搜尋的 SimpleQA 與 FRAMES，以及用於深入研究的 BrowseComp 與 HLE。統稱起來，這些基準測試為知識代理提供了廣受接受的衡量標準。遵循既定慣例，我們使用原始工作中使用的相同提示分類器方法對所有基準測試進行評分。精確的基準測試實作（包含評分器邏輯）可以在我們的 GitHub 儲存庫中檢閱。

我們在設計框架時充分考慮了可重複性與可擴展性。任務層級分數和底層代理輸出都會隨每次執行一同儲存。額外的工具組、基準測試和搜尋 API 產品可以輕鬆整合。研究人員和開發人員可以閱讀我們的 GitHub 文件，以取得有關擴展框架以滿足您精確需求的更多資訊。

評估結果

憑藉此評估框架，我們著手將我們的 Search API 與其他 API 產品進行評效比較。在所有經過測試的基準測試中，Perplexity 都是市場上速度最快且品質最高的 API。

放大

我們發現上述對索引、檢索和排名效率的投資獲得了豐富的回報。Perplexity 的中位數延遲為 358 毫秒，比第二快的提供者快了 150 毫秒以上。第 95 百分位延遲舒適地保持在 800 毫秒以下。憑藉當今前沿模型的長 TTFT（首個 Token 生成時間）指標，在打造令人愉悅的使用者體驗時，每一毫秒都至關重要。過去兩年來，我們一直在為我們自己的使用者最佳化延遲，我們很高興這些相同的投資現在也將惠及開發人員社群。

Search API 延遲

（從 AWS us-east-1 發起的要求）

來自 AWS us-east-1 的請求之搜尋 API 延遲百分位數。

* 許多搜尋 API 供應商使用 SERP 網頁擷取作為其結果的基礎。為了捕捉此類方法的效能，我們使用了 Tavily 提供的具代表性基於 Google SERP 的 API。

這種速度優勢並未以犧牲品質為代價。Perplexity Search API 在單步搜尋和深入研究設定中均產生了最先進的效能。在每個測試過的基準測試中，Perplexity 在提供能夠支援不同複雜度 AI 工作流程的高品質結果方面名列前茅。Perplexity 與最佳替代方案之間的差距在 SimpleQA 和 HLE 上尤其明顯，這表明這些結果在任務複雜度光譜上具有強固性。

放大

與延遲一樣，我們在搜尋品質方面的領先地位源於我們在建構令人愉悅、高流量 AI 產品方面的領先地位。我們的數百萬使用者使用 Perplexity 來滿足他們對各種能想像主題的好奇心，由此產生的品質和關聯性訊號使我們的搜尋模型能夠隨著每個小時過去而不斷改進。

Search API 品質基準測試

SimpleQA、FRAMES、BrowseComp 和 HLE 上的搜尋 API 品質分數。

我們仍處於 AI 原生搜尋引擎的早期階段，衡量藝術與科學無疑將會演進。我們邀請社群透過開發嚴格且具創造力的方法來參與，以便在 AI 代理時代評估搜尋引擎。

AI 下一個篇章的建構模組

代理式系統與智慧助理的未來將取決於是否能夠取得對世界集體知識的豐富程式化介面。當今的傳統搜尋引擎使用量已趨於飽和，每天約有 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}
}