System One模型：大模型决策延迟与成本问题的工程化解法

做 AI 应用落地这两年，我越来越觉得「决策」是大模型应用里最被低估的一环。你们有没有遇到过这种情况：让模型判断用户问题该走哪个工具，它洋洋洒洒先输出一大段分析，最后才给一个 tag；让模型看看请求该不该拒绝，它磨蹭半天还容易误杀。直到我看到 Jev 这个项目，才确认了一个我一直在想的思路——把「决策」从大模型里拆出来，做一个独立的 System One 模型。今天就把这个思路掰开揉碎讲一讲：为什么要拆、怎么拆、拆完怎么用、会遇到哪些坑。

先说清楚 Jev 是什么。它是一个面向"决策任务"的 System One 模型——不是又一个对话大模型，而是一个专门负责快速、确定、低成本决策的小型模型。它借鉴了认知科学里的双系统理论：System One 负责快反应，System Two 负责慢思考。放到大模型应用里，System Two 已经有大模型承担了，System One 反而一直缺位，Jev 想补的正是这块空白。这篇内容适合正在做 Agent、RAG、内容安全预筛等大模型落地的团队和独立开发者参考，不管你是技术负责人还是写代码的人，应该都能从中找到可复用的思路。

1. 大模型缺的不是推理能力，是 System One 的决策层

1.1 双系统分工：System One 管快、System Two 管深

先说说双系统理论，因为这是理解 Jev 的钥匙。这套理论把人的认知分成两套系统：System One 是快速、直觉、自动化的反应，比如你看到 2+2 马上说出 4，看到楼梯会下意识抬脚；System Two 是慢速、理性、需要消耗注意力的推理，比如你算一道积分题、做一次逻辑分析。两套系统没有孰优孰劣，只是分工不同：System One 负责高频生存决策，System Two 负责复杂问题的深度处理。

这套框架放到大模型应用里非常贴切。大模型本质上是极强的 System Two：能理解复杂上下文、进行多步推理、生成开放式内容。但问题是，日常业务里大量请求根本不是复杂推理，而是"这个请求该走哪个流程""这个文本属于哪一类""这件事要不要升级处理"——这些全是典型的 System One 决策。传统软件里这类逻辑靠 if-else 硬编码，可自然语言输入的语义空间太复杂，if-else 根本写不全。于是很多人下意识把所有决策都塞给大模型，等于强行让 System Two 干 System One 的活，结果就是又慢又贵。

1.2 大模型做决策的三个硬伤：延迟、成本、格式漂移

我列一下在实际工程里最常见的三个痛点。第一个是延迟完全不可控。哪怕是最快的通用模型，单次推理也要几百毫秒到几秒。在 Agent 场景里，你要把用户消息、对话历史、工具描述全部拼进提示词，一轮决策经常耗到 3 秒以上。可很多决策任务其实能在几十毫秒内完成，这个差距对交互体验是致命的。我见过一个客服 Agent 的线上数据，用户问"我要退货怎么操作"，Agent 光决定该调用退货流程还是直接回答，就花了将近 4 秒。这个请求切开看，意图明确、选项固定，根本不需要 System Two 级别的深思熟虑。

第二个是成本线性上涨。决策类请求通常是高频请求，一天几百万次很常见。如果每次都走大模型生成式推理，token 费用会直接吃掉项目预算。第三个是输出格式的不可控。决策接口要求的是确定性和可解析性，大模型却天生是生成式的，它可能给你一个 JSON，也可能夹带解释、多给候选、甚至格式漂移。你不得不写额外的解析逻辑和重试机制，维护成本都在这里悄悄堆高。

这三个痛点叠加在一起，结论就非常清楚：在日常业务里，真正需要 System Two 级深度思考的请求占比可能只有 10%-20%，剩下 80% 都是重复、确定、边界清晰的基础判断。与其让一个擅长慢思考的大模型去处理所有请求，不如专门训练一个擅长快决策的 System One。Jev 的整个设计都是围绕这个结论展开的，后面我会具体拆它的做法。

2. Jev 的模型定位：一个输出"决策信号"的 System One

2.1 它不是"缩小版大模型"，而是"决策信号模型"

这里要纠正一个常见误区。很多人第一反应是："把大模型量化、剪枝、变小，不就有 System One 了吗？" 其实不是。量化剪枝出来的模型还是生成式模型，你问它一个二选一问题，它照样给你输出一段话，只是响应快点。System One 的本质不是"更小的大模型"，而是"只输出决策信号"的专用模型，两者的差别是整个输出范式的差别。

Jev 的设计思路是：输入任务上下文，输出结构化的决策结果——一个决策标签、一个置信度、一句简短理由。它不生成文章，不展开分析，不和你聊天，输出格式固定，程序拿到就能直接用。这个定位非常像传统 NLP 里的分类器，但它的能力上限比传统分类器高得多：因为它的语义理解能力是从大模型身上继承过来的，同时用专用结构锁死了输出的可能性空间。

