什麼是 RSI-Jev？一個打造 Jev 風格決策模型的自我改進迴圈

RSI-Jev 是一個第三方開放研究專案，致力於打造 Jev 風格的 System One 決策模型，而本頁面所要介紹的模型是其 4B 版本，RSI-Jev v6.0-VL，日期為 2026-10-06。它由 Shanghua Gao (@gasvn) 撰寫，並在專案庫的致謝中列名 Sufian (@SufianTA)，它並非 TypeSafe 的 Jev，也不隸屬於 TypeSafe AI——該專案自己的授權條款正是這麼寫的。其背後的理念狹窄到可以用一句話說明：針對文件、聊天或圖像提出一個有類型的問題——是/否、從 k 個選項中選一個、按評分標準評分——然後一次前向傳播就會為每個選項回傳一個經過校準的機率。不會生成任何內容，因此沒有推理權杖需要花費，也沒有任何推理權杖被花費。v6.0-VL 並非該專案的第一個版本；它是十二天內的第七個版本，這是理解它最重要的一件事，因為這裡有用的資訊在於這條線的形狀，而不是任何單一檢查點。

在任何數字之前，有一件事必須先說，因為它為所有數字定下了日期。v6.0-VL 位居首位恰好只有一天。在 2026-10-07 07:56 UTC——也就是今天早上——該專案發布了RSI-Jev v6.1-VL，它是將 v6.0-VL 與同一個 Qwen3.5-4B-Base 以其他資料訓練出的第二個微調版本、以各 0.5 的權重取平均而成，且它在專案的 Decision Index 0.3 套件上得分 50.98，而 v6.0-VL 在同一套件上為 46.23。取平均之後沒有再進行任何訓練。它的校準比 v6.0-VL 更差，而它自己的卡片也如此說明。該發布是真實且現行的；本頁談的不是它。以下每一個數字都讀自 v6.0-VL 的發布紀錄，日期為 2026-10-06；而若某項計數自那時以來已有變動——發布總數、實驗總數——本頁會同時給出 v6.0-VL 當時的數字，以及今日所讀到的數字。

RSI-Jev 不是什麼，這一點也值得提早說明，因為三個顯而易見的假設中有兩個是錯的。它不是你今天就能透過一般 API 呼叫的託管產品，也不是由 OrcaRouter 提供——我們的目錄裡沒有 rsi-jev id、沒有 shgao id，也沒有它的模型卡。我們唯一擁有的是這個專案複製其 HTTP 合約的模型：TypeSafe 的商業版 Jev，我們提供為typesafe/jev-1.13，端點是 systemone。這兩者當中，一個是你去呼叫，另一個是你自己下載並自行提供服務。以下所有內容都來自專案本身的儲存庫、發布卡與服務文件，閱讀日期為 2026-10-07；若某個數字是專案自己的、而非外部測量所得，本頁會說明那是誰的數字。

這東西實際上有什麼作用

該專案用一行文字自我描述為「一個會建構 Jev 風格 System One 模型的遞迴式自我改進研究系統」，而它產出的成品是決策器，而非生成器。你交給它一個狀態——一份文件、一段聊天逐字稿、一筆交易，而在 vision 版本中最多可達四張圖片——以及一或多個帶有具名準則的型別化問題。它會針對每個問題，為每個選項回傳一個機率。三種問題型別涵蓋了整個範疇，而它們正是 TypeSafe 的 API 所定義的：

• noul — 真/假判斷，以單一機率回傳，沒有分佈，也沒有信心值，完全符合參考答案的答案形狀。

• 選擇 — 從一組已標記的選項中挑選一個，並回傳完整的機率分布與信心統計量。

• score — 依有序評分規準評分，回傳為以機率加權、從零起算的等級索引，並附上圖例與分布。

由於沒有生成步驟，因此不會有第二次模型呼叫，也不會有取樣。對於模型已經讀取過的文件，做出判斷從構造上來說就是一項低成本操作；而該專案自己對這項成本的說法——「約 10 毫秒」——屬於它的 2B 時代，而非目前版本；v6.0-VL 的實測數據會在下文給出。

