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------被改的列、下游消费它的列、沿路的边型------让决策模型在一次前向里回答三个类型化问题：

python 复制代码

# 示意代码，完整实现见开源仓库
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、数据治理、数据血缘