---
title: "Jev 能否用于银行数据分类分级？从决策模型到语义特征层"
date: "2026-09-27"
description: "Jev 三原语 Choice/Score/Noul 输出类型化概率；$0.042/百万 token、百万条≈$19、AUROC 0.886。结合《办法》三级与 JR/T 0197 五级，分析 Jev 承接分类、初判、合规校验的可行性，给出 Semantic Feature Provider 定位与 Shadow Mode 落地路径。"
tags: ["Jev", "System One", "TypeSafe", "数据分类分级", "JR/T 0197", "JR/T 0358", "银行保险机构数据安全管理办法", "Semantic Feature Provider", "Shadow Mode", "RLCDAlignBench", "数据治理", "合规前置"]
schema_type: "Article"
references:
  - title: "What Is Jev? TypeSafe's Decision Model Explained for Developers"
    url: "https://openrouter.ai/blog/insights/what-is-jev/"
    source: "OpenRouter 官方博客（Kenny Rogers，2026-09-21，更新 2026-09-24）"
  - title: "System One — TypeSafe AI Documentation"
    url: "https://docs.typesafe.ai/concepts/system-one"
    source: "TypeSafe AI 官方文档"
  - title: "Jev 能否用于银行风控？从规则引擎到语义决策层"
    url: "https://developer.aliyun.com/article/1766338"
    source: "阿里云开发者社区（2026-09-26）"
  - title: "信贷初审提速：Jev 把明显异常的申请挡在风控前面"
    url: "https://cloud.tencent.com.cn/developer/article/2750178"
    source: "腾讯云开发者社区（2026-09-23）"
  - title: "Just Ask Jev: Reinforcement Learning for Calibrated Decisions as a Zero-Shot Detector of AI Alignment Failures"
    url: "https://arxiv.org/abs/2609.29429"
    source: "arXiv preprint (2026-09-24, cs.AI, CC BY 4.0)"
  - title: "银行保险机构数据安全管理办法"
    url: "http://dfjrjgj.shandong.gov.cn/articles/ch06816/202501/372e11da-499a-41e4-823c-f86f13260bd7.shtml"
    source: "国家金融监督管理总局（2025-01-06）"
  - title: "JR/T 0197—2020《金融数据安全 数据安全分级指南》"
    url: "https://std.samr.gov.cn/hb/search/stdHBDetailed?id=B081D125A6762DB8E05397BE0A0A5EA7"
    source: "全国标准信息公共服务平台（中国人民银行，2020-09-23 发布实施，备案号 76968-2020）"
  - title: "JR/T 0358—2026《金融数据安全 数据安全能力体系》"
    url: "https://std.samr.gov.cn/hb/search/stdHBDetailed?id=53F6923358061014E06397BE0A0A72B0"
    source: "中国人民银行（2026-06-06，备案号 105994-2026）"
  - title: "JR/T 0223—2021《金融数据安全 数据生命周期安全规范》"
    url: "https://std.samr.gov.cn/hb/search/stdHBDetailed?id=C041BE0B1D190151E05397BE0A0A4D01"
    source: "全国标准信息公共服务平台（2021-04-08，备案号 81859-2021）"
  - title: "浅析《金融数据安全分级指南》"
    url: "https://gat.zj.gov.cn/art/2021/3/29/art_1229442538_59080440.html"
    source: "浙江省公安厅／网络安全等级保护网（2021-03-29）"
# Note: this file does not embed the AIGC implicit label block (ProduceID / ReservedCode).
# Under current labeling rules, AIGC metadata (Label, ContentProducer, ProduceID, PropagateID,
# ReservedCode1, ReservedCode2) must be issued per-article by the labeling platform.
# ProduceID and ReservedCode cannot be inferred or fabricated by the author or the generating tool.
# Leave these fields empty here; complete them after the platform issues the identifiers.
---

**Jev 不是 LLM，而是 TypeSafe 的第一个 System One 决策模型：用 Choice、Score、Noul 三原语输出类型化答案与概率分布，不生成文本。**

**Jev 便宜且校准：官方 $0.042/百万 token、百万条≈$19；RLCDAlignBench 零样本 AUROC 0.886、比 LLM-judge 便宜 63 倍——但校准只在均值意义上成立，单次仍可能错。**

**Jev 不做算术、日期、阈值比较，不给理由、不返回思维链，不做工具调用与多轮对话；非开源、无权重、无论文、只能调用托管服务。**

**本文建议 Jev 只当 Semantic Feature Provider：定级建议进台账、人工在审批环节确认；托管调用先做数据出境与保密评估，仅用脱敏样本，Shadow Mode 起步。**

