OpenRouter 推出即時網頁搜尋基準排行榜與配置指南

網路搜尋是大多數 LLM 請求的基本需求，以克服知識截止點。實驗室與搜尋供應商正迅速演進，讓搜尋更有效率，這使我們面臨一連串棘手決策：使用某些實驗室內建的原生搜尋，或接入第三方引擎如 Exa、Parallel 或 Perplexity？一次搜尋足夠嗎？如果不夠，我該讓代理持續搜尋多久？更多搜尋回合是否值得其帶來的品質提升？

我們建立了即時排行榜，協助您以資料決定最佳搜尋設定。請參閱 我們的新基準頁面 上的資料。

我們對所有組合進行基準測試，以找出優缺點

在設定搜尋請求時，您需要做四項決策：

• 模型。寫出將提交給搜尋引擎的確切查詢，並處理結果。
• 引擎。您可以選擇特定引擎，或依賴某些實驗室提供的捆綁引擎。在 OpenRouter 上，我們提供 Exa、Parallel 與 Perplexity，並配合 OpenAI、Anthropic、Google 等實驗室的原生引擎。
• 搜尋方式。您可以在呼叫模型前先執行搜尋，並將結果作為上下文傳入；或是為模型配備網路搜尋工具，讓其自行決定何時呼叫。
• 搜尋預算。若選擇搜尋工具方式，您亦可給模型允許執行搜尋的次數預算。這使模型能在不滿意結果時調整查詢或進行後續搜尋。我們的執行使用 1、5 或 25 回合。

為了全面瞭解網路搜尋效能，我們定期在多個模型、引擎與搜尋設定上執行四項基準測試：

• BrowseComp：需要實際瀏覽的硬實事證查詢
• DeepSearchQA：多跳研究問題
• WideSearch：廣泛的「填滿整張表」集合
• HLE：帶搜尋功能的專業考試題目

每個頁面都按品質、價值與速度對配置進行排名，讓您可根據工作負載最重要的因素做決策。排行榜為即時更新，數字會隨著新跑次及新模型、引擎加入而變動。今日領先者不一定是明日的領先者。我們不會在此文章中過多討論今日領先者，因預期其會隨時間變化。相反地，讓我們看看資料告訴我們如何為您的工作負載做決策。

搜尋預算比任何其他因素更重要

將引擎預算從一次提升至多次，可比任何單一變更更提升品質。舉例來說，以下是我們在 Perplexity 上對 BrowseComp 進行三個不同預算的初始跑次：

此模式在我們測量的所有供應商中都成立：

這些跑次僅涵蓋 BrowseComp，使用伺服器工具每次搜尋十個結果，未進行頁面抓取或程式碼執行，且為每個配置最新符合條件的跑次。

提升搜尋深度是我們發現的最便宜提升品質方式。將從 1 回合提升至 25 回合，大約可將分數翻倍，而每題成本僅增加 2.5 至 7 倍。

你可能會認為這會普遍降低迴應速度，但實際情況並非如此。例如，Luna 在 1 回合時每題耗時 140 秒，在 25 回合時耗時 111 秒。於我們在 1 與 5 回合下測試的 35 種配置中，超過三分之一在較少回合時更慢。全部皆為 OpenAI 模型。這些模型在有限搜尋預算下仍能進行額外推理。

另一方面，搜尋深度在較簡單的任務中可能會增加成本。例如，在 HLE 上，GPT-5.6 Sol 以 Perplexity 評分在 1 回合與 25 回合之間相近，但成本是三倍。如果你的搜尋通常較簡單，仍值得將預算限制在較低水平。

你的最壞成本情境由失敗率決定

另一種擴大預算會產生負面影響的情況是模型無法找到答案時。我們發現模型會耗盡預算試圖尋找答案，即使最終仍會失敗。

我們記錄到最深的嘗試是對 WideSearch 表進行 81 次搜尋，仍被評為錯誤。如果你的工作負載失敗率高，降低搜尋深度可能是減少成本的有效途徑。

