【2026 最新】NotJev 教學：一個 Token 何時棄權？本機分類與聊天回退 5 步

你想讓本機 AI 幫客服訊息做「退款」或「其他」二選一：每則都請模型寫長篇解釋，速度和等待時間很快變成負擔；只要它吐一個答案，又怕它把模糊訊息判錯。NotJev 教學要解決的，正是「何時可以直接判斷，何時該先棄權」這個問題。

這篇寫給第一次把本機模型接進程式的讀者。我會用一個繁中分類例子，從一個 Token 的原理、安裝與 API 驗收，走到帶標準答案的小題庫、棄權門檻和完整聊天回退。你不需要先懂機率論；照著欄位看，就能知道哪些數字應該拿來驗證，哪些不該當成保證。

先說結論：一個 Token 的判斷，外加一條棄權出口

一句話記住：NotJev ＝封閉選項的一字母投票＋分差門檻＋不確定時的回退路由。它把「退款／其他」排成 A、B，請支援 logprobs 的模型只生成下一個 Token，讀出 A、B 的相對權重。分差夠大才交付答案；分差太小，就讓完整聊天或人工接手。

截至 2026 年 9 月，NotJev 官方 README列出的核心路徑是 max_tokens: 1、logprobs 和可設定的 theta。這裡的「快」是少生成輸出 Token 的設計，不等於每台電腦都會得到相同延遲；輸入的處理、模型大小與推論引擎仍然會影響時間。

NotJev 教學第一步：先分清五個容易混淆的數字

想像老師只准學生在 A、B 兩張卡片中舉一張。NotJev 不讀一段作文，而是看學生下一瞬間舉 A 或 B 的傾向。假設一個教學用假想例子中，A 的原始權重是 0.42、B 是 0.28，其餘 0.30 落在選項之外。把 A、B 的 0.70 重新除成 100% 後，A 是 0.60、B 是 0.40，分差是 0.20；這不是實際模型的測試結果。

• choice：判斷代碼，或 null。null 代表目前沒有交付判斷；你的程式必須指定下一站。
• p1：選項內重新正規化後的第一名權重。它不是「這題有 p1 的機率答對」。
• margin：第一名減第二名；二選一時用它和 theta 比較。
• coverage：選項字母在原始下一 Token 分布中占了多少權重。它和「系統自動處理了多少題」是兩個不同的覆蓋率。
• band：把 p1 放進 low／med／high／certain 的粗區間；名稱只是程式分箱，不是已校準的正確率。

上面的假想例子若設 theta: 0.5，margin=0.20，所以會棄權。另有 degraded: true：代表回傳的候選 Token 裡沒有可用的選項字母，官方程式會把 choice 留為 null。低 coverage 則是另一個警訊：即使選項內 A 勝出，也要先檢查模型是不是想回答別的字。詳見官方輸出欄位說明。

NotJev 教學第二步：接上支援 logprobs 的本機端點

先準備 Node.js 20 以上，以及一個已載入模型、能回應 /v1/chat/completions 且會回傳 logprobs 的本機服務。NotJev 的 NOTJEV_BASE_URL 要填主機根網址，例如 llama.cpp 的 http://127.0.0.1:8080，程式自己加上 /v1/chat/completions；不要把 /v1 再接進去。以llama.cpp 官方 API 文件與NotJev 引擎說明核對自己正在用的版本。

npm install notjev
export NOTJEV_BASE_URL=http://127.0.0.1:8080
export NOTJEV_MODEL=local-model

把下面存成 demo.cjs，再執行 node demo.cjs。local-model 必須換成該端點實際提供的模型 ID；服務還沒開、模型尚未載入，程式就會報連線或模型錯誤。

const { createClient } = require('notjev');
const jev = createClient();
const q = {
  state: '客戶：包裹還沒寄出，想取消訂單並拿回款項。\n',
  question: '這則訊息是否需要退款流程？',
  options: [
    { id: 'REFUND', description: '要求退款或取消訂單取回款項' },
    { id: 'OTHER', description: '其他詢問' },
  ],
  theta: 0.5,
};
(async () => {
  console.log(jev.prompt(q));
  const r = await jev.decide(q);
  console.log({ choice: r.choice, p1: r.p1, margin: r.margin,
    band: r.band, coverage: r.coverage, degraded: r.degraded,
    undecided: r.undecided, ms: r.ms });
})().catch(console.error);

先看 jev.prompt(q) 列出的完整題目，再看回傳值。這一步同時驗收三件事：網址是否正確、端點是否真的回傳選項的 logprobs、繁中題目與選項描述是否被模型按預期讀取。若 degraded 為真，先檢查回應裡的 logprobs、思考模式、Token 切法與提示詞；只看到 HTTP 200 並不算通過。官方文件也說明 vLLM、llama.cpp、Ollama 的設定差異，請按你用的引擎核對。

第三步：讓棄權真正接回完整聊天

NotJev 的 choice: null 只表示「我不交付這一題」。它不會替你的客服系統安排下一步。回退路由可以沿用同一模型的完整聊天模式，但要把原訊息與原問題一起送過去，並記下「由一 Token 路徑棄權」的原因。

const { createClient } = require('notjev');
const base = process.env.NOTJEV_BASE_URL;
const model = process.env.NOTJEV_MODEL;
const jev = createClient();
async function route(message) {
  const q = { state: message + '\n', question: '是否需要退款流程？',
    options: ['REFUND', 'OTHER'], theta: 0.5 };
  const r = await jev.decide(q);
  if (!r.degraded && !r.undecided) return { path: 'fast', value: r.choice };
  const response = await fetch(base + '/v1/chat/completions', {
    method: 'POST', headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ model, messages: [
      { role: 'system', content: '判斷訊息是否需要退款流程；若資訊不足，請指出還需確認什麼。' },
      { role: 'user', content: message }
    ] })
  });
  if (!response.ok) throw new Error('full chat HTTP ' + response.status);
  const data = await response.json();
  return { path: 'full-chat', value: data.choices[0].message.content };
}
route('包裹有問題，請幫我處理').then(console.log).catch(console.error);