**中国《办法》三级（核心/重要/一般）与 JR/T 0197 五级（5、4、3、2、1）并行；4-2 级边界主观性强，是定级误差主要来源，也正是 Jev 可切入的位置。**

---

> 素材说明：本文事实来源为 10 份已归档文件，性质与边界如下：
>
> 1. OpenRouter《What Is Jev?》（来源1，2026-09-21，更新 2026-09-24）：OpenRouter 官方说明文档，含 TypeSafe 定义、三原语、定价、上下文、成本示例、RLCDAlignBench 与 AUROC 0.886 引述。
> 2. TypeSafe AI 官方技术文档（来源2）：与来源1 同源，TypeSafe 侧关于上下文（每请求总 64k，state 32k + 最长问题）与命名由来（Kahneman System One）的官方说明。
> 3. 阿里云开发者社区《Jev 能否用于银行风控？从规则引擎到语义决策层》（来源3，2026-09-26）：中文技术媒体，记载四层架构、催收实例概率（该文示例值）、Shadow Mode 三阶段、Semantic Feature Provider 定性。
> 4. 腾讯云开发者社区 Jev 信贷前置初判（来源4，2026-09-23）：中文技术媒体，Choice 前置初判场景与边界；作者原话声明"文中对比为基于实测口径的方案性测算，非某机构真实数据"。
> 5. arXiv:2609.29429《Just Ask Jev: RLCDAlignBench》（来源5，2026-09-24，cs.AI，CC BY 4.0）：arXiv 预印本，记载 RLCD 训练方法、10 类对齐失败、44 基准、5 目标模型、median AUROC 0.886、比 LLM-judge 便宜 63 倍。
> 6. 《银行保险机构数据安全管理办法》（来源6，国家金融监督管理总局，2025-01-06）：监管机构规章，9 章 81 条，三级分类分级。
> 7. JR/T 0197—2020《金融数据安全 数据安全分级指南》（来源7，中国人民银行，2020-09-23 发布实施，备案号 76968-2020）：行业标准，五级分类，C1/C2/C3 映射，默认值。
> 8. JR/T 0358—2026《金融数据安全 数据安全能力体系》（来源8，中国人民银行，2026-06-06）：行业标准，能力体系，备案号 105994-2026。
> 9. JR/T 0223—2021《金融数据安全 数据生命周期安全规范》（来源9，2021-04-08，备案号 81859-2021）：全国标准信息公共服务平台行业标准条目，配套 JR/T 0358 使用的生命周期规范。
> 10. 浅析《金融数据安全分级指南》（来源10，浙江省公安厅／网络安全等级保护网，2021-03-29）：安全从业者对 JR/T 0197 的实操解读，反映机构实际接触不到 5 级、1 级无需特定措施、重点在 4-2 级之间的流动管控、4 级到 2 级边界用词主观性强；属业界解读，非官方口径。
>
> 凡来源的判断、数据，标注来源；凡本文作者的推论、方案建议、架构设计，标注"本文分析""本文建议""本文推断"。文中银行相关内容均为一般化银行，不涉及特定机构。
>
> 本文不构成监管要求、合规意见或法律意见。

## 一、Jev 是什么：不是 LLM，而是"类型化决策"

Jev 出自 TypeSafe AI，是该公司定义的"决策模型"（decision model）的第一个产品，命名为 **System One model**——取意卡尼曼（Daniel Kahneman）《思考，快与慢》中的 System 1：快速、模式匹配式的判断（来源1、来源2）。

与主流 LLM 的根本差异，是 Jev 不生成文本。它的输入是 `state`（一段文本、JSON 对象或文本数组，可被反引号引用字段名）加 `questions`（若干带类型的提问）；输出是类型化答案 + 概率分布。TypeSafe 用三个原语定义这个输出结构（来源1）：

| 原语 | 语义 | 返回结构 |
|---|---|---|
| Choice | 从固定选项集选一个 | `choice` + 每个选项的 `probabilities` + `confidence` |
| Score | 有序的等级数组（上限 10 级） | `score`（概率加权平均，如 0.85×1 + 0.15×2 = 1.15）+ `legend` + `probabilities` + `confidence` |
| Noul | 判断一个 yes/no 命题是否成立 | 只返回 `noul` 概率值，**没有单独的 confidence 字段** |

一次调用可以问多个问题；`state` 可以是 JSON 对象，指令里用反引号引用字段名。一个关键约定：**问题 id 不会发给模型，所有语义必须写在 `criteria` 描述里**——这意味着"给模型看什么"和"问模型什么"必须分开写（来源1）。

