⏰ 連假加碼即將結束 ⏰ 全站 85 折+$1,010 購課金只到今天就過期 ⚠️ 今天再加碼 LINE Pay 10%❗️
時
分
秒
全站 85 折只到 23:59🎆
登入/註冊

爆紅模型 Jev,正在把「判斷」從「生成」裡拆出來(下)

高玉璁 Samuel高玉璁 Samuel
12:00
2026/09/23
104

這一段會進一步拆解 Jev 真正值得注意的地方:它如何透過 Calibration 表達「自己有多確定」、為什麼同一案件的判斷穩定性對自動化特別重要,以及 Jev 如何與 GPT/Claude 分工,成為客服 Agent、模型路由與風險把關中的決策節點。

接著我們來更深入的討論一些使用場景,還有幾個我們會特別關注的問題 😎

09|那 Jev 會不會解決「同一題,每次分類結果都不一樣」?

這是一個非常實際的問題,如果你曾經拿 ChatGPT 或其他大型語言模型做分類,很可能遇過:

同一封 Email 進行分類

第一次 → Logistics
第二次 → Billing
第三次 → Logistics

生成式模型原本就不是為「每一次都產生一模一樣的結果」而設計的,雖然透過:

  • 降低 temperature
  • structured output
  • 更清楚的 Prompt
  • 更好的分類定義

(⚠️ 忘記的回去前面補課!!)

都可以顯著提高穩定度,但生成式模型的核心任務仍然是 generation(生成),Jev 則把一致性的目標往前推了一步,它希望同樣的語意情境,得到比較穩定的決策分布(decision distribution)。

例如可能跑出以下的結果:

Run 1
Logistics 78%
Billing   18%
Other      4%

Run 2
Logistics 76%
Billing   20%
Other      4%

Run 3
Logistics 79%
Billing   17%
Other      4%

真正重要的不是「三次是不是每個數字都完全一模一樣」,而是「判斷方向是否穩定。」

但這不代表 Jev 完全 deterministic,假設結果本來就是:

A = 51%
B = 49%

這其實代表模型自己都覺得「A、B 真的很接近」,這時如果下一次變成:

A = 49%
B = 51%

並不令人意外,所以真正成熟的自動化流程,不能寫成:只要 A 比 B 高 → 自動執行,而應該設計安全區間,例如:

  • >95% → 自動執行
  • 70–95% → 進一步確認
  • <70% → 真人處理

這也是為什麼 Vercel 這個託管平台,在 Jev 的使用建議中一直強調:Probability 不等於你的 Policy,模型負責提供判斷。

你的系統才負責決定多少機率應該採取什麼行動。

10|把 Jev 放進一個真正的客服 AI Agent,會長什麼樣子?

我們直接來看一個完整案例。

假設你是一間電商公司,每天有 10,000 張客服單,過去可能全部先交給真人分類,現在你想加入 AI。

第一版可能會變成:

客服訊息
↓
GPT
↓
分析
↓
分類
↓
寫回覆
↓
寄出

看起來已經很自動,但風險也很高,因為你等於把:

  • 判斷 + 決策 + 寫作全部交給同一個模型。

如果重新拆開,可以變成:

✨ Step 1|先把資訊整理成 State

例如:

客戶訊息:
「我已經等七天,今天再沒有處理就退款。」

訂單:
已付款、尚未出貨

客戶:
VIP

過去客服:
昨天承諾處理

✨ Step 2|Jev 同時做幾個判斷

案件類型 → Logistics 84%

嚴重程度 → 8.7 / 10

是否要求退款 → 96%

是否需要主管介入 → 91%

資訊是否足夠處理 → 73%

注意!這裡 AI 還沒有寫任何客服回覆,它只是先把情況判斷清楚。

✨ Step 3|系統根據公司規則決定下一步

例如:

嚴重程度 > 8 → 通知主管

退款意圖 > 90% → 標記退款案件

資訊完整度 < 80% → 先要求補充資料

這些真正會影響公司的規則,仍然掌握在企業自己手上。

✨ Step 4|需要「說話」的時候,再叫大型語言模型

