Jev 對比大型語言模型

它們並不在爭同一份工作。大型語言模型負責寫，Jev 負責判斷。有用的比較不是誰更聰明，而是你的程式拿到答案之後還得做什麼——這個差別大到足以改變外面那段程式的寫法。

同一個判斷，兩種寫法

把一張工單路由到四個佇列之一。下面是每一邊在程式上真正要你付出的東西。

用語言模型

const res = await llm.chat({
  messages: [{ role: "user", content:
    `Route this ticket. Reply with JSON: {"queue": "Billing"|"Technical"|"Account"|"Sales"}
     Ticket: ${ticket}` }],
  response_format: { type: "json_object" }
});

let queue;
try {
  queue = JSON.parse(res.content).queue;        // may not be JSON
} catch {
  return retry();                               // ...so there is a retry
}
if (!QUEUES.includes(queue)) return retry();    // may be a queue you never had
// and no idea how close the call was

用 Jev

const { answers } = await jev.systemOne({
  state: ticket,
  model: "jev-latest",
  questions: { queue: { type: "choice", instructions:
    "Which team should own this ticket?", criteria: QUEUES } }
});

const { choice, probabilities, confidence } = answers.queue;
// choice is one of QUEUES. It cannot be anything else.
if (confidence < 0.7) return humanReview(ticket, probabilities);
route(choice);

重試迴圈就是那個破綻。它在第一個版本裡存在，是因為答案以文字抵達，可能解析不了，也可能解析出一個從不在名單上的佇列。在第二個版本裡它無處安身：按建構方式，答案必是 QUEUES 之一。取代它的是完全不同的一條分支——在模型_不確定_時觸發，而不是在它格式錯亂時觸發。

第二個版本看得見什麼

那張工單，真的跑了一遍 Jev。冠軍毫不意外；第二名才是光禿禿的標籤會丟掉的那部分。

“今早 4.2 發版以來，我們的 SSO 登入一直回 500。團隊裡沒人登得進去。Chrome 和 Safari 上一樣，兩個不同的租戶也一樣。”

87% 技術

技術以 87% 勝出，但帳號佔著 13%——而這正是應該存在的分歧，因為 SSO 故障確實卡在兩者之間。一個光禿禿的標籤會把它藏起來。如果你的路由判錯是有代價的，13% 就是該拿來設門檻的那個數。

逐項對照

你送出的是什麼: Jev

一個 state 加一組型別化問題。

大型語言模型

一段提示詞，通常把 schema 和規則當散文一起塞進去。
回來的是什麼: Jev

每個問題一個型別化答案，每個選項都有機率。

大型語言模型

文字。如果你客氣地要了、而且支援那個模式，就是 JSON。
你的下一行程式: Jev

對一個只可能是你自己那些值之一的值做 switch。

大型語言模型

先解析，再驗證，然後為兩者中任一失敗的情況寫一條分支。
它怎麼出錯: Jev

它可能讀錯你的文字。它不可能回傳你沒定義過的形狀。

大型語言模型

它還可能在形狀上出錯——缺欄位、冒出你從沒列過的標籤、JSON 外面裹著一段散文。
問十件事: Jev

十個問題一次請求，平行地針對 state 評估。

大型語言模型

一段塞滿的提示詞，或者十次呼叫。
不確定性: Jev

每個 Choice 和 Score 都帶一個分布和一個信賴度。

大型語言模型

文字自己聲稱的那點把握。