Laya 本機 System One 模型：安裝、用法與 Jev 比較

Laya 提供哪三個模型#

以下列出三個 checkpoint 的預設 context；預設截斷長度與可設定上限不同，長文件設定見後文：

權重大小約 647 到 843 MB，實際執行還要加上 PyTorch、模型結構、中間張量與批次資料的記憶體。它不是一個幾十 MB 的分類器；若正式服務需要高併發，仍要估算 GPU、常駐記憶體與冷啟動。

Laya 的輸出介面模仿 System One 常見的三種 primitive：choice、score 與 noul。它也是非自回歸模型，一次 forward pass 可以處理同一 state 上的多個問題。

安裝與第一個本機判斷#

先建立獨立 Python 環境，再安裝 PyPI 套件：

1
python3 -m venv .venv
2
source .venv/bin/activate
3
pip install laya

README 建議從 Router 開始。它會依文字語言與 script 選擇英文或多語 checkpoint：

1
from laya import Router
2

3
router = Router(preload=True)
4

5
state = {
6
    "subject": "帳單重複扣款",
7
    "body": "信用卡被扣了兩次，請協助退款。",
8
}
9

10
questions = {
11
    "department": {
12
        "type": "choice",
13
        "instructions": "哪個部門應處理這則訊息？",
14
        "criteria": {
15
            "billing": "帳單、付款與退款",
16
            "technical": "系統錯誤與串接問題",
17
            "sales": "價格與新合約",
18
            "other": "其他",
19
        },
20
    },
21
    "refund_requested": {
22
        "type": "noul",
23
        "instructions": "使用者是否明確要求退款？",
24
    },
25
}
26

27
result = router.predict(state, questions)
28

29
print(result["routing"])
30
print(result["answers"]["department"])
31
print(result["answers"]["refund_requested"])

preload=True 會預先載入 checkpoint，以換取之後較低的呼叫延遲，但也會增加啟動時間與記憶體使用量。第一次執行還需要從 Hugging Face 下載權重；正式部署應先完成下載並固定模型 revision，避免啟動時受到外部網路或權重更新影響。

如果已確定只處理單一語言，也能直接載入指定模型：

1
import laya
2

3
agent = laya.load(
4
    "convaiinnovations/laya",
5
    subfolder="multilingual",
6
    device="cuda",
7
)
8

9
result = agent.predict(state, questions)

基本介面最初依 Laya 0.3.4 repository 與模型卡整理；2026-10-15 維護時另核對官方 README 的長文件與已知限制。本文沒有下載完整權重跑 GPU 推論，安裝與推論程式屬文件檢閱範例，延遲以專案公布的特定環境資料為準。

33 ms 很快，但條件要寫完整#

Laya 公布的 Tesla T4 測量中，多語模型單一問題約 32.8 ms；一次處理 10 個問題為 72.3 ms，平均每題 7.2 ms。這是 GPU forward pass 的測量，不包含首次下載、模型載入、應用程式排隊、網路 API 包裝或 CPU 環境差異。

更重要的是準確率。專案自己的 benchmark 明確揭露：

• 目前 BENCHMARKS 所列的基礎 laya 與 laya-multilingual typed-decisions zero-shot 分數為 0.362 與約 0.352（模型卡舊表仍列 0.342，這裡依 repository 的結果檔說明），接近 0.318 的隨機基準，也低於 0.461 的多數類別基準。
• 專門微調的 laya-typed-decisions 公布 0.766；官方 BENCHMARKS 註明這是該 benchmark 自身訓練 split 的結果，且該列尚無已提交的原始結果檔，不應解讀成獨立 holdout 準確率。
• 高分能力主要來自針對該 workflow 的微調，不能當成任意領域的 zero-shot 表現。
• 模型原始輸出過度自信，專案建議以自己的資料重新做 temperature fitting。
• score 是目前較弱的 primitive，大量選項也會受到 Token 分配影響。

這些限制反而說明比較合理的定位：Laya 是可自行微調的快速判斷底座，不是下載後就能理解所有公司分類規則的萬用模型。

Laya 長文件：先確認有沒有被截斷，再談準確率#

