Jev 式量化判斷 × 開源 Laya：用法研究與 Life OS 落地評估

Laya 能做什麼／不能做什麼

出處：site-packages/laya-0.3.4.dist-info/METADATA（PyPI 套件說明，446 行）＋同目錄 laya/agent.py、laya/common.py、laya/presets.py、laya/lang.py、laya/router.py 原始碼。

能做：

• 三種「型別化問題」（laya/common.py:11 QTYPES = {"choice": 0, "score": 1, "noul": 2}）：choice＝多選一（回傳標籤＋各選項機率＋信心度）、score＝序數評分（回傳序數量表上的期望值＋分佈（本 demo 設 0..3 分））、noul＝校準過的 P(true) 機率（0.0–1.0，二元判斷）。三型任意組合、一次前向傳遞全部問完（agent.py:241 system_one，agent.py:345 predict = system_one 是同一函式的別名）。
• 三個現成 checkpoint 加一個 Router 自動選型：laya（ModernBERT-large 421M，英文專用）、laya-multilingual（mmBERT-base 322M，100+ 語言，本機試跑用的就是這個）、laya-typed-decisions（ModernBERT-large 421M，針對「型別化決策」這個 benchmark 微調過）。Router 用純 Python 偵測腳本/語言（<0.5ms）再挑 checkpoint（METADATA 152–168 行）；中文屬於 Router 認得的腳本（laya/lang.py:41 han 區段的 Unicode 範圍表），但 METADATA 全文找不到針對中文的獨立準確率數字（grep -i "chinese|zh|mandarin|中文" 零命中）——只有「英文」與「其他 13/14 種語言」的聚合數字，中文效果未查證，只能靠自己的 demo 測。
• 直接載入單一 checkpoint（laya.load(model_id, device=..., subfolder=...)，agent.py:351-360，本機 demo 走的正是這條路）或用 laya.Router(preload=True) 常駐多顆換模型零延遲。
• 內建四組預設問題集（laya/presets.py）：router_questions（模型路由）、guard_questions（提示注入防護）、moderation_questions（內容審核）、triage_questions（客服工單分流），可以直接套或改。
• CPU 可跑（本機 M 系列 Mac、.venv 純 CPU 環境，本次 5 則樣本 4 指標全跑完，最慢一則 254ms，見 demo_output.txt）；官方數字是 T4 GPU 32.8ms/題（METADATA 表格，163 行一帶）。
• Apache-2.0 授權、自架零 API 費用（METADATA 「Cost | $0.042/1M tokens | $0 self-hosted」一列，337 行附近）。
• 支援微調：Kaggle 免費 2×T4 筆記本，RLCD（proper-scoring-rule 獎勵、GRPO 風格 policy gradient），約 4–5 小時跑完 4 epoch、3 萬題（METADATA 414–426 行「## Fine-Tuning」節）。筆記本本身沒有隨 PyPI 套件安裝（本機 find .venv/.../site-packages -iname "*.ipynb" 零命中），要微調得去 GitHub repo 抓，這條路本次未實測。

不能做／弱項（皆逐字出自 METADATA「Honest limits」與相鄰段落，336–353 行）：

• 零樣本幾乎等於亂猜：laya 與 laya-multilingual 兩顆未微調 checkpoint 在「型別化決策」benchmark 上準確率只有 0.362／0.342，對照隨機基準 0.318、多數類基準 0.461——都低於「照多數類猜」。微調後的 laya-typed-decisions 才到 0.766。Laya 的定位是「拿去微調的快速底座」，不是開箱即用的零樣本判斷引擎（METADATA 原文：「Laya is a fast base to specialise, not a zero-shot decision engine.」）。
• score（序數評分）是三型別裡最弱的一種：SST-5 情緒強度測試只有 0.372（METADATA 385 行附近）。
• 高基數選項（choice 超過約 20 個選項）準確率掉很多：Banking77（77 個標籤）只有 0.425，對照 Jev 的 0.870，原因是每個選項在固定 token 預算下只分到 3–4 個 token（METADATA 「Honest limits」段第二點）。
• 兩個未微調 checkpoint 出廠時信心度沒校準（laya-multilingual 「ships with no fitted temperatures at all」），沒重新校準前信心度不能拿來當自動放行的門檻——這點跟本機既有試跑 RESULT.md 的結論一致（「信心度不能當閘：錯的四題 confidence 0.44–0.49，對的 threads 連結題 0.48，兩邊重疊」）。
• 英文 checkpoint 在非拉丁文字上會整個崩掉（高棉語 0.000 準確率、信心度卻高達 0.952），必須靠 Router 事先做腳本偵測，不能靠模型自己的信心度察覺自己讀不懂。

