Jev 决策模型在数据治理行业的应用实战：用开源 Laya 和数据血缘做变更影响评估
最近一周，一个"不说人话"的模型刷屏了：它不聊天、不写文章，只返回结构化的判断和概率——TypeSafe AI 的 Jev。这篇不讲它怎么用，讲一个更实际的问题：决策大模型放进数据治理的真实工作流里，能干什么、干不了什么。我拿"改表要不要放行"这件事做了个完整的实践，用开源的 Laya 实现，代码全部开源。
一、先说清楚：决策大模型是什么
传统大模型是"系统二"：你问一句，它写一段，结论埋在文章里，你还得自己抠。判断"这封邮件急不急"这种一句话的事，它也要先写三百字分析。
刷屏的 Jev（前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI 出品）走的是另一条路，官方叫"系统一模型"：不给文字，只给判断。输入两样东西——一段待判断的内容（state），一组类型化的问题（questions）；输出直接是结构化 JSON，带概率。
问题只有三种原语：
| 原语 | 干什么 | 返回 |
|---|---|---|
noul | 是非判断 | 0~1 的成立概率 |
choice | 从候选项里选一个（最多 255 项） | 选中项 + 各项概率分布 |
score | 在自定义量表上打分 | 分值 + 分布 |
按 TypeSafe 官方自测的数据：响应 70~500 毫秒（对比传统大模型的数秒到数百秒）、输入 $0.042/百万 token、结构化输出零错误。这三个数字是不是经得起第三方复测先不论，方向是对的——有一类 AI 需求根本不需要它"说话"，只需要它"表态"。
数据治理恰好是"表态"密集的地方。
二、数据治理里，最贵的表态叫"改不改"
一张生产表的变更要过评审：加字段、改类型、删列、上新 ETL。评审人要回答三个问题：影响面多大？风险多高？放不放行？
现状是这道闸门基本靠人：
- 影响面靠查——有血缘平台的团队查一下下游，没有的靠"我记得谁在用这张表"；
- 风险靠经验——同样是改字段类型，加宽无所谓，收窄就可能炸下游取数；
- 决策靠会议——小变更也拉会，大变更反而因为流程重被绕过去。
改错一张表炸掉十个下游的事故，几乎每家数据团队都见过至少一次。机器能不能先表个态？把"放行 / 转人工 / 阻断"的初筛意见和风险分给出来，评审人只看机器拿不准的那部分。这就是决策大模型的位置——不是替人决策，是把人的注意力集中到低置信度的那 20% 上。
而它能这么干，靠的恰恰是"不说话"：判断是结构化的、带校准概率的、毫秒级的，才能直接接进流水线和审批流。让一个聊天大模型来做这件事，你得解析它的回复、祈祷它不编一个影响面出来，还得为三百字的分析付费。
三、实践：给"改表"装一道闸门
我们把这个场景完整做了一遍，代码开源（文末地址）。整体分工是一条铁律：
事实归血缘，判断归决策模型。
- 事实层：一段 SQL 变更进来，先做解析——什么操作、动了哪张表哪些列；再查血缘——下游几张表、多少列在消费它。这一步是确定性的，用开源 SQL 解析库加一份血缘数据就能做，也是我们做列级血缘平台（Esther）的日常；
- 判断层：把血缘分析的结果组装成一个 state——被改的列、下游消费它的列、沿路的边型——让决策模型在一次前向里回答三个类型化问题：
# 示意代码，完整实现见开源仓库
from laya import Router
router = Router(preload=True)
state = {
"change": "ALTER TABLE ods.orders MODIFY COLUMN amount DECIMAL(12,2)",
"operation": "column_type_change",
"type_change": "widen", # DECIMAL(10,2) → DECIMAL(12,2)，加宽兼容
"impacted_column": "ods.orders.amount",
# —— 以下为列级血缘分析的真实返回（该列的下游，端到端，中间层已折叠） ——
"lineage": {
"nodes": [
{ "id": "ods.orders.amount", "type": "COLUMN", "name": "amount" },
{ "id": "dwd.orders_detail.amount", "type": "COLUMN", "name": "amount" },
{ "id": "dws.order_summary.order_amount", "type": "COLUMN", "name": "order_amount" },
{ "id": "ads.dashboard_overview.gmv", "type": "COLUMN", "name": "gmv" }
],
"edges": [
{ "source": "ods.orders.amount", "target": "dwd.orders_detail.amount", "type": "DIRECT" },
{ "source": "dwd.orders_detail.amount", "target": "dws.order_summary.order_amount", "type": "AGGREGATION", "transform_expr": "SUM(amount) GROUP BY user_id" },
{ "source": "dws.order_summary.order_amount", "target": "ads.dashboard_overview.gmv", "type": "DIRECT" }
]
},
"downstream_table_count": 3, # 下游 3 张表（由血缘结果统计）
"downstream_column_count": 3, # 下游 3 个列受影响
}
questions = {
"disposition": { # choice：处置建议
"type": "choice",
"instructions": "Based on the change and the lineage impact in `state`, "
"what is the recommended disposition for this database change?",
"criteria": {
"pass": "auto-approve: the change touches nothing downstream or is fully compatible with all consumers",
"review": "send to human review: there are downstream consumers and it is uncertain whether they break",
"block": "recommend blocking: the change will very likely break downstream consumers",
},
},
"risk": { # score：风险打分
"type": "score",
"instructions": "What is the risk level of this database change?",
"criteria": ["low: no downstream impact", "medium-low", "medium",
"medium-high", "high: downstream breakage is likely"],
},
"breaks_downstream": { # noul：是否可能破坏下游
"type": "noul",
"instructions": "Could this change break downstream consumers?",
},
}
result = router.predict(state, questions)
一次前向，三个答案全回来：处置建议、风险分、破坏概率，各带概率分布。问题文本用英文写——基础 checkpoint 的底座是英文编码器（ModernBERT-large），英文提问效果更稳；Laya 的 multilingual checkpoint 支持中文，可按需切换。
- 门控层：拿概率做流程分流——处置为 pass 且置信度过阈值，自动放行；命中 block 或置信度不够，转人工。决策模型的概率不是装饰，是流程的输入。
实现选了开源的 Laya，不是 Jev。 原因很实际：Laya 是 Apache-2.0 协议的开源实现（GitHub: NandhaKishorM/laya），权重开放、可完全本地部署，数据不出内网——数据治理场景对这一点没有讨价还价的余地。它和 Jev 是同一思路：非自回归架构，基于 ModernBERT-large（421M）和 mmBERT-base（322M）双向编码器，单次前向约 33 毫秒（T4 实测），不生成文本、没有解析负担；内置语言路由自动识别 100+ 种语言分发到对应 checkpoint。API 与上面 Jev 的三原语一一对应，换成 Jev 的 API 几乎不用改设计。
四、实践里最有价值的三条发现
1. 这类模型不是拿来即用的，微调是分水岭
Laya 官方文档交底很诚实：在 typed-decisions 基准（四个工作流、2000 条决策）上，基础 checkpoint 零样本只有 0.362 的准确率，用你自己的领域决策数据微调后能到 0.766。
我们在自己的变更评审任务上量了一遍（6 条人工标注的迷你评测集，随代码开源）：零样本处置建议准确率 33%（2/6）——和官方那个 0.362 是同一量级。更值得警惕的是错误方向：把类型收窄这条该阻断的变更，判成了"无影响"。想清楚这意味着什么：决策大模型不像聊天模型开箱即用，它更像一个分类器——值钱的是你手上的标注数据。好在变更评审天然产生标注（每次人工评审的结论就是一条），数据是治理流程里现成的。
2. 校准过的概率，才是能接流程的资产
Laya 用严格真评分规则做强化学习训练（RLCD），出厂概率仍偏自信，官方提供了按自有数据拟合温度的流程——拟合后概率才真正"可门控"。这个"偏自信"不是纸面推断：demo 一跑起来，运行时就弹了警告——checkpoint 出厂配置里，11 选项以上那一档的温度参数是 0.1006，会把近乎随机的分布放大成 0.99 的"确定"，运行库直接拒绝应用并钳制。这改变了系统的设计方式：不再是"AI 给个答案，人看着办"，而是"概率过线自动放行、不过线转人工"，阈值的松紧就是流程的松紧。当前的开放版本没有内置"弃权"参数，我们的做法是在门控层自己兜底：置信度不过线，一律转人工——让流程承认"不确定"，比让它假装确定值钱得多。
3. 分工错了，方案就错了
实践里最容易犯的错，是让决策模型去"发现事实"。影响面、下游列表、类型兼容性——这些必须是血缘和解析喂给它的输入，不是它该回答的问题。决策模型只对给进 state 的事实做判断：给它的下游数量是错的，它给出的风险分再自信也是错的。决策模型是分诊台，不是专家门诊；专家门诊的那部分能力，该由血缘引擎提供。
五、边界交底
- 零样本水平有限。 基础 checkpoint 直接用，处置建议准确率只有三成（见第四节实测），撑不起门控决策；要落地，先把流程里现成的人工评审记录整理成微调数据——这是整个方案里最花时间的一步，也是真正决定效果的一步；
- 毫秒级是 GPU 上的事。 官方的约 33 毫秒是 T4 实测；我们在普通笔记本 CPU 上跑，一次三问的前向稳态 1~3 秒——对变更评审这种异步流程完全够用，但别拿它承诺毫秒级在线拦截；
- 它判断不了事实之外的东西。 血缘覆盖不到的下游（比如没人登记的临时脚本），决策模型无从知晓——闸门的可靠度上限是血缘的覆盖度；
- Jev 与 Laya 的实测对比请以自己场景为准。 两边的基准数字各有出处，落到"变更评审"这个具体任务上表现如何，只能用自己的数据说话——这也是我们把评测脚本一起开源的原因。
六、写在最后
Jev 刷屏带火的是一类需求：不需要 AI 说话，只需要 AI 表态，而且要快、要带概率、要能接进流程。数据治理里这类需求到处都是——变更门控只是第一个，质量报警分诊、工单路由、标签审核都是同构的问题。
这道闸门的完整实现——SQL 事实抽取、样例血缘数据、三问一前向的门控、置信度分流、迷你评测集——全部开源，拿自己的变更数据换进去就能试。
▎ Esther 是一个企业级 SQL 数据血缘分析平台：28 种 SQL 方言、27+ 种数据源元数据采集、列级血缘、元数据管理、私有化部署。本文"事实归血缘"那一层，就是它每天在做的事。
▎ 本文闸门的开源实现放在 agent-demos 仓库（laya-change-gate 目录）：GitHub github.com/estherdata2026/agent-demos。配套的血缘用例与脚本在资源仓库：GitHub github.com/estherdata2026/esther-official-resources，国内直达 gitee.com/esther2026/esther-official-resources
Jev、决策大模型、Laya、数据治理、数据血缘
