深度分析 StartLux-Decision：它是银行的第几种小模型？风控决策、本地微调与数据分级三条路的可行性核验

StartLux-Decision 是 Jev 的开源等价物：同一 /v1/systemone 接口、同一套三题型，TypeSafe SDK 只改两个环境变量即可指向本地服务，权重公开且可量化到 0.53GB。

它不是银行小模型的升级版。银行评分卡的可解释性来自 WOE 分箱与线性系数，可逐条对监管解释；类型化决策模型给的是选项概率，解释力被封在模型内部。两者是分工，不是替代。

五个基准给出它的真实画像：BANKING77 macro-F1 90.98、ContractNLI 86.36、PhishNChips 70.45 均高于 Jev 1.13，但 GPQA Diamond 50.51 对 78.57、BBH 80.23 对 92.92 明显落后。

API-Bank 是关键反转项。这个银行场景基准上 Jev 1.13 得 88.19，高于 StartLux 全部六个尺寸的最高值 86.22；40 项基准中它有 5 项在全部尺寸上占优，全部落在知识推理域与这一个银行基准上。

本地部署微调技术上无障碍，许可上有一条硬门槛：代码 Apache-2.0，权重 CC BY-NC 4.0 非商业，商业使用须单独授权。银行是商业主体，须先过法务这道门再谈技术。

可落地的位置不是替代评分卡，而是补上中信 AI 天盾"大、小模型双轮驱动"里缺的中间层：语义分类、批量分级、是否转人工的路由判断；高风险环节仍按 8 号文留人工闸。

素材说明：本文事实来源为 12 份材料，性质与核验边界如下。

>

1. StartLuxLabs/StartLux-Decision 仓库（来源1）：一手源码核验。本文将该仓浅克隆到本地，逐文件阅读 README.md、docs/inference.md、docs/finetuning.md、docs/evaluation.md、docs/results.md，并直接读取 results/decision_index_benchmarks.csv 与 results/summary.csv 两个原始数据文件；选项上限 26、温度网格 0.2—5.0 共 801 点、上下文 262144 等代码级断言均由 grep 直接定位至 jevfmt.py、calibrate.py、model.py。凡属模型效果数字，一律标注"仓库自述"，因为仓库明确说明这些数字出自其内部评测管线且"我们的分数不在公榜上"。

2. Hugging Face 权重集合（来源2）：本文工作环境无法连通 Hugging Face，模型卡的 license 字段、gated 状态与 gating 条件均未能独立核验，权重许可仅以来源1 README 自述的 CC BY-NC 4.0 为准。

3. 36氪（来源3）、凤凰网（来源4）、21经济网（来源5）：厂商发布稿与厂商专访，其中效果数字多为转载仓库自述。来源3 的英文版写"36 局棋赢 35 局"，与来源1 README 记录的 256 局 58.4%（Elo +59，95% CI +37 到 +82）不符；本文已核对原始数据并采用仓库口径，该差异在正文第三节单列。

4. Zenn（来源6）：唯一独立第三方实测，使用 RTX 3090 环境，实测对象是 JevK5 与 Jev 官方而非 StartLux-Decision。其对 Decision Index（132,422 个 sha256 冻结请求、unanswered 即 wrong、共同规范加审计式 PR 提交而非中心化隔离）与 JevBench 官方 v1.4.2.2（智力/校准/速度/成本各 25%、含密封 Decisions、公开与密封准确率差超 25% 判为过拟合）两套机制的剖析，是本文据以区分"自报口径"与"隔离复现"的依据。

5. apolinario/decision-index（来源7）：Decision Index 评测套件与公榜的维护仓库，本文仅核验其存在性与公开地址，未运行其套件（完整套件按说明不可再分发）。

6. 新华网中信 AI 天盾报道（来源8）：官方渠道报道，其中"大模型作为全局智能层、小模型作为专业执行层"的双轮驱动表述是本文核心论点的直接支撑；"累计拦截涉案资金超 35 亿元、查控可疑涉案账户近 50 万户、客户投诉率下降 62%"均为该报道引述的银行自述成效，非第三方审计。

7. 搜狐金科创新社中原银行实践文（来源9）：一线建模人员署名文章，"逻辑回归评分卡是金融领域尤其是银行长期以来的黄金标准和基线模型"与"预测违约率降低 20%"均为该文自述，非第三方审计数据。

8. 8 号文（来源11）、证券时报罚单文（来源10）、阿里云 Jev 分析文（来源12）：分别为监管文件转载、财经媒体行业统计、云厂商技术社区分析。来源10 的罚单数量与金额系其自述梳理企业预警通与监管披露所得，非监管官方统计公告；来源12 的催收场景概率为示例值而非实测。

9. 核验边界声明：Decision Index 的完整评测套件不可再分发，分数由各方自跑后以 GitHub PR 提交、经维护者校验拒答率与哈希后合并，属共同规范加审计式 PR 提交而非中心化隔离评测，因此本文全部效果对比应理解为"同一套公开脚本下的厂商自报口径"。文中未出现任何"某行已采用 StartLux-Decision"之类未经证实的落地陈述；所有涉及银行采用该模型的表述均为本文建议或推断，已在文末推论标注一节列出。

一、它到底是什么：不是更大的分类器，而是把"读字母"做成一次前向

先看仓库自己的定义。README.md 第一段的原话是：StartLux-Decision 是一族 typed decision models，从 0.8B 到 27B 五个稠密尺寸，加一个 35B-A3B 的专家混合体；你提交一个 state 和一组 questions——几选一、是否判断、量表评分——它返回每个选项一个概率。"Nothing is generated; the answer is read from the option letters after one forward pass."

这句话是理解这个模型的全部关键。它和银行熟悉的一切模型都不同，因为它的输出不是生成的，而是读出来的。

机制上分三步（来源1 docs/inference.md）：

