Jev 的 state
整理要交由 Jev 判斷的素材:字串、物件或文字陣列。
State 是你要求 System One 模型評估的內容,可以是支援訊息、文章段落或應用程式目前的快照。請將它與問題一同放入 state 欄位。每個請求會針對一個 state 評估一個或多個問題。所有問題都會看到相同的 state,並各自獨立執行。該對照表可混用 Choice、Score 和 Noul。不要把問題放進 state,並移除判斷不需要的內容。
合法資料結構
最簡單的 state 是純字串:「我的卡片被扣款兩次。」若案件只有一段文字,請使用字串;若包含具名欄位、相關記錄或應用程式 state,例如訊息加訂單 ID,則使用 JSON 物件;訊息或記錄的序列則使用文字陣列。在 Python 中,將對應的 string、dict 或 list 傳給 client.system_one(state=...)。
TypeSafe 的 state 頁面建議大多數請求使用物件,讓每個部分都有具描述性的名稱。支援對話、含兩筆已請款交易的訂單及退款政策可放進同一物件,仍然只算一個 state。若決策需要比較各部分,請將相關資訊放在一起。不要把第二個問題藏進欄位名稱。
Jev 僅接受文字。State 必須是字串、JSON 物件或文字值陣列。不支援圖片、音訊及影片。英文是主要訓練語言;其他語言(包括中日韓文字)雖可使用,但準確度較低。語言相關說明請參閱模型卡;像素內容應先轉換成欄位,再放入請求。
將內容與問題分開
State 用來存放內容及佐證資訊,問題則定義要進行的判斷。將退款要求與政策放在 state 中,再詢問客戶是否要求退款,以及政策是否支持退款。若把問題貼進 state 資料塊,Jev 仍會回答 instructions 欄位,等於在會占用 32k state 加最長問題預算的位置重複提示詞。
塞滿無關細節的大型 state,是 jev-1.13 已記錄的失敗模式。無關內容會造成干擾,導致準確度下降;過度膨脹的資料塊也更難追查是哪個欄位引發錯誤答案。請先在程式碼中篩選,只傳送問題所需的欄位。若無法篩選,可先用 Noul 評估段落相關性,再進行主要判斷,做法如 TypeSafe 的 RAG 段落分類指南。
上下文長度有上限。Jev 1.13 允許整個請求使用 64k 個權杖,而 state 加上最長問題則可使用 32k。推測式 fan-out 會在精簡的 state 下集中放入許多短問題。若只需要客戶最後一則訊息與兩列扣款記錄,這種方式比附上完整客服單歷史更便宜,也更準確。
以 state 表示客服紀錄
文件中的物件使用 ticket.subject、由 from/text 配對組成的 ticket.messages、order.id、含 amount 與 status 的 order.charges,以及以句子表示的 refund_policy。如此一來,重複扣款案例便可轉為針對該物件的一組 Nouls 與 Choices,而不必在對話中重述政策。你的程式碼已知道金額;Jev 負責判斷文字是否要求退款,以及政策條文是否適用。
對 Doom 這類遊戲迴圈而言,state 是描述世界狀態的結構化文字,而不是影格。TypeSafe 的示範會以每秒約查詢 10 次的頻率送入該文字。對 Wikiracing 而言,state 是頁面內容加上候選連結。對智慧家庭助理而言,state 是使用者話語,加上記憶體中已有的裝置清單。這些示範全都不會向 Jev 傳送像素。
若資料庫欄位是數值,而判斷本身涉及語意(例如「這個顏色看起來是否像警告」),請傳送具名分組或計算後的數字,並將十六進位運算留在程式碼中。相較於英文色彩名稱,jev-1.13 對 RGB 三元組與十六進位值的判讀較差。日期亦同:先用 Choice 擷取各部分,再於程式碼中比較。
額度與語言
64k 的請求視窗涵蓋 state 及所有問題;32k 視窗則涵蓋 state 與單一最長問題。若把 20k 的政策 PDF 整份塞進 state,不但幾乎不留空間給問題映射,也容易觸發無關細節造成的失誤。請先檢索,再只傳送判斷所需的兩個段落。
目前以英文的準確度最高。若工單使用日文或韓文,請先抽樣測試,繪製 Noul 與 Choice 的 Confidence 分布,並保留人工覆核,直到這些直方圖與英文結果相近。模型仍會接受這些文字,不會暗中拒絕 CJK 內容。
文字陣列用於表示序列,不該拿來暗藏第二套結構描述。需要具名部分時請用物件;只需要一整塊內容時則用字串。把圖片 URL 混入字串不會讓 Jev 具備視覺能力,只會讓 Jev 多出一個可能誤讀的 URL 權杖。請由工作程序擷取並描述內容,再傳送該描述。
若某欄位只供你的日誌使用,就不要放進 state。問題 ID 已能作為關聯鍵。State 應只包含人工評審會閱讀的證據。工單討論串很長時,遵守這項原則也能讓內容維持在 state 加最長問題的 32k 額度內。
具名欄位勝過取巧編碼。order_id、charges[].status、refund_policy 對你和 Jev 都清楚易讀。把相同資訊串成單一字串雖然可行,效果卻更差。文件中的客服工單物件就是範本:依序提供 ticket、order、policy,再提出指向這些名稱的問題。
移除判斷時不需要的個資。Jev 不會使用客戶請求進行訓練,但你自己的日誌仍會保留這些資料。縮減 state 既能修正 jaggedness 問題,也是良好的隱私習慣。
文字陣列代表序列,而非一組具名欄位。若需要名稱,請使用物件。
來源