本機 demo 結果（demo_scores.py，rc=0，5 則樣本 × 4 指標）

跑法：cd laya-trial && .venv/bin/python ../laya-usage-research/demo_scores.py，載入 laya-multilingual（21.4 秒），每則樣本一次問完 4 題的延遲 77–254ms（CPU）。四個指標對照貼文實例①設計：knowledge_density／packaging／traffic_hook／worth_expanding，全部是 score 型別、0..3 分。原始輸出見 demo_output.txt，彙總表：

這份 demo 本身就示範了「零樣本不夠當判準」的風險：plain-greeting（純問候，沒有任何知識內容）的 worth_expanding 得分 1.52，比 dream-media-luhmann（真實三部作品互相參照的長文）的 1.29 還高；分數區間全部擠在約 1.1–1.7 之間（最高 1.72）（滿分 3 分），5 則樣本的區分度很薄弱。這跟 METADATA 「Honest limits」講的零樣本準確率 0.34–0.36（僅略高於隨機基準 0.318）是同一件事的實測版本——不是 bug，是 Laya 本身誠實標注過的已知限制，也是本節第一段結論的直接證據：這顆模型現在只能證明「能跑、格式對」，還不能直接拿分數做決策。

用法拆解：Jev 式量化判斷的兩個實例（貼文摘要，出自工單「來源」節）

1. 貼文歷史評分：把自己過去發的 Threads 貼文／回覆逐則跑一組指標（知識密度、包裝手法、流量要素、值不值得延伸），把「這篇寫得好不好」從人工語感判斷變成一組數字。本檔上一節的 demo 就是照這個實例的指標設計直接複刻的最小範例。
2. 規劃（Plan）分流＋算指標：先依內容性質把規劃分到不同判斷集（例如：技術任務 vs. 對外溝通 vs. 一次性事件），再對該性質算對應指標，確保規劃品質、並加固執行邊界、避免 AI 對任務的理解在長對話中慢慢飄移。
3. 兩個實例共同的做法：先讓 AI 理解 Jev/Laya 的問法規則、自己先測一輪，人看結果給回饋，暴力 A/B 測試找出好用的指標定義；準確度本身不是重點——量化之後 AI 有「數字要被弄對」的強制力，這點跟純語意規則（讓 AI 自由心證判斷合不合格）是本質差異。

Life OS 候選判斷點（5 個，逐項附現有元件路徑）