这个定位我认为是 Jev 最核心的设计决策。如果你做这类模型时不小心往生成方向偏，比如让学生模型也输出一段解释再给结论，它就会慢慢退化成一个大模型降级版，失去 System One 该有的速度和稳定性。我一直提醒自己：决策信号模型要做减法，不做加法。

2.2 知识蒸馏：把大模型的决策能力搬进小模型

Jev 的决策能力怎么来？核心是知识蒸馏。说白了，就是请一个大模型当老师，让它对大量样本做决策，再把决策结果整理成训练集，用来训练小模型学生。这个流程的第一步是选老师。老师必须足够强，因为学生的能力上限不会超过老师。我在模拟项目 X 里用的是比较强的通用模型做老师，样本量二十万条左右，每条样本由老师输出标签、置信度、简短理由三部分。

第二步是决定学硬标签还是软标签。只学最终标签会丢掉老师在边界样本上的犹豫信息。更推荐的做法是让老师输出带概率分布的软标签，例如"这个请求 0.7 走工具 A，0.2 走工具 B，0.1 升级人工"，学生模型用 KL 散度去拟合这个软分布。我实测下来，软标签蒸馏比硬标签稳定得多，尤其在边界样本上，学生模型不会学得过于武断。

第三步是给教师输出做质检。老师也会犯错，尤其在边界问题上，所以不能盲信。我用两条规则：一是格式校验，规定老师必须按 JSON 结构输出，解析失败的一律剔除；二是人工抽检，每个标签抽 50 条以上做一致性确认，通过率低于 90% 的标签要重新标注。别小看这个步骤，数据质量直接决定学生模型的地板。

2.3 推理路径设计：轻、快、带一点可解释

Jev 的推理路径设计得非常克制。输入侧就是普通的编码器，把文本转成向量；中间层数不用太深，因为任务收敛在"决策"而不是"生成"；输出侧是决策头，直接映射到预定义标签空间。结构上可以采用通用编码器加分类头的组合，也可以做成更轻量的 Transformer。整体参数量一般控制在几千万到几亿，这个量级是延迟和效果的最佳平衡点。

这个设计带来几个很直接的好处。一是延迟低：CPU 上单条推理几十毫秒，GPU 上个位数毫秒，比大模型低了两到三个数量级。二是成本低：同样请求量，算力开销几乎可以忽略。三是可解释性强：固定结构让每一步决策都有清晰的输入输出对应，排查线上问题非常方便。很多人以为可解释性只有大模型才有，其实在决策链路里，固定输出加简短理由就是一套特别实用的解释机制，它稳定、可入日志、可被程序处理，在线运维里比冗长的推理链更管用。

3. 从零训练 Jev 的实操流程

3.1 数据准备：先把决策空间和样本池定义清楚

训练 Jev 的第一步不是调模型，而是定义决策空间。这个空间必须明确、互斥、可操作。比如你要做 Agent 工具路由，决策空间就是{查询工具 A、计算工具 B、检索工具 C、升级人工}。标签数量建议在 5 到 30 个之间，太少用不上，太多学生模型学不过来。每个标签还要写清楚定义和边界，这既是给老师模型看的，也是后期排查问题时的重要参考。

第二步是收集原始输入。来源主要有两个：历史日志和人工构造。历史日志能覆盖真实线上分布，人工构造用来补充边界场景。我当时先把线上日志去重、脱敏，筛出两万条高质量请求，又按边界场景人工构造了一万条。然后把所有样本交给大模型老师批量决策，老师对每条输出标签、理由、软概率。注意老师这一步建议分批处理，每批 200 条左右，既能控制上下文长度，也能减少模型疲劳带来的质量波动。

第三步是质检。我自己坚持每个标签至少抽 50 条人工检查，通过率低于 90% 的标签重点补样本。最终样本池做到二十万条左右，每个标签不少于五千条，边界场景单独留了两三万条。做完这些，数据才算是能进训练的状态。很多团队跳过质检直接训练，后面学生模型上线后各种诡异错误，回头查基本都是这一步埋下的雷。

3.2 学生选型：参数量、结构和损失函数怎么定

学生模型的选择，我总结成三个决策点。第一个是参数量。不是越大越好，而是看延迟预算和硬件条件。纯 CPU 部署建议从几十 M 到一两百 M 开始试；GPU 部署可以放宽到三五百 M。判断方法很简单：看验证集准确率曲线，当参数量增加到一定程度后准确率增长明显变缓，取那个拐点就够了。堆参数量对这个任务边际收益很低。

