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 的靈感來自 TypeSafe AI 的 System One Model Jev。它支援具有序或無序標籤的二元與多類別分類，並傳回機率，讓應用程式可用來對輸入進行分類、路由、排序與評估。

兩款 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|> 嵌入。我們只訓練這個新的嵌入、片段預測頭與 LoRA 轉接器，同時凍結原始骨幹模型的權重與決策頭。每個請求的欄位都會有各自的 <|locate|> token。

片段預測頭會結合 <|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 的平均任務準確率為 88.16%，Decider Flash v1.3 為 86.50%，Jev 1.14 則為 85.41%。

放大

NER、PII 與擷取式問答

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

我們使用精確片段 F1 評估 NER 與 PII，這項指標要求預測片段的邊界與參考答案完全一致。抽取式問答使用字元層級 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 為 43.3、Clairic 為 41.5，GLiNER large v2.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 為 93.68%，Jev 1.14 則為 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% 值得調查的合法動作。

放大

監控 RL 推演

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

我們使用 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}
}