不生成文本、只给概率Kev 式决策模型正在刷屏风控审核圈【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev过去一年关于「AI 替代人工」的讨论几乎都被生成式大模型占据让模型写一段总结、生成一句客服话术、补全一份工单描述。但在风控、审核、工单分配这些真正要拍板的业务场景里一句流畅的自然语言并不是业务方想要的东西——他们想要的是一个可审计、可设阈值、可路由的结论。最近在技术社区密集出现的一组文章——「类 Jev 项目 Kev 从入门到实战」「Kev 小型决策模型从自训练到私有化部署的完整指南」「决策模型选型从 Jev、Kev、Laya 分层到 LoRA 微调实践」——把 Kev 推到了这个讨论的中心一个不生成文本、只输出概率分布的决策模型凭什么被风控、审核、工单分配从业者反复引用这篇文章基于 Kev 的开源仓库源码拆解它的架构设计、概率输出的工程意义以及确定性输出为什么能成为企业落地的卖点。不生成文本Kev 与生成式模型的核心差异打开 Kev 仓库第一行对项目的定义就很直白Small Jev-like decision models you can train and run yourselfREADME.md。Jev-like指的是它复刻了 TypeSafe 商业模型 Jev 的 API 与架构思路而决策模型三个字对应的是它和 ChatGPT 这类通用 LLM 之间一条清晰的分界线。这条分界线刻在代码里。Kev 的模型骨架直接去掉了语言模型的词表头——kev/model.py中加载 base model 时明确写的是AutoModel.from_pretrained(...)而不是AutoModelForCausalLM注释是backbone only (no vocab head): we never generate textkev/model.py。一个没有词表头的模型物理上就无法生成文本。它的全部输出路径只有一条把所有选项的隐藏状态收拢到一个指针头PointerHead里做一次 softmax得到一组概率。再看它的输入格式。一次请求由state要评估的文本和若干道类型化问题组成问题只有三种kev/api.pynoul是非判断输出是的概率choice多选一输出每个选项的概率score有序打分输出每个等级的概率与期望等级。kev/model.py里的encode()展示了请求如何被打包成模型输入state 之后每个问题排成q 指令 opt 选项 /opt…decide的独立分支kev/model.py。整个 token 序列在推理时只做 prefill一次性前向从不做 decode。README 里对应有一句很关键的话Each question is answered as its own row that continues from the shared state, so questions cannot influence one another; the state is computed once and cacheddocs/model-cards/kev-0.8b.md——state 只编码一次每个问题各自独立作答问题之间互相看不见。这个设计与风控审核的业务诉求是精确对应的工单里同时问该转给哪个部门是否需要紧急升级客户情绪有多激动三道题的答案必须由同一份事实文本驱动而不是由上一道题的语气污染下一道题。生成式模型做不到这一点Kev 用结构化的分支配对天然做到了。概率分布而非标签为什么这是工程上更诚实的产品生成式模型的输出是 token 序列哪怕你要求它只输出是或否它给出的仍然是一段文本置信度要么藏在 prompt 的措辞里要么根本不存在。Kev 的 API 回应则是一份结构化的概率分布。以 README 中的工单示例为例一次请求同时问三个问题README.md{ answers: { department: { type: choice, choice: returns, confidence: 0.21, probabilities: { returns: 0.47, shipping: 0.28, billing: 0.25 } }, escalate: { type: noul, noul: 0.93 }, frustration: { type: score, score: 1.44, probabilities: { 0: 0.00, 1: 0.56, 2: 0.44 } } }, latency_ms: 495 }这份回应的价值不在choice: returns这个标签而在probabilities那一串数字。README 对此有一句直白的解释The ticket mentions a return, a late delivery and a billing problem, and the department probabilities say so. Thats why Kev returns probabilities instead of a single label: your code can route the confident cases and send the rest to a person.README.md——概率分布让置信的部分自动化、不置信的部分转人工成为可能。在风控审核场景里设置阈值、分流处理几乎是刚需置信度高于 0.9 的自动通过0.6 到 0.9 的进入抽样复核低于 0.6 的直接转人工。Kev 为此在工程上做了两件实打实的事第一默认校准。仓库为每个 checkpoint 都拟合并内置了一个温度参数temperature在kev/model.py的PointerHead中logits 在推理时除以该温度kev/model.py。Kev 1.0 的四个模型分别携带 2.35 / 2.41 / 2.19 / 1.32 的温度docs/releases/kev-1.0.md。校准带来的效果在 README 中有量化数字在新来源数据上校准把 Kev-9B 的 ECE期望校准误差从 0.103 降到 0.041把置信度≥0.9 却答错的错误率从 8.2% 降到 2.4%——低于 Jev 的 3.7%README.md。这意味着0.9 以上可以自动化这个决策在概率层面站得住脚。第二自动化率可评估。kev/metrics.py中定义了完整的评测指标accuracy、Brier score、ECE、NLL以及选择性预测指标coverage_at_error在给定错误预算下的自动化覆盖率和 AURCkev/metrics.py。评测套件把有多少比例的决策可以在 5% 错误预算下自动化作为核心产出指标。这是一个把概率直接换算成业务 KPI 的指标错误预算 5%就意味着每自动处理 100 单最多允许 5 单出错。风控、审核、工单分配圈的共鸣点社区文章反复强调 Kev 适用于风控、审核、工单分配等结构化决策任务这并非空泛的形容词堆砌仓库的数据管线、微调流程和评测体系是围绕这类场景专门设计的。共鸣点一自训练 领域数据注入而不是调 prompt。社区选型文章如「类 Jev 项目 Kev 从入门到实战(6)Jev / Kev / Laya 对比」的核心结论是选型关键不在于零样本性能而在于能否把业务规则、语言和类别体系注入模型。Kev 提供了完整的自训练链路这是它相比闭源商业模型的根本差异。训练脚本kev/train.py支持从自己的 JSONL 数据微调一条命令即可从已发布 checkpoint 继续训练kev/train.pyuv run python -m kev.train --data train.jsonl --base Qwen/Qwen3.5-4B-Base --init_from jaredpalmer/kev-4b \ --epochs 2 --lr 2e-5 --batch 1 --accum 8 --dtype bf16 --checkpointing 1 --device cuda --out runs/mine数据格式与 API 请求同构——每条记录就是一个state 若干带 label 的问题README.md。kev/data.py进一步说明训练数据是经由与线上服务完全相同的to_record()路径转换的the training format is byte-identical to what /v1/systemone feeds the modelkev/data.py。训练与推理同格式是工程上降低离线效果在线崩盘风险的关键设计。共鸣点二微调收益在数据量上有明确刻度。社区文章对到底要多少数据才能微调给出了实操建议仓库用实验数字支撑了这一点。README 记录了典型工单负载上的结果三个问题、1050 条生成记录、H100 上 15 分钟Kev-4B 准确率从 67.7% 提升到 73.6%5% 错误预算下的自动化率从 34% 提升到 48%而在真实数据上5,219 条标注的消费金融投诉上训练一个 epochKev-4B 在未见过的投诉上准确率从 0.804 提升到 0.904README.md。同时 README 也诚实地标注了边界400 条记录时增益落入噪声区间——这提醒工程团队在立项时先把数据规模想清楚而不是盲目堆数据。共鸣点三闭源与开源的落点差异。社区文章对 Jev / Kev / Laya 三层模型的关系做了大量梳理Jev 闭源、性能强但不可训练Laya 轻量快速但缺乏有效微调能力Kev 是唯一支持领域数据注入的可训练开源方案。仓库里的对比数据也支持可训练这一差异的现实意义在用户实测的 836 个支持工具决策上从 base 模型直接微调在 Kev 自己的评测集上只拿到 0.33而从已发布模型--init_from继续训练则保持 0.83并能在新领域达到 0.88README.md。对审核、风控团队来说这解释了为什么拿开源模型在自家标签上再训一版通常是性价比最高的路线。确定性输出为何成为企业落地的卖点卖点一可审计、可设阈值的置信度。生成式模型给出的文本无法直接参与规则引擎的阈值判断Kev 输出的概率分布可以。仓库的校准工具链kev/calibrate.py甚至支持按你自己的负载重拟合温度python -m kev.calibrate --rows runs/xxx/rows.json会给出四个对照臂——raw未校准、shipped出厂温度、workload在你这批数据上拟合的温度以及 workload_oof留一折外估计并用配对 bootstrap 给出 ECE / Brier / 覆盖率差异的置信区间kev/calibrate.py。这等于把置信度在自家数据上是否可信从一个模糊的担忧变成了一个可测量的工程问题。卖点二算力与部署门槛被压到很小。决策模型不做自回归生成推理成本远低于同体量的对话模型。README 的服务性能表显示Kev-4B 在 H100 上处理六个问题约 18.1ms单容器可承载约 101 req/sKev-0.8B 在 L4 上即可运行GPU 占用 3.8GBREADME.md。这让风控审核团队可以用极低成本搭建决策服务。部署链路同样完整kev/serve.py提供了 TypeSafe 兼容的POST /v1/systemone服务kev/serve.pyskills/kev-deploy/SKILL.md给出了单命令部署到 Modal 的流程——按需伸缩、空闲归零、可加 API Keyskills/kev-deploy/SKILL.md。卖点三数据不出域。社区文章强调的私有化部署价值在仓库里同样有直接的代码支撑权重全部开放、协议为 Apache-2.0服务端支持本地启动state文本只在本地处理。模型卡片中关于数据安全的段落明确写着Self-hosting keeps inputs on your own hardwaredocs/model-cards/kev-0.8b.md。对把审核、风控数据视为敏感资产的企业这可能是比精度更重要的取舍。卖点四一条明确的评测与发布纪律。决定要不要信任一个新模型最终要落到评测方法上。仓库在这方面展示了罕见的严谨evals/下的数据冻结并记录 sha256 与数据集 revision如 evals/v4/transfer-v4/manifest.jsontest 集每模型只读一次locked test所有已发布数字都可在docs/claims.json中溯源到具体实验报告并有scripts/verify_claims.py在 CI 中校验README.md。社区文章里提到的评测避坑如淘汰模板化工单数据、双标注分歧数据、闭源模型蒸馏标注数据在docs/releases/kev-1.0.md中有逐条记录docs/releases/kev-1.0.md。对风控审核这类错了要担责的业务这种可审计的评测流程本身就是一种信任资产。Kev 家族四档模型0.8B / 4B / 9B / 27B在新来源模型从未见过的数据集与规则上的表现给出了它当前的能力边界Kev-27B 在 domain-transfer 评测上达到 0.851距 Jev 的 0.857 仅一步之遥而在知识密集型问题MMLU-Pro 0.675 vs Jev 0.840和日期算术上仍落后README.md。决策类任务与知识问答任务的差距恰恰说明只给概率、不生成文本这条路的价值它把模型的精力集中在判断上而不是修辞上。下面的图展示了 Kev 各尺寸模型与 Jev 在不同来源类别上的准确率对比——在分类形状的任务路由、蕴含、科学问答上Kev 与闭源参考模型的距离显著缩小而在知识型任务上差距依旧如果你手上正好有一批带标签的工单、投诉或审核样本Kev 的 playground 可以帮你先零成本验证这条链路输入一段文本配好三五个问题直接看到每个选项上的概率分布docs/playground.png 对应仓库中playground/下的交互界面。再决定要不要用几百分钱在 H100 上跑一轮微调、把自家审核规则注入进去。风向在变风控与审核圈的共识正在从哪个模型写得更像人转向哪个模型判断得更可靠。概率输出、可校准、可微调、可私有化——Kev 把这四件事做成了开源可复制的工程能力。对于每天要在海量工单和内容里做决定的团队这可能是比又一个会聊天的模型更实际的东西。【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 不生成文本、只给概率：Kev 式决策模型正在刷屏风控审核圈
不生成文本、只给概率Kev 式决策模型正在刷屏风控审核圈【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev过去一年关于「AI 替代人工」的讨论几乎都被生成式大模型占据让模型写一段总结、生成一句客服话术、补全一份工单描述。但在风控、审核、工单分配这些真正要拍板的业务场景里一句流畅的自然语言并不是业务方想要的东西——他们想要的是一个可审计、可设阈值、可路由的结论。最近在技术社区密集出现的一组文章——「类 Jev 项目 Kev 从入门到实战」「Kev 小型决策模型从自训练到私有化部署的完整指南」「决策模型选型从 Jev、Kev、Laya 分层到 LoRA 微调实践」——把 Kev 推到了这个讨论的中心一个不生成文本、只输出概率分布的决策模型凭什么被风控、审核、工单分配从业者反复引用这篇文章基于 Kev 的开源仓库源码拆解它的架构设计、概率输出的工程意义以及确定性输出为什么能成为企业落地的卖点。不生成文本Kev 与生成式模型的核心差异打开 Kev 仓库第一行对项目的定义就很直白Small Jev-like decision models you can train and run yourselfREADME.md。Jev-like指的是它复刻了 TypeSafe 商业模型 Jev 的 API 与架构思路而决策模型三个字对应的是它和 ChatGPT 这类通用 LLM 之间一条清晰的分界线。这条分界线刻在代码里。Kev 的模型骨架直接去掉了语言模型的词表头——kev/model.py中加载 base model 时明确写的是AutoModel.from_pretrained(...)而不是AutoModelForCausalLM注释是backbone only (no vocab head): we never generate textkev/model.py。一个没有词表头的模型物理上就无法生成文本。它的全部输出路径只有一条把所有选项的隐藏状态收拢到一个指针头PointerHead里做一次 softmax得到一组概率。再看它的输入格式。一次请求由state要评估的文本和若干道类型化问题组成问题只有三种kev/api.pynoul是非判断输出是的概率choice多选一输出每个选项的概率score有序打分输出每个等级的概率与期望等级。kev/model.py里的encode()展示了请求如何被打包成模型输入state 之后每个问题排成q 指令 opt 选项 /opt…decide的独立分支kev/model.py。整个 token 序列在推理时只做 prefill一次性前向从不做 decode。README 里对应有一句很关键的话Each question is answered as its own row that continues from the shared state, so questions cannot influence one another; the state is computed once and cacheddocs/model-cards/kev-0.8b.md——state 只编码一次每个问题各自独立作答问题之间互相看不见。这个设计与风控审核的业务诉求是精确对应的工单里同时问该转给哪个部门是否需要紧急升级客户情绪有多激动三道题的答案必须由同一份事实文本驱动而不是由上一道题的语气污染下一道题。生成式模型做不到这一点Kev 用结构化的分支配对天然做到了。概率分布而非标签为什么这是工程上更诚实的产品生成式模型的输出是 token 序列哪怕你要求它只输出是或否它给出的仍然是一段文本置信度要么藏在 prompt 的措辞里要么根本不存在。Kev 的 API 回应则是一份结构化的概率分布。以 README 中的工单示例为例一次请求同时问三个问题README.md{ answers: { department: { type: choice, choice: returns, confidence: 0.21, probabilities: { returns: 0.47, shipping: 0.28, billing: 0.25 } }, escalate: { type: noul, noul: 0.93 }, frustration: { type: score, score: 1.44, probabilities: { 0: 0.00, 1: 0.56, 2: 0.44 } } }, latency_ms: 495 }这份回应的价值不在choice: returns这个标签而在probabilities那一串数字。README 对此有一句直白的解释The ticket mentions a return, a late delivery and a billing problem, and the department probabilities say so. Thats why Kev returns probabilities instead of a single label: your code can route the confident cases and send the rest to a person.README.md——概率分布让置信的部分自动化、不置信的部分转人工成为可能。在风控审核场景里设置阈值、分流处理几乎是刚需置信度高于 0.9 的自动通过0.6 到 0.9 的进入抽样复核低于 0.6 的直接转人工。Kev 为此在工程上做了两件实打实的事第一默认校准。仓库为每个 checkpoint 都拟合并内置了一个温度参数temperature在kev/model.py的PointerHead中logits 在推理时除以该温度kev/model.py。Kev 1.0 的四个模型分别携带 2.35 / 2.41 / 2.19 / 1.32 的温度docs/releases/kev-1.0.md。校准带来的效果在 README 中有量化数字在新来源数据上校准把 Kev-9B 的 ECE期望校准误差从 0.103 降到 0.041把置信度≥0.9 却答错的错误率从 8.2% 降到 2.4%——低于 Jev 的 3.7%README.md。这意味着0.9 以上可以自动化这个决策在概率层面站得住脚。第二自动化率可评估。kev/metrics.py中定义了完整的评测指标accuracy、Brier score、ECE、NLL以及选择性预测指标coverage_at_error在给定错误预算下的自动化覆盖率和 AURCkev/metrics.py。评测套件把有多少比例的决策可以在 5% 错误预算下自动化作为核心产出指标。这是一个把概率直接换算成业务 KPI 的指标错误预算 5%就意味着每自动处理 100 单最多允许 5 单出错。风控、审核、工单分配圈的共鸣点社区文章反复强调 Kev 适用于风控、审核、工单分配等结构化决策任务这并非空泛的形容词堆砌仓库的数据管线、微调流程和评测体系是围绕这类场景专门设计的。共鸣点一自训练 领域数据注入而不是调 prompt。社区选型文章如「类 Jev 项目 Kev 从入门到实战(6)Jev / Kev / Laya 对比」的核心结论是选型关键不在于零样本性能而在于能否把业务规则、语言和类别体系注入模型。Kev 提供了完整的自训练链路这是它相比闭源商业模型的根本差异。训练脚本kev/train.py支持从自己的 JSONL 数据微调一条命令即可从已发布 checkpoint 继续训练kev/train.pyuv run python -m kev.train --data train.jsonl --base Qwen/Qwen3.5-4B-Base --init_from jaredpalmer/kev-4b \ --epochs 2 --lr 2e-5 --batch 1 --accum 8 --dtype bf16 --checkpointing 1 --device cuda --out runs/mine数据格式与 API 请求同构——每条记录就是一个state 若干带 label 的问题README.md。kev/data.py进一步说明训练数据是经由与线上服务完全相同的to_record()路径转换的the training format is byte-identical to what /v1/systemone feeds the modelkev/data.py。训练与推理同格式是工程上降低离线效果在线崩盘风险的关键设计。共鸣点二微调收益在数据量上有明确刻度。社区文章对到底要多少数据才能微调给出了实操建议仓库用实验数字支撑了这一点。README 记录了典型工单负载上的结果三个问题、1050 条生成记录、H100 上 15 分钟Kev-4B 准确率从 67.7% 提升到 73.6%5% 错误预算下的自动化率从 34% 提升到 48%而在真实数据上5,219 条标注的消费金融投诉上训练一个 epochKev-4B 在未见过的投诉上准确率从 0.804 提升到 0.904README.md。同时 README 也诚实地标注了边界400 条记录时增益落入噪声区间——这提醒工程团队在立项时先把数据规模想清楚而不是盲目堆数据。共鸣点三闭源与开源的落点差异。社区文章对 Jev / Kev / Laya 三层模型的关系做了大量梳理Jev 闭源、性能强但不可训练Laya 轻量快速但缺乏有效微调能力Kev 是唯一支持领域数据注入的可训练开源方案。仓库里的对比数据也支持可训练这一差异的现实意义在用户实测的 836 个支持工具决策上从 base 模型直接微调在 Kev 自己的评测集上只拿到 0.33而从已发布模型--init_from继续训练则保持 0.83并能在新领域达到 0.88README.md。对审核、风控团队来说这解释了为什么拿开源模型在自家标签上再训一版通常是性价比最高的路线。确定性输出为何成为企业落地的卖点卖点一可审计、可设阈值的置信度。生成式模型给出的文本无法直接参与规则引擎的阈值判断Kev 输出的概率分布可以。仓库的校准工具链kev/calibrate.py甚至支持按你自己的负载重拟合温度python -m kev.calibrate --rows runs/xxx/rows.json会给出四个对照臂——raw未校准、shipped出厂温度、workload在你这批数据上拟合的温度以及 workload_oof留一折外估计并用配对 bootstrap 给出 ECE / Brier / 覆盖率差异的置信区间kev/calibrate.py。这等于把置信度在自家数据上是否可信从一个模糊的担忧变成了一个可测量的工程问题。卖点二算力与部署门槛被压到很小。决策模型不做自回归生成推理成本远低于同体量的对话模型。README 的服务性能表显示Kev-4B 在 H100 上处理六个问题约 18.1ms单容器可承载约 101 req/sKev-0.8B 在 L4 上即可运行GPU 占用 3.8GBREADME.md。这让风控审核团队可以用极低成本搭建决策服务。部署链路同样完整kev/serve.py提供了 TypeSafe 兼容的POST /v1/systemone服务kev/serve.pyskills/kev-deploy/SKILL.md给出了单命令部署到 Modal 的流程——按需伸缩、空闲归零、可加 API Keyskills/kev-deploy/SKILL.md。卖点三数据不出域。社区文章强调的私有化部署价值在仓库里同样有直接的代码支撑权重全部开放、协议为 Apache-2.0服务端支持本地启动state文本只在本地处理。模型卡片中关于数据安全的段落明确写着Self-hosting keeps inputs on your own hardwaredocs/model-cards/kev-0.8b.md。对把审核、风控数据视为敏感资产的企业这可能是比精度更重要的取舍。卖点四一条明确的评测与发布纪律。决定要不要信任一个新模型最终要落到评测方法上。仓库在这方面展示了罕见的严谨evals/下的数据冻结并记录 sha256 与数据集 revision如 evals/v4/transfer-v4/manifest.jsontest 集每模型只读一次locked test所有已发布数字都可在docs/claims.json中溯源到具体实验报告并有scripts/verify_claims.py在 CI 中校验README.md。社区文章里提到的评测避坑如淘汰模板化工单数据、双标注分歧数据、闭源模型蒸馏标注数据在docs/releases/kev-1.0.md中有逐条记录docs/releases/kev-1.0.md。对风控审核这类错了要担责的业务这种可审计的评测流程本身就是一种信任资产。Kev 家族四档模型0.8B / 4B / 9B / 27B在新来源模型从未见过的数据集与规则上的表现给出了它当前的能力边界Kev-27B 在 domain-transfer 评测上达到 0.851距 Jev 的 0.857 仅一步之遥而在知识密集型问题MMLU-Pro 0.675 vs Jev 0.840和日期算术上仍落后README.md。决策类任务与知识问答任务的差距恰恰说明只给概率、不生成文本这条路的价值它把模型的精力集中在判断上而不是修辞上。下面的图展示了 Kev 各尺寸模型与 Jev 在不同来源类别上的准确率对比——在分类形状的任务路由、蕴含、科学问答上Kev 与闭源参考模型的距离显著缩小而在知识型任务上差距依旧如果你手上正好有一批带标签的工单、投诉或审核样本Kev 的 playground 可以帮你先零成本验证这条链路输入一段文本配好三五个问题直接看到每个选项上的概率分布docs/playground.png 对应仓库中playground/下的交互界面。再决定要不要用几百分钱在 H100 上跑一轮微调、把自家审核规则注入进去。风向在变风控与审核圈的共识正在从哪个模型写得更像人转向哪个模型判断得更可靠。概率输出、可校准、可微调、可私有化——Kev 把这四件事做成了开源可复制的工程能力。对于每天要在海量工单和内容里做决定的团队这可能是比又一个会聊天的模型更实际的东西。【免费下载链接】kevJev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own项目地址: https://gitcode.com/gh_mirrors/kev2/kev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考