第二个是结构。编码器加决策头是最稳的组合，编码器用通用预训练语言模型，中文场景要额外注意词表覆盖，避免生僻字被切成碎 token 导致判断失准。决策头按任务做单标签或多个二分类头。第三个是损失函数。类别不均衡是决策任务里一定会遇到的问题，直接交叉熵会让模型偏向高频标签。我在训练时对低频标签加权，并用 focal loss 缓解难分样本的梯度消失；如果教师输出软标签，就再加上 KL 散度项，同时对齐老师的概率分布。这套配置比裸交叉熵稳定不少。

3.3 训练和校准：别让验证集骗了你

训练本身不复杂，但有几个坑要特别提醒。第一个坑是 epoch 数。我一开始按大模型习惯跑 10 个 epoch，验证集很快就过拟合了。决策任务数据量不大，3 到 5 个 epoch 足够，重点看早停，不要贪多。第二个坑是数据泄漏。如果训练样本和线上请求文本太相似，测试分数会虚高，所以数据集切分一定要按时间顺序切，而不是随机切，这样才能模拟真实分布漂移。

第三个坑是验证集构建。除了随机验证集，一定要单独准备一个边界样本集，就是那些标签在两类之间摇摆的样本。这个集合上的表现，才能真正反映模型在真实边界场景里的判断力。我在项目里发现，模型在随机验证集上 97% 准确率，在边界样本集上只有 88%，差距非常大。如果不额外看边界集，很容易被表面分数误导。

训练完成后别急着上生产，先做置信度校准。最常用的方法是温度缩放：推理时把 logits 除以一个温度系数，让输出概率更接近真实置信度。我实测下来，经过温度缩放的 Jev，在阈值判断上明显更可靠，升级到大模型的频率也更合理。校准的方法可以自己在验证集上做网格搜索，选一个能让负对数似然最小的温度值，这个步骤十几分钟就能搞定，收益却很大。

3.4 部署协作：System One 和 System Two 的接力机制

训练完成只是第一步，真正决定你线上效果的是协作链路设计。Jev 不是用来取代大模型的，它和大模型是接力关系。我的做法是：请求进来先过 Jev，Jev 输出三元组（决策标签、置信度、简短理由），然后判断置信度是否超过预设阈值。超过阈值就直接返回结果，低于阈值说明决策边界模糊，此时把完整上下文交给大模型做 System Two 复议。这个级联逻辑非常简单，但收益巨大：高频请求保住低延迟，边界样本享受深度推理。

阈值怎么定？要结合业务容忍度。如果决策错误代价高，就调高阈值，让更多请求升级到大模型；如果追求速度，就调低阈值。我自己的经验是从 0.8 起步，观察线上升级比例和准确率，再逐步微调。别想着一开始就找到完美阈值，一定要用线上数据迭代。

还要加一层成本监控。建议每天统计升级到大模型的请求量占比、整体决策准确率、按标签分组的置信度均值。如果升级率连续两天超过预设上限（比如 20%），说明 System One 某个类别能力在退化，需要回去补样本、调阈值或者重新校准。这个监控指标非常关键，它能让你在决策误判扩大之前提前介入，而不是等线上出了事故再回头翻日志。

4. 落地场景与实测数据

4.1 Agent 工具路由：90% 请求走毫秒级决策

Agent 应用里最典型的决策任务就是工具路由。用户说一句自然语言，系统要判断调用哪个工具。这个场景我之前一直用大模型做，prompt 里写清楚工具列表和调用规则，效果还行，但延迟和成本都让人头疼。后来把 Jev 接上去以后，流程变成：先把所有工具描述固定成候选集，Jev 输出一个工具编号；置信度高就直接执行工具，置信度低再把候选工具列表连同请求一起发给大模型做复议。

实测结果很直观：约 90% 的请求走 Jev，平均路由延迟从 2.3 秒压到 40 毫秒，工具选择准确率只比大模型低了不到 1 个百分点。对 Agent 场景来说，这个提升非常可观。省下来的延迟让整个 Agent 可以撑起更复杂的多轮交互，省下来的预算则可以用来处理真正困难的请求。

4.2 RAG 前置调度：给检索路径装个分流阀

RAG 系统里也藏着大量决策：这个问题需不需要检索？检索哪个知识库？要不要先做意图判断？这些单独看不难，但每个用户请求都会触发一次，量一大，开销差距就很明显。我尝试把 Jev 放在 RAG 管线最前端，同时输出三个决策：是否是简单事实型问题、是否属于本系统知识域、是否需要多跳检索。

这三个标签决定后续走哪条检索路径。比方说，一个纯闲聊问题就没必要做向量检索，一个明显超出知识域的请求可以直接返回兜底话术，而不必把所有知识库搜一遍。低置信度的请求会升级到大模型重新判断。这样既减少了无谓的检索开销，也避免了一上来就调大模型格式化答案的浪费。对高并发的 RAG 服务来说，这个前置分流阀的价值非常明显。