• 选项字母化：一个 choice 题的选项被依次记作 A、B、C，jevfmt.py 里 MAX_OPTIONS = 26，也就是说一道选择题最多 26 个选项。
• 一次前向：整个 state 和全部问题拼成一个提示，跑一次前向传播，不做自回归解码。
• 读 logits：从"字母位置"的 logits 取 softmax，得到每个选项的概率。答案就是概率最大的那个字母。

仓库把推理细节写得很直白，也写了自己的坑。推理文档说模型用了线性注意力层，依赖 flash-linear-attention 与 causal-conv1d 两个内核，"没有这两个包 transformers 会静默回退到普通 PyTorch 实现，慢十倍以上；不会报错，只是慢"。服务器默认要求这两个内核可用，否则拒绝启动。CUDA Graphs 的效果是量级的：4B 开图 26.0 ms，关图 90.3 ms。

三个题型的输出形态（来源1）：

• choice：返回选定项、置信度、全部选项的概率字典。置信度按 (p_max - 1/n) / (1 - 1/n) 计算，选项均分时为 0。
• noul（yes/no）：只返回 yes 的概率，没有单独的置信度字段；文档明确"要判断确定性请用 |2p - 1|"。
• score：上限 10 级，超过 10 级服务端返回 422。置信度是"1 减去概率加权后的偏离度，再归一化"。

这里有一个容易被忽略但影响生产部署的细节：服务端每 GPU 只处理一个请求。要上吞吐必须一卡一进程再加负载均衡。文档还记录了一次行为变更——"2026-10-03 之前包把最大概率当作 confidence 返回，现在仍在 probabilities 里"。这个日期距离模型发布只有三天。它说明这套接口的字段语义仍在变动，银行侧任何基于置信度阈值的策略都必须锁定代码版本。

256K 上下文与多模态是 2026-10-03 同批更新的（commit c61bfab 标题即 "Read images and prompts up to 262,144 tokens"）。model.py 的默认 max_length=262144。视觉侧按每 32×32 像素一个 token、上限 1,048,576 像素处理，视觉塔额外占 0.2 到 0.9 GB。这一点对银行数据治理是实质性的：一份扫描的合同、一张单据影像、一段聊天记录，可以进同一个请求。

一句话概括：它是一个把"在给定选项里选一个并给出概率"这件事做到极致的模型家族，不生成文本，延迟以毫秒计，选项和量表都是硬上限。

二、与银行小模型的四维差异：不是量变，是解释链条不同

"银行的小模型"不是一种模型，是一整套体系。来源9（中原银行零售信贷与信用卡部信亚楠、蒋梦梦的实践文章）把它说得比任何综述都清楚："逻辑回归结构简单，表现稳健，可解释性极强。通过特征分箱和 WOE 编码，可以生成一个直观的、有业务解释性的评分卡。这是金融领域，尤其是银行长期以来的黄金标准和基线模型。"同一篇接着说，2016 年 XGBoost 出现后集成算法走到中央，成为主流与性能冠军，因为它能自动捕捉特征交互。

把这个体系拆开来对比，差异落在四个维度上。

第一维：可解释性的来源不同，这是最本质的差异。

逻辑回归评分卡的可解释性是结构性的：每个特征经 WOE 分箱后变成一个区间，每个区间一个系数，系数可以直接读成"这个区间的客户违约率更高"。风控策略人员可以拿着这张表去和监管解释、和客户解释、和审计解释。决策树更可解释，它输出的是"如果-那么"规则。

StartLux-Decision 的可解释性是概率性的：它给你每个选项一个概率。但"为什么这个选项概率高"这个问题的答案在 262K 上下文的线性注意力权重里，不在表里。它不是不可解释，而是解释的载体从外部规则变成了内部权重。

这个差异在银行的监管语境下不是学术问题。来源9 那篇文章描述他们用递归样本删除决策树重构中原银行"原 e 贷 PLUS"授信策略时，反复强调的核心价值是"业务可解释性与策略亲和力"——"策略人员可以像阅读一份诊断报告一样，清晰地看到：具备特征 A 和 B 的客户风险最高；排除他们后，具备特征 C 和 D 的客户风险次之"，并且这个规则集被用来直接支撑差异化授信、额度、定价。同时那篇文章记录了一项硬数字：细化到 16 个一级分类、82 个二级分类，梳理存量 4 万多个准入单位，"在平均额度几乎不变的情况下，预测违约率降低 20%"。

注意这个数字的口径：模型没变复杂，变复杂的是规则集，而且规则集是人能读懂的。 决策模型给出的选项概率做不出这样的"诊断报告"。

第二维：输出形态不同，决定了它能干什么。

银行小模型的输出是分数或类别：违约概率 0.032、A 级、拒绝。它是标量或单标签。

StartLux-Decision 的输出是一份类型化答案清单。一条客服工单可以一次问三个问题（该归哪个团队、是否要当天处理、严重度几分），一次前向全部返回，每个都带概率分布。仓库的 README 明确说这解决了智能体的一个具体问题：每一步判断都要等一次生成式大模型的完整输出，延迟累积起来影响整体执行效率。

第三维：延迟与算力不同。

来源1 的 docs/inference.md 给出单卡 H200、bf16、三字段请求的延迟：0.8B 12.2 ms、2B 15.5 ms、4B 26.0 ms、9B 35.7 ms、27B 102.3 ms、35B-A3B 52.5 ms。对比 Jev 1.13 官方 64.0 ms（服务端上报时间，100 次均值，不含网络，2026-09-29 测）；Zenn 独立实测记到 Jev 官方约 180 ms 的往返时间。

量化的意义在于部署门槛：0.8B 的 GGUF Q4_K_M 是 0.53 GB，2B 是 1.27 GB，4B 是 2.71 GB。4B 的 Q4_K_M 相对 bf16 保留 96.5% 到 98.3% 的决策一致率，Q8_0 是 99% 以上。Q8_0 之后一致率开始下降。这意味着 4B 级别可以在一张消费级显卡甚至 CPU 上跑。

第四维：训练数据与能力分布不同，这是最能说明问题的一维。