一但我們確定這是一個「高嚴重度、要求退款、物流問題」之後,才把必要資訊交給 Claude、GPT 或 Gemini:

「請按照公司的客服語氣撰寫一封回覆,先道歉、說明目前處理狀況,再告知退款流程。」

這時就真正需要大型語言模型擅長的:

  • 語氣
  • 組織
  • 解釋
  • 長篇生成

✨ Step 5|寄出之前,再做一次把關判斷

我們可以再讓 Jev 判斷我們用大語言輸出的信件:

有沒有真正回答客戶問題? → 96%

是否包含公司不能承諾的內容? → 8%

是否可能透露內部資訊? → 3%

語氣是否符合客服規範? → 高

高風險就不要寄,低風險才繼續。

這種架構的重點不是:「Jev 可以取代大型語言模型。」

而是:不同 AI 開始各自負責自己擅長的工作。

11|另一個更簡單的案例:不是每件事都值得叫「最強 AI」來處理

再看一個更生活化的例子,假設公司內部有一個 AI 助理,每天收到很多不同問題:

  • 問題 A:「幫我把這句英文修順。」
  • 問題 B:「把這 20 筆會議紀錄依照部門分類。」
  • 問題 C:「幫我分析這份 80 頁的年度財報,找出毛利下降可能來自哪些產品組合變化。」

這三件事情,都需要直接丟給最昂貴、最會推理的模型嗎?其實不一定。

你可以先讓一個 decision model 判斷,這是一個:

  • 簡單文字修改?
  • 資料分類?
  • 複雜分析?

接著就可以往下:

簡單文字修改 → 小模型
大量分類 → Decision Model
複雜財報分析 → Frontier Reasoning Model

它就很像公司裡的一個 AI 總機 🤔

不是自己把所有事情做完,而是先判斷:「這個工作該交給誰?」真正重要的成本概念也因此改變!

以前我們可能一直問:「哪一個模型比較便宜?」

但更好的問題其實是:「這一次真的需要叫最貴的模型嗎?」

如果 10,000 次 AI 呼叫裡,有 7,000 次其實只是在:

  • 分類
  • 判斷
  • 打分數
  • 決定下一步

那最有效的成本優化,可能根本不是找到一個便宜 20% 的大型語言模型。

而是:不要讓這 7,000 次工作進入大型語言模型。

這也是 Jev 對 AI Automation 最值得觀察的地方。

12|但是,Jev 並不代表「沒有幻覺」

你可能會看到一些文章形容 Jev:「0 hallucination。」

這句話一定要非常小心理解。

假設你規定 Jev:

只能選:

Billing
Technical
Logistics

那它確實不會突然回答:「請轉給 CEO。」

因為:CEO 根本不在允許的答案裡。

這是 Jev 很大的優勢。

我們可以把它稱為:Bounded Output / Schema Correctness

也就是:

答案一定待在你事先定義好的範圍裡。

但是:

待在範圍裡,不代表答案一定正確。

它完全可能發生:

正確答案:
Logistics

Jev:
Billing = 92%

所以:Jev 解決的是「亂回答」,不是「答錯」。

Vercel 在 Jev 的技術說明中也明確提醒:typed answer 並不等於 decision 本身一定正確,仍應該用有已知答案的資料評估模型。

13|所以 Jev 到底算不算一種全新的 AI?

這也是一個值得保留懷疑的問題,因為如果你熟悉傳統 Machine Learning,可能會想:

「等等,分類器不是幾十年前就有了嗎?」

完全正確,我們早就有:

  • Spam classifier
  • Fraud classifier
  • Sentiment classifier
  • Image classifier
  • Recommendation model

這些模型本來就不是靠「寫一段文章」才做決定。

所以不能把 Jev 描述成:「人類第一次發明不生成文字的 AI。」

這顯然不對。

Jev 真正想證明的是另一件事情。

傳統分類模型通常是:

我有一個非常明確的任務
↓
準備專門的 training data
↓
訓練一個 classifier
↓
這個 classifier 專門做這件事

例如:專門判斷垃圾郵件這種任務。

但是如果明天任務變成:判斷這封 Email 應該交給 Sales、Finance、HR 還是 Customer Success。

你可能需要重新設計資料、重新訓練。