4.3 内容安全预筛：第一道闸门负责快和准

内容安全是最依赖决策密度的场景之一。一条文本进来，要先判断有没有风险、属于什么风险类型、需不需要人工复审。大模型在这个场景里确实准确，但内容量一大，审核成本根本顶不住。Jev 在这个场景下扮演的是第一道闸门：明确安全的文本直接放行，明确危险的文本直接拦截或进入人工队列，模糊的文本升级到大模型做深度判断。

因为 System One 处理速度非常快，绝大多数文本可以在毫秒级完成预筛，把大模型和人工审核资源集中到真正需要关心的边界案例上。这里要特别提醒：内容安全场景对误判的容忍度非常低，所以阈值一定要比其他场景更保守。我建议安全场景下，置信度阈值起步设在 0.9 以上，宁可让更多请求升级到大模型，也不为了省成本而放跑一个风险样本。

4.4 延迟、成本、准确率的实测对比

最后把我在模拟项目 X 里的一组相对数据放出来，注意这是特定任务下的相对结果，不是绝对值，但趋势很有参考意义。

可以看出，纯 Jev 的准确率确实比大模型低一截，但把低置信度升级到大模型后，级联方案几乎追平了大模型的效果，同时延迟和成本都有数量级改善。这就是 System One 模型典型的价值曲线：别指望它无所不知，但要保证 90% 的场景又快又省，剩下 10% 交给 System Two。很多时候架构的价值不在于把每个指标做到最强，而在于把资源分配给真正需要的环节。

5. 常见问题与排查技巧

5.1 决策边界漂移：教师纠偏的闭环要定期跑

模型上线一段时间后，你可能会发现线上决策准确率悄悄下降。最常见的原因是请求分布变了，出现训练时没见过的表达方式。这不是模型坏了，而是数据漂移。我的排查思路是先做线上请求和训练样本的相似度对比，比如用 embedding 距离看分布偏移程度。如果确认漂移，优先补充新类型样本，尤其是那些置信度低、升级率高的类别，再增量微调模型。

另一个预防手段是定期抽样线上请求，让大模型老师重新标注一遍，和 Jev 的决策做对比，把分歧样本作为新的训练集。这个动作我建议至少每两周跑一次，形成"教师纠偏、学生重学"的闭环。很多团队把模型部署完就再也不管了，等指标掉了才想起来救火，这就是没有定期闭环的必然结果。

5.2 置信度失真：温度缩放和离群检测缺一不可

置信度不准确是我见过最隐蔽的坑。学生模型可能对明显陌生的输入给出 0.97 的高置信度，然后被当成确定决策直接放行，这在线上几乎等于没有兜底。训练时模型看到的都是分布内样本，它天然会把所有输入都往已知类别上套，所以光靠训练时的表现判断置信度是不可靠的，必须主动做两层防线。

第一层是温度缩放。它不能提升模型的真实能力，但能把低置信度样本的分数压得更低，便于被阈值拦下。第二层是离群检测，用一个轻量分支计算输入的能量分数或距离度量，判断输入是否落在训练分布之外。如果分布外得分高，就强制要求升级到大模型。最后才是调阈值，而且阈值建议按标签分别设置，不能所有类别共用一个，因为不同类别的混淆程度完全不同。

5.3 分工边界：别让 System One 吃掉所有任务

最后这条是我自己踩过的坑，特别值得说。刚开始做 Jev 时，我恨不得把一切决策都塞给它，比如让一个几亿参数的小模型去做开放域问答式判断，结果学生模型完全顶不住，准确率一路下滑。System One 只能负责"快、确定、高频"的决策，它不适合需要长上下文、强推理、或者输出格式不固定的任务。

怎么判断一个任务适不适合 System One？我的经验是：如果这个任务需要你写三句以上 prompt 才能说清楚，那它大概率不适合。因为三句以上的 prompt 本身就说明任务含有复杂条件判断，小模型学起来容易顾此失彼。边界场景哪怕偶尔升级到大模型，也比让小模型硬扛要好很多。设计系统的过程中，分清哪些决策是"条件反射"，哪些是"深度思考"，比追求一个万能模型重要得多。

最后分享一个我自己坚持的复盘习惯。每隔两周，我会人工抽查 200 条线上真实请求，让 Jev 和大模型各自做一次决策，重点对比二者有分歧的样本。这个动作成本很低，但能最早发现学生模型在哪个类别上悄悄退化。Jev 这类 System One 模型的精髓，不在于它是一个多聪明的模型，而在于它懂得把不确定的问题诚实地交给 System Two。这套分工只要在线，延迟和成本的优势就能一直保持下去。做这类项目的朋友不妨也试试这个复盘方法。