**阿里云文章（来源3）给了一个催收实例的完整数值**（下文概率均为"该文示例值"，非实测）：LLM 转写摘要后，Jev 输出 `是否承诺还款 YES 0.96 / 还款意愿 HIGH 0.82 / 投诉倾向 MEDIUM 0.63 / 继续自动外呼 NO 0.78 / 是否人工复核 YES 0.61`；再进 Blaze 规则引擎：`IF PTP=YES AND complaint_risk>=MEDIUM THEN 24小时内停止自动外呼`。另一组示例为 `repayment_intent: High 0.83 / Medium 0.14 / Low 0.03`、`PTP_reliability: High 0.71 / Medium 0.23 / Low 0.06`、`complaint_risk: Low 0.89 / Medium 0.09 / High 0.02`。

**腾讯云文章（来源4）在信贷前置初判上给出了另一组语义输出**：用 Choice 原语把一份申请分成四类——资料缺失、信息矛盾、正常申请、高欺诈风险；高风险转人工，正常进自动化风控。作者原话："Jev 在信贷场景只能做'前置筛选辅助'，绝不能替代风控模型和人工审核""Jev 只给粗粒度判断、不给理由，也可能误判"。**作者明确声明"文中对比为基于实测口径的方案性测算，非某机构真实数据"**。

## 二、性能证据：校准、成本、AUROC

**校准性**：TypeSafe 声称 Jev 的概率是校准的——它说 0.8，就在该类回答上大约 80% 的时候是对的。但这是**在大量样本的均值意义上成立**，单次回答仍然可能错（来源1）。

**概率波动**：不同调用之间概率会小幅波动。官方实验：同一条消息两次分别返回 0.52 和 0.49。这是为什么阈值必须按区间设、而不是按精确值设（来源1）。

**Noul 的 0.5 语义**：Noul 接近 0.5 = Jev 不知道答案（来源1）。

**成本量级**：官方定价 $0.042 / 百万输入 token，输出免费（来源1）。一个三问题的调用 447 输入 token = $0.000019（约两万分之一美分）；一百万条这样的票据约 $19（来源1）。

**上下文**：OpenRouter 列 32,000 token；TypeSafe 文档列每请求总 64k（state 32k + 最长问题）（来源1、来源2）。

**模型 ID**：`typesafe/jev-1.13`（固定）/ `~typesafe/jev-latest`（别名）（来源1）。

**学术证据**：arXiv:2609.29429（来源5）首次把 Jev 的训练方法公开为 RLCD（Reinforcement Learning for Calibrated Decisions）。作者团队（Ruoqi Guo, Yi Liu, Gelei Deng, Yuekang Li, Lida Zhao, Yutao Wu, Simin Chen, Ying Zhang, Leo Yu Zhang）提出 RLCDAlignBench：用 Jev 检测 **10 类对齐失败**——sycophancy（谄媚）、jailbreaks（越狱）、deception（欺骗）、prompt injection（提示注入）、hallucination（幻觉）、privacy violation（隐私违规）、social bias（社会偏见）、reward hacking（奖励作弊）、concealing uncertainty（隐藏不确定性）、power seeking（权力寻求）。规模：**44 个基准、5 个目标模型**，由每个基准的官方评分器标注，其中 2 个由人类标注。

核心结果：**零样本 median AUROC = 0.886**，在多数基准上超过有监督基线；Jev 与参照评分器对人工标签的一致性相当；成本比 LLM-judge 评分器便宜 63 倍；代码与数据发布于 github.com/sumleo/RLCDAlignBench（来源5）。

一个反直觉的洞察（来源5）：**"问题措辞影响很小，上下文影响更大，主要通过那些编码了标签的字段"**——很多对齐失败是"关系性的"，相对某个参照（用户信念、被注入的指令）定义的，仅看回复本身无法发现。方法要义是"**把'问什么'和'让它看到什么'分开变化**"——问题措辞与答案类型在一侧，输入的字段在另一侧。这一洞察对数据分类分级有直接方法学意义：Jev 判断"这段字段属于哪类"时，"字段名/字段说明/表血缘"这些上下文字段，比提问措辞更能决定准确率。

## 三、Jev 的边界清单

Jev 的能力边界比"能做类型化决策"更具体。以下每一条都是本文认为在数据分类分级落地前必须写进需求文档的边界（来源1）。

