什么是 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 选一、按评分标准打分——一次前向传播就会为每个选项返回一个校准过的概率。不会生成任何内容，因此没有推理 token 可花，也一个都没花。v6.0-VL 不是该项目的首个版本；它是十二天内的第七个版本，而这是理解它时最重要的一件事，因为这里真正有用的信息在于这条线的形状，而不在于任何一个检查点。

在任何数字之前，有一件事必须先说明，因为它决定了所有这些数字的时间背景。v6.0-VL 位居榜首的时间恰好只有一天。在 2026-10-07 07:56 UTC——也就是今天早上——该项目发布了RSI-Jev v6.1-VL，它是将 v6.0-VL 进行平均、权重各为 0.5，并结合对同一 Qwen3.5-4B-Base 使用其他数据完成的第二次微调所得；在项目 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 模型”，而它产出的工件是决策器，而非生成器。你交给它一个状态——一份文档、一段聊天记录、一笔交易，并且在视觉版本中最多可包含四张图像——以及一个或多个带具名准则的类型化问题。它会针对每个问题，返回每个选项的概率。三种问题类型覆盖了整个空间，而它们正是 TypeSafe 的 API 所定义的那几种：

• noul — 一个真/假判断，以单个概率的形式返回，不包含分布，也不包含置信度值，与参考的答案形态完全一致。

• 选择 — 从一组带标签的选项中挑选一个，返回完整的概率分布和置信度统计量。

• 分数 — 依据有序评分量表评分，以概率加权的、从零开始的等级索引形式返回，并附上图例和分布。

因为没有生成步骤，也就没有第二次模型调用，也没有采样。对模型已经读过的文档做出判断，从构造上就是一种低成本操作，而项目自己为这一成本给出的说法——“约 10 毫秒”——属于它的 2B 时代，并不属于当前版本；v6.0-VL 的实测数据见下文。

关于归属，有两个事实比本页其他任何内容都更重要。RSI-Jev 并非 TypeSafe 的作品，TypeSafe 也未对其表示认可。完整引用许可声明如下：“代码：MIT。权重：Apache-2.0，沿用基础模型；部分图像训练来源为非商业用途，已在各模型卡中列出。与 TypeSafe AI 无关联。”而且这种关系是单向的：该项目有意复制 Jev 的传输格式，并公开说明这一点，因为兼容的服务器才是关键。“Jev 风格”（Jev-style）是该项目对自己所构建的这类模型的称呼。TypeSafe 的 Jev 是一个不同的、闭源的商业模型，二者并非同一个东西的简称。

当前模型内部：一个带有三个出口的 4B Qwen 塔

RSI-Jev v6.0-VL 是一个 Qwen3.5-4B-Base 塔式模型，其中塔式模型经过微调，并在其上训练了一个决策头。这就是整个架构——没有混合专家，没有路由器，也没有第二个模型。它运行整个基础模型，这就是为什么它的参数量是 4.69B，而不是更小的值：3.57B 位于 32 个解码器层中，0.64B 在 token 嵌入中，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 改变了什么：它消耗的是深度，而不是 token。

当前版本的机制是一个名为力度的设置，它控制着一种不寻常的东西：一个请求可以使用模型的多少层。由于各个头位于三个深度，简单的问题可以在第 16 层得到回答，而困难的问题可以跑满全部 32 层。低会在第 16 层停止，中在第 20 层，高在第 32 层，而自动会在第一个其校准概率超过该出口阈值的出口处给出答案。在 Decision Index 样本上，每个请求的中位延迟，在一台 H200 上以 bf16 测得：23 ms 在低时，27 ms 在中时，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；同规模的下一个条目是 43.04 的 JPT-4B。这条线上更早的发布属于沿革，并非当前模型：v5.0-VL（2026-10-02）把模型裁剪到 32 层中的前 20 层，并让它在问题没有答案时说“unknown”；v4.0-VL（2026-10-01）是第一个能读图的版本；而 v3.0（2026-09-28）则是强化学习首次奏效的发布，靠的是 listwise 排序奖励——在 16 个候选上的 NDCG@5——把重排序的 R@1 从 0.192 提升到 0.308，相对其监督学习父模型，代价是在该套件上损失 0.0028。项目的强化学习故事就是从这里开始的，而如今已经过去三个发布版本了。

