做 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 是快速、直觉、自动化的反应比如你看到 22 马上说出 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 One2.1 它不是缩小版大模型而是决策信号模型这里要纠正一个常见误区。很多人第一反应是把大模型量化、剪枝、变小不就有 System One 了吗 其实不是。量化剪枝出来的模型还是生成式模型你问它一个二选一问题它照样给你输出一段话只是响应快点。System One 的本质不是更小的大模型而是只输出决策信号的专用模型两者的差别是整个输出范式的差别。Jev 的设计思路是输入任务上下文输出结构化的决策结果——一个决策标签、一个置信度、一句简短理由。它不生成文章不展开分析不和你聊天输出格式固定程序拿到就能直接用。这个定位非常像传统 NLP 里的分类器但它的能力上限比传统分类器高得多因为它的语义理解能力是从大模型身上继承过来的同时用专用结构锁死了输出的可能性空间。这个定位我认为是 Jev 最核心的设计决策。如果你做这类模型时不小心往生成方向偏比如让学生模型也输出一段解释再给结论它就会慢慢退化成一个大模型降级版失去 System One 该有的速度和稳定性。我一直提醒自己决策信号模型要做减法不做加法。2.2 知识蒸馏把大模型的决策能力搬进小模型Jev 的决策能力怎么来核心是知识蒸馏。说白了就是请一个大模型当老师让它对大量样本做决策再把决策结果整理成训练集用来训练小模型学生。这个流程的第一步是选老师。老师必须足够强因为学生的能力上限不会超过老师。我在模拟项目 X 里用的是比较强的通用模型做老师样本量二十万条左右每条样本由老师输出标签、置信度、简短理由三部分。第二步是决定学硬标签还是软标签。只学最终标签会丢掉老师在边界样本上的犹豫信息。更推荐的做法是让老师输出带概率分布的软标签例如这个请求 0.7 走工具 A0.2 走工具 B0.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 不是用来取代大模型的它和大模型是接力关系。我的做法是请求进来先过 JevJev 输出三元组决策标签、置信度、简短理由然后判断置信度是否超过预设阈值。超过阈值就直接返回结果低于阈值说明决策边界模糊此时把完整上下文交给大模型做 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)直接调用大模型决策级联方案 (Jev 大模型)单条 P50 延迟约 8ms约 1.8s高频走 Jev升级部分约 2s每千次调用成本约 0.2 元约 15 元约 1.8 元决策准确率96.5%98.2%97.9%结构化输出稳定性高固定格式中偶发格式漂移高可解释性中标签短理由高完整分析中高可以看出纯 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。这套分工只要在线延迟和成本的优势就能一直保持下去。做这类项目的朋友不妨也试试这个复盘方法。