1. 喚醒前置閘（要不要叫醒大模型）——scripts/wake-precheck-probe.sh。目前只是「空手率量測探針」：只數候選數量、一律 exit 0 不擋，腳本自己的註解寫明「等累積出真實空手率之後，才由 so85 決定哪幾支值得把它換成會回 rc=10 的真閘」——也就是說「這批輸入值不值得叫醒常駐對話」現在還沒有真正的語意判斷，只有計數。這正是既有研究卡（vault/raw/2026-09-21-輕量判斷模型當路由節點-Jev-TypeSafe-對LifeOS與ADHD的效應.md）點名的「最值錢的用法」，因為系統的成本大頭是喚醒常駐對話本身，不是分類動作。
2. 告警嚴重度——scripts/alert-inbox-pending.sh（五欄格式：時間／source／severity／status／訊息，見腳本 55 行附近註解）。目前的 severity 是每支產生告警的腳本自己手寫死的字串（例如 scripts/oneshot-coraline-ddrescue-watch.sh:15 的 alert() { # $1=severity $2=訊息 }、scripts/supervisor-witness.sh:140），不是從告警文字內容判斷出來的，同款告警文案不同人寫可能給出不一致的 severity（腳本 itunes-price-parity-watch.sh:10 自己的註解就點出這個風險：「共用一個 severity 或一句 reason 會讓兩者在 inbox 裡長得一樣」）。可以拿一個 score 問題對告警訊息文字打嚴重度分，跟人工填的 severity 做交叉核對，抓不一致。
3. 卡片人類板／系統板分類——rules/card-rules.md（ADR-0048）。現在「這是使用者本人開口要的事（human）還是 Life OS 自己的毛病（system）」是開卡當下由該線 AI 自行判斷，沒有腳本層的二次檢查；rules/card-rules.md 第 29 行明講 Astra 只吃 labels 含 system 的卡，貼錯標籤會讓卡片路由錯線。可以用 choice 型問題對卡片內容打分類，跟人填的 labels 對照當作 sanity check。
4. 語氣閘的語意層——hooks/line-tone-gate-check.py。目前是純規則／正則比對（EMOJI_PATTERN、URL_RE、LIST_PREFIX 等一串 re.compile，逐一 grep 確認過），只驗格式（emoji 位置、條列符號、全形半形混排這類）。~/.claude/CLAUDE.md 的既有教訓（工作軸「LINE 送出紀律」條）也點名「語氣閘只驗格式，關切作息這類內容禁令它一條都擋不到」——這種語意層的判斷（例如「這句話有沒有變成說教語氣」）正是 noul（是／否機率）型別可以補位的地方，但風險段會說明為什麼現在不建議急著接。
5. 引用冷卻前的相關度判斷——rules/citation-cooldown.md §1–2。文件明講「皆人工自律，無腳本強制，違反時的發現面＝條目引用記錄與使用者肉眼」（§2）。現有 scripts/cite-append.sh --check 只查「這部作品在不在冷卻期」（時間計數），完全不判斷「這次引用跟當下話題到底搭不搭」——這個相關度判斷現在整個是人工，可以用 noul（機率）問「這部作品的這個元素，跟目前談的主題是不是真的相關」，當引用前的第二道機檢。

資料需求

• 零樣本可以先跑起來，但如上一節 demo 所示，準確率貼著隨機基準，不能直接拿分數做自動決策，只適合當「先跑起來看格式、看有沒有區分度潛力」的探索階段（跟本次 demo 的定位一樣）。
• 要接產線一定要微調：METADATA 給的微調路徑是 Kaggle 免費 2×T4，約 4–5 小時、4 epoch、約 3 萬題（見上「Fine-Tuning」節出處），每個候選判斷點都要自備一批已標記樣本；需要幾則沒有官方數字（未驗證），可參考的量級只有 typed-decisions benchmark 本身的 400 案例、2000 決策，以及官方微調用的約 3 萬題。
• 素材來源盤點（沿用既有規則檔本來就有的真實資料，不用另外造）：
• 候選 1（喚醒閘）：state/wake-precheck-probe.tsv 累積的候選數紀錄可以當起點，但要另外標「這一批到底值不值得叫醒」的人工判斷才能當訓練標籤。
• 候選 2（告警嚴重度）：state/alert-inbox.tsv（五欄格式，各腳本已經寫入的 severity 可以當弱標籤起點，但如前述可能本身就不一致，得先人工複核一批）。
• 候選 3（人類板／系統板）：beads 既有卡片的 labels 欄位（bd list --json --brief）已經是人工標好的分類，量夠大可以直接拿來微調，不用重標。
• 候選 4（語氣閘語意層）：hooks/line-tone-gate-check.py.bak-* 系列備份檔加上既有的 tone-gate 糾正史（rules/tone-feedback-log.md）可能有歷史案例，但這批屬於核心層檔案，微調用的資料匯出要走現有的「不改核心層」邊界，只能讀不能碰。
• 候選 5（引用相關度）：條目「## 阿普引用記錄」節（wiki/entities/*.md）裡逐筆記錄的「脈絡」欄位，是既有的人工判斷紀錄，理論上可以整理成標記樣本，但要先確認這些欄位夠不夠格式一致來自動抽取（本次未逐一核對，標未查證）。
• 中文語料量：本機 demo 只測了 5 則、既有 RESULT.md 試跑只測了 16 則，兩者都遠小於能穩定微調或評估的量級，任何候選點真的要上線前都需要重新累積更大的中文標記樣本，而不是套用 METADATA 裡以英文與其他語言為主的公開 benchmark 數字。

風險與限制

• 最大風險：零樣本分數看起來像判斷，其實接近亂猜——本檔 demo 一節已經實測示範（純問候的 worth_expanding 分數比真實長文還高）。若不先微調就把分數接進任何自動化流程（例如自動調整 severity、自動覆蓋人工 labels），等於把「看起來科學的數字」凌駕在現有的人工判斷之上，比純語意規則更危險——語意規則錯了容易看出來，零樣本分數錯了看起來還是一個「分數」，反而更難被人肉眼抓到（這正是既有教訓「信心度不能當閘」「斷言假綠」系列在講的同一類問題）。
• 微調成本是真實門檻：4–5 小時 GPU、一批自標樣本（量級未驗證，見上），這對每一個候選點都是一次性的工程投入，不是「掛上去就會動」。ticket 若要往下推進，第一步應該是先為單一候選點（見下節建議順序）標一小批資料，實測微調後準確率提升幅度，而不是五個點一次全上。
• 高基數分類不適合：候選點如果選項數超過約 20 個（例如工單分類如果類別很細），準確率會因 token 預算被稀釋而大幅下降（Banking77 案例），要嘛拆成兩層分流，要嘛提高 head_max_len／max_len 設定並接受更慢的推論。
• 中文效果無官方數字背書：METADATA 全文沒有針對中文的獨立準確率報告，只有「Router 認得中文腳本」這一層保證（laya/lang.py:41），實際好不好完全要靠自己測，不能拿英文或其他語言的公開 benchmark 數字直接套用。
• 核心層邊界：候選 3（人類板／系統板）與候選 4（語氣閘）的資料來源與判斷邏輯本身住在受保護的規則層／hooks（rules/card-rules.md、hooks/line-tone-gate-check.py），任何要把 Laya 接進這兩個判斷點的施工，照 ~/.claude/CLAUDE.md 子代理紅線與 Tier 0 邊界，都必須是主 session 親自動手，不能派子代理直接改。
• 與現有規則的分工要先講清楚：既有研究卡已經指出「訊息分流節點現在靠 bindings＋關鍵字路由，已經夠用，換成模型的增益小」——本檔候選 5 個裡沒有把「訊息分流」單獨列出來當候選，就是採納這個既有結論；真正有增益的是「這批東西值不值得處理」這類目前完全沒有語意判斷、只有計數或人工的空白點（候選 1、2、5）。

建議順序

1. 候選 1（喚醒前置閘）優先：風險最低（現在的 wake-precheck-probe.sh 本來就設計成「只量不擋」，接上 Laya 分數也只是多一欄量測資料，不改變正線行為）、既有研究已經標出這是最值錢的用法、而且已經有現成的量測帳本（state/wake-precheck-probe.tsv）可以拿來標記訓練資料，不用另外造素材管線。
2. 候選 5（引用相關度）次之：現況是「完全沒有腳本化判斷」（§2 白紙一片），加一道機檢是淨增益、不是取代既有機制；且風險段對「零樣本不可靠」的警告在這裡衝擊較小——就算判斷不準，最壞情況只是漏擋或多擋一次引用，不是自動改動核心資料。
3. 候選 2（告警嚴重度）第三：屬於「交叉核對」用途（跟人工填的 severity 對照找不一致），不是取代，風險可控；但需要先把 state/alert-inbox.tsv 的歷史 severity 標記品質核過一輪，避免拿本身就不準的弱標籤去微調。
4. 候選 3、4 最後、且要先問過使用者本人：兩者都涉及核心層規則（rules/card-rules.md、hooks/line-tone-gate-check.py），微調資料的取用與判斷邏輯改動都要主 session 親自處理，不適合排進自動化管線的早期試驗，等前三個候選都有實測數字（微調後準確率、實際攔下/放過的案例）再評估要不要往這裡推進。

紅隊待辦（照工單「紅隊點」）

本檔完成後，依工單要求需派 codex 唯讀審一次「數字與出處有沒有編造、Laya 能力敘述是否與套件原始碼一致」，證據落 內部研究資料夾的 redteam.md——本次尚未執行，留給下一步或由使用者決定要不要先看報告再排紅隊。

紅隊結果（2026-09-23 20:0x codex 唯讀審數字）

VERDICT: FIX → 已修 5 條：延遲改標為每則 4 題的延遲（HIGH）、兩處「上千則標記樣本」改為未驗證並列出僅有的官方量級（MED×2）、分數區間補「約」與最高 1.72、score 型別的回傳範圍改寫為 METADATA 的描述（LOW×2）。