摘要

我是 Sapeet 股份有限公司 的演算法工程師西田。

本文假設要分派到公司內部專案，使用 TypeSafe AI 的 Jev1 對「專案徵才條件」與「工程師技能表」的組合（以下稱為配對）進行評分，衡量它們有多適合。以 Claude Opus 5.5 的判定取代人工標準答案，並與 Claude Haiku、日文嵌入模型比較，結果如下：

• 速度與費用：每個配對 182 ms、$0.00009，約為 Haiku 5.5 的 1/8 時間、1/5 費用
• 排序精度：候選者的排列順序與 Haiku 相當或更好（但與 Haiku 4.5 之間未達統計顯著差異）
• 篩選：依 Jev 的匹配度由低到高排序，最多可先排除 19 個配對，且不會把正確配對排除掉（Haiku 5.5 為 17 個）
• 信心度：Jev 信心度較低的配對，其與標準答案的落差約為其他配對的 3 倍，可作為人工複查的提示

下圖以橫軸表示回應延遲（越左越快），縱軸表示與標準答案排序的接近程度（越上越準確），點的大小表示費用。垂直線為 95% 信賴區間。與其他方法相比，Jev 位於左上角，也就是又快又準的位置。

0. 什麼是 Jev

Jev 是在 2026 年 9 月開始早期提供的模型1。它不生成文章，而是接收輸入的狀態（state）與型別固定的問題，並以機率形式回傳答案。本文使用以下兩種問題型別：

• Score：以有序階段（例如：無關 / 部分符合 / 幾乎完全符合）進行評分，並回傳各階段的機率與信心度。若機率集中在某一個階段，信心度就高；若分散到多個階段，信心度就低2
• Noul：回傳敘述正確的機率

費用為每 100 萬輸入 token $0.042，輸出免費3。

Jev 的信心度不同於讓 LLM 回答「自己有多有把握」所得出的值，而是由模型輸出的機率分布計算而來。

Jev 的應用

目前已公開許多 Jev 的應用案例，尤其常見於以下領域：

• 詢問分流／文件分類
• 驗證 agent 的工具呼叫
• LLM 輸出的評估（取代 LLM-as-a-judge）

另外，自版本 1.14.0 起，已正式支援圖片輸入，相關應用也備受關注4。

1. 本文介紹的 Jev 示範

在將工程師分派到產品時，這種做法往往容易被包裝成組織內「憑感覺做得剛剛好」的潛規則。我所屬的 Sapeet 正是在處理這類問題，以及推動組織隱性知識的 AI 解決方案與 AI 產品開發。

因此，為了調查 Jev 在分派場景中的 AI Transformation（AX）能扮演什麼角色，我們進行了實驗。本文將介紹其結果與討論。

2. 方法

資料與匹配度

我們準備了 5 個虛構專案與 8 位工程師，共評分 40 組配對。資料先由 Claude 起草，再經人工審閱後定稿，未使用任何真實人物或公司內部資料。工程師包含只具備相近領域經驗者、技能較舊者、經驗過於豐富的技術主管，以及描述含糊不清者，以納入較難判斷的案例。

ID專案主要技術P1EC 金流基礎架構的分期付款／後付款支援Go、gRPC、PostgreSQLP2經營儀表板的新開發React、Next.js、TypeScriptP3測試與正式環境的 IaC 化與 CI/CD 整備Terraform、AWS、GitHub ActionsP4營收資料基礎架構的可靠性改善SQL、dbt、BigQuery、AirflowP5健身 App iOS 版的品質改善Swift、Swift Concurrency、HealthKitID &nbsp職種經驗年數特徵E1後端 7 年負責以 Go 建置 EC 金流基礎架構E2前端 4 年以 React 開發 SaaS 的管理頁面與分析頁面E3SRE 6 年主導將既有 AWS 環境遷移為 Terraform 管理E4資料工程師 5 年負責廣告成效衡量基礎架構。未曾接觸營收／會計資料E5伺服器端 15 年過去以 Objective-C 開發 iOS 健康照護 App。近 2 年主要使用 JavaE6技術主管 18 年前一份工作主導 EC 金流基礎架構的分期付款／後付款支援。現在以設計與審查為主，實作多半只在 PoC 或障礙調查時進行E7iOS 4 年以 SwiftUI 負責改善健身 App 的當機率E8工程師 2 年什麼都做一點的內部工具擔當。描述含糊，自我評估偏寬鬆對每一組配對，從以下 4 個觀點判定後，加權合併成 0–1 的「匹配度」。

觀點問題型別階段技術堆疊一致性Score從無關到幾乎完全一致的 5 階段領域經驗Score無 / 有相近領域經驗 / 有同領域經驗對難度的經驗程度Score從明顯不足到非常充裕的 4 階段最近實務是否使用主要技術Noul否 / 是另外，Jev 的 Score 會回傳各階段為正解的機率與期望值。

