大概半年前我在一个内部项目里第一次意识到团队花了大量成本接入大模型最后真正高频调用的居然都是“把这张工单放到 A 类还是 B 类”“这个请求要不要进审核通道”“这条内容是否命中拒收规则”这种简单决策。也就是从那时候起我决定把决策能力从大模型里拆出来单独做一个轻量级的 System One 内核项目代号就叫 Jev。今天想把这套思路、架构拆解和踩坑过程完整记录下来希望给同样在折腾大模型落地、又苦于延迟和成本失控的团队一点参考。1. 大模型直接做决策时慢和贵只是表象真正的麻烦在于动机错位先说一个反直觉的结论大批量决策上大模型最大的问题不是它“答错”而是它被设计成了另一种东西。你有没有发现同一个 prompt同样的上下文让大模型连着跑十次它可能在第八次突然换了个答案这不是偶然的 bug而是它的底层机制决定的。模型的目标是预测下一个 token 和“人类意图”的匹配概率它不是在做决策优化而是在做语言延续。说得再直白一点它是被训练来“说得像人”而不是被训练来“选得对”。1.1 语言概率模型和决策优化器本质上不是同一类东西我举一个实际场景。客服工单分流里规则很简单“退款相关走售后物流问题走物流组其余走咨询组”。如果让大模型来做分类你把它放进 prompt 里它的表现通常不差至少 90% 以上的准确率能跑出来。但真正到了高峰期问题就来了十次里有几次答案会抖动甚至同样一段话换个标点符号就从“物流组”蹦到“咨询组”。对语言模型来说这完全正常因为它学的是语义分布的近似不是业务规则的最优解。这里有一个很容易被忽略的点在大模型里塞决策任务等于让一个擅长写散文的人去当会计。它不一定算错但你没法保证他每一行都算对。它的优化目标里根本没有“决策损失”这一项。它不是不行而是动机错位——你把它当成决策优化器来用就得承担它在决策边界上的随机性。另一个问题是可解释性。做业务的人很快就会来问你“这条工单为什么判给 A 组”如果答案是“大模型觉得是这样”那这个线上系统根本走不到验收。它不是让你写总结报告而是要一条一条能查的决策日志。大模型给不了这类东西至少给不了生产环境需要的那种细粒度解释。1.2 延迟、成本、可审计性如何在生产环境里叠加成事故做技术的人可能会觉得我把大模型当一个带置信度的分类器用延迟 2 秒我能忍成本嘛也就那样审计的事再想办法。但真实情况是这三样东西会互相放大最后变成一场事故。先算一笔账假设你的业务每天有 100 万次决策每次调大模型平均消耗 1500 个 token。按比较便宜的模型价格粗算每天光决策逻辑就要烧掉一笔不小的费用一个月下来比一台高配推理机器贵得多。而且这还是保守估计因为真实业务里 prompt 会越写越长长上下文时代价直接翻倍。延迟的账更狠。你的前端可能等得起 2 秒但你的下游系统等不起。比如路由决策之后还要接 SQL 查询、推送调度、风控锁定这一整条链路大头模型那一哆嗦直接把本来 100ms 的接口拖成了 3 秒。峰值一上来整个系统开始排队排队之后超时超时之后重试重试又会新增更多请求——这种放大效应才是生产事故的根源。我把三类代价摆一个表方便理解维度大模型直接做决策的代价生产系统的真实反馈延迟单次 1.5 到 4 秒上游接口超时下游任务排队成本按 token 计费随着 prompt 变长线性膨胀固定预算很快被吃掉可审计性决策路径隐含在权重里难以回溯业务方无法确认判别依据真正让我决定动手做 Jev 的最后一根稻草是审计需求。某次周会上业务方拿出一条被系统拒掉的工单问“它到底哪里命中风险了”。我们翻遍了 prompt 日志和模型输出只能给出“模型综合判断风险偏高”这种话。这种话骗得了自己骗不了业务方。也就是从那次之后我不再把大模型当作默认的决策器开始把“决策”当成一个独立模块来看。1.3 “拆出来”不是否定大模型而是回归正确的分工这里必须澄清一点把决策从大模型里拆出来不等于“不用大模型了”。恰恰相反大模型在整个系统里的地位会更高只是它的角色变了。就像人脑一样Kahneman 把认知系统分成快慢两个通道System 1 负责快速的、自动化的、低耗能的判断System 2 负责慢速的、逻辑推理的、高耗能的思考。我们的业务场景里 80% 的决策其实都是 System 1 该干的活——输入状态是有限的输出空间是结构化的历史上有大量样本可以学习。剩下 20% 的疑难杂症才需要 System 2 上场也就是交给大模型深度推理。大模型的强项本就不是高频小决策。它是处理“理解完整语义、跨信息融合、生成可供选择的方案”这类模糊任务。你让它当一个兜底决策器、一个处理 API 调用是在把它从将军降成了排长。拆出来之后这个系统反而更健康快通道负责日常和大批量慢通道负责疑难和小流量两条腿走路。2. Jev 的架构决策快通道是怎么从生成链路里独立出来的Jev 不是一个“单个模型”严格说它是一个决策网络或者叫决策内核。它的设计目标只有一个用毫秒级延迟处理 80% 的常规决策并且每条决策都能给出依据。它从大模型那里接过来的不是推理能力而是“决策接口”。2.1 三明治结构上下文构造器、快捷决策内核、慢思考仲裁器整个 Jev 分层上很简洁像一个三明治顶层是决策上下文构造器。它负责把任何形式的输入——自然语言工单、用户画像、业务线标识——标准化成一张决策卡片。这张卡片是 JSON 结构包含事件类型、业务线、用户等级、历史行为计数、文本 embedding 等字段。注意这里如果还需要语义理解我们可以临时调一次大模型但这属于“特征抽取”它不参与决策。特征抽取是一次性成本抽完以后就沉淀到卡片里决策环节完全不再依赖模型推理。中间层是快捷决策内核这是 Jev 的心脏。所有决策在这里遵循一套执行顺序先过规则闸门再做轻量打分再算置信度最后决定是直接输出还是升级。整个链路没有串行网络请求所有数据都在内存里延迟目标定在 50ms 以内。底层是慢思考仲裁器也就是大模型代理和它周围的重策略工具。这个层只有在中间层明确表示“我拿不准”的时候才会被调用。它接收的不是原始请求而是带着 Jev 已经算好的候选集、置信度、规则命中记录这种输入方式也叫“决策升级包”。大模型要做的就是在这个局部的、清晰的问题域里给出判断而不是从头开始理解整件事。这样的三明治结构在工程上还有一个好处每一层都可以独立升级。规则闸门调整不影响评分模型评分模型版本更新不影响仲裁器仲裁器换了更强的模型也不会波及前面的决策链。这在生产系统里的价值非常大你不需要为了一个优化点去重新跑整套链路。2.2 快捷决策内核里到底跑什么规则闸门、轻量打分、决策走廊很多人一听到“快思考模型”第一反应就是“你是不是要上一个轻量神经网络”。不是至少不全是。Jev 的快捷决策内核由三部分协作组成分别解决不同粒度的问题。第一层是规则闸门。凡是命中硬性规则的事件直接给出不可推翻的决策。比如内容审核里如果工单文本命中明确的法律禁词或安全红线不需要任何模型参与决策就是“拒绝”。这类规则是人类多年积累的确定性知识它们的准确率接近 100%模型反而学不好。规则闸门优先于一切模型判断这是决策系统的铁律。第二层是轻量打分模型。规则闸门放行之后剩下的模糊地带交给它。我的第一版原型用的是梯度提升树特征上游已经做好了所以输入就是几十个数值型特征。这一层不追求“把每一题都答对”它的输出是候选类别概率集合。第三层是决策走廊。这是我比较坚持的一个设计。传统分类器是“输出唯一标签”而 Jev 输出的是一个候选集合加动作建议。举个例子它可能判定“这张工单大概率走售后但也有 25% 的可能性是物流问题建议进入仲裁验证”。这个“走廊”给下游的裁决模块留出了一道安全缓冲。宁可在大模型仲裁时多花一次推理也不要让快通道自己拍板拍错。2.3 置信度才是 System One 的核心能力而不是准确率这应该算是整个 Jev 项目方法论上最重要的一个认知真正决定一个快速决策系统靠不靠谱的不是它在训练集上的准确率而是它敢不敢承认自己不知道。做一个 System One 模型最关键的能力是“知道自己不知道”。怎么让机器知道自己不知道我在 Jev 里用了三种互补的置信度信号。第一个是 margin也就是最高概率和次高概率之间的差距。margin 越大说明模型对“选谁”越笃定margin 越小说明它自己都很纠结。这个信号计算简单第一个版本就可以用。第二个是预测熵也就是概率分布的均匀程度。如果三条路线的概率都在 0.3 左右那模型其实完全没把握这时候让它硬出结果就是赌。第三个是样本密度。我提取了历史决策样本的 embedding构建了一个近邻索引。在线决策时如果当前样本在特征空间里离历史样本都很远说明它不在训练分布里即使 margin 看着很高也要大概率升级交给仲裁器。这个信号用来治“未知之未知”比前两个都可靠。用这三个信号组合成一个“升级判据”Jev 原本 97% 的决策准确率可以靠人工审查补刀弥补但你能明确知道哪些决策是“可信直接落袋”哪些是“必须慢通道走一走”。从风险角度看这比单纯追一个漂亮准确率有用得多。3. 系统一的直觉怎么训练用大模型当老师不如用业务日志当老师做完了架构下一个问题自然是程序里怎么知道“售后 vs 物流”这种直觉判断最开始团队有人提了个很诱人的方案让大模型批量生成训练数据拿这些数据去训练 Jev。听起来很顺大模型教小模型。我一开始也差点这么干但很快就发现这条路有个大坑。3.1 为什么“用大模型生成训练数据”这件事要慎用大模型教小模型教育学上叫知识蒸馏。理论没问题问题出在“老师自己也不稳定”。你让大模型给一万条工单打标签它会因为 prompt 里的一个字之差在边界样本上给出抖动很大的答案。这些抖动最后会变成小模型训练集里的固有噪声。噪声标签倒也不是不能治治起来麻烦而已。更恐怖的是大模型在生成标签时往往“过于自信”它不知道哪些样本自己其实不会于是把错的东西原封不动教给小模型。等小模型真正上线了第一周的效果往往很漂亮第二周开始出现诡异误判——一查全部来自于训数据里那部分噪声样本。我后来想明白一个道理大模型应该被当作“参谋”而不是“老师”。参谋可以给方向性建议但你得让业务结果来定最终答案。与其拿一个猜测当标签不如拿真实世界里已经发生的事情当标签。3.2 我推荐的数据蒸馏路径从历史日志里挖决策三元组Jev 真正用的训练数据不是大模型的输出而是业务系统里的历史日志。这听起来朴素但效果反而扎实。具体做法是每个决策样本被表示成一个三元组输入状态、实际决策动作、结果反馈。输入状态从历史请求日志里抽取字段包括业务线、客户等级、渠道、内容 embedding 等。实际决策动作是当时业务执行下的最终处理结果比如“退款”“转人工”“拒绝”。结果反馈是事后才能拿到的信号比如客户是否申诉、是否二次投诉、财务是否确认入账。关键点在于标签不是某个人或某个模型“认为应该”的动作而是“事后验证有效”的动作。比如某条工单当时被分到了售后但客户事后抱怨“我不是要退款我就是要投诉物流”那这条样本的结果反馈就是负面的它就进不了正向训练集。这种蒸馏方式有个额外好处标签质量天然比大模型生成的高而且随着业务运行日志每天在更新Jev 的训练集随时可以滚动刷新。我用了几十万条这类历史决策样本做初训模型很快收敛边界判断也没有出现大模型教小模型时的那种偏置。3.3 和规则引擎“混血”而不是谁替代谁模型和规则在 Jev 里不是二选一而是一个前后叠加的关系。规则管确定性的、可解释性要求极高的事件模型管模糊的、需要综合多个特征判断的事件。它们之间的配合可以拿客服工单分流来举例一条工单进来先查规则表如果包含“银行卡”“冻结”等关键词不管模型给什么概率直接进财务安全通道。如果规则表没命中才轮到轻量打分模型输出分类概率。而如果模型输出的候选集合里最高和次高只差 0.05它又自动把问题升级到大模型仲裁。我建议读者在做同类系统时先把你能想到的硬规则都列完再上模型。否则模型上线后遇到规则边界你还要回头给它加闩来回折腾的成本更高。一条实用经验是不要试图在模型里“学会”规则规则就是规则没有为什么。4. 升级仲裁链什么时候把皮球踢给大模型现在到了最容易被做砸的部分快通道处理了 80% 的决策剩下 20% 升级给了大模型。这个升级听起来简单但它涉及三个问题什么时候升级、升级时如何切换、升级完之后怎么给快通道“喂饭”。任何一个处理不好整个 Jev 都会变成半吊子系统。4.1 低置信度、高影响度、周期抽检三种升级触发条件我把升级触发条件设计成三类合并使用。第一类是低置信度升级。这就是前文说的 margin、熵和密度三个信号综合判定的结果。举一组实测阈值当 margin 大于 0.4 且熵小于 0.5 时Jev 直接输出当 margin 在 0.2 到 0.4 之间时中低风险业务直接输出高风险业务进入二次校验当 margin 小于 0.2 时一律升级。这个阈值的设定和业务风险强相关不能拍脑袋拍出一组全局值我会在后面踩坑部分再细说。第二类是高影响度升级。一个决策即使看起来有把握如果它的“影响面”足够大也要走一次慢通道确认。我在 Jev 里给每个决策卡片加了一个“影响权重”字段由上层业务方定义。比如一个普通用户的内容标记动作影响权重是 1但一个企业认证账号的封禁判断影响权重是 100哪怕模型给了 0.45 的 margin也照样升级。这类升级不是因为模型不自信而是因为决策错了代价不可承受。第三类是周期抽检。即使前两类都没触发Jev 也会在每个周期里随机抽取固定比例的高置信度决策发到慢通道复核。这一步是在治“系统性盲区”比如你训练集里某个角落的特征分布发生变化但模型自己并不知道。周期抽检的目的是用极小的成本换取快通道质量的可观测性。4.2 无缝切换的关键把“决策上下文包”原样交给大模型升级不只是一次 API 调用关键在于上下文如何移交。好多团队做这类系统升级的时候只丢一句“请你判一下这个问题”这就把前面快通道已经算好的特征全扔了。Jev 的做法是构建一个决策升级包里面必须包含结构化决策卡片的完整 JSONJev 当前给出的候选类别和概率分布已命中的规则项和约束条件历史相似样本的统计摘要以及原始请求文本如果语义信息有用这个升级包对 Transformer 类模型非常友好。它不需要模型从头理解问题只需要在 Jev 已经做了一半的工作上继续做精判。大模型拿到候选集是 A/B/C只需要在这些选项里分析输出空间大幅收窄幻觉概率也随之下降。另外要强调的是大模型的输出不会直接变成最终决策。我把它的输出也视为一条“证据”和 Jev 已有的候选概率、业务规则一起进入最终裁决器。最终裁决器是一个简单的小组件合并所有证据卡生成最终决策和建议依据。这么做的好处是即使大模型犯了偏也不会立刻污染整个决策链。4.3 评估闭环仲裁结果必须回流到 Jev 的训练回路升级不是为了把问题甩出去而是为了积累更难样本。Jev 的每一次仲裁调用在结束后都会被记录成一条带标签样本初始候选、仲裁输出、最终业务结果、是否被用户申诉。这些样本每天回流到样本池经过清洗后进入下一轮训练。这就是一个典型主动学习闭环快通道不知道的问题慢通道解决了慢通道解决的结果又回去训练快通道。跑完整流程后 Jev 的升级率会逐月下降说明它学到了越来越多的边界知识。有读者可能会问升级结果会不会因为大模型本身错反而把噪声带进训练集这是个好问题。我的对策是两段式校验。首先只有带着正向结果反馈的样本才可以进训练集客户申述成功的会被丢掉其次回流样本会做一轮“对抗式筛选”如果当前 Jev 能给出与仲裁结果非常接近的答案说明这个升级其实是没必要的浪费这种重复样本会被剔除保留真正的边界样本。5. 生产环境里最容易踩的五个坑写完 Jev 的第一版我以为难点已经全部解决了直到上生产才意识到真正的战斗刚刚开始。这里记录五个我在生产环境里踩过、并且非常典型的坑每一条都值得你在做同类系统时提前绕开。5.1 只比对正确率没比对延迟分位数第一个坑是评估方式的问题。团队一开始报 Jev 指标用的都是“准确率提升了 0.5%”“和大模型持平”这种话。我当时也没多想直到某天大促压测看着高峰期的延迟曲线心凉了半截。原因很简单平均延迟低不代表 P95 可控。Jev 快通道本身跑 50ms但只要 5% 的请求升级到大模型大模型那次 3 秒的调用就会直接砸进延迟分布里P95 分位数立刻暴涨。解决方案是延迟指标必须分两列看。一列是快通道内延迟看 P50/P95/P99另一列是端到端延迟看升级流量对整体分布的影响。如果 P95 超标先别急着优化快通道看看升级率是不是太高了。这条建议应该写进你的监控面板第一条规则。5.2 阈值拍脑袋上线第一天误伤一片我最早把升级阈值设成统一的一组值margin 小于 0.2 就升级。上线第一天三个业务线同时报警。A 业务线满是边缘案例升级率飙到 40%大模型被打到超限B 业务线样本非常清晰几乎从不升级C 业务线升级一次要等好几天才出结果根本联系起来。这个问题的根源是不同业务的风险偏好和样本分布完全不同一套全局阈值必然顾此失彼。后来我把阈值参数改成分业务配置存成 JSON 配置表每个业务线走各自微调。同时优化了“阈值寻优”流程上线前用历史日志回放模拟不同阈值下的直接落袋率和误判率选一个在安全范围内的最佳平衡点。回放这个动作成本极低但能避免上线后花一周时间盲调。5.3 规则和模型打架没人知道先听谁的Jev 里规则闸门和模型打分是串联的规则先过模型后跑。但我在第一版代码里没有显式规则优先级表业务规则散落在各个判断函数的 if-else 里。某次修改规则时没注意到一个关键词规则的优先级被别的分支悄悄改掉了结果模型对一条本应被规则拦截的内容输出了“通过”直接放行。这条坑的教训是规则之间的关系必须用一张显式的优先级表管理而不是依赖代码顺序。每条规则要注明优先级、适用业务线、生效版本。我后来把规则下沉到了配置中心用 YAML 维护任何改动都可以走版本审查。一旦出问题能快速定位是哪条规则的哪个版本在生效。5.4 升级流量太大大模型反而成了新的瓶颈第四个坑是我没料到的Jev 的升级链路设计得很好所以大家都乐意把更难的 case 推给大模型仲裁。升级率从预期的 10% 慢慢爬到了 30%大模型的并发池直接被打满延迟翻了一倍整个链路慢成了单核 CPU。这里面有流量控制的问题也有一个架构设计的反思任何慢通道都需要一个熔断和降级机制不能让慢通道反过来拖着快通道走。我现在给 Jev 加了三重保护。首先是信号量限流大模型并发超过设定值后超出的升级请求先在本地队列排队不无限塞给上游。其次是超时熔断仲裁调用如果超过 2 秒直接降级成“业务规则兜底”宁可给出保守决策也不能让链路挂着不动。最后是升级率周报如果某一周升级率突然升高说明快通道可能遇到了新趋势要查数据而不是盲目扩模型池。5.5 回流样本一锅端干净模型被脏标签埋了最后一个坑来自回流训练。我把升级仲裁的结果全量倒进训练集想着数据越多模型越强。结果下一次迭代的 Jev 在线上表现反而下降了 2%后来一查才发现仲裁输出本身有一部分是错的而且这些错样本都集中在某些特定类型里模型被“教坏”了。治这个病没有捷径只能把回流管道的卫生抓起来。我设计了一套清洗规则只有带正向业务反馈的仲裁样本才入训练池负反馈样本单独存到“待复核”表由人工定期抽查对抗式筛选筛掉的重复样本另放一堆用来评估升级冗余度但不进训练集。这套流程跑了几周后迭代后的 Jev 不仅没有下降升级率还显著降了下来。6. 一点个人体会这个项目让我想明白了一件事在大模型时代真正拉开团队差距的往往不是模型本身多聪明而是你能不能把“推理”和“决策”分得足够清楚。大模型的推理能力再强也架不住每天几百万次的重复决策压在它头上而一个设计得当的 System One 内核哪怕用的都是最简单的技术——规则、打分、置信度判断——也能把 80% 的决策稳稳地接住。如果你也要做类似的系统我的建议是别急着选型先拿出一周时间把业务决策日志翻出来看看输入和输出的状态空间到底有多大。如果输入是有限的、输出是结构化的、历史样本足够多那你大概率应该做自己的 Jev而不是再往大模型里堆 prompt。等到真正需要慢思考的疑难杂症再请大模型出场也不迟。