JASON LIRESEARCH

研究筆記 · AGENTS & PROBABILISTIC DECISIONS

Jev 與 KG-RAG：兩種評分方式的比較

了解 Jev 後，重新思考 KG-RAG 的 progress、proximity 與 BFS 搜尋。

GUI AgentsProbabilistic Decisions
作者
Jason Chun Lok Li
日期

了解 Jev 後，我重新想起我們在 EMNLP 2025 發表的 KG-RAG。當時，我們用 LLM 為 GUI 的候選 trajectories 評分，再交由搜尋演算法決定探索哪些路徑。Jev 也把模型的判斷變成有明確範圍的 probabilities，讓程式直接使用。

兩者確實有相似之處，尤其是模型負責判斷、程式負責控制流程的分工。但仔細比較後，搜尋的對象、分數的算法，以及訓練想改善的能力，都有不同。

我想用同一個例子，看看兩種評分方式何時會做出相同選擇、何時會分歧，再思考 Jev 為我們下一版 trajectory scorer 帶來甚麼值得測試的想法。

1 相似的核心：把模型放進程式裡，擔任評審

KG-RAG 處理的是 agent 缺乏 app 導航知識的問題。Offline pipeline 會探索 UI Transition Graph（UTG），利用 intent milestones 評估 trajectories，再把有用的 intent–trajectory pairs 存起來，供 online retrieval 使用。搜尋每輪批次展開候選路徑、評分，再保留 top-K 作為下一輪 frontier。這裡搜尋的是 UI 路徑，不是 token-decoding tree。[論文 §3.2、Algorithm 3]

01 / 程式提出候選路徑沿 UI graph 展開 trajectories。
02 / 模型判斷完成進度估計每條路完成多少 milestones。
03 / 程式選擇下一輪 frontier排序、篩選，再決定繼續展開哪些路徑。
簡化的 offline search loop。下一輪的候選範圍，依賴這一輪的評分結果。

假設任務有兩個 milestones：先到設定頁，再打開私隱政策。我們可以問模型：「這條 trajectory 已完成 0、1，還是 2 個 milestones？」取出相關 LLM logits，經過 softmax，就得到這三種答案的 probability distribution。

pi=exp⁡(zi/T)∑jexp⁡(zj/T)p_i = \frac{\exp(z_i/T)}{\displaystyle\sum_j \exp(z_j/T)}

這就是和 structured scoring 相似的地方：模型對明確的答案範圍給出數字，外面的程式決定如何利用這些數字完成任務。

Jev 把這個介面明確化，例如用 Noul 表達 yes/no probability、Choice 選擇類別、Score 評估有順序的 levels。Choice 和 Score 另外回傳 confidence 指標。對我們的 milestone 例子，最接近的是 Score。[TypeSafe primitives]

2 同一個例子，其實在回答四個問題

假設某條 trajectory 得到以下分布：

0尚未完成
10%
1完成一個
20%
2完成兩個
70%
同一條候選路徑，三種可能的完成狀態。

我們的 progress score：最高 probability 有多高？

Progress=max⁡(0.1, 0.2, 0.7)=0.7\begin{aligned}\mathrm{Progress} &= \max(0.1,\,0.2,\,0.7) \\ &= 0.7\end{aligned}

這裡有兩個不同的數字：「2」是模型最相信的完成數量；「0.7」是它給這個答案的 probability。按論文的 progress 定義，我們取後者。所以 0.7 並不代表「完成了 70% 的任務」。只保留最高 probability，也會丟掉其餘分布的資訊；這就是下一個分數能補充的地方。

我們的 proximity score：排序是否偏向較多進展？

先問一個更直觀的問題：模型的判斷是否傾向「完成越多越可能」？我們想偏好的排序是「完成 2 個」排第一、「完成 1 個」第二、「完成 0 個」最後，也就是 [2, 1, 0]。這個例子的 probabilities 是 70% > 20% > 10%，剛好符合。Algorithm 2 比較實際排序與這個目標排序，逐個位置計算差距的平方，再取負號：

Proximity=−[(2−2)2+(1−1)2+(0−0)2]=0\begin{aligned}\mathrm{Proximity} &= -\bigl[(2-2)^2 + (1-1)^2 \\ &\qquad + (0-0)^2\bigr] \\ &= 0\end{aligned}

Progress 一樣，proximity 為甚麼不同？

現在比較兩條候選路徑。兩者都給「完成兩個 milestones」70% probability，所以 progress 同分：

左右滑動表格，查看全部分數 →