来源1 的 results/summary.csv 给出 JevBench hard 层的 Brier 与 ECE（ECE 越低越准）：0.8B 是 Brier 0.5243、ECE 0.1239；2B 是 0.3942、0.0814；4B 是 0.3748、0.1035；9B 是 0.3552、0.0557；27B 是 0.2655、0.0536；35B-A3B 是 0.2803、0.0389。

两个小尺寸模型的校准明显更差。 0.8B 的 ECE 0.1239 是 35B 的三倍。这个事实直接回答了"银行能不能用小尺寸模型省钱"：省算力可以，校准质量会一起省掉，而校准质量正是决策模型在决策链上能被采信的前提。

三、它能不能用于银行风控决策：五个基准给出的"能"和"不能"

仓库自己公布了一个 40 项基准的原始数据文件。我把 Jev 1.13 的公榜分数和 StartLux 六个尺寸逐项比较，得到的结论不是"全面领先"，而是一个清晰的强项域和一个清晰的弱项域。

强项域：检索、分类、语言理解。 下表数字取自 results/decision_index_benchmarks.csv（原始 native metric，非乘覆盖率版本）：

• BANKING77（macro-F1，77 类银行客服意图）：0.8B 89.88、2B 86.07、4B 85.85、9B 91.40、27B 90.98、35B-A3B 91.14；Jev 1.13 是 79.74。
• CLINC150（151 类意图）：27B 92.97、35B 93.70；Jev 89.27。
• ContractNLI（合同文本蕴含判断，macro-F1）：27B 86.36、9B 86.58、35B 85.44；Jev 71.69，差距超过 14 个点。
• PhishNChips（钓鱼识别，accuracy）：27B 70.45、35B 69.10、9B 64.25；Jev 62.55。
• RAGTruth（幻觉检索，F1 on hallucinated class）：27B 85.57；Jev 76.53。

面积分（README 主表，乘覆盖率口径）：检索与分类域 66.8 对 Jev 55.4；工具与自动化域 82.2 对 75.1；语言理解域 70.1 对 61.8。

弱项域：知识与推理。 同一 CSV：

• GPQA Diamond（研究生级科学问答）：27B 50.51、35B 51.02；Jev 78.57。差 28 个点。
• BBH：27B 80.23、35B 76.10；Jev 92.92。
• MMLU-Pro：27B 69.77、35B 67.10；Jev 82.70。
• HLE：27B 12.38、35B 10.18；Jev 20.36。

面积分：知识与推理域 44.3 对 Jev 51.4。注意 35B-A3B（51.02）已经追平 27B（50.51），而 MMLU-Pro 上 35B（67.10）反而低于 27B（69.77）。在这个域上，加大参数不解决问题。

然后是关键反转项：API-Bank。

API-Bank 是一个银行场景的 API 调用基准。CSV 原始数据：0.8B 17.91、2B 50.39、4B 86.22、9B 78.35、27B 84.06、35B-A3B 79.92；Jev 1.13 是 88.19。

这是 40 项基准里唯一一个 Jev 在全部六个尺寸上都占优的银行场景基准。 注意 4B 的 86.22 反而是六个尺寸里最高的，9B、27B、35B 都在往下掉——这个基准上尺寸不是单调关系，而 0.8B 只有 17.91，接近随机。

我把 40 项全部跑了一遍比较，Jev 在全部六个尺寸上都占优的基准共 5 项：API-Bank、BBH、GPQA Diamond、HLE、MMLU-Pro。其中 4 项是知识与推理域，1 项是 API-Bank。 StartLux 在 34 项上至少有一个尺寸占优。

这个分布说明了它的能力边界：它是一个擅长"从给定候选里选对"的模型，不擅长"没有候选、需要自己推"的任务。 银行风控里，客户欺诈识别、反洗钱判断、征信评估这些任务，输入是结构化特征、候选是有限标签——落在它的强项域。而授信策略推理、反洗钱情景推演、复杂规则生成这些任务，需要跨特征的组合推理——落在它的弱项域。

媒体数字与实际数据的差异，值得单独列出来。 36氪英文版写"36 局棋赢 35 局"，凤凰网那篇转载的也是同一个口径。但仓库 README 记录的象棋对弈是256 局（128 个开局各走一次、黑白各下一盘），结果是 StartLux-Decision-27B 与 Jev 1.13 各下一盘，149.5 分对 106.5 分，胜率 58.4%，Elo 差 +59（95% 置信区间 +37 到 +82）。

"35/36"这个说法在仓库里找不到任何依据。 58.4% 的胜率是一个不错的结果，但离"碾压"很远，而且 95% 置信区间下界只有 +37。这类数字漂移在厂商发布稿中常见，而它恰恰说明一件事：厂商自述的效果数字必须回到原始数据核验，本文第三节的全部数字都取自 CSV 而非 README 的叙述段落。

再对照银行的真实架构。 来源8（新华网）报道中信银行"AI天盾"时用了这样一个表述："大模型作为全局智能层，聚焦复杂语义理解、多模态数据关联、深度风险推理，能够精准解析诈骗话术、挖掘隐性风险网络；小模型作为专业执行层，专注于反欺诈、反洗钱、账户安全等细分场景，能够实现毫秒级精准计算、快速决策与高并发响应，从而支撑亿级交易实时风控需求。"

中信银行的"小模型"指的是传统机器学习模型（反欺诈、反洗钱、账户安全场景），不是 StartLux-Decision。 该体系是"1+1+N"架构，第一道防线的"哨兵"反欺诈应用已累计拦截涉案资金超 35 亿元、查控可疑涉案账户近 50 万户、客户投诉率下降 62%（均为该报道引述的银行自述数据）。

把这个架构和 StartLux-Decision 的能力分布放在一起，会出现一个缺口：中信的大模型做语义与推理，小模型做毫秒级分类判断，但两者之间缺一个"能读懂非结构化语义、又能毫秒级输出类型化判断"的层。 StartLux-Decision 的位置恰好在中间。它不替代评分卡（可解释性差），也不替代大模型（推理差），但它比大模型快两个数量级，比评分卡多得多语义能力。