- **只接受文本**：字符串、JSON 对象、文本数组。**不接受图片、音频、视频**。扫描件 OCR 必须先由 OCR 模型转文本，Jev 只能处理转文本之后的结果。
- **不做精确算术、日期运算、阈值比较**：官方原话"精确算术、日期运算和阈值比较不是 Jev 的工作"——先把这些算好，再把语义部分交给 Jev。
- **不给理由，不返回思维链**：可见推理必须留给下游代码或 LLM。合规要求的"为什么这样定级"不能由 Jev 直接回答。
- **不做工具调用、对话、多步规划**：所有下游动作必须由调用方代码执行。
- **confidence ≠ 正确率**：confidence 是概率分布的"集中度"，来自分布形状而非正确性。极端情况：全部权重压在一个选项上 → confidence = 1.0。
- **Noul 没有单独的 confidence 字段**：只有 noul 概率值。
- **Score 上限 10 级**：超出 10 级会被截断。
- **问题 id 不发给模型**：所有语义必须写在 criteria 描述里。
- **校准只在均值意义上成立**：单次回答仍然可能错。
- **阈值必须用自有标注数据来设**：官方建议标注几百条样本，看概率落点，选三个区间。
- **非开源**：TypeSafe 没有公布 Jev 的权重，也没有发表 Jev 的论文；所有用户调用的是同一个托管模型。
- **官方适用场景**：路由与分流、大规模分类打标、智能体动作前置闸、校验 LLM 输出、排序与过滤。
- **官方不适用场景**：需要散文输出、输入是图片、逻辑是确定性的（正则和数据库查询比任何模型都好）。

## 四、中国监管与技术标准梳理

### 4.1 《银行保险机构数据安全管理办法》：三级分类

国家金融监督管理总局《银行保险机构数据安全管理办法》（来源6，2025-01-06）共 **9 章 81 条**：总则、数据安全治理、**数据分类分级**、数据安全管理、数据安全技术保护、个人信息保护、数据安全风险监测与处置、监督管理、附则。

**原则**："谁管业务、谁管业务数据、谁管数据安全"（来源6）。

**三级分类分级**：**核心、重要、一般**；**"一般"再细分为"敏感数据"和"其他一般数据"**；采取差异化安全保护措施（来源6）。

办法还要求：委托处理、共同处理、转移、公开、共享 → 安全评估；全生命周期技术手段；个人信息必须明确告知、授权同意、最小范围收集，共享和外部提供需履行个人告知及取得同意；数据安全风险纳入全面风险管理体系（监测、评估、应急响应及报告、事件处置）（来源6）。

### 4.2 JR/T 0197—2020：五级分类

中国人民银行 JR/T 0197—2020《金融数据安全 数据安全分级指南》（来源7，2020-09-23 发布实施；证券时报报道 9/28 印发）定义了**五个级别**，由高到低 **5、4、3、2、1 级**。

**影响对象**：国家安全、公众权益、个人隐私、企业合法权益。**影响程度**：非常严重、严重、中等、轻微（来源7）。

**与 JR/T 0071 的映射**（来源7）：

- **C3 类信息（主要为用户鉴别信息，如各类账户密码）属于 4 级数据**
- **C2 类（主要包括支付账号、动态口令等）为 3 级数据**
- **C1 类（主要包括账户开立时间、开立机构等）为 2 级数据**

**6 项定级原则**：合法合规性、可执行性、时效性、自主性、差异性、客观性（来源7）。

**附录 A《金融业机构典型数据定级规则参考表》**，其中 **3 级以上数据比例约 30%**（来源7）。

**默认值**（来源7）：

- 安全管理数据（系统漏洞、安全防护配置与策略、威胁数据、安全告警、安全事件等）**默认最低 2 级**
- 技术安防信息、物理安防信息均为 **3 级**
- **4 级** 主要为身份鉴别信息和生物隐私信息、健康信息
- 个人地理位置信息与个人财产信息、个人联系信息**同为 3 级**
- 跨境收付业务（除撤销、漏报类）均为 3 级

**起草**（来源7）：人民银行科技司发起，全国金融标准化技术委员会归口，国家金融IC卡安全检测中心牵头；招商银行、农业银行、兴业银行、平安保险、蚂蚁集团等参与。

**注意**：JR/T 0197 未细分到证券/保险/银行子行业标准 → 统一适用、监管穿透式（来源7）。

### 4.3 JR/T 0358—2026 与 JR/T 0223—2021

**JR/T 0358—2026《金融数据安全 数据安全能力体系》**（来源8，中国人民银行，2026-06-06 发布实施，备案号 105994-2026）——**这是能力体系，不是分级指南**。

**JR/T 0223—2021《金融数据安全 数据生命周期安全规范》**（来源9）是与 JR/T 0358 同级配套的**生命周期规范**，与 JR/T 0197（分级指南）合起来构成"分级—能力—生命周期"三位一体的标准体系。

### 4.4 业界实践反馈

来源10 记载的业界反馈（媒体转述，非官方口径）：机构实际接触不到 5 级数据，1 级无需特定措施，**重点在 4-2 级之间的流动管控**；4 级到 2 级边界用词（"一般影响""轻微影响""不宜广泛公开"）主观性强，**定级有误差**。

### 4.5 两套体系的对应关系与冲突点

