uqlm：把 LLM 幻覺偵測拆成可組合的評分器
[JMLR 2026] "UQLM: A Python Package for Uncertainty Quantification in Large Language Models"
秒懂
- 它是什麼？
- CVS Health 開源的 Python 套件，用不確定性量化替 LLM 輸出打 0 到 1 的信心分數。它解決的不是「模型答不答對」，而是「這次回答值不值得信」。
- 適合誰用？
- uqlm 適合已經在用 LangChain、而且能接受「多生成幾次再比對」這種成本結構的團隊，尤其是需要對外解釋信心分數來源的場景。不適合的是：要求單次呼叫、低延遲的即時應用，或是無法取得 token 機率、又不想付出多次生成成本的推論環境。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的問題不是準確率，而是可信度
多數 LLM 評測工具回答的是「這個模型在測試集上表現如何」。uqlm 問的是另一個問題：面對某一個具體回答，我們能不能給出一個量化訊號，說明它有多可能是錯的。README 把這件事定義得很清楚，每個 scorer 回傳 0 到 1 的信心分數，分數越高代表出錯或幻覺的可能性越低。
這個定位決定了它的使用場景。它適合放在推論路徑上，對每一次生成做即時或準即時的品質判斷，而不是離線跑一份報告。也因為如此，它的設計重心放在「多種可替換的評分方法」，而不是單一模型或單一資料集。目標讀者是需要在產品裡加一層防護的工程團隊，例如客服回覆、摘要生成、或是任何會把模型輸出直接送到使用者面前的流程。
要注意的是，uqlm 產出的是相對訊號，不是真值標籤。分數低不代表一定錯，分數高也不保證正確，它只是一個排序依據。
五類評分器各自用什麼訊號
README 把 scorer 分成五類，分類的依據其實是「訊號從哪裡來」。
黑箱評分器走一致性路線。同一個 prompt 生成多次，比較這些回應彼此是否一致，用語意熵、語意集合數量、非矛盾機率等指標換算成信心分數。它不需要模型內部狀態，任何 LLM 都能用。代價寫在 README 的對照表裡：延遲中到高，成本高，因為每一次評分都牽涉多次生成與多次比較。
白箱評分器走 token 機率路線。它讀取模型本來就會回傳的 token 機率，因此額外延遲極小、沒有額外 LLM 呼叫成本。限制也很硬：必須拿得到 token 機率。走 API 的封閉模型通常不給，這條路就斷了。README 另外註明，多生成版本的白箱評分器不適用這個低成本描述，它們的成本和延遲都會上升。
LLM-as-a-Judge 讓另一個模型來當評審，延遲低到中等，成本取決於評審數量，任何 LLM 都能當評審。集成評分器把上面幾種組合起來，README 說它對初學者友善，也留了調校空間給進階使用者。長文本評分器則把粒度切到 claim 層級，延遲高到極高。
這張對照表是整個專案最實用的部分。它沒有宣稱哪一種最好，而是把延遲、成本、相容性攤開，讓你自己選。
安裝與最小可用範例
安裝只有一行：
pip install uqlm
README 標示需要 Python 3.10 以上。範例走 LangChain 介面，先建立一個 Chat Model，再交給 BlackBoxUQ：
from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4o-mini")
from uqlm import BlackBoxUQ bbuq = BlackBoxUQ(llm=llm, scorers=["semantic_negentropy"], use_best=True)
results = await bbuq.generate_and_score(prompts=prompts, num_responses=5) results.to_df()
這裡有幾個關鍵參數值得注意。scorers 接受一個清單，代表你可以同時掛多個評分器。num_responses=5 是黑箱路線的成本來源，生成五次才有東西可比。use_best=True 啟用 mitigation，README 的說明是選出「不確定性最小」的那個回應。
generate_and_score 是 async 方法，範例裡用 await 呼叫，所以你的呼叫端必須在事件迴圈裡。輸出用 to_df() 轉成 DataFrame，方便接後續處理。
README 明確指出，範例雖然用 ChatOpenAI，但任何 LangChain Chat Model 都可以替換。這一點對已經在用 LangChain 的團隊幾乎沒有遷移成本。
黑箱路線的成本是乘上去的
黑箱評分器的機制決定了它的成本結構。num_responses=5 意味著同一個 prompt 要生成五次，再加上語意比對的開銷。如果你的應用每秒處理上千個請求，這個倍數會直接反映在帳單和延遲上。
README 的對照表沒有迴避這件事，黑箱那一列寫的是「延遲中到高、成本高」。長文本評分器更進一步，因為它要在 claim 層級做多次生成與比對，表格裡標的是「延遲高到極高」。
另一個容易被忽略的點是 use_best=True。它同時做偵測和緩解，選出信心分數最好的回應，但這也表示你回傳給使用者的內容已經不是原始生成結果。對需要保留完整生成軌跡、或需要對同一份輸出做審計的場景，這個行為要事先想清楚。
還有一個邊界：黑箱方法假設多次生成之間有足夠的差異可以比較。如果溫度設得極低，五次生成幾乎一樣，一致性訊號就會失去解析度。README 沒有針對 temperature 給出建議值，這一項需要自己驗證。
白箱便宜，但前提是你拿得到 token 機率
白箱評分器的吸引力在於成本。token 機率本來就跟著回應一起回傳，所以額外延遲極小、沒有額外呼叫成本。對延遲敏感的線上服務來說，這是唯一不需要重新計算成本模型的路線。
代價是相容性。README 的對照表在這一列標示「受限，需要存取 token 機率」。實務上這意味著自架模型、或是提供 logprobs 的 API 才有機會用。走一般封閉 API 的團隊，這條路通常直接出局。
README 另外加了一條註腳：多生成版本的白箱評分器不適用「延遲極小、成本為零」的描述。也就是說，白箱這個標籤底下其實混了兩種東西，一種是單次生成就能算的，一種還是要多次生成。選 scorer 的時候要看清是哪一種，不能只看分類名稱。
如果你同時想要低成本和通用性，這兩者在 uqlm 的框架裡是互斥的。黑箱給你通用性但貴，白箱給你便宜但綁模型。
什麼情況下它會是錯的工具
第一種情況是嚴格的單次呼叫架構。如果你的推論路徑規定一個請求只能觸發一次模型生成，黑箱和長文本評分器都用不了，剩下的選項只有單生成白箱或 LLM-as-a-Judge，而前者需要 token 機率，後者需要額外一次呼叫。三個條件湊不齊，uqlm 就幫不上忙。
第二種情況是把信心分數當成事實判斷。分數是相對訊號，不是正確性標籤。README 對 scorer 的描述是「回傳 0 到 1 的信心分數，分數越高代表出錯或幻覺的可能性越低」，這是機率語言，不是判決。把它直接接到自動封鎖或自動放行的邏輯上，需要先在自己的資料上確認分數分布和實際錯誤率的對應關係。
第三種情況是需要跨模型比較分數。不同 scorer 的校準基準不同，semantic_negentropy 的分數和某個 judge 的分數不能直接放在同一個尺規上比。集成評分器可以組合多個來源，但組合方式本身也需要驗證。
還有一個現實限制：這個專案沒有提供現成的標註資料集或基準分數。README 給的是 API 和範例，閾值要自己定。
和單純用 LLM 當評審的差別
最直覺的替代方案是直接叫一個 LLM 來評分，也就是 uqlm 自己歸類的 LLM-as-a-Judge。兩者的差別在訊號來源。
純評審路線只依賴評審模型的判斷，成本低到中等，任何 LLM 都能當評審，實作也最簡單。但它把整個判斷責任交給另一個模型的內部偏好，你很難解釋為什麼這個回答被打了 0.8。
uqlm 的黑箱路線用的是可計算的量：多次生成之間的語意熵、語意集合數量、非矛盾機率。這些指標有對應的論文（README 引用 Farquhar et al. 2024、Lin et al. 2024、Kuhn et al. 2023 等），計算過程可重現。代價就是前面說的生成次數。
如果你的場景需要對外解釋信心分數怎麼來的，黑箱路線的論述基礎比純評審厚。如果只是想要一個粗略的排序訊號、而且預算緊，純評審更省。uqlm 的集成評分器把兩者放在一起，README 說它對初學者友善、也留了調校空間，但組合之後的延遲和成本同樣是加起來的。
授權、維護與版本節奏
授權是 Apache-2.0，寬鬆授權，允許商用與修改，附帶專利授權條款。實際的合規義務（例如保留聲明檔案）要由你們的法務確認，這裡不做法律判斷。
維護面可以從版本節奏看出一些東西。最近的發布是 v0.6.6（2026-09-03）、v0.6.5（2026-08-13）、v0.6.4（2026-07-26），大約三到四週一個版本。最後一次推送是 2026-09-07。版本號還在 0.x，代表 API 尚未進入穩定承諾階段，升級時要預期介面可能變動。
專案有 JMLR 2026 的發表紀錄，README 另外掛了 TMLR 的 EnsembleUQ 與 LongTextUQ、以及 EMNLP 的 CodeGenUQ，表示這些 scorer 背後有對應的學術工作。這對需要引用方法來源的團隊是加分項，但也意味著新增 scorer 的速度可能跟論文綁在一起。
依賴面上，範例走 LangChain，README 也標示使用 uv 與 Ruff。升級成本主要落在 LangChain 版本相容性和 scorer 介面變動這兩處。建議在 CI 裡固定 uqlm 的版本號，升級時先跑一遍自己的評分結果，確認分數分布沒有位移。
編輯結論
uqlm 適合已經在用 LangChain、而且能接受「多生成幾次再比對」這種成本結構的團隊，尤其是需要對外解釋信心分數來源的場景。不適合的是：要求單次呼叫、低延遲的即時應用，或是無法取得 token 機率、又不想付出多次生成成本的推論環境。採用前先確認三件事：你的模型是否走 LangChain Chat Model 介面、你能否負擔 num_responses 帶來的呼叫倍數、以及你要的評分器屬於哪一類（黑箱、白箱、評審或集成），因為這三件事直接決定延遲與帳單。
社群筆記