Perplexity Decider v1.3 新增 Locate:分類之外,如何擷取原文與核對位置?

Decider v1.3 新增 Locate 原文擷取,回傳片段、字元位置與分數。本文整理文字輸入限制、分類與擷取差異、版本遷移、校準門檻及部署取捨,協助判斷是否適合客服分流和證據整理。

Share
Hugging Face 原平台上 Perplexity pplx-decider-v1.3 模型卡的官方分享預覽圖
Perplexity 在 Hugging Face 提供 Decider v1.3 模型卡與部署說明。圖片來源:Perplexity/Hugging Face。 圖片來源:官方原文。

客服分流常需要兩個結果:這張單該交給誰,以及原文到底哪一句提到錯誤代碼。只有分類標籤,接手的人還是得重讀整段內容。只有摘要,又可能難以核對文字出處。

Perplexity 在 2026 年 11 月 12 日透過開發者官方帳號公布 Decider 與 Flash 的 v1.3 更新,並加入 Locate 原文片段擷取能力。這是既有決策模型的新版,重點不只是再次提供分類介面。

Decider v1.3 的官方模型卡說明,Locate 會回傳符合問題的原文字串、起迄字元位置和分數。程式可以把結果對回輸入,讓分類後的證據有明確落點。

但 Locate 目前要求文字輸入,不接受圖片,而且同一次請求最多 128 個擷取問題。模型其他分類能力可以看圖,不代表擷取模式就能替圖片完成文字辨識。

我會先用需要保留原文依據的低風險流程試跑,例如整理客服錯誤代碼。測試時要同時核對片段是否正確、是否漏找,以及換版本後原本的分類門檻是否仍合適。

接下來先看 Locate 的輸出代表什麼,再把它與分類、效能和部署限制放進同一個工作流程評估。

Locate 把答案指向原文,不替原文重新寫一句話

Locate 的任務是找出輸入文字中的片段,讓應用程式能核對出處。

例如,一張客服單寫著更換金鑰後一直收到錯誤代碼,分類模型可以回答該交給技術支援。Locate 則可以把錯誤代碼的原始字串找出來。前者回答要如何處理,後者提供回查文字的位置,兩者並不互相取代。

官方定義的片段包含起點、終點、文字與分數。終點不包含在片段裡,程式按照這個範圍切出輸入內容,應該得到完全相同的字串。這使介面能把片段標亮,也方便接手人員直接回到原句確認上下文。

這個保證談的是位置和原文一致,不代表選中的片段一定符合任務。若問題是找合約簽署人,模型可能擷取到文件提及的另一個人名。文字確實出現在原文中,和它是否回答對問題,是兩項不同的驗收。

因此測試不能只確認回傳格式合法,還要準備正確片段,分開計算多抓、漏抓與邊界偏移。相同名字出現多次時,也應檢查位置是否指向正確段落。這些是依介面提出的測試建議,並非本刊宣稱已驗證的產品成效。

沒有符合內容時,官方規格允許回傳空片段陣列。應用程式需要保留這種狀態,而非硬把空結果轉成一段猜測。對需要留下證據的流程來說,能清楚表示沒有找到,往往比交付貌似完整的摘要更實用。

資料顯示方式也會影響位置的實用性。若前處理先移除空白或合併段落,擷取位置應對應送進模型的那個版本,而不是另一份排版後文件。團隊需要保留輸入原文及版本,才能讓標亮位置和接手者看到的內容一致。

對只有一個錯誤代碼的句子,這項檢查很容易。若同一代碼在引用的舊紀錄和目前描述中都出現,就需要更精確的問題文字與上下文。單看字串是否相同,無法確定擷取到的是本次故障證據。

原文抽取還有完整與必要的取捨。只取一個詞可能失去否定語氣,抓下整段又會增加閱讀負擔。可以先請領域人員標出真正需要交接的最小片段,再比較模型是否維持足夠意思,避免把越短或越長都當成比較好。