四、许可红线：这条比技术门槛更难翻

第三个问题技术上先回答：能。 仓库给了完整的本地化路径，我把每一步都核对到代码了。

下载：hf download startlux-models/StartLux-Decision-4B --local-dir StartLux-Decision-4B，六个尺寸在 Hugging Face 的 startlux-models 组织下。

部署：python -m startlux_decision.server --model StartLux-Decision-4B --port 8090，健康检查 curl localhost:8090/health 返回 {"status": "ok", "model": "...", "fast_kernels": true}。文档给了一段可直接用的迁移配置：export TYPESAFE_BASE_URL=http://127.0.0.1:8090 和 export TYPESAFE_API_KEY=unused，官方 TypeSafe SDK 即可指向本地服务。

量化：GGUF 与 llama.cpp 已集成，有专门的 gguf_server.py。0.8B 的 Q4_K_M 是 0.53 GB，可以放在边缘节点或部门级服务器上。

微调：finetune/finetune_lora.py。数据格式是每行一个 JSON，包含 state、questions 和 targets。文档给了三个值得注意的设计：

• 多人标注的投票份额可以直接当目标分布。原文："When several people labelled the same item, pass their vote shares as they are... the loss uses the whole distribution." 这对银行的专家标注场景很友好——不需要把分歧抹平成一个硬标签。
• 超过 26 个选项的选择题会被跳过，文档要求"先拆成不超过 26 个一组"。这是硬约束。
• 训练目标是选项字母位置的 softmax 交叉熵，与服务时的读法是同一条通路，文档明确说"训练与服务之间不会有任何改变"。这消除了训练-服务错配（train-serve skew）这一类常见问题。
• 默认参数：rank 16、alpha 32、dropout 0.05、学习率 1e-4、5% 热身余弦衰减、2 个 epoch。仓库自报 4B 在单张 H200 上跑 6000 条短工单约 3 分钟（含内核编译）。27B 的 bf16 权重约 54 GB，需要 80 GB 显存的卡。

校准：finetune/calibrate.py。它对 choice、noul、score 三种题型各拟合一个温度，网格是 0.2 到 5.0 之间 801 个对数等距点，样本不足 200 条的题型退化为合并拟合。它会把温度写进 decision_config.json。

但这里有一段必须逐字引用的警告，因为它直接决定了这套流程在银行场景能不能用：

"If the model is right on nearly every dev question, the fit pushes the temperature to the bottom of its range (0.2) and the probabilities become very sharp, which is rarely what you want on new data; use a larger or harder dev set. And a temperature fitted on one source of data can over- or under-correct on another, so check it on a second held-out set if you have one."

翻译过来：如果你的模型在几乎每一个开发集问题上都能答对，温度拟合就会把温度推到 0.2 的下限，概率变得极其锐利——这在新数据上通常不是你想要的。 而且在一个数据源上拟合的温度，在另一个数据源上可能过度校正或校正不足。

这段话和上一篇文章关于校准的核心结论完全一致。 校准不是训练出来的，是用你自己的标注数据量出来的，而且开发集越"简单"，校准结果越危险。银行的数据分级分类恰恰容易出这种问题：标注员对明显案例几乎不会错，模型在这些案例上全对，温度被压到下限，然后遇到真正模糊的边界案例时给出虚假的高置信度。

部署侧还有两个技术约束：

• FP8 不能直接跑带 padding 的批量请求。文档明确警告：动态 per-row activation scales 下，全零 padding 行会得到零 scale 并产生 NaN，NaN 会通过注意力层泄漏进真实行。开启 FP8 的批量评测，一致率从正常水平掉到约 52%。必须"一次前向处理一个问题，不带 padding"。FP8 本身每决策慢 2.7 倍、只省一半显存，与 bf16 一致率 96.3% 到 98.6%。
• 决策过程不在权重里。权重目录里只有 config.json、decision_config.json、权重文件、tokenizer.json。真正的答案提取逻辑在 startlux_decision/ 包里。文档原话："The decision procedure is not in the weights. Keep the server code in front of llama.cpp." 这意味着只拿权重自己实现推理是不完整的，必须用配套的代码。

Apple Silicon 也已支持：mlx_model.py、mlx_int8.py，27B 的 8 比特量化可在 64 GB 内存的 Mac 上跑，公开 JevBench 得 208/231（bf16 是 209/231）。M5 及以上支持 int8 矩阵乘，与 bf16 在 97.4% 到 99.6% 的题目上一致。

现在说许可。 这是本文最重要的一个事实，因为它决定了第三个问题的真实答案。

仓库 README.md 最后的 License 一节，逐字是：

"The code in this repository is Apache-2.0 (LICENSE). The model weights on Hugging Face are released under CC BY-NC 4.0: free for research and other non-commercial use, with attribution. Commercial use requires a separate license from StartLux Labs; contact contact@startlux.com."

拆开来看：

• 代码（startlux_decision/、finetune/、eval/、demos/）：Apache-2.0，可以商用、可以闭源修改、可以纳入内部系统。
• 权重（Hugging Face 六个模型）：CC BY-NC 4.0，即 Creative Commons Attribution-NonCommercial 4.0。"NC"是 NonCommercial。免费用于研究和其他非商业用途，需署名。
• 商业使用：需要向 StartLux Labs 另行取得授权，联系 contact@startlux.com。

银行的定义是商业主体。信贷审批、反欺诈拦截、客户分级、数据治理，没有一项是非商业活动。

所以第三个问题的完整答案是：技术上完全可行，许可上必须先拿到商用授权，否则权重部分不可用于银行生产环境。 这是一个和上一篇文章里 Jev 的处境方向相反的困境：Jev 的问题是"闭源、只走 API、数据和决策都出本地"，StartLux-Decision 的问题是"技术全开放、但商用要另外买"。