這段示範省略了正式服務需要的驗證、逾時、重試、回應格式檢查與人工接手規則；若端點設了 API key，兩條路都要加授權標頭。完整聊天的文字也不等於已確認的退款決策，應由你的業務規則或人工流程決定是否執行。若你的應用需要把「低 coverage」也送入回退，先在有標準答案的資料上選一個 coverage 下限，再加到 if 條件，別把示例門檻當產品設定。

第四步：用繁中小題庫選 theta，而不是相信 p1

門檻的意思不是「分差大就一定對」，而是你願意讓多少題自動通過。做一張 id、訊息、標準答案、是否模糊 的小表：退款明確、查物流明確、取消但尚未付款、反諷、混合意圖、錯字與口語各放幾題。先由人寫好標準答案；「資訊不足」另標出來，免得把歧義硬塞成錯誤的二選一。

1. 固定測試條件。記錄模型檔、量化格式、引擎版本、題目文字、選項順序、提示詞與日期。改其中一項就視為新實驗。
2. 存原始回應。用 theta: 0 收集每題的 choice、p1、margin、band、coverage、degraded、ms 與原始 logprobs；不要只存最後代碼。
3. 掃門檻。離線重算幾個候選 theta，分別看「自動交付題數／全部題數」與「自動交付中答對題數／自動交付題數」，再算剩餘題目進完整聊天後的總錯誤與延遲。
4. 留出驗收題。用一部分題選門檻，另一部分從未參與調門檻的題檢查；否則會把小題庫的偶然特性學進去。

這是NotJev 官方量測流程的核心：掃描 theta，看自動交付比例與已交付判斷的準確度如何互換。scikit-learn 的機率校準說明也提醒：一個顯示 0.8 的預測，只有在相似分數的一群案例中約八成真實正確時，才談得上校準。p1 是選項內權重，先經過本地題庫驗證，才能作為工作流的信號。

如果「全猜退款」在題庫裡就能拿高分，模型的準確率看起來漂亮也可能沒有價值。至少加一條永遠猜多數類的基準線。再分開看明確與模糊題、不同類別、不同語氣：整體正確率改善，不代表每個子群都改善。選擇性分類研究把這稱為「覆蓋率與錯誤率的取捨」，也指出棄權可能放大不同群體的差異。可參考選擇性分類原始論文與群體差異研究。

第五步：換推論引擎時，連 band 也重新驗收

作者在2026 年 9 月的自報測試觀察到：同一模型經不同引擎服務，原始 p1 會移動；它把 band 視為較穩定的粗粒度標記。但該文件的跨伺服器重新提問只列出 3 題。對你的繁中題庫而言，band 仍是一個需要驗收的假設。

換引擎後，把同一批保留題逐題重跑，對齊 choice、p1、band、coverage、degraded；重新畫每個 theta 下的自動交付與錯誤曲線。特別查看從 high 變 certain、從可交付變棄權，以及原本答對卻翻錯的題。若結果變動，就為新引擎另存一份門檻與版本紀錄，別直接沿用舊 theta。

最常見的四個坑

1. 把 0.9 當九成正確。這是選項內權重與分箱的混淆；用保留題檢查每個分數區間的實際正確率。
2. 只看 margin，漏看 coverage。選項外權重很大時，A、B 的相對勝負可能掩蓋「模型想說別的」；同時記錄兩者。
3. 換選項文字卻沿用門檻。描述與順序會改提示詞；官方程式直接按呼叫者的順序排 A、B，需重新驗收。
4. 只算一 Token 呼叫的延遲。使用者體驗取決於「快速通過」加上「棄權後完整聊天」的整條路；兩條路都記耗時與失敗率。

常見問題：NotJev 的棄權與回退

Q1：NotJev 是一個新模型嗎？

不是。它是讀取既有模型下一 Token logprobs 的 Node 套件與服務；模型仍由你的推論端點提供。

Q2：p1=0.9 就代表九成會答對嗎？

不能直接這樣解讀。它先在選項字母間重新正規化；要在你的保留題中比較分數與實際正確率。

Q3：choice=null 是判成 OTHER 嗎？

不是。它表示未交付判斷；讓完整聊天、人工或補資料流程接手。

Q4：degraded 和一般棄權一樣嗎？

不一樣。前者是讀不到可用選項權重，常要先查端點與提示詞；後者可只是分差低於 theta。

Q5：只有兩個選項才能用嗎？

官方支援封閉選項、布林與分數三種形式；選項字母機制最多 26 個選項，但題目越多越需要驗證分布與覆蓋率。

Q6：換成 vLLM 或 Ollama，門檻能照搬嗎？

先不要。固定資料、模型與提示詞重新測 p1、band、margin、coverage，再決定新設定。

Q7：完整聊天回退就一定比較準嗎？

不一定。它能用較完整的回答處理歧義，但仍應在同一題庫上記錯誤率、延遲與人工接手比例。

Q8：第一個小專案該做什麼？

先用 20～30 則自己有權使用、帶人工標籤的繁中句子練習；這個數量是教學起點，不足以證明正式服務的錯誤率。

給新手的三個重點

• 先把問題寫成封閉選項，並確認本機端點真的回傳 logprobs。
• 把 p1 當未校準的訊號；同時看 margin、coverage、degraded。
• 用保留題選 theta，再驗證「快速判斷→棄權→完整聊天」整條路。