Choice、Score 與 Noul

如何選擇原語

答案為單一具名選項時，請使用 Choice，例如佇列、技能、類別標籤或下一條連結。TypeSafe 顯示的問題是「要選擇哪一個選項？」回傳內容為 choice、probabilities 與 confidence。Criteria 是一份最多包含 255 個選項的對照表。如果有數百條 Wikipedia 連結，就不能全塞進單一 Choice；Wikiracing 示範會先評分，再從候選清單中選擇。

當答案是簡短有序圖例中的程度時，請使用 Score，例如平靜／挫折／非常挫折，或 1-5 的嚴重度。回傳內容為 score、legend、probabilities 和 confidence。Criteria 是包含 2 至 10 個等級的有序陣列。請勿將內插分數解讀成精確量值。Jev 1.13 的等級不適合重建兩個級距間的數值；期望值只應用於門檻檢查。

問題只有是或否時，請使用 Noul，例如：「這是真的嗎？」它會回傳 0 到 1 的 noul 值。條件可選擇性說明何謂真與假。不含 confidence 欄位。接近 0.5 的 Noul 代表不確定，而非中等強度。請勿假設 Noul 等同於雙選項的 Choice，也不要把針對其中一者調校的門檻直接套用至另一者。TypeSafe 的 jaggedness 頁面，在同一張客服單中並列了 0.22 的退款 Noul 與 0.01 的「是」Choice。

平行問題與 ID

單一請求中的問題共用 state，彼此獨立平行執行，增加問題數量幾乎不影響延遲。同一份對照表可混用 Choice、Score 和 Noul。鍵名由你決定，例如 urgency、department、frustration；對應答案會以相同鍵名回傳。鍵名不會傳送給底層模型，也不會用於推論。

在迴圈中產生鍵名時，這項 ID 規則尤其重要。jaggedness 頁面的計數範例會為每個清單項目各詢問一次 Noul（item_0、item_1、…），並在 Python 中加總答案。Jev 絕不會將這些名稱視為權杖。請讓日誌中的名稱維持穩定，才能把重試記錄對應回原始映射。

每個 primitive 回應共用的回傳中繼資料包括 requestId、時間戳記、延遲及 metadata。請使用 requestId 串接追蹤記錄。時間戳記與延遲只是傳輸資訊，不應因此重新提問。Metadata 是附加於核心承載內容的選填資料。請先比較三種 primitive，再將這些共用欄位視為包覆型別化答案的外層資訊。

實務限制

255 個 Choice 選項是硬性上限，不是建議值。Wikiracing 會先用 Score 建立候選清單，再執行 Choice，以處理超出上限的情況。如果分類體系有 400 個標籤，就需要採用相同的兩階段形式，或建立 Choice 階層。別指望 API 會接受 256 個。

Score 的 2 至 10 個等級，適合人類能直接念出的簡短圖例。100 分制的品質量表選錯了原語；應拆成不可再分的 Scores，再於程式碼中相加。出現 1.4 這類等級間分數很正常，但不應用這些小數重建金額。

Noul 沒有 confidence 欄位，因此門檻必須依據 noul 值及額外加入的第二個問題。常見搭配是先用 Noul 判斷「這是否屬於處理範圍」，只有 noul 偏高時才以 Choice 判斷「應歸入哪一類」。jaggedness 的不變量記錄警告，不可將這兩個數字視為同一項統計量。

針對同一張工單，在一個請求中混用三種原語是標準做法，不是進階技巧：以 Noul 判斷緊急程度、以 Choice 判斷部門、以 Score 判斷挫折程度，之後再交由程式碼處理。這與快速入門的 curl 範例使用相同對照表。本頁提供比較，是為了讓你在撰寫 JSON 前先選對型別。

共用外層欄位不是第四種 primitive。requestId、時間戳記、延遲與 metadata 會隨每個答案一併傳送，方便追蹤呼叫。產品資訊應放在 state 中。如果你正把政策硬塞進 metadata，請改放到 Jev 實際讀取的物件裡。

撰寫 Criteria 時，應假設新隊友明天就會閱讀。Choice 的選項名稱及 Score 的等級名稱都是問題的一部分。含糊標籤會讓字面解讀問題直接出現在正式環境中。

Noul 是專有名稱。即使請求其餘部分是英文散文，也要維持原拼法。