有一个合规上必须额外考虑的点。 LoRA 微调产物是什么许可证？CC BY-NC 约束的是权重；用它做 LoRA 微调得到的 adapter，其下游使用是否仍然受非商业条款约束，取决于授权协议的具体措辞。这是 CC 许可证在机器学习场景的一个已知灰色地带，本文无法替任何机构判断，必须由其法务就具体协议条款出具意见。

替代路径也要说清楚。 如果不想走商用授权，同一技术路线上有两条完全开源的替代方案，都是 Apache-2.0 且自述包含权重：

• rlcd-lite（arnabgho/rlcd-lite，198 star）：README 自述为"Simplified RL for Calibrated Decisions"，用 GRPO + RLCR 奖励函数重建校准决策训练，并明确写"This is not TypeSafe's algorithm (they have not published it)"。它给的是训练方法，需要自己准备标注数据。
• TypeSafe 的官方文档仍描述的是 Jev 的 API 形态，没有开源权重。

本文的判断是：对一家银行而言，"技术上可行、商业上要买授权"是一个可接受的商业决策，不是一个技术障碍。真正需要评估的是这个模型的能力分布是否匹配你的场景——这回到了第三节。

五、数据分级分类治理：三个具体可行的用法与四个具体不可行的用法

把 StartLux-Decision 放进银行数据分级分类治理，要对照两件事：一是监管要求，二是模型能力分布。

监管侧的框架在前一篇文章里已经梳理过，这里只取与本文相关的三条：

• 来源11（金融监管总局 8 号文）要求"将人工智能风险纳入全面风险管理体系，实施风险分类分级管理和高风险应用准入管理"，并且同一句里有一个硬约束——"在高风险应用关键环节要建立人工监督和干预机制"。
• JR/T 0197（《金融数据安全 数据安全分级指南》）规定了 5、4、3、2、1 五级。
• 《银行保险机构数据安全管理办法》把数据分为核心、重要、一般三级，一般再分敏感与其他。
• 来源10（证券时报，霍莉 2026-06-16）统计：2026 年 1 至 5 月数据安全类罚单 55 张、超过上年全年；数据报送与治理违规罚单是去年同期的 2.5 倍。该文为媒体梳理口径，非官方公告。

三个具体可行的用法：

用法一：非结构化数据的批量预分级。 这是最贴合它能力的一个场景。JR/T 0197 的五级完全在它的容量内（score 上限 10 级，choice 上限 26 选项）。256K 上下文加视觉输入意味着一份 PDF 合同、一张扫描单据、一批聊天记录可以整份进一个请求。用 choice 题问"这份文档的数据等级是什么"（选项 A 到 E 对应 5 到 1 级），用 score 题问"文档中是否包含个人金融信息"，一次前向返回概率分布。

这里 256K 上下文的价值是量级的。 传统小模型需要先做文档解析、字段抽取、特征工程，才能进评分卡；决策模型可以直接吃原文。银行数据治理的现实痛点正是大量非结构化资产没有分级——不是因为没有标准，而是因为分级标准要落到字段级、而字段级信息散落在文档里。

用法二：字段类型的语义分类。 数据分级依赖字段类型识别（身份证号、手机号、账户号、征信记录、交易流水）。这一类任务的本质是"从给定候选里选对"——恰好在 BANKING77 和 CLINC150 的强项域。9B 在 BANKING77 上 91.40、CLINC150 上 93.15。

用法三：是否转人工的路由判断。 用 noul 题问"这个数据操作是否应转人工复核"。这直接对接 8 号文的"高风险应用关键环节要建立人工监督和干预机制"。仓库的三题型设计天然适合做这个路由层——它自己就是为智能体的高频判断设计的。

四个具体不可行的用法：

不可行一：替代评分卡做授信决策。 原因是第二节的解释链条差异。授信策略要能向监管和客户解释"为什么你被拒"，评分卡的 WOE 系数和决策树规则可以做，选项概率做不了。

不可行二：复杂反洗钱情景推演。 这类任务落在知识与推理弱项域。GPQA Diamond 50.51 对 Jev 78.57、MMLU-Pro 69.77 对 82.70，说明它不具备足够的跨域推理能力。

不可行三：超过 26 个选项的单次分类。 硬上限。如果字段类型字典有 200 项，必须拆成多轮或多阶段——先用一道题分大类，再在每个大类内细分。这可行，但架构上要自己设计。

不可行四：在没有自己标注数据的情况下直接上线。 这是最致命的一条。原因是 calibrate.py 那段警告：温度拟合在开发集全对时会退化到 0.2，概率变得虚假锐利。银行必须先用自己的历史标注数据跑一遍，量出真实的 ECE，才能决定置信度阈值怎么设。 而且小尺寸的校准差距是实质性的：0.8B 的 ECE 0.1239 对 35B 的 0.0389。

六、四道硬门槛：从"能跑"到"能用"之间是什么

把本文的所有发现汇总成一个落地检查表。这四道门槛是技术性的，法务那道门槛在前一节。

门槛一：锁定代码版本，不要只锁定权重。 证据是"2026-10-03 之前包把最大概率当作 confidence 返回"这次变更——距离模型发布只有三天，字段语义就变了。银行侧任何基于置信度的阈值策略都必须同时锁定 startlux_decision 包版本和 decision_config.json 里的温度值。

门槛二：必须自建标注集并自己量校准。 证据是 calibrate.py 的 0.2 下限退化警告，加上 0.8B（ECE 0.1239）与 35B（0.0389）之间的三倍差距。开发集不能太简单，且要在第二份留出集上复验。

门槛三：FP8 禁止用于批量推理。 证据是文档记录的 NaN 泄漏：全零 padding 行得到零 scale，产生 NaN，通过注意力泄漏进真实行，一致率掉到约 52%。批量场景必须用 bf16，或改为"一次前向一个问题不带 padding"。

门槛四：吞吐要按"每 GPU 一请求"规划。 服务端默认串行。要上高并发必须一卡一进程加负载均衡。中信那种"亿级交易实时风控"的量级，需要专门评估。

