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 都带一个分布和一个置信度。

大语言模型

文本自己声称的那点把握。