Jev 1.13 的參差之處

Jev 並非完美。以下是我們在 jev-1.13 上已知的一些參差之處。其中許多將在後續版本中修復。

jev-1.13 快速、校準良好、擅長常識判斷，但並非完美。jev-1.13 在 System One 任務上表現最好。它可能難以應付需要多一層間接的任務。它的理解可能相當字面。它不擅長需要數值精確度的任務。

失敗模式詳解

字面理解

jev-1.13 回答的是你寫下的問題，而不是你心裡想問的那個。限定詞、否定和隱含條件都按字面理解。模型會依據 instruction 中寫下的字面來作答，而人可能會讀出指令背後的意圖。

改為： 在 instructions 裡寫明確切的條件。要具體。把邊界情況放進 criteria。當你看到一個錯誤答案、忍不住要解釋你真正想表達什麼時，那段解釋就是 instruction 缺失的另一半。在解釋不可避免的地方，把它拆成兩個字面問題，在程式碼裡組合。

數學與數字

Jev 不是計算器。我們強烈建議把任何數學邏輯放在程式碼裡實現。Jev 在語義問題上比在數學問題上表現更好。

計數

jev-1.13 數數不可靠。這包括單詞裡的字元數、某個詞在段落中出現的次數，以及長列表中的項數。模型是在辨認答案的大致形狀，而不是逐項累加，而且被數的東西越大，誤差越大。

在提出計數問題之前，先問一句：為什麼這個計數需要一個模型？如果被數的單位是正規表示式或解析器能找到的東西，那計數就該放在程式碼裡，模型幫不上忙。

改為： 在程式碼裡計數。想統計滿足某些標準的項時，在程式碼裡遍歷候選項，每項問一個問題，然後自己把答案加起來。

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

數值表示

jev-1.13 在語義表示上比在數值表示上表現更好。例如，用十六進位制值詢問顏色，效果不如用英文顏色名。給定 RGB 三元組或十六進位制值，它無法可靠地判斷兩個值是否相近。

同理，關於高階程式語言的問題，表現會好於關於底層彙編或二進位制編碼指令的問題。

改為： 在程式碼裡做轉換，傳入算好的數字或命名的分桶。把模型留給真正屬於判斷的部分，比如某個顏色讀起來是否像警告。

用 score 做數學

請不要用 score 的輸出（例如期望和機率）去計算某個數在 criterion 兩級之間的確切大小。你可以用期望來判斷它是否越過某個閾值，但 jev-1.13 的 score 檔位在數值校準上很弱。它無法通過在最近的兩個檔位之間插值來幫你還原確切的數字。

日期與時間比較

jev-1.13 把日期當作文本讀，而不是有序的量。問兩個日期哪個更早、相隔多遠、或某個日期是否落在某視窗內，都不可靠。格式混用、相對指代，以及季度、結算視窗、計息期這類領域邊界，會讓情況更糟。

改為： 把工作拆開。抽取是判斷，交給模型。算術不是，留在程式碼裡。

日期的每一部分都是一個小範圍閉集：十二個月、三十一種可能的日、有界的年份範圍。這樣抽取就變成在一個Choice 上對列舉選項的選擇，而不是自由形式的解析，而且你還多了一個地方放顯式的“未說明”選項，這樣缺失的部分會被報告出來而不是被猜。程式碼再把各部分組裝成真正的日期，並接管之後的一切，包括排序、時長、偏移和星期。

完整示例見日期抽取 cookbook，包括相對日期和置信度門控。

間接

帶有雙重否定或複雜間接的指令，回答的可靠性更低。關於“屬性的屬性”，或需要多跳推理的問題，都會損失準確率。

改為： 把指令寫得儘可能直接。儘可能按名字指出狀態中相關的部分。

充滿無關細節的大狀態

當狀態裡塞進與決策無關的內容時，準確率會下降。無關細節會充當干擾項，而龐大的狀態會讓你更難判斷是輸入的哪一部分導致了錯誤答案。

改為： 先在程式碼裡檢索和過濾，只發送問題需要的欄位。當無法在 state 裡過濾時，可以用 Noul 過濾相關性。對 RAG 段落分類的 cookbook 有一個完整示例。

對抗性內容

狀態是資料，jev-1.13 預設不把它當作敵意的。為了對抗性地操控模型而寫的內容——無論是注入的指令、刻意誤導的框定，還是為自己的分類辯護的文本——都可能改變答案。我們期望未來在這方面有所改進。

改為： 在 criteria 裡寫清楚。在部署給大量使用者之前，充分測試你的整合。

互相矛盾的 instructions 和 criteria

當 instructions 和 criteria 要求的是不同的東西時，jev-1.13 可能會困惑。最好的表現來自清晰的措辭。例如，一個讓 true 對映為“否”、false 對映為“是”的 Noul，表現會更差。目標是讓普通人也能輕鬆讀懂你的 instructions。

改為： 把 criteria 當作 instruction 的延伸。用清晰精確的語言把兩者對齊。

Choice 的選項順序

在某些情況下，我們觀察到 Choice 的選項順序會影響答案，而 jev-1.13 更傾向於排在最前面的選項。

改為： 重新排列選項，複核答案是否保持一致。

生成

jev-1.13 沒有為生成文本而訓練。雖然你可以通過串聯 choice 強迫它生成，但效果不好而且會很慢。對於資料抽取，更好的做法是用正規表示式或生成式模型抽出可能的選項，再讓 jev-1.13 挑出正確的那個抽取結果。

改為： 當答案空間有界時，把抽取變成在選項上的 Choice，而不是直接問那個值本身。如果你真的需要生成文本……那有別的模型來做這件事。