Perplexity Decider

我們正式推出 Decider v1.3 和 Decider Flash v1.3，接替我們先前的決策模型：v1、v1.1、v1.2 和 Flash v1.2。

Decider Flash v1.3 是由 Decider v1.3 蒸餾而成的較小型模型。兩款模型均以 Apache 授權在 Hugging Face 提供，亦可透過 OpenRouter 及 Perplexity Decisions API 使用。

Perplexity Decider 的靈感來自 Jev，即 TypeSafe AI 的 System One Model。它支援有序或無序標籤的二元及多類別分類，並傳回機率，供應用程式用於分類、路由、排序及評估輸入。

兩款 v1.3 模型透過雙向注意力、更精心篩選的訓練數據及改良的訓練方法，在廣泛的文字和視覺任務上提升了效能和穩健性。我們亦推出全新功能 locate，可在命名實體識別、個人資料識別及擷取式問答任務中標示所選內容。

在本文中，我們會說明如何訓練和評估 Decider，並分享我們在 Perplexity 內部的使用方式。

甚麼是決策模型？

決策模型是一種通用分類器。你提供一項輸入及一組問題，每個問題附有可能的答案。模型會就每個問題傳回各答案的機率分佈。它支援 3 種問題類型：

• 是／否：二元決策。
• 多項選擇：自訂多類別標籤。
• 評分：有序等級。

決策模型支援各種分類和評分任務：

• 評判輸出：評估忠實度、品質和安全性。
• 路由：根據難度將請求分配至較小或較大的模型。
• 內容審核與安全：偵測工具輸出中的有害內容、網絡釣魚及提示注入。
• 篩選和標記：整理大量內容。
• 檢索與重新排序：按相關性為搜尋結果評分。

這些任務當中，有許多以往都由 LLM 等生成式模型處理，儘管它們並不需要自由形式的文字生成。決策模型介乎 LLM 與特定任務分類器之間。它們能在單次前向傳遞中，針對同一輸入的多個問題返回機率，避免逐個 token 生成答案，並讓各問題共用運算。與特定任務分類器不同，它們可透過自然語言提示處理新任務；這種靈活性源自以共用問答格式在多樣化任務上進行的訓練。

訓練

將生成式 LLM 轉化為決策模型

我們透過改造強大的生成式 LLM 骨幹模型來打造 Decider。為說明改造方式，我們先描述請求的表示方式。如下圖所示，一個請求由共用上下文（狀態）和多個問題組成。所有問題都會重複使用該狀態。

例如，給定一份文件及其摘要，單一請求可以同時詢問摘要是否忠實反映文件內容，以及摘要的對象是專家還是一般讀者。在狀態之後，每個問題區塊包含一個問題及其可能的答案，每個答案都會分配一個預設的標籤 token，例如 A、B 或 C。特殊的 <|marker|> token 標示讀取模型預測的位置。在這個位置，一個經學習的線性輸出層（決策頭）會將隱藏狀態映射為該問題各答案選項的分數，然後再轉換為機率。

放大

我們以基礎模型的輸出層進行初始化（該層通常會從整個詞彙表中為下一個 token 評分），並只保留對應預設選項 token（例如 A、B 或 C）的列。然後，我們訓練這個經修剪的層，將 <|marker|> 的隱藏狀態轉換為答案分數。這個方法涵蓋所有分類問題，因為它們都可以表述為多項選擇題。

在訓練方面，我們採用數百個涵蓋不同任務（情緒、自然語言推理、意圖偵測、實體配對、內容審核、事實查核、評分等）的公開數據集，並將每個範例轉換為上述統一格式：一個狀態、一個或多個問題、其選項及一個目標。如果有標準答案標籤，目標可以是單一正確選項，亦可以是各選項的機率分佈。

