Jev vs Agents：在軟體中整合決策原語

除非你過去一週都住在石頭裡，否則你一定看過 Jev 來自 @typesafeai 的動態。

https://x.com/CompleteSkeptic/status/2099925682726002904

他們將自己的模型描述為：

一類專為做出快速、結構化決策而設計的 AI 模型，這些決策可直接供軟體使用。System One 模型會評估一個
state 並回傳帶有型別的結果與機率。

根據 TypeSafe 的基準測試，Jev 比 LLM 快 20-200 倍，且成本低 40-400 倍。

但這為什麼重要？我們以前也訓練過分類器（手機自動更正、Gmail 過濾等），但根據 Twitter 上的討論，Jev 似乎有些特別之處。

在這篇文章中，我將教你 Jev 是什麼、它為何存在，以及你可以如何將其導入你的生產系統。

所以 Jev 究竟是什麼？

「把 Jev 想像成一個前沿智能函數呼叫：輸入非結構化的狀態，輸出帶有型別的機率決策。」 - TypeSafe

Jev 提供 3 個基本原語：Choice、Score 和 Noul。

Choice 是一種問題類型，從定義好的集合（最多 255 項）中選擇一個選項，其答案包含選定的選項、每個選項的機率以及信心分數。
Score 針對內容進行評級，對應有序的描述性等級，其答案包含分數、每個等級的機率以及信心分數。
Noul 要求模型評估是非題，並回傳答案為「是」的機率。

以下是一個客戶支援用例的輸入與輸出範例：

json

1// Input
2{
3  "model": "jev-latest",
4  "state": "Hi, I was charged twice for my monthly subscription. Could you refund the extra charge? My account is working fine.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Which team should handle this message?",
9      "criteria": {
10        "billing": "Charges, payments, subscriptions, and refunds",
11        "technical": "Bugs, errors, and broken features",
12        "account": "Login, passwords, and account access"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Is the customer explicitly requesting a refund?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "How frustrated does the customer sound?",
22      "criteria": [
23        "Calm: politely describes the issue without expressing frustration",
24        "Frustrated: expresses annoyance or dissatisfaction",
25        "Very frustrated: expresses strong anger or threatens to leave"
26      ]
27    }
28  }
29}
30// Output
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Calm: politely describes the issue without expressing frustration",
53        "1": "Frustrated: expresses annoyance or dissatisfaction",
54        "2": "Very frustrated: expresses strong anger or threatens to leave"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

建議你透過他們的 dashboard onboarding 來更深入理解 state 與 questions 是如何協同產生輸出的。

這不就只是一個分類器嗎？

既是也不是。它更像是 LLM 與分類器的結晶。

傳統分類器適合處理高流量、固定分類體系的任務。想想看 LeNet-5 能夠識別圖像代表的數字。然而，分類器通常高度專業化且限於特定領域。LLM 擅長生成序列。它們靈活且適合在執行時定義的開放式任務，但也更慢（相比分類器）、更昂貴且較不可預測。

Jev 是一個「用於分類的基礎模型」，結合了 LLM 的自然語言靈活性與分類器受約束的機率輸出。你可以在無需訓練新模型的情況下完成各種多樣的任務，同時維持跨不同領域（程式碼、文字、日誌、UI 狀態、事件等）的專業能力。Jev 也能平行生成輸出，這使其比受限於序列生成的 LLM 快得多。

TL;DR 這是一個非常聰明且具泛用性的分類器。

Jev 為何存在？

TypeSafe 的執行長兼共同創辦人 Diogo Almeida 曾在 OpenAI 參與 RLHF（基於人類回饋的強化學習）及 ChatGPT 產品的開發。RLHF 讓我們能訓練 LLM 更好地遵循指令與提示，這符合其自回歸的本質。

隨後他離開 OpenAI 創辦 TypeSafe，致力於訓練另一類模型以賦能 AI 驅動的軟體，而非 Agent。Jev 採用 RLCD（基於校準決策的強化學習）進行訓練，這意味著他們訓練模型專注於輸出準確的信心分數與機率，而非單純的答案。

TypeSafe 認為軟體應該具備智能。Agent 無法自然地融入軟體過去的運作方式，而人在迴路（human-in-the-loop）機制使得既智能又自主的軟體難以實現。Jev 是邁向將智能作為軟體系統內可組合、可靠原語的一步。

這並非全新的概念，2017 年的研究人員發現強大的預測準確度並不意味著可靠的信心估計（因此 LLM 在此並非完美解）。

為何選擇 RLCD 而非 RLHF？

RLHF 的問題在於人類想要的並不總是客觀正確的。僅僅因為我們偏好某種格式的答案，並不會讓模型變得更聰明，只是讓它更好用而已。

這也會導致模式崩潰（mode collapse），RLHF 使 LLM 收斂到單一答案，儘管有時有多種軌跡都是「正確」的。