路徑P(0), P(1), P(2)ProgressProximity
A[0.1, 0.2, 0.7]0.70
B[0.2, 0.1, 0.7]0.7−2

再看剩下的 30%。A 的第二選擇是「完成一個」；B 的第二選擇卻是「一個也沒完成」。換句話說：如果模型猜錯了「全部完成」，A 的後備判斷仍然比較有進展。 單看同樣是 0.7 的 progress，就看不到這個差別。

A 把結果排成 [2, 1, 0]，與目標排序完全相同。B 則排成 [2, 0, 1]，最後兩個位置倒轉了。因此 B 得到 −(0² + 1² + 1²) = −2，A 則得到 0。Progress 同分時，KG-RAG 便優先保留 A。

為甚麼 0 比較好？它代表「排序沒有扣分」，不是「沒有進展」。 差距的平方只可能是 0 或正數；加上負號後，分數就只可能是 0 或負數。完全吻合目標排序時，沒有任何扣分，所以 0 已是最高分。可以想成一開始有 0 分，每個排錯的位置都會扣分。

這也解釋了 proximity 的意思：它量度的是離理想排序有多近，不是 UI 上還要走幾步。0 也不代表任務肯定完成。例如 [0.32, 0.33, 0.35] 與 A 排序相同，同樣得到 0，但判斷明顯不那麼肯定。Proximity 只看名次，沒有保留 probabilities 之間的差距。[論文 Algorithm 2]

Actions 是否真的完成了 milestones，仍要由 trajectory evaluator 判斷。Proximity 只是把 evaluator 給出的 probabilities 整理成一個排序分數。

Jev 的 Score：預期完成多少？

Score=0×0.1+1×0.2+2×0.7=1.6\begin{aligned}\mathrm{Score} &= 0\times0.1 + 1\times0.2 \\ &\qquad + 2\times0.7 \\ &= 1.6\end{aligned}

這是以 probability 加權的 level 平均數。平均的是 milestone 數量，不是 logits。1.6 表示分布下的期望值，並不代表介面真的完成了小數個 milestone。[官方 Score 文件]

Jev 的 Score confidence：判斷有多集中？

為甚麼有了 Score，還要 confidence？「肯定完成 1 個 milestone」和「一半機會完成 0 個、一半機會完成 2 個」的平均都是 1，但後者的判斷分歧大得多。Confidence 把這種分散程度濃縮成一個數字，讓程式決定是否需要更多證據。在 BFS 中，我們可以測試：遇到分散的判斷時，多保留幾條候選路徑。

Levels 是有順序的答案刻度；n 才是刻度的數量。這裡的三個 levels 是「完成 0、1、2 個 milestones」，相鄰兩級相差 1，所以 0 距離 2 比 1 距離 2 更遠。「貓、狗、鳥」也是三個 classes，卻沒有這種距離，應使用 Choice。公式按 level 的索引計算等距步幅；對「低、中、高」這類文字標籤，等距是評分方式的設定，不代表現實差異必然相等。

沿用同一個分布：P(0) = 0.1、P(1) = 0.2、P(2) = 0.7。最可能答案是完成 2 個 milestones。Confidence 在問：其他可能性，是否也集中在這個答案附近？這與 Score 把所有 levels 加權平均、得到 1.6，是兩個不同問題。

第一步：量度 probability 離最可能答案有多遠

想像在數線上放 100 顆棋子：10 顆放在 level 0、20 顆在 level 1、70 顆在 level 2。現在量度每顆棋子離最可能答案 2 有多遠。10 顆相距兩格，20 顆相距一格，70 顆已經在那裡。平均距離就是：

D=0.1 ∣0−2∣+0.2 ∣1−2∣+0.7 ∣2−2∣=0.2+0.2+0=0.4\begin{aligned}D &= 0.1\,|0-2| + 0.2\,|1-2| \\ &\quad + 0.7\,|2-2| \\ &= 0.2 + 0.2 + 0 = 0.4\end{aligned}

把這個距離叫做 D。它的單位是 levels，不是 probability。D 越小，分布越集中在最可能答案附近。由於答案有順序，相差一個 level，應該比相差兩個 levels 扣得少。

第二步：找一個「平均分散」的比較基準

要把距離變成正規化的 confidence，需要一把尺。Jev 文件選用的基準是 uniform distribution：每個 level 的 probability 一樣。對 0、1、2 三個 levels 而言，中間位置是 1。