在這頁上，關於歸屬的兩項事實比其他任何事都重要。RSI-Jev 並非 TypeSafe 的作品，且 TypeSafe 並未為其背書。許可證那一行，完整引用如下：「程式碼：MIT。權重：Apache-2.0，依基礎模型而定；部分圖像訓練來源為非商業性，列於各模型卡上。與 TypeSafe AI 無關。」而這段關係是單向的：該專案刻意複製 Jev 的傳輸格式，而且明白說出來，因為重點就是要有一個相容的伺服器。「Jev-style」是該專案自己用來指稱它所打造的那類模型的說法。TypeSafe 的 Jev 是另一款不同的、封閉的商業模型，而這兩者並不是同一個東西換個更短的名字。

在當前模型內部：一個帶有三個出口的 4B Qwen 塔

RSI-Jev v6.0-VL 是一個 Qwen3.5-4B-Base 塔，該塔經過微調，並在上面加上一個訓練過的決策頭。這就是整個架構——沒有專家混合、沒有路由器，也沒有第二個模型。它會執行整個基礎模型，這就是為什麼它的參數量是 4.69B 而不是更小的數字：3.57B 位於 32 個解碼器層中，0.64B 在詞元嵌入中，0.33B 在視覺塔中，0.05B 在主決策頭中，0.10B 在兩個提前退出頭中。釋出的檢查點是自包含的，且在 bf16 中為 9.7 GB。

三個決策頭分別附加在基底的第 16、20 與 32 層，而它們正是當前版本之所以為人所知的一切背後的機制。第 12 層的第四個出口曾被建構、衡量，最後遭到捨棄——「第 12 層出口在每一次比較中都敗給來自第 16 層的級聯，因此不在套件裡」——所以三個出貨，四個不出。這些出口讀取的是其所屬層的分離副本，這是該專案吃過苦頭才發現的細節：在訓練期間出口已附加於其上的主幹上重新調校頭部，並未恢復深層的準確度，因此將它們分離，才是恢復深度的關鍵。

這裡有一個數字，是最容易讓人誤讀這個專案的地方。直到 v3.0（含）為止，全部都是以 Qwen3.5-2B-Base 為基礎的 2B 模型，而那是它的血統，不是目前的模型。v4.0-VL 是 2B，v5.0-VL 將模型切換到 3B，而 v6.0-VL 是 4B。若某個頁面把目前的 RSI-Jev 模型稱為 2B，那它已落後三個版本。

這個迴圈才是真正的專案

模型是產出；真正被打造的是流程。該專案聲稱「跑研究的迴圈就是下一版的 AutoScientists」，也就是哈佛 Zitnik 實驗室所發表、能自我組織的代理團隊系統，而它的運作方式正如這句話所暗示。AI 代理提出假設，在花費 GPU 時間之前先登錄它們的預測，執行實驗，並在證據顯示該這麼做時，讓自家的優勝者退場。有兩項數字讓這一點更具體。在 2026-10-07 查看時，該儲存庫的標題數字是十三天內八次發布，從 v1.0 到 v6.1-VL；就 v6.0-VL 自己在 2026-10-06 的發布而言，當時顯示的是十二天內七次發布，每一次都由這個迴圈訓練、評估與記錄。而實驗次數，在本頁發布上線時是 471，今天則顯示為 496——每一次都有完整記錄，包括失敗。這兩項數字都出自該專案本身，而且兩者都在變動。

紀律正是讓那些數字具有意義的關鍵，而這個專案把它明白條列出來。虛無底線是量測出來的，而非憑空假設——那些可證明與對照組完全相同的實驗分支，在任何 GPU 時間之前就先以物件身分驗證過，因此它們之間的離散程度是雜訊底線，而比這個離散程度更小的差異並不構成結果。預測在執行之前就先登記，因此一個未達自己設定門檻的版本會以失敗的形式發布，而不是被悄悄重新剪裁。產出物也經過驗證：檢查點會從磁碟重新載入並重新評分，唯有能重現其訓練執行時逐題預測結果的才會被發布，而兩個 v1.0 檢查點都以 1.0000 做到了這一點。汙染是「經過檢查而非僅憑宣稱」。而且失敗也會發布，包括那些終結了專案自家冠軍的失敗。