雖然引擎重要，但模型更為關鍵

預算設定後，下一個最重要的問題是選擇哪一個模型。

上表顯示 25 回合的 BrowseComp 結果，將前沿模型與預算模型在各搜尋引擎間進行比較。

在保持模型不變的情況下改變引擎，平均分數變化 10 分，而前沿模型與成本效益模型之間的平均差距則為 15 分。在各引擎中，前沿模型的成本變化最大，最昂貴的引擎成本是最便宜的 2.5 倍，成本效益模型則為 1.5 倍。

之所以能進行此類比較，是因為伺服器工具位於供應商之上。改變請求中的模型，搜尋行為保持一致，即使是供應商不提供搜尋功能的模型亦是如此。

當然，基準測試只是可能表現的參考。它們告訴你哪些配置值得嘗試以及大致成本。對你實際任務而言，這些選擇的成本與品質會有所不同，因此你能從這些頁面中獲得最高價值的做法是將其視為候選清單，然後將自己的問題投給前幾名。

在你自己的工作負載上嘗試

上述所有內容都是你今天可以在 OpenRouter 上設定的請求引數。

• 網頁外掛。 web plugin 在模型開始撰寫前執行一次搜尋，適用於只需要最新事實的快速、低成本選項。
• 伺服器工具。 server tool 將搜尋工具交給模型，讓它決定下一步搜尋什麼，適用於答案需要多步尋找的情況。
• 引擎。 在 OpenRouter 上，你可以將 engine 設為 exa、parallel、perplexity 或 native；auto 先嘗試本機，若失敗則回退到第三方。
• 搜尋預算。 最上層的 max_tool_calls 請求欄位限制代理人可進行的回合數，即在回答前最多搜尋幾輪；max_results 設定每次返回多少結果。

一個合理的起點：選擇最接近您任務的套件，挑選距離最高分幾分之內最便宜的設定，然後將您自己的評估資料集重新跑在它上方兩到三行，觀察額外支出是否在結果中顯現。

基準測試方法

每一次執行都透過公開的 OpenRouter API 對接生產端點，使用我們的 開源基準測試工具。

• 僅聚焦於搜尋效能。為確保我們只比較搜尋設定，我們統一每次搜尋十條結果，未執行頁面抓取亦不執行程式碼。推理流程對每個模型固定，表格中已呈現。
• 評分嚴格。每個被評估的答案都以官方答案鍵為基準判斷正確或錯誤，必要時使用 LLM 判斷進行語義比較。WideSearch 還會分別報告答案專案的準確率。
• 成本與速度以每題計算。成本為總支出（含評分）除以評估題數；速度則為每題候選答案產生時間。
• 每頁顯示每個設定最新符合條件的執行。當一次執行完成最低題數即視為符合條件，新的執行會取代舊的。

常見問題

這些分數與已公佈的供應商代理排行榜有何比較？

它們無法直接比較。大多數已公佈的基準表格衡量的是結合搜尋、完整頁面抓取及程式碼工具的完整代理產品。這些排行榜將搜尋設定獨立出來：模型僅閱讀搜尋結果摘錄，頁面抓取與程式碼工具皆關閉。這樣可直接比較不同設定，但不會最大化基準分數。

我應該選擇哪個搜尋引擎？

取決於模型與任務，這也是頁面存在的原因。對某些模型來說引擎之間的差距大，對其他模型則微乎其微，且供應商自家的原生搜尋並不一定是最佳選擇。檢視最接近您工作負載的套件的即時排行榜，閱讀成本與延遲與分數並列，並隨時間重新檢查，因為新執行落地後排序會變動。

數字有多新鮮？

排行榜始終顯示每個設定最新符合條件的執行，使用 OpenRouter 的基準測試工具對接生產端點。新執行會取代頁面上的舊執行。

在 Discord 的 #feedback 頻道告訴我們下一步應測試哪些搜尋引擎或模型。