架構與評估 AI 原生搜尋 API

構建一個可擴展且具備 AI 前瞻性的搜尋 API，在資訊檢索、人工智慧與系統設計的交集處帶來了獨特的研究挑戰。與處理受限資料的傳統服務不同，搜尋 API 必須持續索引數十億份文件，理解跨語言與跨領域的查詢意圖，並在毫秒級別內呈現相關結果。在人工智慧代理（AI agents）的世界中，搜尋 API 還必須謹慎地整合提供給開發者模型的 上下文（context），以確保這些模型表現最佳並納入最準確的資訊。有效的上下文工程要求 API 不僅要捕捉文件層級的相關性，還要將文件的各個章節與片段視為獨立的一等單位。

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

隨後，我們將描述我們透過全新開源評估框架，對搜尋 API 效能進行實證評估的方法。透過與現有商業 API 的綜合基準測試，我們證明了在品質與延遲方面均達到了最先進的效能。Perplexity 搜尋 API 即日起向全球開發者開放。

[在 GitHub 上尋找 search_evals]

構建針對 AI 模型最佳化的搜尋系統

自創立以來，我們深知強大的搜尋能力對於實現我們想要推出的品類定義型人工智慧產品至關重要。起初，我們希望這些能力已經以公開可用的形式存在。我們在 2022 年底嘗試了現有的各種搜尋 API 產品組合，而 Perplexity 答案引擎的 最初版本 確實整合了其中一些產品。具體來說，我們會分析用戶查詢，制定並發送請求至這些 API，然後收集結果作為我們後續生成管道的上下文。

然而，隨著用戶湧向 Perplexity，我們很快意識到這些 API 無法隨著我們的增長而擴展。我們遇到的價格昂貴得令人咋舌，其中一家領先的 API 提供商收費高達 每千次查詢 200 美元。但更致命的是，這些傳統 API 根本不是為前沿人工智慧系統所引入的新檢索範式而設計的。

放大

首先，這些傳統 API 的請求與回應格式，是為了人類作為搜尋結果的唯一使用者這一世界所設計的。因此，這些 API 優先考慮文件層級的結果，而排除了子文件單元所揭示的更細緻的資訊。人工智慧模型的成功取決於所提供上下文的品質與緊湊度，我們親眼目睹了過度廣泛的檢索如何使人工智慧模型偏離軌道，無論所檢索的文件整體看起來多麼相關。我們試圖將精確性強加於不精確結果的嘗試，成效十分有限。

我們還觀察到傳統 API 要麼過時，要麼太慢。獨立開發的搜尋 API 依賴不完整且更新頻率過低的索引。基於網頁抓取的 API（例如各種用於 Google 搜尋的非官方 SERP API）受益於更全面的索引，但由於查詢第三方搜尋引擎固有的效率低下，導致其延遲高得令人無法接受。高延遲使得 API 不適用於面向用戶的應用程式，而過時的結果集則使得任何希望準確且值得信賴的人工智慧系統無法使用。

最後，我們觀察到人工智慧生態系統在詞法搜尋與語義搜尋之間出現分歧，並出現了過度偏向其中一種模式而犧牲另一種的系統。我們看到了向量資料庫的興起，它們甚至無法充分支援簡單的布林過濾器。傳統搜尋後端的情況也沒好到哪裡去，對人工智慧解鎖的語義排序與檢索機會的支援極為原始。

當我們意識到要讓 Perplexity 更進一步，需要構建我們自己專用的搜尋基礎設施時，我們將我們的觀察歸納為三個關鍵準則：

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

細粒度的內容理解：人工智慧模型的脆弱性與有限的上下文窗口，要求搜尋結果必須以儘可能細緻的層級進行呈現與排序。

混合檢索與排序：檢索與排序管道都必須整合詞法與語義訊號，才能使結果對人工智慧有用。

放大

爬取與索引基礎設施

以 Perplexity 的規模營運，需要能夠全面映射網路並對其持續演變做出回應的基礎設施。我們的搜尋索引追蹤超過 2000 億個唯一網址，並具備追蹤數千億個更多網址的能力。