LLM 的革命則是我不用每件事情都重新訓練一個模型,只要用自然語言描述任務,它就可以試著理解。

Jev 想取得的是兩者中間一個很有意思的位置:

擁有接近通用語言模型的語意理解能力,但提供像 classifier 一樣直接、受限、快速的 decision output。

如果這件事成立,才是 Jev 真正值得注意的地方,所以 Jev 未來真正需要被驗證的,不只是:

「它會不會分類?」

而是:它能不能同時做到廣泛語意理解、少量設定就換任務、高速度、高一致性,以及真正可靠的 calibrated probability?

這些仍然需要更多獨立測試;老實說我自己是覺得現有的大語言模型一定多少會開始導入這樣的思維去優化自己的演算法啦...(小聲)

14|真正值得看的,可能不是 Jev,而是 AI Software 開始「分工」

過去幾年,我們常常有一種 AI 架構:

有問題
↓
丟給 GPT

需要分類 → GPT。

需要搜尋 → GPT。

需要判斷 → GPT。

需要計算 → GPT。

需要寫文章 → GPT。

需要決定下一步 → 還是 GPT。

這就像公司裡所有事情都丟給同一個超級員工。

他很厲害,但不代表這是一個好的組織設計。

更成熟的 AI 系統可能會變成:

需要查資料 → Search
需要取得內部資訊 → Database / RAG
需要精準計算 → Code
需要快速判斷 → Decision Model
需要複雜推理 → Reasoning Model
需要寫作與溝通 → Generative Model
需要執行 → Tool / Workflow

這也是 AI On Duty 這門課程從底層想要幫助大家建構的思維,這裡真正發生的改變其實不是,又多了一個新模型。

而是:AI Software 開始從「一個模型包辦所有事情」,走向「把不同能力拆成不同零件」。

好啦,教學的部分就整理到這裡,看完 Jev,你可以先做一個很簡單的盤點

先不用急著導入 Jev,反而可以先打開你現在正在使用的 AI Workflow,問自己:

我們目前有哪些 AI 呼叫,其實只是在做判斷?

找找看有沒有這些:

是不是?

  • 這封信需要回覆嗎?
  • 這份文件含不含敏感資訊?
  • 這個客戶是不是有退款意圖?
  • 這段回答有沒有違反規範?

是哪一個?

  • 這封 Email 屬於哪個部門?
  • 這張工單是哪一種類型?
  • 這個任務應該交給哪個 AI?
  • 這筆 Lead 屬於哪個客群?

程度多少?

  • 這個案件有多急?
  • 客戶有多不滿?
  • 這個 Lead 有多值得優先處理?
  • 這份文件的風險程度是多少?

如果你發現:

「欸,我們有一大堆 AI 呼叫,其實最後只是為了得到一個 Yes / No、一個分類或一個分數。」

那你就已經理解 Jev 為什麼突然受到這麼多人注意了。

最後:不要再只問「哪個 AI 最強?」

Jev 現在還非常新,這意味著它的:

  • 完整模型架構
  • RLCD 細節
  • Training data
  • 大規模第三方 benchmark
  • 跨 Domain calibration 能力

都還需要更多證據。

所以現在就宣稱:「Jev 會取代大型語言模型。」顯然太早。

但它提出了一個非常值得記住的問題:

AI 真的每一次的回答都需要生成文字嗎?

有時候,我們需要 AI 寫一封信,有時候,需要深入分析一個問題。

但更多時候,我們其實只需要:

  • 「這個是不是?」
  • 「這是哪一個?」
  • 「程度多少?」

當 AI 開始進入真正的工作流程之後,我們可能會慢慢發現:

最強的 AI 系統,不一定是把所有事情都交給最強的模型。

而是:先理解工作,再選擇適合的 AI。

  • 搜尋交給搜尋
  • 計算交給程式
  • 複雜推理交給 reasoning model
  • 寫作交給 generative model
  • 快速判斷則可以交給 decision model

而真正需要人負責的,永遠是:我們要怎麼設計這套流程,以及什麼條件下,我們願意讓 AI 自己做決定。這或許才是 Jev 現在最值得我們注意的地方 ✨