在 v1.3 中，我們推出 locate，它會從狀態中擷取文字，而非從預設選項中選擇。locate 問題描述要尋找的內容，可以是簡短標籤，例如「地點」，也可以是指示，例如「擷取該職位所在的城市名稱。」模型會傳回狀態中完全相符的文字，以及其起始和結束字元位置。如果沒有找到任何相符內容，則會傳回空白列表。

放大

由於狀態是共用的，單一請求可以就同一輸入同時包含 locate、分類和評分問題。例如，它可以詢問某職位是否需要資深級別經驗，同時擷取所需技能。

雙向注意力：讓模型能雙向閱讀

我們的模型以強大的預訓練生成式骨幹模型為基礎，其因果注意力只允許每個 token 關注自身及之前的 token。我們的消融研究顯示，將骨幹模型的全注意力層改為雙向可提升效能，因此我們採用這個設計，讓每個 token 都能整合整個輸入的上下文。

雙向注意力帶來另一個設計抉擇：狀態和問題應如何互動？我們考慮了三種注意力模式，它們對效能、答案穩定性及快取重用各有不同影響：

• 全部互相可見（v1.2）：狀態和所有問題會以完整的雙向注意力一併處理。狀態的運算可以共用，但某個問題的答案可能會因同時提出的其他問題而改變。
• 獨立問題（v1.3）：狀態會關注所有問題，而每個問題只關注狀態及其自身的 token。問題之間仍可透過共用狀態間接互相影響，但結果更加穩定。
• 完全可快取：狀態只對自身進行注意力運算，而每個問題則對狀態及其自身的 token 進行注意力運算。狀態與問題無關，可在不同請求之間重複使用，以善用提示快取。我們預設不採用此方式，因為讓狀態看到問題對多項任務非常重要，但只需少量微調，即可讓模型切換至此方式。

我們最終選擇了獨立問題，因為它效能強勁且穩定。

放大

訓練方法

兩種規模的模型均分三個階段進行訓練。我們首先在大型數據集上以交叉熵訓練基於 Qwen3.8-27B 的較大模型，然後將其蒸餾至較小的 Qwen3.5-4B 模型。

第一階段是通用訓練，我們會在大規模語料庫上對模型進行全面微調。在這個階段，我們只接受能全面提升模型能力、且不針對任何基準的數據；因此，我們排除了所有基準的訓練數據分割。

完成通用模型的訓練後，我們會使用 LoRA 進行第二個更精細的階段。此階段所用的數據針對特定領域和任務。如果我們觀察到增益有限，或其他任務出現退步，便會在第二階段而非第一階段加入數據。我們使用 LoRA，是為了避免與通用模型偏離太遠，以免為了適應這些特定領域而犧牲效能。目標是在保留骨幹模型通用知識的同時提升效能。將 LoRA 合併回基礎模型時，我們亦會使用權重，以更精確地控制偏移，並優先考慮保留數據上的指標，而非任何領域內的增益。

最後，我們加入一個視覺專用步驟。與第二階段類似，視覺步驟被視為另一個細粒度的專門化步驟，使用一個 LoRA 適配器，並按權重合併回基礎模型。部分視覺能力可能以犧牲文字效能為代價。由於我們觀察到模型在文字方面的使用量遠高於視覺，因此我們優先考慮文字指標，其次才是視覺指標。

在兩個文字訓練階段中，我們都採用三次運行的平均權重，每次運行使用不同的隨機種子。我們發現，這能提升聚合模型的效能和穩健性。

取得最終的大型模型後，我們會對較小的模型套用相同的三階段訓練程序。在此，大型模型擔任教師：其預測的輸出分佈取代黃金標籤，而較小的模型則經訓練，以最小化其預測與教師預測之間的 KL 散度。在相同的訓練數據上，此蒸餾目標的表現優於交叉熵。雖然交叉熵在設有專用訓練數據的基準測試中表現較佳，但對保留數據的泛化能力較弱。我們推測，蒸餾能更好地傳遞教師的輸出分佈，包括其對非黃金標籤選項的信心；而交叉熵則會促使模型過度擬合基準測試特定的訓練分佈。因此，我們採用基於 KL 的蒸餾目標。