專案在其貢獻指南中用自己的話說明什麼是貢獻：「這裡的貢獻通常是一筆量測，而不是一個修補。」已發布的紀錄是以一條鏈的形式保存，而非快照——「versions/ 為每個發布保留一張卡，全部保留，永遠留在 main 上……那條鏈就是這個專案」——這正是為什麼某個舊發布的數字可以拿來對照專案日後對它們的說法，也是為什麼下面討論到的那一處更正看得見，而不是無聲無息。

v6.0-VL 改變了什麼：它耗費的是深度，而非詞元

當前版本的機制是一項名為effort的設定，它控制著一件不尋常的事：一個請求允許使用模型的多少層。由於這些頭（heads）位於三個深度，簡單的問題可以在第 16 層得到答案，而困難的問題則可以一路跑到第 32 層。low 停在第 16 層，medium 停在第 20 層，high 停在第 32 層，而 auto 則在第一個校準機率超過該出口閾值的出口給出答案。在 Decision Index 樣本上，於單一台 H200 以 bf16 測得的每請求延遲中位數：low 為 23 ms，medium 為 27 ms，high 為 40 ms，未設定時採用預設值則為 40 ms。這些是該專案在其自有硬體上自行測得的數據，不應與服務文件中的 GB10 數字混為一談，因為那是不同的機器。

所量測到的 auto 行為才是有意思的部分：在該專案的十五項基準測試套件中，20% 的問題停在層 16，46% 停在層 20，34% 一路跑到 32，平均為 32 層中的 23.3 層。單一固定閾值平均為 20.9，而過度停止正是單一閾值所換來的結果。auto 並非在品質上妥協，這點值得說明，因為那通常是自適應設定的寫照：它在所有設定中繳出最佳的套件成績（0.771，預設為 0.770）、最佳的 MMLU-Pro 成績（0.444 對 0.440），以及最佳的最终校準（ECE 0.024 對 0.036）。high 唯一勝出的地方是留出集，0.702 對上 auto 的 0.696。有些任務確實會隨著深度增加而明顯變差——BANKING77 差了 0.035，New Yorker 圖片說明配對差了 0.060——這正是為什麼投入程度是呼叫端所做的選擇，而不是伺服器強加的規定。

讓這成為正式發布而非實驗的結果，就在專案公開的 Decision Index 0.2.1 上：分數在一個發布版本內從 v5.0-VL 的 38.38 提升到 v6.0-VL 的 46.24。在日期為 2026-09-28 的公開排行榜上，這是 4B 模型及任何更小模型中最高分，總體排名 71 個中的第 14；同樣規模的下一個項目是 JPT-4B 的 43.04。這條線上較早的發布版本屬於沿革，而不是目前模型：v5.0-VL（2026-10-02）把模型裁減到 32 層中的前 20 層，並讓它在問題沒有答案時說「unknown」；v4.0-VL（2026-10-01）是第一個能讀取影像的版本；v3.0（2026-09-28）則是強化學習首次發揮作用的發布版本，透過一項清單式排名獎勵——在 16 個候選項上的 NDCG@5——將其重排序 R@1 從 0.192 提升到 0.308，相較於其監督式父模型，代價是測試套件上 0.0028 的損失。那正是專案 RL 故事的起點，而現在已經隔了三個發布版本。

這些數字，以及伴隨它們而來的注意事項

Decision Index 0.2.1 中 v6.0-VL 的主要分數為 46.24，這是在一次完整執行中得出的，套件內全部 150,759 個請求都獲得回答：知識 28.8、語言 46.2、檢索 55.5、工具 65.8、藝術 37.1。十五項基準測試套件讀數為 0.770，保留集為 0.698，MMLU-Pro 為 0.440，最終 ECE 為 0.024，搭配 auto。兩點但書必須與那些數字同時並提，因為少了它們，這些數字就會產生誤導。

第一項是測試套件中的一項剔除。內部測試套件任務 open_jev_ood 與 579 筆訓練資料列重疊，因此其數字被不明幅度地虛增；自 v6.0-VL 起，專案改為在不含它的情況下回報該測試套件，結果為 0.770。v5.0-VL 的 0.764 是包含它的結果，而 v6.0-VL 的模型卡將該發布版本重新表述為不含它時的 0.763。這兩個數字不可互相比較；若你仍要比較，就必須使用重新表述後的 0.763，並說明你正在這麼做。留出集、MMLU-Pro 與 BBH 沒有重疊，未受影響。一項相關稽核發現，Decision Index 套件的測試列中約有 1,000 個項目出現在訓練語料中——ANLI 274 項、RouterBench-GSM8K 90 項、ARC 5 項，以及 BRIGHT/ToolRet 不帶標籤的查詢文字，約占該套件資料列的 0.3%——而移除它們重新評分後，在該專案的樣本上，該指數最多變動 0.04。這是對 v5.0-VL 紀錄的更正，已刊載於 v6.0-VL 的模型卡中；而這正是該專案自身的汙染規則讓它少掉一個數字。