**本文分析**：《办法》的三级与 JR/T 0197 的五级不是简单嵌套，而是两套并行体系。

| 体系 | 级别 | 依据 |
|---|---|---|
| 《办法》三级 | 核心 / 重要 / 一般（其中"一般"再分敏感 / 其他一般） | 来源6 |
| JR/T 0197 五级 | 5 / 4 / 3 / 2 / 1 | 来源7 |

**对应关系（本文分析）**：

- JR/T 0197 **4 级** → 《办法》**核心**（身份鉴别信息、生物隐私属于最敏感）
- JR/T 0197 **3 级** → 《办法》**重要**（多数 3 级以上数据占比约 30%，与"重要数据"覆盖面吻合）
- JR/T 0197 **2 级** → 《办法》**一般（敏感数据）**
- JR/T 0197 **1 级** → 《办法》**一般（其他一般数据）**
- JR/T 0197 **5 级** → 业界实际接触不到，来源10 反映为"事实上空档"

**冲突点（本文分析）**：

- **数量不匹配**：三级 vs 五级，"一般"这一档内含两个 JR/T 0197 级别（2 与 1），需要在台账里显式映射。
- **4-2 级边界主观**：来源10 指出 JR/T 0197 4 级到 2 级之间的定级用词主观性强，是实操中定级误差的主要来源。
- **JR/T 0197 未细分行业子标准**：证券/保险/银行统一适用，穿透式监管（来源7）。

**本文建议**：在台账中同时保留两套标记（"办法三级" + "JR/T 五级"），避免在报送或审计时被两套口径交叉质疑；对 4-2 级边界使用 Jev 做**语义辅助初判**，但最终定级必须由人工在审批环节确认。

## 五、可行性分析（本文分析，核心章节）

### 5.1 Jev 能承接的部分

**本文分析**：Jev 在数据分类分级中可承接三类工作，都是**语义层**的粗粒度判断，不是最终裁决。

- **分类（Choice）**：把资产目录或系统字段映射到类别。例如"这条字段属于哪个业务域"、"这段描述属于哪一类风险事件"。Choice 天然适配固定选项集的分类任务。
- **辅助初判等级（Score）**：映射到 JR/T 0197 五级。Score 的原语支持最多 10 级，把 JR/T 0197 的 5 级作为 legend（5=极敏感、1=低敏感）是合规用法；返回的加权平均分（如 0.85×1 + 0.15×2 = 1.15）本身就体现了"跨档"的语义信息，正好匹配 4-2 级边界的模糊性（来源7、来源10）。
- **合规性校验（Noul）**：判断某条字段描述是否含个人金融信息、是否属于 C2/C3（来源7 定义的 C1/C2/C3 是"映射参考"，不是清单扩展）。Noul 接近 0.5 表示 Jev 不知道答案（来源1），这类样本必须转人工。

### 5.2 Jev 不能承接的部分

**本文分析**：以下四类必须留给规则引擎或代码。

- **最终定级结论**：必须人工在审批环节确认。Jev 只能作为"定级建议"进入台账。
- **字段精确匹配**：正则、字典、字段血缘比对——正则和数据库查询比任何模型都好（来源1 明确说不适用场景"逻辑是确定性的"）。
- **扫描件 OCR**：Jev 不接受图片，必须先做 OCR 再交 Jev（来源1）。
- **算术与阈值**：日期有效性、金额区间、期限比较（来源1 明确不是 Jev 的工作）。

### 5.3 架构建议

**本文建议**：与阿里云文章（来源3）的四层架构对齐，但把语义判断层接到数据治理的资产目录与定级台账上。

来源3 的四层分工：Blaze/Drools = 确定性规则/政策/流程/阈值；ML/Score Model = 基于历史数据概率预测（PD/Score）；**Jev = 对复杂上下文和非结构化信息做语义判断**；LLM = 深度分析、解释、交互、内容生成。

来源3 的架构：`Data → State → {Rules, ML, Jev} → Decision Engine → Workflow → Human/AI/Tool`。

来源3 原文定性：**"Jev 更适合成为一个 Semantic Feature Provider / Semantic Decision Engine，而不是整个风控体系的最终裁决者。"** 本文建议把同一句定性中"风控体系"换成"数据分类分级体系"：**Jev 更适合成为定级建议生成器 + 一致性校验器，而不是最终定级者**。

来源3 明确：授信/额度/拒贷这类高影响决策**不适合**设计成 `Jev → Approve / Reject`。本文建议同理：**数据定级不应设计成 `Jev → 4 级 / 3 级 / 2 级`**，而应设计成 `Jev → 定级建议 + 概率` → 人工审批。

### 5.4 合规前置条件