為減輕訓練與測試數據互相污染，我們會移除任何可能與我們所用評估重疊的訓練樣本。這一點很重要，因為部分公開訓練數據集包含某些評估數據集的大量內容。我們亦進行廣泛的偏差審查和消除，確保我們的增益可靠，而非單純由學到的偏差所驅動。

加入資訊抽取能力

locate 功能 可從文字中擷取命名實體等資訊，同時不會改變模型回應一般請求的方式。為此，我們加入了一個額外的訓練階段：為 Decider 新增一個特殊 token <|locate|>、一個 span head 及一個 LoRA 適配器。

<|locate|> 的嵌入是以先前訓練階段學到的 <|marker|> 進行初始化。我們只訓練這個新嵌入、span head 和 LoRA 適配器，同時凍結原有的骨幹模型權重和決策頭。每個所請求的欄位都有各自的 <|locate|> token。

片段頭（span head）結合 <|locate|> 的表徵與狀態 token 的表徵，為相符片段的起點和終點評分，並判斷哪些起點與終點應配成一對。它亦會利用 <|locate|> token 的表徵，為這些分數預測各欄位專屬的閾值。選定的片段會以原始文字中的字元位置返回。

我們以經改造的 InfoNCE 損失函數訓練片段頭，將每個黃金片段推高至閾值以上，並將閾值推高至所有其他片段以上。此損失函數包含兩項：第一項將正確片段的分數推高至閾值及錯誤片段之上；第二項將閾值推高至錯誤片段的分數之上。沒有答案的欄位只會套用第二項，從而教導模型返回空白清單。

我們以多種片段擷取任務進行訓練，包括命名實體識別、PII 偵測及擷取式問答。我們讓欄位描述由簡短標籤到詳細指示各有不同，使模型學會遵循請求，而不是死記一組固定的標籤。

Locate 教導模型一項結構上截然不同的任務，而我們希望在加入這項任務的同時，不會失去模型原本擅長的能力。將 locate 適配器合併至骨幹模型，會令決策請求的表現有所退步。為了減輕這情況，我們正在進行多項研究，例如使用更多來自先前階段的重播數據，以及加入輔助目標，使模型對決策請求的輸出貼近原始模型。然而，我們發現合併目前仍未能做到無損，因此我們讓適配器保持不合併，只在處理 locate 請求時才啟用。

評估

我們以 Hugging Face Decision Index、Vals AI 的 ClaimBench 及 Artificial Analysis Decision Index 的外部基準測試評估 Decider v1.3 和 Decider Flash v1.3。

在這些評估中，我們的模型均展現出強勁表現。儘管這些排行榜包含非公開任務，但仍可能透過重複提交，以及根據排行榜回饋反覆調校而被刷分。為補足這些排行榜，我們以一套內部評估組合來評估模型，當中結合非公開的生產環境任務，以及取自公開非基準測試數據集的保留評估。這些評估為公開基準測試以外的泛化能力提供額外檢驗，幫助我們區分廣泛的改進與只針對熟悉評估組合的增益。

我們在內部建立了一套包含超過 200 項任務的測試集，涵蓋多個領域，任務類型包括分類、評分、重新排序和實體擷取。為如實評估 Decider 在真實環境中的表現，所有評估均以零樣本方式進行，不作任何針對特定任務的微調，讓我們清楚了解模型需要改進的地方。

查詢分類

在 Perplexity，我們使用多頭分類系統處理每個用戶查詢。每個查詢首先會經過一個作為特徵擷取器的嵌入模型，然後將所得的嵌入輸入多個獨立的分類頭，當中包括二元分類器和多標籤分類器。例如，其中一個分類頭會判斷用戶查詢是否應觸發網上搜尋。

在 63 項由前沿 LLM 獨立重新標記參考答案的分類任務中，Decider v1.3 的平均準確率達到 91.6%，比我們的正式環境分類器高出 6.54 個百分點。Decider Flash v1.3 同樣勝過正式環境基準，而 Decider v1.3 則勝過 Jev 1.14。