LEVEL 0離中間位置 1：一格Probability：1/3
LEVEL 1離中間位置 1：零格Probability：1/3
LEVEL 2離中間位置 1：一格Probability：1/3
基準把 probability 平均分給三個 levels，再量度它們離數線中間位置的平均距離。
U=∣0−1∣+∣1−1∣+∣2−1∣3=1+0+13=23\begin{aligned}U &= \frac{|0-1|+|1-1|+|2-1|}{3} \\ &= \frac{1+0+1}{3}=\frac{2}{3}\end{aligned}

2/3 就是這樣來的：距離 1、0、1 的平均數。 它不是訓練出來的參數，也不是「有三分之二機會正確」。分母由 level scale 決定。若有 0–4 五個 levels，基準就會變成 (2 + 1 + 0 + 1 + 2) / 5 = 6/5。

這裡有兩個不同的參考點：分子量度離這次預測的最可能 level有多遠，本例是 2；分母則量度 uniform reference 離整把尺的中間位置有多遠，本例是 1。不要把分母的中心也移到 2。這是 TypeSafe 定義的 normalization 方式。

第三步：把「分散程度」轉成 confidence

先把 D 除以基準距離 U，再用 1 減去這個比例，最後把負數截到 0：

Confidence=max⁡ ⁣(0, 1−DU)\mathrm{Confidence}=\max\!\left(0,\,1-\frac{D}{U}\right)

這樣設計後，D = 0 時 confidence = 1，因為所有 probability 都在同一個 level。當 D 等於基準的分散程度，confidence 就是 0。若 D 更大，也一律取 0，因為 uniform baseline 只是參考值，並非所有分布中最大的距離。這是一個選定的統計指標，並非 confidence 唯一可能的數學定義。[TypeSafe 的定義]

回到我們的候選路徑，平均距離 0.4 是基準 2/3 的 60%。用 1 減去這個比例，便得到：

Confidence=max⁡(0, 1−0.423)=0.4\begin{aligned}\mathrm{Confidence} &= \max\left(0,\,1-\frac{0.4}{\frac{2}{3}}\right) \\ &= 0.4\end{aligned}

這次 spread 和最後的 confidence 剛好都是 0.4，純粹是巧合。例如候選 B 的分布 [0.2, 0.1, 0.7]，D 是 0.5，但 confidence 是 0.25。

Confidence = 0.4，不代表「答案有 40% 機會正確」。 模型給「完成全部」的 probability 仍是 0.7；confidence 描述的是分布是否集中在最可能答案附近。模型也可以非常肯定「完成 0 個」，所以 high confidence 不代表路徑有前景。這是 Score 的公式；沒有高低順序的 Choice 使用另一個公式。

試試看：最可能的答案不變，分歧可以有多遠？

完成 2 個的 probability 固定為 70%。只改變剩餘 30% 放在 1 個還是 0 個。

0 個 milestones
10%
1 個 milestone
20%
2 個 milestones
70%

D = 0.40 · Confidence = 0.40

從 2 看出去：1 只差一步，0 差兩步。同樣是 30% 的其他可能，放得越遠，D 越大，confidence 越低。這是示意計算，沒有呼叫 Jev。
指標結果它在問甚麼？
Progress0.7最高 probability 有多高？
Proximity0Probability 排序是否偏向較高完成數量？
Jev Score1.6預期完成多少 milestones？
Jev Score confidence0.4分布是否集中在最可能答案附近？

3 兩種評分方式，可以找到同一條路嗎？

可以。上面的 A/B 例子已經是一次相同決定：KG-RAG 用 proximity 打破 0.7 的同分；Jev 的 expected score 則是 A 得 1.6、B 得 1.5。兩者都選 A，只是計算的方式不同。

再把整個搜尋走一次。任務仍然是先到 Settings，再打開 Privacy Policy。為了清楚看見每次選擇，這裡用一個很小的 top-K search，設 K = 1：每輪展開一個 UI action，只保留一條候選路徑繼續走。這是會剪枝的搜尋，不是遍歷所有候選的 BFS。

兩種 scoring rule 使用同一組假設 probabilities，以及相同的終點畫面檢查。第二個版本是在我們的 search loop 裡，改用 Jev-style expected milestone score。Jev 提供判斷，搜尋流程仍然由程式控制。

第一輪：從 Home，選 Settings 還是 Help？

兩條路都尚未通過終點畫面檢查。Evaluator 給出以下估計：

左右滑動表格，查看全部分數 →

Probabilities 依次是 P(0)、P(1)、P(2)。KG-RAG 先比較 progress，再比較 proximity。
候選路徑ProbabilitiesKG-RAGprogress / proximityJev-style預期完成數量
Home → Settings[0.20, 0.70, 0.10]0.70 / −60.90
Home → Help[0.70, 0.20, 0.10]0.70 / −80.40

