跳至主要內容
HK Learn AI
AI 資料分析

Jev confidence 教學:分清機率、校準與門檻,設計人手覆核

用留出資料校準 Jev 門檻:分清 probability、confidence、真實標籤、Brier score、coverage 與接受個案錯誤率,附標明非實測的計算例子。

HK Learn AI 編輯部標誌

HK Learn AI 編輯部

編輯部

發佈於 2026年9月20日

最後審閱:2026年9月20日

分享這篇文章
本頁內容
Jev 資訊圖:Jev confidence 教學:分清機率、校準與門檻,設計人手覆核;具體情境與概念分工示意

難度

中階

所需時間

約 30–60 分鐘(含練習與自行驗證)

你需要準備

TypeSafe 官方文件

開始之前

  • 能閱讀 JSON 與基本流程規則
  • 先用教學或去識別資料,保留人手回退

Jev 的 confidence 是從答案機率分佈導出的統計,不是「這一題有相同百分比一定答對」的保證。要把它變成工作流門檻,需要有標籤的資料、留出測試,以及對錯誤後果的明確定義。本篇提供一套可執行的評估思路,不提供未經驗證的通用安全門檻。

資料核對:2026 年 9 月 21 日。本文依官方文件研究;原創情境、門檻及計算例子均有標明。本站未以 Jev API 執行性能或廣東話準確率測試。模型、價格與 early access 狀態可能更新。

分清 probability、confidence 與 correctness

概念代表甚麼不能代替甚麼
probabilities模型在這題各候選答案之間分配的機率外部事實或人手真值。
confidenceChoice/Score 的分佈集中程度所衍生的統計通用的實際準確率或授權。
correctness按預先定義的標籤,這次結果是否正確不能單靠模型自評判定。
calibration一組預測的機率與實際發生比例是否相符不表示每一個高機率個案都正確。

Noul 只有 noul 值,沒有另一個 confidence。不要把 Choice 的 confidence 欄位、最高選項機率及 Noul 數值放入同一個共用門檻,因為它們不是同一個量。更改選項數量、題目措辭或模型版本後,數值的意義也需要重新檢查。

核對來源:Confidence、TypeSafe HTTP API reference、Jev 1.13 jaggedness — 已知能力弱點。

用有標籤資料檢查模型機率與信心,另以系統權限限制行動
把「模型很肯定」和「系統准許執行」分成不同決策。(HKLearnAI 生成式資訊圖;概念示意,並非產品畫面或測試結果。)

先有測試設計,才有門檻

以付款支援分類為例,先寫好哪種工單算 billing,將歷史工單按完整對話分組,再拆成設計、調整及留出資料。由人手標註主要意圖,模糊個案保留裁決紀錄。如果同一張工單的改寫同時出現在設計集及留出集,結果很容易過度樂觀。

不要只收集單一句子和容易的典型例子。要包括否定、反諷、引述客服舊回覆、中英夾雜、兩種意圖、資訊缺漏,以及看似高信心但最終判錯的個案。最後一類尤其值得加入下一版設計集,但不能反覆用同一留出集挑門檻。

校準怎樣讀?用一個計算例子

假設一批教學用、非 Jev 實測的 Noul 預測落在 0.8–0.9,平均預測機率為 0.85;如果當中人手標為「是」的比例只有 0.65,這批資料呈現過度自信。每個區間都要列出樣本數,因為十個例子和一千個例子的穩定程度不同。

二元預測可計算 Brier score:每筆以 (p−y)² 計,再取平均;y 是 0 或 1。以下四筆純示例 p=[0.9, 0.8, 0.2, 0.1],y=[1, 0, 0, 0],平均為 0.175。它用來量度機率預測的整體誤差,數值較低較好;不要把它直接稱為準確率。

const predictions = [0.9, 0.8, 0.2, 0.1];
const labels = [1, 0, 0, 0];
const brier = predictions.reduce((sum, p, i) =>
  sum + (p - labels[i]) ** 2, 0) / labels.length;
console.log(brier); // 約 0.175;這是計算示例,不是模型測試。

門檻應同時看 coverage 和接受個案錯誤率

你可以把低把握個案交人手,令自動處理部分更可靠,但代價是 coverage 下降。coverage 是系統接受自動處理的數量除以所有待分類數量;接受個案錯誤率則只看已接受的那一批。後者不能拿來冒充整體系統準確率。

假設門檻接受數/總數接受個案錯誤數coverage接受個案錯誤率
示例 A:較寬鬆800/1,0004080%5%
示例 B:較嚴格500/1,000550%1%

上表為原創算術示例,並非 Jev 跑分。它只說明取捨:B 每千筆多交三百筆給人手。你仍要檢查錯的是哪一類,以及人工佇列是否有能力承接。當某門檻沒有接受任何個案時,錯誤率應記為「不適用」,不能寫成 0% 並宣稱完美。

評估模型要同時檢查標籤、設定、端到端延遲及總成本
門檻不是孤立數字;覆核量與成本同樣影響是否能上線。(HKLearnAI 生成式資訊圖;概念示意,並非產品畫面或測試結果。)

從數值到行動:分類與批准分兩層

第一層根據已驗證門檻決定可否自動送去某個內部佇列。第二層則根據身份、角色、付款記錄及批准規則決定可否執行退款。即使第一層的分類非常肯定,第二層也不能省略。若不同類別的錯誤後果不同,應各自設計驗收標準,而非全系統共用一個 0.9。

多題判斷亦不應直接相乘後稱為整個流程正確的機率,除非你有足夠理由支持相應的統計假設。題目可能依賴同一段含糊資料,錯誤會相關;一次請求中平行運行,不代表統計獨立。

核對來源:Confidence-based routing、Jev 1.13 jaggedness — 已知能力弱點。

上線後記錄哪些變化?

  • 記錄門檻使用哪個欄位、對應哪個模型和題目版本,避免換版本後沿用舊結論。
  • 按語言、渠道及類別抽查;英文總體表現可能掩蓋廣東話的錯誤。
  • 觀察人工覆核率突然上升或下降,並檢查是否資料格式改變。
  • 保留被接受卻出錯的個案,以及模型不確定但人手很容易決定的個案。
  • 用新的時間區間重新評估,不只重跑同一批熟悉資料。

下一步閱讀

資料來源與引用

我們附上第一手及官方來源,方便你逐一核實。

  1. 1.Confidence — TypeSafe AI
  2. 2.Confidence-based routing — TypeSafe AI
  3. 3.TypeSafe HTTP API reference — TypeSafe AI
  4. 4.Jev 1.13 jaggedness — 已知能力弱點 — TypeSafe AI
  5. 5.Models — Jev 1.13、定價與限制 — TypeSafe AI

常見問題

confidence 0.9 就代表九成答對嗎?

不能直接這樣解讀。它是分佈導出的統計,必須在相應模型、題目與資料上驗證。

有通用的安全門檻嗎?

沒有本篇能驗證的通用數字。需要按類別、錯誤後果及人工負荷,以獨立資料調整與驗收。

本文遵循我們的 編輯準則.

HK Learn AI 編輯部標誌

關於作者

HK Learn AI 編輯部

HK Learn AI 編輯部負責研究、查證同編寫每一篇內容,並引用官方及第一手來源。