比較的方法

手法內容Jev以 Score 與 Noul 判定 4 個觀點Claude Haiku 5.5以 Structured Outputs 讓模型回答同樣 4 個觀點，信心度則由模型自我申報Claude Haiku 4.5（temperature 0）同上。由於無法調整 Haiku 5.5 的 temperature，因此另外加入作為輸出固定條件ruri-v3-310m（以下稱 ruri）日文嵌入模型。以職缺說明與技能表的餘弦相似度作為匹配度### 標準答案與評估方法

以更高階的 Claude Opus 5.5 對相同 4 個觀點判定 5 次，並將其匹配度平均值作為標準答案。本文中的「精度」是指與 Opus 5.5 的判定有多接近。

手法細節（匹配度計算、權重、呼叫條件）匹配度的計算

階段從低到高依序編號為 0、1、2、…，並以 編號 ÷ (階段數 − 1) 轉換為 0–1 分數。Jev 的 Score 會回傳階段的期望值，因此用同樣公式計算時，分數也可能落在階段與階段之間。Noul 則直接把「是」的機率當作分數。LLM 會以階段標籤作答，因此依階段編號求得分數。

將各觀點的分數乘上專案類型的權重後加總。權重由作者決定，並在所有方法中共用。若改變權重，結果可能會不同。

專案類型技術堆疊領域經驗經驗程度最近實務基礎整備、資料基礎架構0.450.250.200.10新規開發0.550.150.200.10品質改善0.300.400.200.10既有功能擴充0.400.300.200.10配對的信心度是 4 個觀點信心度中最低者，取 5 次結果平均。由於 Noul 沒有信心度，因此參照「二選一問題的信心度等於 2·p_max − 1」的觀察5，使用 2·max(p, 1 − p) − 1 作為信心度。

呼叫條件

• Claude 各模型皆透過 Amazon Bedrock 的 global 跨區域推論設定檔，從東京區域呼叫；Haiku 5.5 關閉 thinking，Opus 5.5 則無法關閉，維持預設值
• Jev 與 Claude 皆對 40 個配對各評估 5 次，逐一順序執行（2026 年 10 月 15 日）。精度以各方法 5 次平均匹配度的排名計算
• ruri 在 Apple Silicon 的 GPU 上評估 1 次
• 費用以 token 數 × 公布價格計算

3. 結果

排序精度

對每個專案，將 8 位工程師依匹配度由高到低排序，並計算與標準答案排序的接近程度（Kendall 的 τ_b6：1 表示完全一致，0 表示無關，越高代表排序越接近），再對 5 個專案取平均。

手法與標準答案的排序相關性 [95% 信賴區間]Jev**0.87 [0.67, 1.00]Haiku 5.50.61 [0.25, 0.89]Haiku 4.5（temperature 0）0.78 [0.53, 0.95]ruri0.47 [0.06, 0.81]Jev 的數值最高，但與 Haiku 4.5 的差異在統計上並不顯著**（p = 0.46）。由於只有 40 個配對，誤差範圍較大，因此最多只能說「與 Haiku 相當或更好」。另外，作為標準答案的 Opus 5.5 自身 5 次判定之間的排序相關性為 0.95，表示標準答案本身波動很小。

Jev 在 5 個專案中都把與標準答案相同的人排在第 1 名。不過，EC 金流基礎架構（P1）中，標準答案第 1 名的技術主管（E6）與第 2 名的後端工程師（E1）差距只有 0.03，而 Jev 也只有不到 0.02 的極小差距。E6 在前一份工作中主導過與 P1 相同的分期付款／後付款支援，因此標準答案與 Jev 都把這點視為重要。Haiku 4.5、5.5 則把目前仍在實作的 E1 排在第 1 名。

LLM 與其他方法差異最明顯的是營收資料基礎架構（P4）與 E6 的配對。E6 沒有使用 P4 所需的 dbt 或 BigQuery 的經驗。標準答案與 Jev 都將其經驗程度判為「稍嫌不足」，而 Haiku 4.5、5.5 都判為「非常充裕」。看起來 Haiku 較重視經驗年數的長短。

速度、費用與穩定性

手法延遲中位數每 1,000 個配對的費用做 5 次評估時的波動（標準差）Jev**182 ms$0.0930.003Haiku 5.51,472 ms$0.500.031Haiku 4.5（temperature 0）1,740 ms$4.640.000ruri284 ms$0（本地）―- 速度**：Jev 比 Haiku 快 8–10 倍。不過，由於 Jev 的 API 與 Bedrock 到伺服器的路徑不同，不能直接硬比。另外，ruri 的數值是每個配對都重新計算嵌入向量時的結果；若事先計算，速度還能更快