另外三条架构性约束：

• 选择题 26 选项上限、量表 10 级上限（超过返回 422）。
• 决策逻辑不在权重里，必须用配套的 startlux_decision 包。
• CUDA Graphs 关闭会让 4B 从 26 ms 变 90.3 ms，性能敏感场景必须确认内核可用。

七、结论：它是银行风控体系里的第三种小模型，不是替代者

回到最初的问题。

"这模型与银行的小模型有何区别？" 区别不在规模，在解释链条的载体。银行小模型的可解释性住在 WOE 分箱表和 if-then 规则里，人可以直接读；StartLux-Decision 的可解释性住在选项概率里，概率可读、理由不可读。前者支撑"为什么"的对话，后者支撑"是什么"的快速判断。两者不在同一个位置上竞争。

"是否可以用于银行风控场景的决策？" 部分可以，而且位置很明确。它在检索分类域（66.8 对 55.4）、语言理解域（70.1 对 61.8）、工具自动化域（82.2 对 75.1）全面占优，其中 ContractNLI 86.36 对 71.69 与 PhishNChips 70.45 对 62.55 直接对应合同审查与反欺诈前置筛选这两个银行场景。但它在知识与推理域落后（44.3 对 51.4），且在唯一一项银行场景基准 API-Bank 上被 Jev 反超（88.19 对最高 86.22）。它的正确用法是中信"AI天盾"大小模型双轮驱动里缺失的中间层：比大模型快、比评分卡懂语义、负责高频路由判断；而不是替换任何一层。

"是否可以本地部署微调后用于银行数据分级分类治理？" 技术上三条路全通（权重可下、LoRA 可训、温度可校准、量化到 0.53 GB 可跑、256K 加多模态可读整份文档），但权重的 CC BY-NC 4.0 许可是一个必须在技术评估之前先过的法务门槛。拿到商用授权之后，它的三个可行用法（非结构化批量预分级、字段类型语义分类、转人工路由）和四个不可行用法（替代评分卡、复杂推演、超 26 选项单题、无标注数据上线）构成了一份可以直接执行的边界清单。

一个必须强调的立场。 本文所有模型效果数字都来自厂商仓库自述，且仓库自己声明"我们的分数不在公榜上"。来源6 的第三方剖析进一步说明，Decision Index 的评测机制是"共同规范加审计式 PR 提交"而非中心化隔离评测，完整套件不可再分发。因此本文的全部效果对比应当理解为"同一套公开脚本下的厂商自报口径"，而不是"经过独立第三方隔离复现的结论"。 银行在决定是否采购或授权之前，应当用自有数据复现——这恰恰也是 finetune/ 和 eval/ 两个目录存在的意义。

最后需要指出，仓库把自身评测的边界写得相当清楚，这一点值得肯定。docs/evaluation.md 明确说官方 JevBench 分数是另一套度量（加了密封层、速度、成本，只能由维护者测量），"我们不引用它"；docs/results.md 说明表格由内部评测代码生成、未重跑的外部数字未重跑、"少数边界题目在不同运行间会翻转"；docs/finetuning.md 主动写出温度退化的陷阱。一家成立不到五个月的公司把评测口径和已知陷阱写进文档，这比很多"全面领先"的表述可信。

但对银行的判断必须回到自己的数据上。这就是 8 号文那句话的真正含义：高风险应用关键环节要建立人工监督和干预机制——不是技术做不到的时候才要人，而是永远要。

八、行动清单

合规条线

• 依据 8 号文把决策模型应用登记为"高风险应用"并履行准入程序，明确"人工监督和干预机制"落到哪个环节、由哪个岗位执行（来源11）。
• 先过法务这道门：权重为 CC BY-NC 4.0，对商业主体不适用，须向 StartLux Labs 取得书面商用授权后再谈部署（来源1）。
• LoRA 微调产物的许可边界须由法务就具体授权协议条款出具意见。不能从"代码是 Apache-2.0"推出"下游一切自由"。
• 任何送往模型的银行数据先完成脱敏与去标识化，留档评估结论与操作日志，满足模型全生命周期管理要求（来源11）。

数据治理条线

• 先做标注集：从既有定级台账中抽取经人工确认的样本，作为训练集与温度标定集。这是唯一的真实门槛，不是算力。
• 开发集不要只用"明显的"样本。calibrate.py 明确警告模型在几乎全部开发题上都对时温度会退化到 0.2 下限、概率变得虚假锐利，且需第二份留出集复验（来源1）。
• 按 JR/T 0197 五级建字段级分级台账，字段间蕴含关系写成规则而非提示词。
• 字段类型字典超过 26 项时按大类拆成多轮：choice 硬上限 26 选项、score 硬上限 10 级，超限服务端返回 422（来源1）。

信息科技条线

• 锁定代码版本而非只锁权重。接口的 confidence 字段语义在 2026-10-03 发生过变更，距模型发布仅三天（来源1）。
• Shadow Mode 起步：先只输出建议字段、不参与决策，与人工定级结果比对至少一个完整整改周期，再逐步开放低风险自动决策。
• 批量推理禁用 FP8：全零 padding 行得到零 scale 产生 NaN，经注意力层泄漏进真实行，一致率掉到约 52%。批量场景用 bf16，或改为一次前向一个问题不带 padding（来源1）。
• 吞吐按"每 GPU 一请求"规划，一卡一进程加负载均衡，按目标 QPS 反推卡数。
• 验收必测五项：准确率、ECE（0.8B 0.1239 对 35B 0.0389 的三倍差距说明尺寸选择会同时改变校准质量）、选项顺序翻转率、跨字段一致性、"应转人工"触发率。
• 部署形态优先本地：4B 的 GGUF Q4_K_M 仅 2.71 GB，可在部门级服务器运行；0.8B 的 Q4_K_M 仅 0.53 GB，可放边缘节点（来源1）。

十、事实来源