这些数字，以及随之而来的种种限定条件

在完整运行、套件中全部 150,759 个请求均得到应答的情况下，v6.0-VL 的 Decision Index 0.2.1 头条得分为 46.24：知识 28.8、语言 46.2、检索 55.5、工具 65.8、艺术 37.1。这套包含十五项基准的测试套件读数为 0.770，留出集为 0.698，MMLU-Pro 为 0.440，最终 ECE 为 0.024，采用自动。有两点警示必须与这些数字一并说明，因为少了它们，这些数字就会产生误导。

第一项是套件中的一处裁减。内部套件任务 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。

• Criteria 必须是字符串或 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 数据 URL 形式提供，状态通过字面标记引用每一张。

在读者真正能够运行它的情况下，以及他们无法运行的情况下

RSI-Jev 可供下载。该项目自带自己的服务器，该服务器支持那种 Jev 兼容 API，而文档中说明的途径是：从仓库进行 pip install，然后运行其 serve 命令，并带上别名和一个 effort 设置。权重位于 Hugging Face 上的 shgao 名下，依照基础模型以 Apache-2 许可发布；项目指出了一个悬而未决的问题：五个图像训练来源是非商业或仅限研究用途的，而“在非商业数据上训练的权重会继承这些条款”这一点尚无定论。代码采用 Apache-2 许可。

硬件不是制约因素。该项目在 HP ZGX Nano 上开发，这是一台 NVIDIA GB10 机器，并将其归功于 HP 和 NVIDIA；而服务器可运行在任何 CUDA GPU、Apple Silicon 或普通 CPU 上——文档对最后一种给出的数据是，在 GB10 自身的 Arm CPU 上回答单个问题耗时 733 毫秒，因此它可用，但算不上快。

它不会出现在通用模型目录中，而这正是我们必须明确自身定位之处。RSI-Jev 不在 OrcaRouter 上，也没有可供其路由的模型卡。我们提供的是 TypeSafe 的商业版 Jev，typesafe/jev-1.13，位于专用的 systemone 端点，需通过向 /v1/systemone 发送 POST 请求访问，而非 OpenAI chat-completions 形式——这正是本项目所实现的同一套请求与应答结构，来自它所复制契约的那个模型。关系仅此而已：二者讲同一种协议，我们提供其中之一，另一个由你自己运行。如果你已持有我们的密钥，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 模型卡坦承，这些提升来自数据而非深度，并且那 10% 本应进入第 32 层、却停在第 16 或第 20 层的问题，正是深度策略仍在猜测之处。重排序还有更长的路要走：hippo-memory 自身的检索顺序得分为 0.484 R@1，仍领先于模型在 v3.0 时达到的 0.308，而项目自那以后再未声称弥合这一差距。RL 证据仅有一个种子，而 v3.0“本身没有匹配的 SFT 对照”。训练语料和策略开发集未公开，因此无法仅凭仓库重新运行这些阶段，而且重排序语料构建器——约 96 GB 内存——也没有端到端重新运行。

热度，同日读取：73 颗星、5 个 fork、0 个未解决问题、7 个 GitHub 发布版本。这些数字每天都在变，而一个只有三周大的仓库不是什么成熟项目，无论其发布节奏如何。诚实的总结是，RSI-Jev 是该领域这一角落里较为清晰可读的研究工作之一——一连串有日期、有度量、有时会落败的发布，搜索过程与评分一并公开——同时也是最少经过独立验证的工作之一，因为本页几乎每个数字都来自它自己，没有任何外部方拿它与它所兼容的商业模型进行基准对比。

值得关注的不是下一次发布，因为以这种节奏，几天内就会有一次；值得关注的是项目之外的任何一方是否开始进行度量。会改变这一局面的有两件事：一是在已发布的检查点上运行独立基准测试，二是进行一次决策模型比较，让开源的 4B 和 TypeSafe 的托管模型都跑在同一套评测框架之下。这两者目前都不存在。在其中一项出现之前，解读像 46.24 这样的分数时，有用的方式是将它视为一份有充分记录的声明，来自一个会预先登记其预测、并发布失败试验臂的项目——这比大多数项目留下的证据链都更强，但仍然不是第三方结果。