• 費用：Jev 約為 Haiku 5.5 的 1/5、Haiku 4.5 的 1/50（Haiku 4.5 的每 token 價格是 Haiku 5.5 的 10 倍）
• 穩定性：Jev 的匹配度標準差為 0.003，輸出相當穩定，但並非完全為 0。Haiku 5.5 在不同配對之間的標準差接近 0.1

TypeSafe AI 說明其產品「比 LLM 快 20–200 倍，費用為 1/40–1/400」1，但這次的差距比那個數字小。推測是因為這次比較的對象本身就是 LLM 中體積較小、成本較低的模型。

篩選與信心度

標準答案中匹配度低於 0.2 的「明顯不合適」配對共有 40 個中的 22 個。我們依各方法的匹配度由低到高逐一排除，計算在標準答案中匹配度達 0.2 以上、也就是不該被排除的配對混入之前，可以排除多少個。

手法可無誤排除的配對數（22 個中）Jev**19**Haiku 5.517Haiku 4.5（temperature 0）―（匹配度為 0 的同分有 20 個，其中混入 1 個錯誤）ruri3Jev 可無誤排除 19 個配對，略優於 Haiku 5.5 的 17 個。對於明顯不合適的配對，不論 Jev 或 LLM，都能做到一定程度的排除。

信心度可作為 Jev 的匹配度可信到什麼程度的參考。Jev 信心度最低的 20%（8 個配對），其與標準答案的落差（匹配度差的絕對值平均）約為其他配對的 3 倍（0.082 對 0.026）。信心度最低的 8 個配對（占整體 20%）中，包含了與標準答案落差最大前 8 名中的 5 個。若優先請人工複查信心度低的配對，就能更有效率地找出落差較大的案例。以 Haiku 5.5、4.5 的自我申報信心度用相同方式計算時，8 個配對中只有 4 個。

我們也試了只把低信心度配對交給 Haiku 5.5 重新判定的兩階段流程，但精度與單獨使用 Jev 相同（0.87），費用卻約增加 2 倍。若改由更高階的 LLM 或人工重新判定，結果可能會不同。

4. 討論

從這次結果來看，Jev 很適合在候選者很多時，用來決定人工確認的優先順序，作為第一階段篩選。例如可這樣使用：

1. 先用 Jev 為所有配對打分
2. 對匹配度特別低的配對降低確認優先度
3. 其餘配對則依匹配度高低由人工確認；信心度低的配對因較容易出現分歧，應特別注意

配對數會隨專案數 × 工程師數增加。例如若有 100 個專案 × 100 位工程師（1 萬個配對），依本次實測值計算費用如下：

手法1 萬個配對的費用Jev**約 $0.9**Haiku 5.5約 $5Haiku 4.5（temperature 0）約 $46Opus 5.5約 $210與用於標準答案的 Opus 5.5 相比，Jev 的費用約為 1/220。

本次實驗有以下限制：

• 標準答案不是人類判斷，而是 Opus 5.5 的判定；資料也由 Claude 起草。同系模型之間較容易做出相似判定，因此可能對 Haiku 有利
• 只有 40 個配對，規模偏小，精度差距可能落在誤差範圍內
• 有研究指出，Score 的信心度在偏離訓練資料的任務上可能過度自信7
• 在招募與分派中使用 AI，仍需檢驗公平性並由人做最終判斷。本實驗並未檢驗公平性

5. 結論

Jev 在排序表現上與 Haiku 同等甚至更好，但速度遠快於 Haiku、成本也更低，而且每次試驗的輸出波動極小。對於匹配度特別低的配對，在本次資料中可無誤排除，信心度可作為人工應該優先查看的提示。當使用 LLM 全面判定成本過高時，Jev 有潛力作為第一階段篩選工具。

最後，本次的分派只是示範。實務上的招募或分派要導入這種簡化系統並不容易。另一方面，利用 AI 來提升招募與人事效率、或進行自動化，本身也是重要的社會課題。Sapeet 正持續開發 AI 解決方案與 AI 產品，希望透過科學化的人類研究，打造更能貼近人與人溝通的支援工具。例如在這個問題上，預期需要處理以下課題：

• 如何將真實現場中獨有的評估軸融入 AI
• 如何建構可信、公正且可解釋的 AI

若你對這類工作有興趣，歡迎參考我們公司的招募頁面。

1. TypeSafe AI，開始提供 AI 模型「Jev」早期體驗（gihyo.jp） ↩ ↩2 ↩3
2. Score - TypeSafe docs ↩
3. Models - TypeSafe docs ↩
4. Jev: For the builders AND dreamers - TypeSafe AI Blog ↩
5. AnthusAI/Jev-Calibration（GitHub） ↩
6. 肯德爾順位相關係數（BellCurve） ↩
7. scienthoon/jev-ood-calibration（GitHub） ↩

原文出處：https://qiita.com/akimasanishida/items/8d965a85f2aac8ebcb12