• 来源1：StartLuxLabs/StartLux-Decision（GitHub 开源仓库）。https://github.com/StartLuxLabs/StartLux-Decision ；Apache-2.0 代码，Python，161 star，2026-09-29 创建、2026-10-03 最后推送，commit c61bfab（"Read images and prompts up to 262,144 tokens"），360 个文件。本文克隆整仓核验：README.md 与 docs/inference.md（三题型与输出字段、MAX_OPTIONS=26、score 上限 10 级、confidence 字段 2026-10-03 变更、每 GPU 一请求、CUDA Graphs 26.0/90.3 ms、H200 延迟 12.2—102.3 ms、Q4_K_M 0.53/1.27/2.71 GB、Q8_0 一致率 99%+、FP8 NaN 泄漏与约 52% 一致率、Jev 官方 64.0 ms、256K 上下文、视觉每 32×32 像素一 token 上限 1,048,576 像素、MLX 27B 8bit 208/231、"The decision procedure is not in the weights"）；docs/finetuning.md（LoRA 数据格式、多人投票分布作目标、26 选项跳过、softmax 交叉熵与服务同通路、rank16/alpha32/dropout0.05/lr1e-4/5%热身/2epoch、4B 单 H200 6000 条约 3 分钟、27B bf16 约 54 GB、calibrate.py 温度网格 0.2—5.0 共 801 点、少于 200 条退化合并拟合、温度退化到 0.2 下线的完整警告原文）；docs/evaluation.md（Intern-Decision 与 JevBench 评分器来源、"官方 JevBench 分数是另一套度量，我们不引用"、Typed Decisions 400 题、ECE 与卡上不可比、Decision Index 需 3.11、套件不可再分发、5 张 H200 约 25 分钟 1.9 GPU 时、内部 48.38/52.75 对脚本 48.42/52.75）；docs/results.md（表格由内部代码生成、未重跑、少数边界题翻转、官方 JevBench v1.4.2.2 含密封层与速度成本）；startlux_decision/jevfmt.py（MAX_OPTIONS = 26）、finetune/calibrate.py（GRID = [math.exp(math.log(0.2) + i*(math.log(5.0)-math.log(0.2))/800) for i in range(801)]）、model.py（max_length=262144、GROUP_OPTIONS=25、GROUP_KEEP=3）；results/decision_index_benchmarks.csv 与 results/summary.csv（全部 40 项基准原始分数与 Brier/ECE 汇总表）；License 一节（代码 Apache-2.0、权重 CC BY-NC 4.0、商用需单独授权 contact@startlux.com）。仓库自述效果数字：Decision Index 0.2.1 总分 27B 63.88 对 Jev 1.13 57.91，38 项中 31 项占优；JevBench public 35B-A3B 210/231、27B 208/231、Jev 199/231；象棋 256 局 149.5 对 106.5、58.4%、Elo +59（95% CI +37 到 +82）；面积分知识与推理 44.3 对 51.4、检索分类 66.8 对 55.4、工具自动化 82.2 对 75.1。
• 来源2：Hugging Face StartLux-Decision 模型集合。https://huggingface.co/collections/startlux-models/startlux-decision-6abba92b301b573fa154d493 ；六个尺寸权重仓库。本文工作环境无法连通 Hugging Face，未能核验模型卡字段（license、gated 状态），权重许可仅以来源1 的 README 自述为准。
• 来源3：36氪《Jev跌下王座 StartLux中国开源决策模型登顶行业第一》（机器之心，2026-10-03）。https://eu.36kr.com/zh/p/4009510615027849 ；公司背景（上海原点星辉科学技术有限公司，成立不到五个月）、CTO 郭权玮专访、前作 StartLux-27B 经工信部中国信通院测评以约 1/60 参数比追平 DeepSeek-V4-Pro、"36 局棋赢 35 局"口径（与仓库 256 局 58.4% 不符，本文采用仓库口径）、高风险操作（支付、删除、权限修改）仍需原授权确认机制、概率须在具体业务场景校准、Auto Research 95% 实验自动化。
• 来源4：凤凰网转载观察者网《AI参与"造AI"？StartLux 3天完成决策模型研发与验证》（2026-10-02，2026-10-04 更新）。https://news.ifeng.com/c/8wtoCJTC8H1 ；3 天完成研发与验证、七项评测平均 91.82% 对 Jev 88.74%、Auto Research 闭环（假设—实验—验证—新假设）、AI 承担约 70% 实验研发工作而研究员把关方向与关键取舍、"现有测试主要反映模型在公开基准和受控环境中的表现，在更复杂任务中能否持续作出可靠判断仍需通过后续实验和实际应用检验"。
• 来源5：21经济网（新华财经，记者高少华）《原点星辉推出开源决策模型 智能体"高频判断"迎来专用方案》（2026-10-01）。https://www.21jingji.com/article/20261001/herald/6ea7314e164e497a59a61f54cf6cf837.html ；公司全称"上海原点星辉科学技术有限公司"、TypeSafe AI 由前 OpenAI 研究员迪奥戈·阿尔梅达（Diogo Almeida）创办、2026 年 9 月推出 Jev、书生·明决为上海 AI 实验室决策模型、"让复杂问题及时转交到合适的模型或人"。
• 来源6：Zenn《JevK5 v0.3実機検証｜Jev Decision Index・JevBench評価と全判断モデル比較マスター表》（ヌルソフト@AI_Teck_PoC，2026-10-03 发布 2026-10-04 更新）。https://zenn.dev/null_teck/articles/jevk5-benchmark-decision-index ；独立第三方实测（RTX 3090 环境，非 StartLux）。关键机制剖析：Decision Index 基于 132,422 个 sha256 冻结请求、unanswered = wrong 严格罚分、机会校正分数、"共同规范加审计式 PR 提交"而非中心化（模型方自跑官方 harness 后以 GitHub PR 提交结果，维护者校验拒答率与哈希后合并，与 LMSYS Chatbot Arena 的中心化隔离机制不同）；完整套件不可再分发；JevBench 官方 v1.4.2.2 是四等分（智力/校准/速度/成本各 25%）、含密封 Decisions（v1.5.5 每系统 1,624 决策）、公开与密封准确率差超过 25% 判定过拟合并大幅扣减智力分；Jev 官方 ECE 0.048、JevK5 S1Bench 86.80% 对 ECE 0.061、VRAM 7.95 GB、72.3 ms；Kev-4B 多肢选择 60 项仅 21.7% 属能力崩塌；Jev 官方在"鹤之报恩"识别上 95% 大误认。
• 来源7：apolinario/decision-index（GitHub）。https://github.com/apolinario/decision-index ；Decision Index 评测套件与公榜（多模态研究者维护）。
• 来源8：新华网《筑牢安全屏障 守护金融民生——中信银行打造"AI天盾"数智化护航体系》（2026-04-21）。https://www.news.cn/money/20260421/c76648a0ac674c3790594a0a690f08ce/c.html ；"1+1+N"架构；"大模型作为全局智能层……小模型作为专业执行层，专注于反欺诈、反洗钱、账户安全等细分场景，能够实现毫秒级精准计算、快速决策与高并发响应，从而支撑亿级交易实时风控需求"；三道防线（业务管理、风险合规、审计纪检）；"哨兵"智能反欺诈应用累计拦截涉案资金超 35 亿元、查控可疑涉案账户近 50 万户、客户投诉率下降 62%（均为该报道引述的银行自述）；获《亚洲银行家》"中国最佳反欺诈和风险管理项目"。
• 来源9：搜狐金科创新社《中原银行：递归样本删除决策树算法在中原银行智能风控中的实践》（作者中原银行零售信贷与信用卡部信亚楠、蒋梦梦，2025-10-16）。https://www.sohu.com/a/944520853_100278905 ；"逻辑回归……通过特征分箱和 WOE 编码，可以生成一个直观的、有业务解释性的评分卡。这是金融领域，尤其是银行长期以来的黄金标准和基线模型"；2016 年 XGBoost 后集成算法成主流与性能冠军；传统决策树四缺陷（稳定性差、容纳指标少、易过拟合、对数据变化敏感）；递归样本删除决策树算法的四项创新（含业务可解释性与策略亲和力、以风险差异为目标的"无监督"到"有监督"跨越）；应用于原 e 贷 PLUS 授信策略重构（2022-06-10 推出，近两年平均增长率 78%，全行首款规模破百亿元的自营个人信用类贷款产品）；单位分层细化为 16 个一级分类 82 个二级分类、梳理存量 4 万多个准入单位、平均额度几乎不变下预测违约率降低 20%（该文自述成效）。
• 来源10：证券时报网《罚单翻倍、追责升级！银行业数据安全进入深水区》（记者霍莉，2026-06-16）。https://stcn.com/article/detail/3964803.html ；2026 年 1 至 5 月数据安全类罚单 55 张超上年全年、数据报送与治理违规罚单为去年同期 2.5 倍。该文为媒体梳理口径，非官方公告。
• 来源11：《关于银行业保险业人工智能安全开发应用的指导意见》（金融监管总局，山东省委金融办转载，2026-06-22）。http://dfjrjgj.shandong.gov.cn/articles/ch06816/202606/6d0d89ca-12e0-41f4-8226-9326c9bc0146.shtml ；32 项意见；"将人工智能风险纳入全面风险管理体系，实施风险分类分级管理和高风险应用准入管理"、"在高风险应用关键环节要建立人工监督和干预机制"、高质量数据集与知识工程建设。
• 来源12：阿里云开发者社区《Jev 能否用于银行风控？从规则引擎到语义决策层》（2026-09）。https://developer.aliyun.com/article/1766338 ；Jev 的能力边界与"语义决策层"定位分析；催收场景概率示例为该文示例值非实测，"基于实测口径的方案性测算，非某机构真实数据"。

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