- **非开源/无权重/托管调用**（来源1）→ 数据出境与保密评估：Jev 的所有调用走的是 TypeSafe 托管服务，银行需按《办法》关于"委托处理、共同处理、转移"的要求做安全评估（来源6）。
- **核心/重要数据不得直接送外部托管模型**（**本文建议**）：结合《办法》的"核心/重要/一般"三级与 JR/T 0197 的 5-4 级，仅使用脱敏后样本。
- **Shadow Mode 起步**（来源3）：先"只判断、不影响生产"。
- **个人金融信息的告知同意**（来源6）：任何将个人信息送外部托管服务的动作，需履行告知和取得同意。

### 5.5 与既有体系的关系

**本文分析**：Jev 不替代资产目录、不替代 DLP、不替代数据目录台账。它是**"定级建议生成器 + 一致性校验器"**：

- 资产目录提供字段清单
- DLP 提供敏感信息扫描结果
- Jev 提供"这段描述是否属于 C3"、"这段描述对应 JR/T 0197 几级"的语义建议
- 台账记录 Jev 的建议与人工最终结论，形成审计轨迹

**本文分析**：这套分工与《办法》"谁管业务、谁管业务数据、谁管数据安全"原则（来源6）呼应——Jev 只承接"语义判断"这一细分业务，不承担"数据安全"的最终责任。

## 六、技术方案（本文建议）

### 6.1 分层架构

**本文建议**的分层如下（与来源3 的四层架构对齐）：

- **资产盘点层**：元数据 / 血缘 / 系统目录。Jev 不介入。
- **语义层**：LLM 摘要 + Jev 分类 / 评分 / Noul 判断。Jev 只处理文本状态。
- **规则层**：JR/T 0197 默认值、C1/C2/C3 映射、《办法》三级归类（来源6、来源7）。规则引擎（如 Blaze/Drools）执行。
- **人工审批层**：分级刹车。Jev 输出进"定级建议"字段，人工在审批环节确认最终级别。
- **台账与再定级层**：记录 Jev 建议、人工结论、变更原因；定期再定级。

### 6.2 阈值三区间

来源1 官方建议：**阈值必须用自己的标注数据来设**。做法：标注几百条样本，看概率落点，选三个区间：

- 超过上阈 → 自动执行（自动入建议池）
- 中间区间 → 加人工确认
- 低于下阈 → 转人工

**本文建议**：在数据定级场景中，"自动执行"应被严格限制为"自动入定级建议池"，而不是"自动写入最终定级"。因为校准只在均值意义上成立，单次仍可能错（来源1）。

### 6.3 Shadow Mode 三阶段

来源3 记载的落地顺序，本文改写为数据定级场景的六步：

- 历史数据离线回放：用已有定级台账的历史样本回放
- 与现有策略结果比较：与人工既有定级结果对比，计算一致率与偏差分布
- Shadow Mode 只判断、不影响生产：写入"定级建议"字段，不改实际定级
- 生成 Semantic Features：输出"是否 C3"、"是否含个人金融信息"、"是否投诉倾向"等语义特征
- 规则层决定最终策略：JR/T 0197 默认值 + Jev 建议决定"是否进入人工审批"
- 逐步开放低风险自动决策：从 2 级以下字段的自动分类起步

### 6.4 与资产保全/催收场景的复用

**本文分析**：来源3 举例的催收场景产出的语义状态（还款意愿 / PTP 可信度 / 投诉风险 / 是否继续自动外呼 / 是否人工复核）本身就是**需要定级的数据**。形成闭环：**Jev 产出的语义特征也要进分级台账**——这些语义特征通常包含客户行为推断（还款意愿、投诉倾向），按 JR/T 0197 默认值规则，个人行为相关的敏感信息很可能属于 3 级（个人联系信息 / 个人财产信息同 3 级，来源7）。

**本文推断**：这个闭环的意义是——Jev 不仅用于"分类分级"，Jev 自身的输出也需要被分类分级。这与《办法》"谁管业务、谁管业务数据、谁管数据安全"原则（来源6）形成呼应。

### 6.5 成本粗估

**本文建议**：按来源1 官方单价 $0.042 / 百万 token、平均 400–500 token / 条推算，一百万条记录约 $19 量级（来源1 记载"一百万条这样的票据约 $19"）。

**本文提示**：上述成本为按官方单价的算术推算，**非某机构实测**，与来源4（腾讯云）的口径一致——原文已声明"文中对比为基于实测口径的方案性测算，非某机构真实数据"，本文按同一限定沿用。

## 七、行动清单

**合规条线**：