截至 2026-10-15，官方 README說明 laya-multilingual 可用 max_len=8192，但預設仍是 1,024 Token。只把長信件交給預設 Router，可能沒讓模型讀到末段條件；英文佔多數時，也可能路由到英文 checkpoint。

延續前面的 router 與 questions，文件提供的明確指定方式如下。long_document 應換成實際待判斷文字；這段未在本機載入模型執行：

1
long_document = "將完整待分類信件放在這裡"
2
result = router.predict(
3
    long_document,
4
    questions,
5
    model="multilingual",
6
    max_len=8192,
7
)

驗收時，準備一封有人工答案的長信件，把決定分類的同一句資訊分別放在開頭、中段、末段，其餘內容保持一致；逐一記錄套件版本、checkpoint revision、實際 Token 長度、回傳的 routing 與分類結果。若只有末段版本錯誤，先排查截斷，再檢查語意能力。把上限設成 8,192 不會保證所有長度都同樣準確，也不能把字元數直接當成 Token 數。

這是建議的控制變因驗收設計，本文未執行長文件推論；它能幫助定位問題，不能單憑三筆結果證明正式資料準確率。

Noul 高信心答錯：把正反案例和標籤一起驗收#

官方已知限制指出，英文 checkpoint 的 noul 可能受 false:／true: 選項文字主導，甚至對明確正例仍給出高信心否定。原文的退款問題使用未指定 criteria 的簡短寫法；接入真實服務前，應補上明確判準並做成對測試。

以下是同一 refund_requested 問題的替代規格，屬待驗收範例；保留 true／false 作為 criteria key，labels 則改變模型看到的標記：

1
refund_question = {
2
    "type": "noul",
3
    "instructions": "使用者是否明確要求退款？",
4
    "criteria": {
5
        "true": "使用者明確要求退回款項",
6
        "false": "使用者沒有提出退款要求",
7
    },
8
    "labels": {"true": "A", "false": "B"},
9
}

用「請退回這筆重複扣款」與「只想確認帳單，不需要退款」做正反例，再換成實際流量中的否定句、引用文字和模糊請求。比較預設與替代標記、英文與 multilingual checkpoint；替代標記本身也可能改變結果，不能當成已修好的證明。若要改用中性 key 的雙選項 choice，回傳契約也會改變，應同步檢查呼叫端解析。

校正與最終驗收要使用不同資料#

官方 README 提醒，微調 Notebook 的 calibration samples 取自訓練項目。若用同一批資料擬合 temperature，又用它宣稱信心可靠，無法回答新資料是否有效。可以把資料用途分成模型訓練、校正／門檻選擇與最終測試；同一客服對話的改寫或多封回信應按群組隔開，避免相似內容跨集合。

固定最終測試集後，同時記錄分類正確率、接受自動處理的比例，以及「被接受案例中的錯誤率」。先用校正集選門檻，再只在未參與調整的測試集驗收；不能看到測試錯誤就反覆調門檻，還把該結果稱為 holdout。這是部署驗收建議，並非本文已完成的模型評測。

Laya 和 Jev 怎麼選#

少量或不固定的請求，Jev API 通常比較容易估算；資料敏感、請求量大、能維護模型服務，或需要針對內部標籤微調時，Laya 才比較有評估價值。

不要只拿單次推論價格比較。自架模型還有 GPU 閒置、容器映像、權重更新、監控、校正與事故處理成本；雲端 API 則要考慮資料傳輸、供應商限制與服務可用性。

上線前要做的四個檢查#

第一，先建立自己的 holdout dataset，不要使用微調資料衡量正式準確率。第二，分語言看準確率與 ECE，尤其繁體中文不要和英文平均。第三，測試選項順序、other 案例及對抗性文字。第四，將高影響操作放在程式規則與人工審核後面。

「沒有文字生成」不等於「沒有 hallucination」。Laya 不會寫出 schema 外的答案，但仍會自信地分錯類；它的 README 也直接記錄英文 checkpoint 對非拉丁文字可能高信心答錯。格式安全與語意正確必須分開驗證。

想先理解這類模型的共同介面，可讀 Jev 是什麼？；若決定採用託管 API，可接著看 Jev TypeScript API 教學。如果需求來自 Codex 額度問題，則先確認 Skill、MCP 與 Router 的差異，不要把安裝套件當成成本優化完成。

常見問題#