KG-RAG 保留 Settings：progress 都是 0.70，但 −6 比 −8 高。Settings 把結果排成 [1, 0, 2]，所以是 −(1² + 1² + 2²) = −6；Help 則排成 [0, 1, 2]，所以是 −(2² + 0² + 2²) = −8。

Jev-style scoring 也保留 Settings：它的 expected completion 是 0.70 + 2 × 0.10 = 0.90；Help 則是 0.20 + 2 × 0.10 = 0.40。直覺上，一條路很可能已完成第一個 milestone，另一條路則很可能一個也沒完成。

第二輪：從 Settings，選 Privacy Policy 還是 Notifications？

左右滑動表格，查看全部分數 →

兩種搜尋都繼續展開同一條 Settings 路徑。
下一個畫面ProbabilitiesKG-RAGprogress / proximityJev-style預期完成數量
Privacy Policy[0.02, 0.08, 0.90]0.90 / 01.88
Notifications[0.20, 0.70, 0.10]0.70 / −60.90

兩者都選 Privacy Policy。KG-RAG 比較 progress：0.90 高於 0.70，這次不需要用 proximity 打破同分。Jev-style scoring 則偏好較高的 expected count：0.08 + 2 × 0.90 = 1.88。最後，相同的畫面檢查確認 Privacy Policy 已經打開。

HomeSettingsPrivacy Policy
選了同一條 trajectory，也確認到達同一個終點；使用的是不同評分方式。

這個例子的重點是：分數不同，行為不一定不同。剪枝時真正影響選擇的，是誰排在前面。這裡兩種規則每次都選同一條路。它示範了「可以一致」，但不代表兩個訓練過的模型總會給相同 probabilities 或搜尋結果。下一個例子便說明，為甚麼仍然要分清楚這些分數。

4 對我們的 BFS，我會怎樣測試？

現在把 A 與一條「模型很肯定它沒甚麼進展」的路徑比較：

相同的 distributions，四種不同的摘要分數。
路徑分布ProgressProximity預期完成數量Confidence
A[0.1, 0.2, 0.7]0.701.60.4
C[0.9, 0.08, 0.02]0.9−80.120.82

C 的 confidence 更高，但 A 更值得探索。 模型很肯定一條路失敗，不等於那條路值得繼續展開。如果最高 probability 是主要排序依據，而 proximity 只用來打破同分，C 就可能排在 A 前面。這是按字面公式推導的結果，並不代表我們已在實際程式中重現了這種錯誤。

如果做下一輪 ablation，我會把三個決定分開：

  • 下一輪展開甚麼：嘗試以 expected milestone count 作主要 progress heuristic。
  • 甚麼路徑看來已完成：檢查完成所有 milestones 的 probability，再配合適合任務的成功驗證。
  • 哪裡需要更多判斷：用 uncertainty 決定是否重新評分，或保留更多候選。低 confidence 就直接剪枝，可能錯過好路徑。

Expected progress 仍然只是 heuristic，不保證最終成功。完成較少 milestones 的路徑，也可能有更好的後續選擇；等權平均還假設每個 milestone 同樣重要。真正有意義的實驗，是固定 evaluator、候選圖和搜尋預算，只改 scoring rule，再比較找到多少成功路徑，以及花了多少搜尋成本。

5 Jev 在程式裡負責甚麼？

首先，我們到底叫 Jev 做甚麼？

可以把它想成大型程式裡，一個職責明確的 function call。我們提供待判斷的證據，叫做 state，再寫下問題，以及允許答案的描述。Jev 回傳 probabilistic judgment；我們的 code 再決定如何處理。

沿用開啟 privacy policy 的任務，三種 question types 可以這樣理解：

  • Noul：「提供的 trajectory 是否顯示 privacy policy 已經打開？」回傳 yes 的 probability。
  • Choice：「這段描述屬於哪種畫面：Settings、Help、Privacy Policy，還是 Other？」回傳 category、整個分布，以及 confidence。
  • Score：「這條 trajectory 完成了多少 milestones？」先定義有順序的 0、1、2 三個 levels，再回傳分布、預期 level，以及 confidence。

Typed 的意思，是答案符合宣告的格式，而且落在允許的答案範圍內。這不代表模型一定理解正確：畫面明明是 Help，卻選了 Privacy Policy，仍然是可能的語意錯誤。Types 限制了程式會收到甚麼，卻沒有替我們驗證現實。[Noul] [Choice] [Score]

Jev 會取代整個 KG-RAG 嗎？