放大

特定領域分類

我們從公開數據集中整合出一套特定領域評估集，用於評估決策模型在七個領域的分類表現：聲明驗證（6 項任務）、醫療保健（7 項）、網絡安全（8 項）、程式設計（16 項）、政府（7 項）、法律（9 項）及金融（9 項）。

例如「判斷一個 Python 程式的時間複雜度」，或「根據年度財務報告，判斷一間公司的非限制性現金能否支付未來十二個月內到期的債務本金」。Decider v1.3 在全部七個領域均處於領先，領先 Jev 1.14 的幅度在金融領域最多達 12.9 個百分點，在法律領域則達 9.3 個百分點。Decider Flash v1.3 在金融、程式設計和法律領域落後於 Jev 1.14，在其他領域則表現相若。

放大

檢索與重新排序

搜尋是 Perplexity 的核心。我們維護一套廣泛的檢索任務，用於評估模型的重新排序效能。在每項任務中，我們首先使用一組嵌入模型，從每個語料庫中檢索前 50 個候選文件，然後使用 Decider 為這些候選文件重新排序，並將其效能與強大的重新排序基準模型 Qwen3-Reranker-8B 比較。

我們在零樣本、逐點（pointwise）的設定下評估 Decider，使用模型直接為每個查詢與文件組合獨立評分，並按相關性為文件排序。在 72 項檢索任務中，Decider v1.3 的平均 nDCG@10 達到 83.99，比 Qwen3-Reranker-8B 高出 1.81 分，比 Jev 1.14 高出 2.24 分。

在 BEIR 基準上，兩款模型的 nDCG@10 分別比 Qwen3-Reranker-8B 高出 8.78 和 7.05。與 Jev 1.14 相比，Decider v1.3 高出 1.33 分，而 Flash 版本則低 0.4 分。

放大

多語言分類

為評估決策模型在英語以外的表現，我們整合了一個多語言分類基準，包含來自 8 個公開數據集的 19 項特定語言任務，共有 46,484 個範例，涵蓋八種語言：德語、西班牙語、法語、意大利語、俄語、日語、韓語及中文。此基準涵蓋意圖偵測、主題分類、情緒分析、自然語言推理、轉述偵測、冒犯性語言偵測及語法可接受性。

我們報告每種語言內各項任務的平均準確率，每項任務的權重相同。Decider v1.3 在全部八種語言中均勝過 Jev 1.14，Decider Flash v1.3 則在其中六種語言勝出；Decider v1.3 和 Decider Flash v1.3 的平均任務準確率分別為 88.16% 和 86.50%，而 Jev 1.14 則為 85.41%。

放大

NER、PII 及擷取式問答

我們在 17 項領域外任務上評估 locate 功能，測試其在不同領域、輸入格式（文字、表格、結構化文件）及指示類型（簡短標籤、問題及詳細描述）下的擷取能力。領域涵蓋維基百科、科學論文、網絡威脅報告、技術支援、私隱政策、履歷及法律合約。請求範圍由「人物」或「電郵地址」等簡短標籤名稱，到有關表格或支援工單的問題，以至用於結構化擷取的詳細欄位描述，例如保密協議（NDA）的訂約方或發票上的總額。

我們使用精確片段 F1 評估 NER 和 PII，此指標要求預測片段與參考邊界完全吻合。抽取式問答（QA）使用字元級 F1，對重疊的答案文字給予部分分數；結構化抽取則使用欄位準確率，即正確抽取欄位的比例。至於履歷解析，我們取 NER 和 PII 精確片段 F1 分數的平均值。

我們將自家模型與不同規模的通用擷取模型進行比較：GLiNER large v2.5（0.5B）、Liquid d1（2B）及 Cloudflare 的 Clairic（未公開）。Decider v1.3 的平均得分達到 69.0（採用每項任務的主要指標），Decider Flash v1.3 則為 63.6，而 Liquid d1、Clairic 和 GLiNER large v2.5 分別為 43.3、41.5 和 33.6。兩款 Decider 模型在每個類別中均處於領先。