• 《大模型能训练出 Jev 吗？银行数据分类分级的四个事件、七个实测与一条分层路径》——本文是其续篇。该文论证了"RLCD 训练一个大模型来替代 Jev"不成立，本文则回答了一个不同的问题：当 Jev 的开源等价物真的出现并且技术上全部可落地时，它能不能替代银行已有的小模型体系。 两篇文章的结论互补：该文把 Jev 定位为语义特征层与决策门控，本文把 StartLux-Decision 定位为中信式大小模型双轮驱动之间缺失的中间层，而不是任何现有层的替代。
• 《Manifold Theory in Quantitative Investing》——本文关于"温度拟合在开发集全对时退化到 0.2 下限"的讨论与该文关于银行须以自有数据校准模型的方法论互为印证：校准不是模型属性，是你自己的标注数据量出来的量。
• 《Financial Harness: 银行 AI 治理的技术骨架与实施路径》——本文第六节的四道硬门槛与该文的"先定硬规则、再放模型"思路同源；本文的门槛一（锁定代码版本而非只锁权重）是该文配置治理要求在决策模型场景下的具体化。
• 《当AI开始监控AI，银行风险管理该做什么》——本文第三节把 StartLux-Decision 放在"路由判断"位置、并把高风险环节交回人工闸，与该文关于分级刹车与人工干预的架构思路一致。

本文推论部分（非来源表述）：一、二节的四维差异框架与"第三种小模型"定位；三节的"缺口"判断（中信架构中缺失的中间层）与"哪个任务落在强项域/弱项域"的映射；五节的三个可行用法与四个不可行用法；六节的四道硬门槛及其对银行的落地含义；七节全部结论；八节末尾与系列文章关系一节中的评价性表述。文中所有模型效果数字、许可条款、代码常量、延迟与显存数字均为来源1—9 的原始记录，凡厂商自述均已标注。

本文不构成监管要求、合规意见或法律意见。权重许可证在 LoRA 微调场景下的适用边界须由具体机构的法务就授权协议条款出具意见。

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