這些驗收條件也應保留在改版測試中。若新版本擷取率提高,卻經常把過去事件當成當前事件,就不能只用找到更多片段宣稱品質提升。

這種位置資訊適合建立可追溯流程,但片段是否符合問題,仍需要另外驗證。

Hugging Face 原平台上 Perplexity pplx-decider-v1.3 模型卡的官方分享預覽圖
Perplexity 在 Hugging Face 提供 Decider v1.3 模型卡與部署說明。圖片來源:Perplexity/Hugging Face。 圖片來源:官方原文。
Perplexity 官方 Decider v1.3 更新介紹。 來源:官方原文。

分類和擷取可以同時要求,運算方式仍不同

同一份狀態資料可以交給分類問題,也可以交給 Locate 擷取問題。

分類問題仍可要求真假判斷、選項選擇或有序評分。Locate 新增的則是從狀態文字中定位內容,問題名稱可以作為預設標籤,也可以用指示文字改成更具體的擷取要求,例如只找簽署合約的人,而非所有人名。

兩種問題雖能放在同一份請求中,實際運算不是完全共用。官方說明,擷取與決策需要分開執行模型運算,混合請求因此可能比只做一種任務增加延遲。把它拆成兩次程式呼叫,也不會消除本來就需要的運算步驟。

Locate 還有自己的限制:狀態必須是非空文字,不接受圖片,每次最多一百二十八個問題。這與分類模式能處理圖片的能力要分開讀。若手上是掃描文件,仍需要先選擇合適的文字辨識或文件解析步驟,不能把 Locate 當成直接讀圖工具。

多個擷取問題會一起讀取共享狀態,所以可能相互影響。這與預設分類模式中各題獨立作答不同。若新增一個擷取欄位後,原有欄位的結果有所變動,測試應記下整組問題,而不只保留單一欄位的輸出。

以客服流程來說,可以先衡量每張單是否都需要所有欄位。若大多數單只需部門標籤,全部都加上姓名、代碼和產品型號擷取,未必能改善處理效率。應依接手工作真正需要的內容設計問題,避免把功能數量當成完成度。

設計流程時應把兩種輸出與運算成本分開記錄,才知道合併請求實際省下了什麼。

v1.3 遷移要重建格式,也要重新校準門檻

新檢查點使用自己的請求建構方式,不能假設舊版提示格式可原封不動沿用。

版本遷移首先涉及請求格式。官方模型卡提醒,新檢查點需要使用 v1.3 的建構方式,不能直接沿用 v1.1 或 v1.2 的提示建構器。只更換模型名稱卻保留舊格式,可能得不到可比較的結果。

另一個差異是機率校準,也就是比較模型分數和實際答對比例是否相符。模型會套用在保留資料上估計的溫度參數,調整選項分布,但官方也明確指出,單一溫度不會適合每一種應用流量。

假設舊系統將高於某個分數的客服單自動分流,換版後不能因分數格式相同,就繼續使用同一門檻。應拿已人工標記的歷史單對照,查看高分錯誤、低分正確和人工接手比例,再決定新的採用規則。

這個過程也要區分分類分數與擷取片段分數。兩種輸出服務不同任務,未經資料驗證,不宜假設相同數值代表同等可信度。比較門檻時,應清楚記下所用欄位、問題文字與測試資料日期。

若原本工作是排序候選內容,官方另外提供讀取原始分數的方法,避免機率接近上限時大量並列。這反映同一模型也可能有不同的讀取方式,選型時要先決定需要的是排序、固定標籤,還是可以採取動作的門檻。

保留一份舊版對照資料,再根據新版的錯誤分布調整採用門檻,才能避免無聲改變工作結果。

自架的記憶體與加速模式,會影響功能選擇

本篇的具體部署限制來自 27B 版官方模型卡,不套用到所有大小或代管供應商。