第二點是：這份基準測試究竟是誰的。Decision Index 是 RSI-Jev 自家的公開榜單，而非第三方評判，而 46.24 只是該榜單上的一個分數。它無法與 TypeSafe 所公佈的任何數據相提並論，因為這兩個數字並非來自同一套評測框架，而且沒有人針對 RSI-Jev 與 Jev 1.13 進行過獨立的正面對決。能說的是結構上的差異，而非數字上的：一個是託管在廠商端點上的商業模型，另一個則是你自行下載並部署的檢查點。

還有兩項背景脈絡應歸入這組內容。該專案明確指出，「十五項基準中有十項以某種形式貢獻訓練資料，因此這些數字沒有一個是零樣本」；留出集是那個被留出的比較對象，而且即便是它，「也是從訓練中留出，而非對搜尋密封」。而 v6.0-VL 在自己的產品線上跑了 97 個實驗臂——若不計四項資料稽核則為 93 個——這正是讓該指數躍升 7.86 點的搜尋規模。

它採用 Jev 的傳輸格式，但有四項差異是呼叫端應該知道的。

相容性介面正是這個專案以目前這種形態存在的原因。相同的請求形狀（{state, model, questions}）、相同的三種題型搭配相同的準則形狀、相同的答案形狀、每次請求相同的 1 到 64 題、相同的錯誤封套，以及相同的信心統計量——峰值，(K · p_max − 1) / (K − 1)，夾限於 0..1。專案本身對該介面的說法是「任何針對 Jev 撰寫的東西都能不加修改地套用到這個專案上」，而伺服器記錄了哪些被複製、哪些沒有，這比那句宣稱更有用。

• 提示詞與讀出層都是它自己的。RSI-Jev 是一個配有已訓練讀出頭的基礎模型，並隨其訓練時所用的編碼器一同提供服務，因為使用參照方的提示詞「會讓模型偏離其訓練分布」。通訊契約才是相容性介面；提示詞則不是。

• 選項鍵對模型可見。參考會將它們隱藏，因此重新命名某個鍵可證明無法改變那裡的答案。在這裡則可以，而伺服器會誠實地回報為 option_keys_visible_to_model: true。

• 準則必須是字串或 null。結構化準則——也就是物件——會以 422 遭到拒絕，因為沒有任何發行版本是以此訓練的。這是參考實作會接受、但在這裡無法執行的請求的唯一一處。

• 不會有任何內容被截斷。服務時最多可使用 32,768 個文字 token，再加上影像的額度；更長的請求會以 422 拒絕並明確說明，而不是被默默截斷。較舊卡片中出現的 2,048 token 數字，是模型訓練時所用的長度，而非服務上限；把「默默截斷至 2,048」描述成目前的行為是錯誤的。

服務端的選項數量明顯佔優，差距極大：每個問題最多可達 5,120 個選項（RSIJEV_MAX_ANSWERS），相較之下，訓練時為 160 個，參考實作則只允許 64 個。不要把 160 當成服務端的上限。v6.0-VL 的回應中有一點是新加入而非沿襲而來：每個答案都會在 usage.depth 中回報是哪一層回答，並附上校準後的信心值，因此自適應決策可在事後稽核。圖像是參考實作所沒有的擴充功能——每次請求一至四張，以 base64 data URL 形式提供，而狀態會以字面標記指涉每一張。

讀者實際上可以執行它的地方，以及他們無法執行的地方

RSI-Jev 是一個下載項目。該專案自帶伺服器，能說那種與 Jev 相容的 API，而官方記載的路徑是先從儲存庫以 pip install 安裝，接著執行其 serve 指令，並帶上 checkpoint 別名與一項 effort 設定。權重置於 Hugging Face 上、隸屬 shgao 組織，依循基礎模型以 Apache-2.0 釋出；專案本身也點出一個未解的問題：五個影像訓練來源屬非商業或僅限研究用途，而「以非商業資料訓練出的權重是否承繼那些條款，尚未有定論」。程式碼則採 MIT 授權。