確保我們的索引覆蓋足夠全面的網際網路範圍，並使每份文件反映最新狀態是一項艱鉅的任務。完整性與時效性之間存在固有的緊張關係：在固定的索引預算下，現有頁面的重新整理操作必須與新未訪問頁面的索引操作競爭。我們透過結合擴展（透過增加索引預算來放寬優化限制）與機器學習驅動的優先級排序（確保每次索引操作對整體索引的價值最大化）來平衡這種緊張關係。

我們構建了一個 EB（Exabyte）規模的索引與爬取裝置，可隨規模與查詢量進行水平擴展。Perplexity 的爬蟲與索引集群總共包含數萬個 CPU 與數百 TB 的 RAM，並為進一步擴展留下了相當大的餘地。我們將此計算基礎設施與冷熱儲存的平衡相結合。我們同時使用學習模型與調整後的啟發式演算法來確定哪些文件應保持活躍狀態，優先考慮來自權威網域的文件、涉及未充分覆蓋主題的文件，以及其他具有極大潛力豐富我們索引的類別。

此基礎設施使 Perplexity 能夠每秒處理數萬次索引操作。但即使擁有如此相對寬裕的預算，網際網路的規模過於龐大，無法頻繁且週期性地索引每一個網址。這正是機器學習發揮作用的地方。我們訓練了一個機器學習模型來預測給定的候選網址是否需要被索引。訓練目標旨在確保我們將索引決策校準到特定網址的重要性與可能的更新頻率。我們還依賴機器學習來精確告知何時安排索引操作。對於具有常規發布與更新節奏的網站，這使我們能夠將操作推遲到它們最可能有用的一刻。透過對這些機器學習模型的持續改進，我們能夠維護一個在完整性與時效性上都達到標準的索引。

儘管我們的爬取基礎設施很容易進行水平擴展，但我們意識到網站運營商面臨著不同的技術限制。我們小心地保持對任何特定網域的請求頻率在可預測且可管理的範圍內。我們的搜尋爬蟲 PerplexityBot 會遵守 robots.txt 檔案中規定的明確限制，若無特定網域限制，則遵循有關請求頻率的行業標準規範。當我們檢測到網站不可用時，也會調整我們的爬取行為。我們的分散式系統架構旨在強制執行這些限制，即使在數萬個並發操作下也是如此。

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

即使擁有全球最大、最新的搜尋索引之一，每個查詢的結果品質仍取決於我們系統對每份文件內容的理解。在這裡，我們面臨一個根本性的挑戰：網路是一個混亂的地方。沒有一組固定的解析規則可以處理在整個網際網路上發現的無限多樣的佈局、結構與風格。

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

為了促進這種動態適應，我們（當然）轉向了人工智慧。在 Perplexity 的規模下，我們在每小時處理數百萬次用戶查詢的過程中，觀察到了網路極其豐富的橫截面。這形成了迭代式自我改進迴圈的基礎。我們觀察當前規則集在我們的查詢範圍內的解析行為與提取輸出。然後，我們使用前沿大型語言模型（LLM）從兩個主要維度評估效能：

完整性：我們的索引應接收儘可能多具有語義意義的內容，同時避免錯誤提取無資訊量或無意義的內容。

品質：我們的索引依賴於在實質與形式上皆高品質的內容。資訊的捕捉方式應保留原始內容的結構與佈局。

請注意，完整性和品質構成了另一個固有的緊張關係：手動優化品質是可行的，但產生的解析規則可能無法捕捉關鍵內容。同樣，我們可以用手動編寫寬鬆的規則，對原始內容進行最小程度的過濾，這可能會提高完整性，但會以犧牲品質為代價。這就是為什麼我們轉向人工智慧驅動的自我改進，以一種能以領域自適應方式同時優化兩者的手段來發展我們的規則集。