二百七十億參數等名稱,常讓人只注意模型大小。實際部署還要看資料格式、權重精度和工作記憶體。本篇模型卡的二百七十億級檢查點,以 BF16、也就是用十六位元數值保存權重的精度載入時,光權重約需四十九 GiB,另須預留運算空間,不能當成一般輕量筆電工具。

模型卡標示 Apache 2.0 授權,但下載權限與部署環境仍要另外確認。授權描述如何使用程式與權重,不等於每個代管入口都已提供相同功能,也不代表任意聊天完成介面都能正確執行這種決策檢查點。

預設的 separate 模式讓每個分類問題各自讀取狀態,所以增加、刪除或調整其他問題的順序,不應改變該題的輸入關係。它的代價是長狀態可能被重讀多次,當問題很多時,運算量也會跟著增加。

isolated 模式則用不同安排共讀狀態,減少重複工作,但官方樣本中約有百分之一點五至二點二的最高選項與預設模式不同。這是可觀察的行為差異,不能只用較便宜或較快決定替換。

加速設定同樣有功能取捨。官方目前說明 fast=True 會停用 Locate,因此不能將分類模式的加速成績直接承諾給原文擷取流程。部署決策應先確認必要功能,再用整張工作單衡量延遲,而非把不同模式最好的數字拼在一起。

長文件還要預留問題本身的空間。官方擷取模式預設最多三萬二千七百六十八個 token,若單一問題加狀態放不下,會回報長度錯誤,而非保證替你截成仍然完整的證據。應先決定文件切分與跨段核對方式,保留每段對應的原始位置。

功能先跑對,再選擇能接受差異的加速方式,比只追求每秒請求數更實際。

Decider v1.3 與 Locate 常見問題

最容易混淆的地方,是原文位置、分類機率,以及圖片支援的適用範圍。

Locate 會幫我改寫摘要嗎?

不會。它定位輸入中的原文片段,輸出文字應可用位置切回原文。若需要跨段摘要,仍是另一種生成任務。即使摘要合理,也不能拿來替代這裡的逐字證據。

同一張圖片能先分類,再擷取文字嗎?

分類模式的圖片支援,不會讓 Locate 自動接受圖片。官方列出的 Locate 輸入是文字且不含圖片。若前面另接文字辨識,必須一起驗證辨識結果與後續擷取,錯誤可能發生在不同步驟。

回傳分數很高,就能直接自動處理嗎?

不能單憑高分判斷。應以自己的標記資料檢查門檻,並依錯誤成本決定是否交給人工。涉及付款、對外通知或資料刪除時,分類結果也不等於取得執行許可。

官方影片能證明所有功能已在我的入口開放嗎?

影片展示 Locate 的原文擷取概念,但實際可用能力仍取決於模型版本和供應商介面。自架模型卡、Perplexity 代管服務與其他平台的參數和開放進度,應分別核對。

確認每種問題的輸入限制與驗證方式後,才適合接到正式資料流程。

從可人工核對的抽取工作開始

適合先試的工作,是原文清楚、標籤固定、錯誤可以回頭查出的分類與擷取。

可以先準備一批已有部門標籤與正確原文位置的客服單,保留沒有代碼、多個代碼及內容矛盾的情況。先跑通分類與擷取各自的結果,再接到同一個操作畫面,讓人能看見為什麼被送到那個部門。

驗收時應分開記錄漏找、多找、部門誤判與整段等待時間。如果接手人員仍須重看全文,擷取功能可能只是增加欄位。若正確位置能縮短查證,才形成可衡量的改善。

這次更新的價值在於讓固定決策旁邊多了可追溯的文字位置。它不會自動完成所有文件理解,也不替團隊決定哪些結果可以無人覆核。

只有在擷取品質、分類門檻與整段延遲都符合需求時,這次更新才算改善了你的流程。

延伸閱讀:Perplexity 推出 Decisions API:文字與圖片進來,選項機率出去

延伸閱讀:決策模型怎麼做 LLM 評測?Hamel Husain 教你調門檻、比成本、讀分數

原始資料來源