- 梳理《办法》三级与 JR/T 0197 五级的映射表，明确"核心/重要/一般（敏感/其他一般）"与"5/4/3/2/1"的对应关系（本文建议）。
- 评估 Jev 托管调用的数据出境与保密要求，明确核心/重要数据不得直接送外部托管模型的边界（来源1、来源6）。
- 建立个人金融信息送外部托管服务的告知同意机制（来源6）。
- 关注 JR/T 0358—2026 能力体系对本行能力评估的影响（来源8），确保"定级建议生成器"能力被纳入能力体系。

**数据治理条线**：

- 建立"Jev 定级建议"字段进台账的流程，与人工最终结论并列存储（本文建议）。
- 明确 4-2 级边界使用 Jev 做语义辅助初判的场景清单，避免全量使用（来源10）。
- 定期复盘 Jev 建议与人工结论的一致率与偏差分布（本文建议）。
- 与资产目录、DLP、数据目录台账的接口方式明确，避免重复定级（本文建议）。

**信息科技条线**：

- 按 Shadow Mode 六步部署，先历史回放、再与现有人工定级结果比对、再"只判断不影响生产"（来源3）。
- 建立 Jev 阈值三区间配置，用自有标注数据（几百条）标定上阈、下阈（来源1）。
- 对 Jev 产出的语义特征（还款意愿 / PTP 可信度 / 投诉风险等）进分级台账，形成闭环（本文分析）。
- 保留正则 / 字典 / 数据库查询作为字段精确匹配的替代方案，不要交给 Jev（来源1）。

## 八、FAQ

**Q1：Jev 能直接完成"给数据定级"吗？**

A1：**本文建议**：不能。Jev 只能作为 Semantic Feature Provider 输出"定级建议 + 概率"，最终定级必须由人工在审批环节确认。来源3 原文定性："Jev 更适合成为一个 Semantic Feature Provider / Semantic Decision Engine，而不是整个风控体系的最终裁决者。"

**Q2：Jev 说 0.8，我就有 80% 的把握对吗？**

A2：不是。来源1 明确："它说 0.8，就在该类回答上大约 80% 的时候是对的——但只在大量样本的均值意义上成立，单次回答仍然可能错。" 而且 confidence ≠ 正确率：confidence 是概率分布的"集中度"，来自分布形状而非正确性。极端情况：全部权重压在一个选项上 → confidence = 1.0。

**Q3：Jev 会不会输出选项外的答案？**

A3：不会输出结构外的文本，因为 Jev 是"类型化决策"，不生成文本（来源1）。但"结构保证 ≠ 事实正确"——它只能从固定选项集选一个，选错的时候照样是错的。

**Q4：非开源的 Jev 能用于银行吗？**

A4：**本文建议**：可以做，但只能做合规前置之后的场景。来源1 明确"TypeSafe 没有公布 Jev 的权重，也没有发表 Jev 的论文；所有用户调用的是同一个托管模型"。按《办法》关于"委托处理、共同处理、转移"的安全评估要求（来源6），需要先做数据出境与保密评估，且核心/重要数据不得直接送外部托管模型，仅使用脱敏后样本。

**Q5：为什么必须把 Jev 的输出进分级台账？**

A5：**本文分析**：因为 Jev 产出的语义特征（如"还款意愿 HIGH"、"投诉倾向 MEDIUM"）本身就是对客户的行为推断，按 JR/T 0197 默认值规则（来源7），个人行为相关的敏感信息很可能属于 3 级。来源3 的催收示例本身就包含这些字段。所以 Jev 用于"分类分级"和 Jev 的"输出被分类分级"是同一件事——形成闭环。

**Q6：本文哪些内容最需要人类核实？**

A6：**本文认为最需要人类核实的有两处**：

- **来源3（阿里云）与来源4（腾讯云）中的催收、信贷场景概率值**，如 `repayment_intent: High 0.83 / Medium 0.14 / Low 0.03`、`PTP_reliability: High 0.71 / Medium 0.23 / Low 0.06` 等，均为"该文示例值"，非实测数据。来源4 原文明确"文中对比为基于实测口径的方案性测算，非某机构真实数据"。
- **成本推算"一百万条 ≈ $19"**，是按来源1 官方单价 $0.042 / 百万 token 与平均 400–500 token / 条的算术推算，非某机构实测。

## 九、事实来源