具體來說，在每次人工智慧驅動的解析效能評估後，我們的系統會制定一組擬議的規則集變更，以解決最重大的錯誤類別。這些規則集會經過進一步驗證，之後我們將新版本部署到索引器中。鑑於解析與提取邏輯的改進只能使未來的索引操作受益，我們在機器學習優化重新索引上的投入顯得尤為重要：使用此邏輯的最新版本持續重新整理高流量文件，確保了緊密的自我改進迴圈。

這些規則不僅對基準解析效能很重要，對分割成子文件單元也同樣重要。對於前沿大型語言模型而言，每一分上下文 tokens 都彌足珍貴。大量先前的研究記錄了大型語言模型效能如何隨著上下文大小的增加以及無關資訊對上下文的污染而下降。擁有結構良好且全面的解析，使我們能夠將文件分解為獨立的區塊，每個區塊都可以在查詢時進行單獨檢索與排序。

檢索與排序管道

現代搜尋需要在嚴格的延遲預算下確保完整性與相關性。Perplexity 的檢索與排序管道透過多階段架構實現了這一點，該架構透過一系列日益複雜的模組逐步完善結果。我們透過將任何潛在的瓶頸水平擴展到最大程度，來解決潛在的效能障礙。

該管道始於從我們的索引中進行檢索。我們不強迫在詞法與語義檢索之間做出選擇。相反，我們透過兩種模式查詢搜尋索引，並將結果合併為一個混合候選集。在此階段，優先順序是完整性勝過精確度——管道的後續階段將針對精確度進行優化。

管道繼續進入預過濾階段，在此階段，我們應用基本的啟發式演算法與初步篩選，以從候選集中移除明顯無回應或過時的內容。

然後，我們採用多個逐步先進的排序階段。較早期的階段依賴於針對速度優化的詞法與基於嵌入的評分器。隨著候選集逐漸減少，我們使用更強大的交叉編碼器（cross-encoder）重排序模型來對結果集進行最終雕琢。感謝我們在推理效能上的大量投入，我們能夠利用最先進的模型架構進行後續階段，同時保持整體的排序延遲在低水平。

在整個管道中，我們在文件與子文件層級檢索並評分結果。如上所述，人工智慧需要細心的上下文工程。我們的管道旨在向模型呈現儘可能原子的單位，以便後續消費者可以合併這些精確的單位，而不會從來源文件中的其他地方提取無關的上下文。

確保管道每個階段的高品質，只有透過與 Perplexity 的產品組合共同設計才能實現。排序堆疊的每個細節都旨在利用我們每小時處理的數百萬次用戶請求所產生的豐富訊號。絕大多數訊號是自動化的，每個生成的 Perplexity 答案都在實時代理工作流程（agentic workflow）中提供了關於搜尋品質的實證數據點。我們結合人工智慧驅動的評估與實時的人類回饋，以豐富我們嵌入與排序模型的訓練資料，這遠遠超過任何手動構建的資料集所能提供的效果。

這種搜尋與產品之間的協同效應對 Perplexity 而言是獨一無二的。傳統搜尋引擎僅限於藍色連結遙測（blue-link telemetry）提供的粗略訊號。較新的搜尋產品嘗試實施一些這些具備人工智慧前瞻性的概念，但它們缺乏能夠驗證搜尋品質並提供快速改進迴圈所需訊號豐富度的真實世界環境。我們很幸運擁有了缺失的要素：一個由前沿大型語言模型驅動、並由全球數百萬好奇用戶持續實戰檢驗的實時搜尋品質試驗場。

建立品質與效能的新前沿

在構建 Perplexity 搜尋 API 與 SDK 以向全球開發者提供我們的搜尋基礎設施後，我們希望了解各種商業 API 產品在真實的人工智慧使用案例中表現如何。評估人工智慧模型本身已成為常態，但我們需要對這種模式進行調整：評估搜尋 API 在被人工智慧模型呼叫時的品質。

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