最自然的實驗，是替換或比較其中的 trajectory evaluator。KG-RAG 的 graph expansion 仍然負責提出路徑，ranking code 仍然決定下一輪 frontier，offline knowledge construction 和 online retrieval 也各有工作。Jev 能夠評分，不會自動接手整套系統的職責。

假設 evaluator 回傳 [0.1, 0.2, 0.7]。無論分布來自我們的 LLM 還是 Jev，普通 code 都能算出 Score 1.6 和 confidence 0.4。接著，我們可以測試「用 expected progress 排序；evaluator 不肯定時，多保留一些候選路徑」這類策略。這是我們的設計選擇，confidence 公式本身不會替我們決定。

反過來，在現有 scorer 加上相同兩條公式，也不等於重現了 Jev 的模型。算出一樣的數學結果很直接；底層 probabilities 的品質和 calibration 是否一樣，則需要實驗。

這裡的「parallel」是甚麼意思？

我們的 BFS 在同一輪評估多條候選路徑。Jev 的 speculative fan-out，則是對已經取得的證據一次問多條問題，即使 code 還不知道最後會用到哪些答案。

例如一張 support ticket：逐步流程先問「是不是 bug？」等答案是 yes，才問「bug 有多嚴重？」Fan-out 把兩條問題一起問。如果原來是帳單問題，code 就忽略 severity。由於 ticket 本來已經包含兩個判斷需要的證據，提前問可以省下一次來回呼叫。[官方 fan-out 模式]

但它不能憑空產生新證據。如果判斷某個 GUI action，必須先看到尚未觀察的下一個畫面，我們仍然要取得那個 observation。把已知問題一起問，與消除真正的依賴關係，是兩回事。

為甚麼比較速度時，要留意我們的 baseline？

TypeSafe 描述了一套為 structured judgments 設計的模型和 parallel sampler。與生成文字或 JSON 的 LLM 比較，可以說明這種介面的動機；但我們的 scorer 已經直接讀指定 logits，不需要生成長篇解釋。要知道 Jev 對我們的 BFS 實際有多少加速，仍需在相同 trajectory judgments、相近品質和 serving 條件下直接比較。[TypeSafe 發布文章]

6 Probability 可靠嗎？用 calibration 檢查

「預測 probabilities 對應實際結果的發生頻率」可以換成一句話：當模型對很多不同例子都說「完成的機會約 70%」，事後檢查，應該有大約七成真的完成。這就是 calibration 想檢查的事情。

例如，收集 100 條沒有用來訓練的不同 trajectories，模型對每條都給出約 70% 的「完成兩個 milestones」probability。再逐條查看實際操作紀錄，核實是否完成：

100 條路徑，每條都預測 70% 完成機會

綠色：實際完成兩個 milestones · 灰色：未完成兩個

預測 70% → 實際 70/100：這一組吻合。

示意資料。每一點是一條不同路徑，不是把同一條路徑重新問模型一次。

切換成 40 條完成：模型仍然說 70%，但結果只有 40%。這一組的完成機會被高估了。這裡的 70% 不是完成了 70% 的 milestones，也不是 confidence = 0.7；它是模型對「兩個 milestones 都完成」這件事給出的 probability。

單一組例子只方便理解。真正評估時，要在不同 probability 區間收集足夠的案例；有限樣本不必剛好吻合。TypeSafe 把改善這種機率可靠性列為 RLCD 的目標。[官方 AI primer]

Confidence 看模型的答案分布有多集中；calibration 要拿預測與實際結果比較。只看一條路徑的分布就能算 confidence，但看不到真實結果，就無法驗證 calibration。模型可以很肯定，卻經常判斷錯誤。

對我們的 BFS，計算 Jev 式 Score 和 confidence 很容易；更值得驗證的是：這些 probabilities 是否可靠，以及使用它們後能否用較少搜尋找到正確路徑。

資料來源與範圍

本文根據 2026 年 10 月 22–23 日查閱的公開論文與文件撰寫。數值例子是示意計算，不是 benchmark 結果或即時 Jev 輸出。Progress 按論文 §3.2 的文字取最高 probability，proximity 作為次要排序依據；本文沒有核對實作程式。兩輪搜尋例子刻意固定 probabilities、K = 1 與終點檢查，只比較 scoring rule。

  1. Guan et al., KG-RAG, EMNLP 2025，尤其是論文的 §3.2 與 Algorithms 1–3。
  2. Aman Arora, Jev: A New Way to Make Probabilistic Decisions：引起這次比較的文章。
  3. TypeSafe 文件：Score、Confidence、Speculative fan-out。
  4. TypeSafe：Introducing System One Models & Jev 與 AI primer。