放大

圖像分類

Decider 自 v1 起已原生支援視覺任務。為評估其在文字以外的表現，我們整合了一套包含五項任務的基準測試集，特別著重於文件分類，包括發票、信件及履歷。這套測試集亦涵蓋衛星圖像分類、紋理分類、寵物品種分類及動物計數。

Decider v1.3 在五項視覺任務中的平均準確率達到 76.99%，比 Jev 1.14 高出 1.47 個百分點。Decider Flash v1.3 的準確率為 72.77%，展現出較小型模型的視覺分類能力。

放大

現實世界中的決策請求

我們從 Perplexity Decision API 推出後首 18 天內收到的請求中，抽取了一百萬個已去重複並已遮蔽 PII 的請求作為樣本。由於每個請求可就同一狀態包含多個問題，此樣本共有 2,318,887 個獨立問題。所有請求均在用戶明確准許下納入研究。

正式環境中的請求不會附帶真實標籤，因此我們使用前沿 LLM 評審模型生成參考答案，並衡量每個模型與這些答案的一致程度。我們亦將請求分為 10 個任務類別，包括資訊擷取、領域分類、情緒分析、意圖與路由、相關性排序、內容審核、品質與合規審查、實體配對、業務分析，以及「其他」類別。這個細分結果顯示了效能在不同真實使用情境中的差異。

任務分佈並不平均：資訊擷取佔 425,402 個問題，領域分類佔 409,564 個，情緒分析佔 344,158 個。這三個類別合共佔抽樣問題的 50.8%。

Decider v1.3 與評審模型的一致率最高，達到 93.98%，而 Decider v1.2 和 Jev 1.14 分別為 93.68% 和 93.35%。Decider v1.3 與 Jev 1.14 在領域分類和情緒分析上表現相近，差距分別為 0.34 和 0.07 個百分點。Jev 在相關性排序上領先 0.69 分，而 Decider v1.3 則在資訊擷取（樣本中最常見的任務）上領先 0.93 分，在意圖與路由上領先 1.21 分。

放大

下圖比較了執行同一批一百萬個正式環境請求的報告成本。每個請求可包含多個問題，因此這裏的單位是請求，而非個別問題。

放大

穩健性

我們以 372 道多項選擇題評估標籤敏感度，每個模型發出 4,788 個請求。我們在保留每個問題原意的前提下，重新排列選項、將標籤重新分配給答案文字，以及重新命名標籤，然後檢查模型的語義答案是否改變。翻轉率越低，代表穩定性越高。

在每種轉換下，Decider v1.3 僅在 0.27% 的問題上改變答案，而 Jev 1.14 則為 2.69–4.84%。我們亦重複輸入相同內容，以衡量服務過程中的變異：Decider v1.3 沒有出現任何變化，而 Jev 1.14 則在 1.88% 的問題上改變了答案。

放大

我們如何使用 Decider

Decider 專為需要快速、結構化決策的工作流程而設。在本節中，我們會探討如何善用它，為我們的工作方式帶來實質影響。以下是一些突出的例子。

自我改進的安全規則

在內部，我們已在使用 Decider 改善我們的安全政策。

我們會記錄 AI 代理程式的活動，並執行一系列基於規則的檢查，以找出任何有問題的行為。採用基於規則的方法，意味著我們可以即時監察 AI 代理程式，而增加的延遲微乎其微。在離線環境中，我們使用 Decider 檢視這些已記錄的 AI 代理程式日誌樣本。如果沒有標記任何有問題的行為，Decider 會檢查是否有規則遺漏的情況；如果觸發了警報，Decider 則會檢查這是否屬於誤報。無論哪種情況，凡是規則集出錯的記錄都會交由 AI 代理程式分流處理，並提出規則修正建議，再由安全團隊成員審批。

