看得懂規則的 LLM 評審

這裡的評審是什麼

一套規則是一到四個問題：choice 在 2–12 個準則標籤中選一個、noul 依 true 與 false 準則給出是非機率、score 落在 2–7 個有序等級上。一次請求會為單筆資料回答全部問題，不論問一個或四個都算 1 點。每個答案都以你送出的 id、你指定的型別回傳；超出準則範圍的答案會被拒收，不會交回給你。

這與請聊天模型評分不同：沒有生成的理由要讀，也沒有自由形式的評語要解析，你存下的是自己寫的問題的答案。這也代表評審的品質等於你的準則品質：指示越模糊，模型對「說不上來的東西」回答得越有自信。

{
  "text": "INV-2291 的退款重複入帳兩次，客戶要求停止第二筆轉帳。",
  "questions": [
    {"id": "outcome", "type": "choice", "instructions": "這則紀錄反映哪種結果？", "criteria": {"resolved": "問題已結案。", "in_progress": "仍有人正在處理。", "blocked": "等待第三方。"}},
    {"id": "is_negative", "type": "noul", "instructions": "這則紀錄是否指出我們流程的失誤？", "criteria": {"true": "指出我們流程中的錯誤。", "false": "說明進度或一般交接。"}}
  ],
  "threshold": 0.9
}

請求契約 · 文字分類 API

自己寫規則，或生成草稿後檢查

你可以自己寫問題，也可以用簡短描述讓生成器提出規則：從已登入的工作階段呼叫 POST /api/judges，prompt 為 5–800 字元，並指定用語的語言。生成器是固定模型上的聊天 completion，其輸出會先通過 API 相同的型別化問題驗證，才會顯示給你。

一次生成花費 1 點，失敗會退還。沒有任何東西會自動執行：生成結果是一份草稿，由你編輯後自行執行。請檢查準則是否互斥、等級是否有順序，以及是否有問題索取個人資料。把 prompt 當成資料：生成器只寫規則，不做任何判定。

curl https://jevapi.pro/api/judges \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: judge-support-triage-v1' \
  -b 'jev_session=YOUR_SESSION' \
  -d '{"prompt": "判定一則客服紀錄是已解決、處理中或受阻，並說明是否指出我方流程的失誤。", "locale": "zh-tw"}'\n\n{
  "judge": {
    "name": "客服紀錄覆核",
    "questions": [{"id": "outcome", "type": "choice", "instructions": "這則紀錄反映哪種結果？", "criteria": {"resolved": "…", "in_progress": "…", "blocked": "…"}}]
  },
  "model": "openai/gpt-4.1-mini",
  "id": "6f2c1a4e-9d7b-4c11-8f3a-2b5e9c0d1a77",
  "latencyMs": 2140,
  "credits": 19
}

批次分類與匯出 · 限額與點數規則

用人員標記檢查評審，而不是看它自己的信心

把答案與熟悉業務的人寫下的標記逐題比較，並計算代價高的錯誤，而不是整體一致率。機率是模型自己的輸出，不是實測準確率；在你的資料上，高數值仍可能出錯。

只要指示、準則或模型改變，就重跑一次比較，並把請求 id 與模型名稱和結果一起保存，日後的比較才有意義。把不確定的紀錄送去人工覆核，而不是把評審當成最終決定；對外公布的準確率只能來自你自己的保留資料集。

請求契約 · 什麼是 Jev AI