硬體並不是限制。這個專案是在 HP ZGX Nano 上開發，這是一台 NVIDIA GB10 機器，並將此歸功於 HP 與 NVIDIA；而伺服器可執行於任何 CUDA GPU、Apple Silicon 或一般 CPU 上——文件將最後者標示為 733 毫秒，這是在 GB10 本身的 Arm CPU 上處理單一問題的耗時，因此是可用，而非快速。

它不會做的一件事，就是出現在一般模型目錄中，而這正是我們必須精確表明自身立場的地方。RSI-Jev 不在 OrcaRouter 上，也沒有任何模型可供它路由。我們提供的是 TypeSafe 的商業版 Jev，typesafe/jev-1.13，位於專用的 systemone 端點，需以 POST 至 /v1/systemone 存取，而非 OpenAI chat-completions 形式——這與本專案所實作的請求和回應形式相同，來自它複製其契約的那個模型。這便是這段關係的全部：兩者說同一種協定，我們提供其中一個，另一個則由你自己運行。如果你已持有我們的 API 金鑰，Jev 1.13 的呼叫形式是一個 API 取用 200+ 個模型、0% 加價（供應商定價原樣轉嫁，因此供應商降價這裡當天就生效）——這對這項比較在某個特定面向上很重要。像這樣的一頁，若能先試用商業契約，然後才決定自行運行開放式 4B 檢查點是否值得那些維運工作，那麼採取行動的代價就很低。

如何在 2026-10-07 解讀 RSI-Jev

該專案所公布的弱點，和它的結果一樣具體，而日期也很重要。對 v2.1 的外部測試發現，模型在有序選項與評分規準分數上傾向選擇較嚴重或代價較高的選項，當文件無法回答時很少選擇「unknown」，而且對一個問題及其否定的回答並不一致。後續版本把資料瞄準「unknown」這個情況——KoBBQ 的 unknown-when-ambiguous 在 v4.0-VL 為 0.891，在 v5.0-VL 為 0.932，在 v6.0-VL 則為 0.918／0.939——而 v6.0-VL 的說明卡坦然指出，這些增益來自資料而非深度，而且那些本應進到第 32 層、卻在第 16 或 20 層就停下來的 10% 問題，正是深度策略仍在猜測的地方。重新排序還有更大的進步空間：hippo-memory 自身的檢索排序得分為 0.484 R@1，仍領先模型在 v3.0 達到的 0.308，而此後該專案未曾聲稱縮小過這個差距。RL 的證據只有一個隨機種子，而且 v3.0「本身沒有配對的 SFT 對照組」。訓練語料與策略開發集並未公開，因此無法只憑儲存庫重跑各個階段，而且重新排序語料建構器——約需 96 GB 記憶體——並未從頭到尾重新執行過。

聲量，同日讀取：73 顆星、5 個分支、0 個待處理問題、7 個 GitHub 版本發布。這些數字每天都在變動，而一個才三週大的儲存庫稱不上成熟專案，無論它的發布節奏多快。平心而論，最誠實的總結是：RSI-Jev 是這個領域角落裡較為清晰可讀的研究成果之一——一連串標註日期、經過衡量、有時甚至吞下敗績的發布，並將搜尋過程與分數一併公開——同時也是最缺乏獨立驗證的成果之一，因為這一頁上幾乎每個數字都出自它自己，而沒有任何外部單位拿它與它所相容的商業模型做過基準比較。

值得關注的不是下一次發布，因為以這樣的節奏，幾天內就會有一次；而是專案外部是否開始進行衡量。會改變局面的兩件事，是對已發布的檢查點進行獨立基準測試，以及一項決策模型比較，將開源的 4B 與 TypeSafe 的託管模型放入同一個測試框架中進行。目前這兩者都不存在。在其中一項出現之前，解讀像 46.24 這樣的分數的有用方式，是把它視為一項有充分記錄的主張，這項主張來自一個會事先登記其預測並發布失敗實驗分支的專案——這是一條比大多數都更強的證據軌跡，但仍不是第三方結果。