使用此評估框架，我們對 Perplexity 搜尋 API 與其他產品進行了嚴格的基準測試。優化搜尋效能非常複雜，品質與速度之間存在許多細微的權衡。對於開發者來說，這是一個勝利，我們發現 Perplexity 搜尋 API 在品質與延遲方面皆樹立了最先進的新標準。開發者不再需要在構建極速應用程式與確保高品質結果之間做出選擇：有了 Perplexity，兩者皆可兼得。

放大

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

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

複雜度光譜：評估框架應衡量在簡單與複雜代理型人工智慧使用案例中的表現。

中立性：評估框架應在同等條件下評估所有 API。

簡潔性：儘管某些使用案例可能很複雜，但框架本身應儘可能簡單，以便其他人能夠理解它、重現結果，並以最小的繁瑣程度擴展框架。

我們輕量級的評估框架 search_evals 透過簡單的模組化設計實現了這些目標。我們開發了兩個人工智慧代理組件，用於捕捉傳統的單次搜尋使用案例與先進的代理型工作流程（以消費市場廣泛提供的各種「深入研究」產品為例）。兩個組件都以直接明瞭的方式實施，幾乎沒有隱藏優勢的空間。

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

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

評估結果

利用此評估框架，我們著手評估我們的搜尋 API 與其他 API 產品的比較。在所有測試的基準中，Perplexity 是市場上速度最快且品質最高的 API。

放大

我們發現，我們上述在索引、檢索與排序效率上的投入獲得了豐厚的回報。Perplexity 的中位數延遲為 358 毫秒，領先第二快提供商超過 150 毫秒。第 95 百分位數延遲穩定地控制在 800 毫秒以下。隨著當今前沿模型漫長的 TTFT（首個 token 生成時間）指標，每一毫秒對於創造令人愉悅的用戶體驗都至關重要。過去兩年我們一直致力於為我們自己的用戶優化延遲，我們感到欣慰的是，同樣的投資現在也將惠及開發者社群。

搜尋 API 延遲

(請求發起自 AWS us-east-1)

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

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

這種速度優勢並非以犧牲品質為代價。Perplexity 搜尋 API 在單步搜尋與深入研究環境中皆帶來了最先進的效能。在每個測試的基準上，Perplexity 在提供高品質結果方面都處於領先地位，這些結果可以驅動各種複雜度的人工智慧工作流程。Perplexity 與最佳替代方案之間的差距在 SimpleQA 與 HLE 上尤為顯著，這表明這些結果在整個任務複雜度光譜中皆具有穩健性。

放大

與延遲一樣，我們在搜尋品質上的領先地位，源於我們在構建令人愉悅且高流量的人工智慧產品方面的領導地位。我們的數百萬用戶使用 Perplexity 來滿足他們對各種主題的好奇心，而由此產生的品質與相關性訊號使我們的搜尋模型每小時都在改進。

搜尋 API 品質基準

Search API 在 SimpleQA、FRAMES、BrowseComp 和 HLE 上的品質分數。

我們仍處於人工智慧原生搜尋引擎的早期階段，測量的藝術與科學無疑將會演變。我們邀請社群透過開發嚴謹且具創造性的方法，在人工智慧代理時代評估搜尋引擎來做出貢獻。

人工智慧下一個篇章的基石

代理系統與智慧助手的未來，將取決於對世界集體知識進行豐富的程式化介面存取的能力。當今的傳統搜尋引擎的使用量已達到每天約 10¹⁰ 次查詢的飽和點，這個數字很可能已經見頂。下一代搜尋與檢索系統將處理數量級更多的請求，因為越來越多的人工智慧代理依賴它們獲取準確的即時資訊。

我們迄今的努力使我們成為最快、效能最高的 API 可存取搜尋引擎。但我們需要更宏大的創新來推動人工智慧的下一個篇章。面對不斷增長的需求，我們如何有效地擴展這些系統？鑑於上下文工程與後訓練（posttraining）的新穎方法，這些搜尋系統如何進行優化？我們如何駕馭完整性、時效性與延遲之間持續存在的緊張關係？這些都是公開的問題，而 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}
}