- **来源1**：OpenRouter《What Is Jev?》（2026-09-21，更新 2026-09-24）。https://openrouter.ai/blog/insights/what-is-jev/ ；含 TypeSafe 定义、三原语、$0.042/百万 token 定价、447 token = $0.000019 成本示例、一百万条 ≈ $19、RLCD 校准性、32k 上下文、AUROC 0.886 相关引述。
- **来源2**：TypeSafe AI 官方文档《System One》。https://docs.typesafe.ai/concepts/system-one ；含 Kahneman System One 命名由来、三原语示例（choice / score: 1.4 / noul: 0.95）、"System One models are trained for calibrated decisions"。注：64k 上下文（每请求总计 64k，state 32k + 最长问题）出自来源1 转述的 TypeSafe model page。
- **来源3**：阿里云开发者社区《Jev 能否用于银行风控？从规则引擎到语义决策层》（2026-09-26）。https://developer.aliyun.com/article/1766338 ；含四层架构、催收实例概率（该文示例值）、Shadow Mode 三阶段、Semantic Feature Provider 定性。
- **来源4**：腾讯云开发者社区 Jev 信贷前置初判（2026-09-23）。https://cloud.tencent.com.cn/developer/article/2750178 ；含 Choice 前置初判、作者原话"文中对比为基于实测口径的方案性测算，非某机构真实数据"。
- **来源5**：arXiv:2609.29429《Just Ask Jev: Reinforcement Learning for Calibrated Decisions as a Zero-Shot Detector of AI Alignment Failures》（2026-09-24，cs.AI，CC BY 4.0）。https://arxiv.org/abs/2609.29429 ；作者 Ruoqi Guo, Yi Liu, Gelei Deng, Yuekang Li, Lida Zhao, Yutao Wu, Simin Chen, Ying Zhang, Leo Yu Zhang；含 RLCDAlignBench、10 类对齐失败、44 基准、5 目标模型、median AUROC 0.886、比 LLM-judge 便宜 63 倍；代码数据 github.com/sumleo/RLCDAlignBench。
- **来源6**：《银行保险机构数据安全管理办法》（国家金融监督管理总局，2025-01-06）。http://dfjrjgj.shandong.gov.cn/articles/ch06816/202501/372e11da-499a-41e4-823c-f86f13260bd7.shtml ；9 章 81 条；三级分类（核心/重要/一般，"一般"再分敏感/其他一般）；"谁管业务、谁管业务数据、谁管数据安全"。
- **来源7**：JR/T 0197—2020《金融数据安全 数据安全分级指南》（中国人民银行，2020-09-23 发布实施，备案号 76968-2020）。https://std.samr.gov.cn/hb/search/stdHBDetailed?id=B081D125A6762DB8E05397BE0A0A5EA7 ；五级（5、4、3、2、1）；C3=4 级、C2=3 级、C1=2 级；3 级以上约 30%；默认值（安全管理数据最低 2 级、安防 3 级、4 级为身份鉴别与生物隐私、地理位置/财产/联系同 3 级、跨境收付 3 级）；招商银行、农业银行、兴业银行、平安保险、蚂蚁集团参与。
- **来源8**：JR/T 0358—2026《金融数据安全 数据安全能力体系》（中国人民银行，2026-06-06 发布实施，备案号 105994-2026）。https://std.samr.gov.cn/hb/search/stdHBDetailed?id=53F6923358061014E06397BE0A0A72B0
- **来源9**：JR/T 0223—2021《金融数据安全 数据生命周期安全规范》（2021-04-08，备案号 81859-2021）。https://std.samr.gov.cn/hb/search/stdHBDetailed?id=C041BE0B1D190151E05397BE0A0A4D01
- **来源10**：浅析《金融数据安全分级指南》（浙江省公安厅／网络安全等级保护网，2021-03-29）。https://gat.zj.gov.cn/art/2021/3/29/art_1229442538_59080440.html ；安全从业者实操解读，反映机构实际接触不到 5 级、1 级无需特定措施、重点在 4-2 级之间流动管控、4 级到 2 级边界用词主观性强；属业界解读，非官方口径。

**与系列文章的关系**（仅按标题引用，不描述其内容）：

- 《金融harness怎么设计与实施》——本文关于"规则层用 JR/T 0197 默认值 + C1/C2/C3 映射"呼应"先定硬规则"的思路。
- 《当AI开始监控AI，银行风险管理该做什么》——本文关于"分级刹车"（阈值三区间 + Shadow Mode）与"AI 监控 AI"的"level-1 brake"思路同源。
- 《Utopia (deeplethe/utopia): An Enterprise World Model — A Review》——本文关于"Jev 输出进定级建议字段、人工在审批环节确认"呼应"双时态台账 / 写=提案 / 人工在 Review 审批"。
- 《Manifold Theory in Quantitative Investing》——本文关于"阈值必须用自有标注数据来设"呼应"银行要用自有数据校准模型"的方法论。

**本文推论部分（非来源表述）**：4.5、5、6 各节的"本文分析""本文建议""本文推断"段落；七节行动清单；FAQ 中标为"本文建议/本文分析"的部分。

**本文不构成监管要求、合规意见或法律意见。**

*（内容由AI生成，仅供参考）*