在一天內，Decider 讀取了 7,000 個 AI 代理程式工作階段中的 10 億個 token，並找出導致 14 項規則修正的缺陷，其中 6 項在兩天內獲批並上線。在一星期的日誌上重播後，這些修正使我們最繁忙規則的觸發量減少了 52%，而擴闊後的規則則多捕捉了約 40% 需要調查的合法操作。

放大

監察強化學習推演

當我們以強化學習對模型進行後訓練時，終端獎勵等匯總指標並不能解釋某次推演（執行任務的單次嘗試）為何成功或失敗。推演可能因工具服務或沙箱故障而被不公平地扣減獎勵，也可能因評估器忽略了缺乏根據的陳述（例如沒有任何工具傳回的捏造數值）而獲得不應得的獎勵。

我們使用 Decider 監察推演中的這些情況。首先由程式碼找出推演中值得仔細檢查的部分：失敗的工具呼叫及其前後的推理、無錯誤執行的程式碼，或最終答案。然後，Decider 會就每個部分回答多項選擇題，例如某個步驟中是甚麼出錯（工具服務、外部網站、沙箱、harness，還是 AI 代理程式本身的程式碼），以及 AI 代理程式是否正確解讀結果。我們會將有關某個部分的所有問題合併為單一請求，並儲存機率而非判定結果，這樣日後無需再次查詢 Decider 便可調整閾值。監察器只負責觀察和診斷：它從不更改獎勵，亦不會中止任何運行。

放大

網頁品質篩選

在爬取網頁以建立索引並提供給用戶時，許多網頁的品質太低，毫無用處。這包括反機械人攔截頁、CAPTCHA 和錯誤頁面，以及雖然正確載入但不含任何有用資訊的網頁，例如垃圾內容、SEO 填充內容或純導覽頁面。我們需要識別這些低品質網頁，並將其從索引中剔除。

透過 Decider，我們可以在爬取網頁的同時判斷網頁質素。在同一次前向傳遞中，我們還會執行一系列其他分類任務，例如識別內容所屬的領域和目標受眾，以及內容是否包含有害、違法或可識別個人身份的資訊。與使用 LLM 評判相比，Decider 明顯更快、更便宜。

放大

除了這些內部用途外，Decider 亦適用於以下工作流程。

視覺問答

由於 Decider 能讀取圖像，它亦可用作視覺檢查工具，審查網頁或應用程式的樣式變更並找出問題。它可以在變更推出前檢查網頁截圖，找出被截斷的文字、重疊的元素及損壞的版面，亦可標記設計可能誤導讀者或違反品牌指引的圖表。

放大

瀏覽器導航

AI 代理程式可以使用 Decider 處理大型任務中的細小決策。瀏覽器 AI 代理程式可以在每個步驟傳送螢幕截圖，並取得有關網頁狀態以及每個可能操作預期結果的詳細資訊。

放大

規劃研究任務

用戶問題的複雜程度可以差異很大，找出答案所需的搜尋深度亦然。Decider 可在搜尋開始前估算這一點，從而減少在簡單問題上耗用的資源。

放大

開始使用

Decider 會傳回機率。合適的決策閾值取決於應用場景。標籤頻率以及偽陽性與偽陰性的相對成本，會因使用情境而異。因此，我們建議用戶以一個小型、具代表性且已標記的開發集來調整閾值，而不是假設固定的分界值能在所有任務上同樣有效。

對於需要細緻判斷、詳盡評分準則，以及出錯代價高昂的工作流程，我們建議使用 Decider v1.3。如果是以延遲和成本為主要限制的大量路由、標註和篩選工作，請選擇 Decider Flash v1.3。請以您工作負載中具代表性的範例評估兩款模型，再選擇符合您品質、延遲和預算要求的模型。

兩款模型均以 Apache 授權在 Hugging Face 提供可下載權重，亦可透過 OpenRouter 及 Perplexity Decisions API 使用。

引用

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}