本頁內容

難度
中階
所需時間
約 30–60 分鐘(含練習與自行驗證)
你需要準備
TypeSafe 官方文件
開始之前
- 能閱讀 JSON 與基本流程規則
- 先用教學或去識別資料,保留人手回退
Jev 的 confidence 是從答案機率分佈導出的統計,不是「這一題有相同百分比一定答對」的保證。要把它變成工作流門檻,需要有標籤的資料、留出測試,以及對錯誤後果的明確定義。本篇提供一套可執行的評估思路,不提供未經驗證的通用安全門檻。
資料核對:2026 年 9 月 21 日。本文依官方文件研究;原創情境、門檻及計算例子均有標明。本站未以 Jev API 執行性能或廣東話準確率測試。模型、價格與 early access 狀態可能更新。
分清 probability、confidence 與 correctness
| 概念 | 代表甚麼 | 不能代替甚麼 |
|---|---|---|
| probabilities | 模型在這題各候選答案之間分配的機率 | 外部事實或人手真值。 |
| confidence | Choice/Score 的分佈集中程度所衍生的統計 | 通用的實際準確率或授權。 |
| correctness | 按預先定義的標籤,這次結果是否正確 | 不能單靠模型自評判定。 |
| calibration | 一組預測的機率與實際發生比例是否相符 | 不表示每一個高機率個案都正確。 |
Noul 只有 noul 值,沒有另一個 confidence。不要把 Choice 的 confidence 欄位、最高選項機率及 Noul 數值放入同一個共用門檻,因為它們不是同一個量。更改選項數量、題目措辭或模型版本後,數值的意義也需要重新檢查。
核對來源:Confidence、TypeSafe HTTP API reference、Jev 1.13 jaggedness — 已知能力弱點。

先有測試設計,才有門檻
以付款支援分類為例,先寫好哪種工單算 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,000 | 40 | 80% | 5% |
| 示例 B:較嚴格 | 500/1,000 | 5 | 50% | 1% |
上表為原創算術示例,並非 Jev 跑分。它只說明取捨:B 每千筆多交三百筆給人手。你仍要檢查錯的是哪一類,以及人工佇列是否有能力承接。當某門檻沒有接受任何個案時,錯誤率應記為「不適用」,不能寫成 0% 並宣稱完美。

從數值到行動:分類與批准分兩層
第一層根據已驗證門檻決定可否自動送去某個內部佇列。第二層則根據身份、角色、付款記錄及批准規則決定可否執行退款。即使第一層的分類非常肯定,第二層也不能省略。若不同類別的錯誤後果不同,應各自設計驗收標準,而非全系統共用一個 0.9。
多題判斷亦不應直接相乘後稱為整個流程正確的機率,除非你有足夠理由支持相應的統計假設。題目可能依賴同一段含糊資料,錯誤會相關;一次請求中平行運行,不代表統計獨立。
核對來源:Confidence-based routing、Jev 1.13 jaggedness — 已知能力弱點。
上線後記錄哪些變化?
- 記錄門檻使用哪個欄位、對應哪個模型和題目版本,避免換版本後沿用舊結論。
- 按語言、渠道及類別抽查;英文總體表現可能掩蓋廣東話的錯誤。
- 觀察人工覆核率突然上升或下降,並檢查是否資料格式改變。
- 保留被接受卻出錯的個案,以及模型不確定但人手很容易決定的個案。
- 用新的時間區間重新評估,不只重跑同一批熟悉資料。
下一步閱讀
資料來源與引用
我們附上第一手及官方來源,方便你逐一核實。
常見問題
confidence 0.9 就代表九成答對嗎?
不能直接這樣解讀。它是分佈導出的統計,必須在相應模型、題目與資料上驗證。
有通用的安全門檻嗎?
沒有本篇能驗證的通用數字。需要按類別、錯誤後果及人工負荷,以獨立資料調整與驗收。
本文遵循我們的 編輯準則.

關於作者
HK Learn AI 編輯部
HK Learn AI 編輯部負責研究、查證同編寫每一篇內容,並引用官方及第一手來源。
此主題相關文章

Jev benchmark 與價格分析:193.6 倍、444.6 倍點計?成本與限制逐項拆解
閱讀 Jev 官方測試原圖、模型共識標籤與比較設定;核對 US$0.042/百萬輸入 tokens、64k/32k context 及速率限制,附成本試算與公平測試流程。

ChatGPT 做 Excel 財務模型教學:現金流預測、情境分析同公式核對
用一間虛構的香港小型網店做例子,分兩條路線用 ChatGPT 建立 12 個月現金流模型:對話上傳 Excel 用資料分析起草,或用官方 ChatGPT for Excel 增益集直接改工作簿;再用 Excel 內建 What-If 工具做 base、upside、downside 三個情境,最後核對 NPV、IRR 公式。不是投資或稅務意見;資料核對 2026 年 9 月 15 日。

ChatGPT Visualize 完整教學:把 CSV/資料集變成可篩選互動圖表與下鑽分析
以 1949–1960 航空旅客月度資料示範 Visualize:確認帳戶可用性、用 @Visualize 選取 plugin、描述資料與問題、建立年份/月份篩選、摘要卡、趨勢線和可點選明細,再核對筆數、缺失值、單位、合計與極值。附逐張人工審核的去識別畫面、3 段預覽、提示公式與 QA 清單。