「對人類來說有吸引力的輸出，未必足夠可靠以用於無人值守的自動化。人類偏好與機器可信度是不同的優化目標。」

Mode collapse via Jev's Docs

Jev 並非為了構建 Agent 而生

與你在時間軸上看到的情況相反，Jev 作為獨立 Agent 表現並不出色。我們曾嘗試構建其版本，包括僅使用 Jev 以及 LLM + Jev 的組合。

https://x.com/kylejeong/status/2100622054945095934

老實說，Jev Agent 確實能做出很酷的 Demo。已有大量案例利用 Jev 以極快的速度執行 Agent 任務。但即使是最好的 Demo，也尚未準備好部署到生產環境。

像 Jev 這樣的模型旨在用於 AI 驅動的軟體，它能協助你在確定性代碼中做出決策。若缺乏推理或生成能力，將其用作獨立 Agent 純粹是無知。

AI-powered Software

與其讓 Jev 成為獨立的電腦操作 Agent，不如將其應用於客戶支援路由、發票處理、安全警報與分流，或作為 Agent 監控器。

數據說話

他們的首個模型 Jev 1.13.0 輸入成本為 $42/btok（即 $0.042/mtok），輸出 token 免費。作為參考，Fable 5.1 的輸入成本為 $10/mtok，即 $10,000 / Btok。典型的企業工作負載輸入輸出 token 比例為 3:1 或 4:1，因此 Fable 的成本約為 ~$20,000/Btok（假設輸出為 $50/mtok）。

上下文視窗為每次請求 64k tokens，其中 state 加上最長的問題必須容納在 32k tokens 內。

然而，在內部基準測試中，他們在準確率/成本與準確率/速度方面超越了來自 OpenAI、Anthropic 和 Deepseek（透過 Fireworks 進行推論）的所有模型。

accuracy/cost

廢話少說，如何使用它？

你現在應該對 Jev 有了足夠的了解，無論你目前在做什麼，應該都能想到幾個用例。(如果沒有，這裡有一份 TypeSafe 推薦的用例清單)。

為了不限制你對其應用的創意，我將展示我們如何將 Jev 整合進我們的框架 Stagehand。

過去兩年，Stagehand 已發展成為一個讓 AI 和 Agents 控制遠端瀏覽器的框架。在 Agent 還不夠強大之前，我們建立了 AI 原語 Act（執行動作）、Extract（提取結構化資料）和 Observe（發現頁面上潛在的動作），以幫助開發者編寫自愈腳本來自動化網頁。

與其使用 Playwright（或其他舊式框架）並手動解析 DOM 以在動作中提供選擇器，Stagehand A/E/O 讓你使用自然語言來構建自動化流程。

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("click the submit button")

這在首次編寫腳本時很有幫助（開發速度快得多），但在腳本維護方面尤其有用。如果網站變更導致 DOM 選擇器更新，Playwright 腳本必須重寫以匹配新頁面。Stagehand 在執行時選擇選擇器和動作，具有「自愈」能力。

你大概能猜到我們要往哪裡走了。Jev 非常適合這些原語。我們原本使用 LLM（提供頁面外觀與目標的上下文）來決定該做什麼。有了 Jev，我們可以使用 Choice 來決定要互動哪些選擇器。

讓我們具體以 Act 為例來探討這個流程。通常，我們會給 LLM 一個使用混合 a11y-tree 的簡潔頁面表示。有了 Jev，我們首先將 a11y tree 中的節點標記為可互動（甚至包括富文本編輯器）或不可互動。

當 stagehand.act 被調用時：

Jev 將指令分類為一個動作（如 click、fill 或 scroll）
Stagehand 解析參數並為該動作建立候選清單（包含附近的頁面上下文）
Jev 回答「哪個候選最佳」以及「是否有候選匹配」，接受閾值為 0.7
如果候選動作被接受，則由 Stagehand 處理執行
如果動作未被接受，則 Stagehand 回退到 LLM

Act Flow

在早期測試中，Act 的中位延遲從 1.97 秒降至 0.46 秒，快了約 4.3 倍（或減少 77% 的時間）。查看完整的 PR stack。

在電腦操作方面，Jev 是拼圖的一塊，但不是獨立解決方案。我們現在能夠構建更多 Agent 可用的確定性軟體工具。

When to use Jev

在現實世界中普及 AI

Jev 會構建出生產級的電腦操作 Agent 嗎？不會。它是拼圖中有用的一塊嗎？我認為是的。

感覺有很多想法在 Jev 出現之前是不合理的。我看過人們構建即時搜尋、智慧複製貼上，以及其他簡單但極具幫助的工具。

AI 不應局限於某種版本的聊天介面，無論是同步還是非同步。有了像 Jev 這樣的模型，我們可以構建整合預測模型的軟體，而無需聊天輸入框。儘管分類器已經存在很久，但它們從未顯得如此有用。也許我們需要的只是靈感。

-> Kyle