Perplexity 在其 Agent API 加入 Wide Research，並推出 500 項任務的 WANDR 基準測試
Perplexity 已在其 Agent API 加入 Wide Research 預設，並推出 WANDR——一項用於具證據支持研究工作的 500 項任務基準測試。
Perplexity 已在其 Agent API 提供 Wide Research 預設，並推出 WANDR——一項包含 500 項任務的基準測試，旨在測試 AI 系統能否完成廣泛而有證據支持的研究工作，而不只是找出幾份相關文件。
這項產品改動針對一類以覆蓋範圍為核心要求的工作：找出所有符合既定準則的結果、以額外事實充實這些結果、辨別名稱相近的實體，以及為每項結論提供證據。Perplexity 行政總裁 Aravind Srinivas 在公布這項發布時，形容一般的「狹義搜尋」大致已解決，並將更困難的問題界定為大規模進行的廣泛研究。
這個區別很重要，因為對研究請求而言，有用的答案未必就是合格的研究交付成果。一個模型或許能從大量候選對象中識別出幾個看似合理的例子，卻仍可能遺漏合資格的實體、把指向不同人士或公司的紀錄合併，或提供僅支持最終清單其中一部分的引文。這些失誤在市場盤點、供應商篩選、公共紀錄研究、競爭分析，以及文獻或政策審查等工作流程中尤其代價高昂。
Perplexity 為 Agent API 加入甚麼
Perplexity 表示，Wide Research 預設採用其「Search as Code」架構。其所述設計是讓模型建立一次研究計劃，然後在較大規模的搜尋和檢索操作中，以確定性方式執行該計劃，而不是反覆把每項中間結果帶入模型的上下文視窗。
這與傳統以聊天為基礎的研究流程，在技術重點上有所不同。在狹義任務中，代理通常可以搜尋、閱讀少量頁面，並在一段持續發展的對話內綜合出答案。廣泛任務則可能要求對數十或數百名候選對象重複進行相同的檢查步驟：識別候選對象、測試資格規則、擷取欄位、取得支持頁面、解決重複項目，以及產生結構化輸出。
Perplexity 的說法並非模型不再需要就任務進行推理。模型仍須判斷應搜尋甚麼、何謂合資格結果、哪些證據足夠，以及最終輸出應如何組織。改變的是計劃的執行方式：重複操作可作為程式化的研究工作流程處理，而毋須把不斷增加的原始結果清單強行放回模型的工作上下文。
實際上，這種方法旨在減少廣泛研究工作中兩種常見的壓力。第一，上下文可能被已處理、但仍須保留作比較的紀錄擠滿。第二，長時間運行的代理若必須多次重述其準則，或反覆重新評估同類型紀錄，便可能偏離原有方向。確定性執行層本身無法保證完整覆蓋，但可令研究計劃中重複的部分更一致，也更易於檢查。
這項公布並未為「每一個」合資格結果建立一個通用定義。完整性始終取決於可用來源、確切的納入準則，以及相關資料是否可公開檢索。更具體的說法是，API 現已提供一項預設，專為覆蓋範圍及逐項紀錄證據屬首要要求的任務而設。
WANDR 將廣泛研究轉化為可測試任務
WANDR 是 Perplexity 配套推出、用於「廣泛而深入研究」的基準測試。其公開儲存庫把這項基準測試描述為結構化、高工作量的資訊工作，需要廣泛發現、充分充實資料、系統化擷取、精確實體消歧，以及由證據支持的答案綜合。
這些要求令 WANDR 與主要為單一答案或短推理鏈評分的基準測試顯著不同。一個系統必須處理一組實體，並為任務產生所需檔案或結構化輸出。這項基準測試的原始任務包括任務樹、schema、提示詞、評分設定和任務專屬產物。這些原始定義其後會被轉譯為自包含的任務套件。
每個生成的 WANDR 套件都包括求解器指示、任務中繼資料、公開 Docker 環境、評估器材料，以及有序的任務 manifest。儲存庫表示，任務本地的評估器是刻意設計：任務可以發布、下載及驗證，而毋須在執行時依賴另一個獨立的 WANDR 套件。這令基準測試更具可攜性，同時也使評估合約更明確。
評估過程的設計不只檢查最終答案是否聽起來具說服力。代理產生所需輸出檔案後，WANDR 的驗證器可以取得已提交頁面、標準化實體、去除重複紀錄，並判定結果。儲存庫區分得到零獎勵的已完成運行與驗證器錯誤：零分是已評分的結果，而錯誤則代表未有產生有效分數。
這對研究代理評估十分重要，因為表面上精緻的敘述可能掩蓋操作失誤。一個系統可以寫出流暢文字，卻未能返回所需紀錄、引用不支持某欄位的頁面，或以多個名稱重複列出同一機構。相比單靠廣泛的偏好判斷，檢查任務專屬檔案及評分材料的驗證器更適合偵測這些失誤。
圍繞可重現性建立的基準測試，而不只是提示詞
Perplexity 已以 Apache-2.0 授權條款發布 WANDR。該儲存庫把可編輯的任務原始碼、生成的基準測試套件，以及用於執行遠端端點的通用代理轉接器分開。這種分隔讓研究人員和開發者可更清楚界定修改任務語義、將任務轉譯為 Harbor 基準測試格式，以及針對生成套件測試代理時的邊界。
該專案亦包括單一任務 smoke test、所有供應商 smoke test、兩項任務驗證運行，以及完整基準測試運行的設定。其文件列出的供應商矩陣包括 OpenAI、Anthropic、Perplexity、Exa、Parallel 和 Gemini 整合。儲存庫提醒，完整評估會產生付費的求解器、擷取和裁判 API 呼叫，而基準測試工具不設消費上限。
這項警告有助提醒人們，廣泛研究評估究竟衡量甚麼。該基準測試並不會將複雜的研究工作簡化為廉價的一次性提示詞。評估廣泛發現、頁面檢索、證據驗證和結構化輸出，可能需要大量模型及網絡存取使用量，尤其是在多個系統上運行同一任務時。
該專案的 Relay 元件會記錄每次試驗的生命週期事件、工具活動、使用量、產生的檔案、提示詞、最終訊息，以及標準化結果中繼資料。它亦要求已聲明的輸出檔案在驗證器啟動前必須存在且非空白。這些機制使人們可以檢查結果失敗的原因：代理未有產生所要求的產物、輸出格式不正確，還是提交的研究未符合任務的評分規則。
對開發者而言的實際改變
對建立研究代理的開發者而言，Wide Research 預設最適用於輸出是資料集、已審閱的候選清單或證據軌跡的情況，而不只是附有幾個連結的一段答案文字。
例如，一個採購工作流程可能需要找出所有符合地區、認證、產品類別和規模門檻的供應商，並以來源支持每個欄位。一名政策研究員可能需要找出指定時期內所有相關申報文件，解決重複實體，並按固定評分準則為每項內容分類。在這兩種情況下，找出幾個好例子並不足夠；工作流程需要可重複的操作，以及可逐項紀錄檢查的結果。
WANDR 提供一種公開方式來測試這個區別。其任務結構、驗證器設計和已發布產物，讓開發者在比較研究代理系統時，得到比個別示範更具體的依據。與此同時，Perplexity 的 API 預設將 Search as Code 呈現為一種執行模型，用於處理這類任務產生的重複工作。
這項發布並未證明任何單一模型已解決全面研究問題。不過，它令底層標準更明確：廣泛研究系統應按覆蓋範圍、擷取質素、實體解析、輸出合約和證據來評判，而不只是看其最終文字是否具說服力。
參考來源
Share