1. 从概念到生产这道坎Jev 到底卡在哪聊 Jev 之前先把一个现实摆出来绝大多数号称下一代 AI 决策系统的东西死在从 demo 到生产环境的路上。不是模型不行是决策链路一旦接入真实业务输入噪声、延迟约束、可解释性要求、回滚机制这些东西会同时压上来实验室里那套输入问题→输出答案的玩法立刻失效。Jev 这个概念之所以值得单独拿出来讲是因为它瞄准的不是再做一个更强的推理模型而是把 AI 决策当成一套工程系统来设计。换句话说它关心的核心问题是一个 AI 系统如何在真实业务里持续做出可追溯、可干预、可回滚的决策而不是偶尔给出一个惊艳的答案。我接触过不少团队他们的典型路径是这样的先用一个大模型 API 跑通一个决策场景效果不错老板很满意然后开始往生产推。推到一半发现三个致命问题——第一同样的输入两次调用结果不一样业务方不敢用第二出了错没人知道是哪一步错的因为整个链路是个黑盒第三成本随调用量线性上涨量一上来预算就崩。这三个问题本质上都不是模型能力问题而是决策系统架构问题。Jev 的价值就在于它试图从架构层面回答这些问题。它把一次 AI 决策拆成若干个可观测、可替换、可验证的阶段每个阶段都有明确的输入输出契约。这样做的好处是你可以单独优化某一个阶段而不必推倒重来你也可以在某个阶段插入人工审核而不影响整体流程。这篇文章适合三类人看一是正在把 AI 能力往业务系统里塞的工程师二是负责 AI 产品落地、被效果不稳定折磨过的产品经理三是想搞清楚AI 决策系统和调个大模型 API到底差在哪的技术负责人。我会尽量把架构讲透把落地步骤讲细也会把我在实际项目里踩过的坑摊开来说。需要先说明一点Jev 目前公开的完整技术细节有限很多具体实现属于各家自研范畴。所以下文里涉及具体参数、模块划分的部分我会基于一个合格的 AI 决策系统在这个环节通常会怎么做来补全并明确标注哪些是通用工程实践、哪些是 Jev 这类系统特有的设计取向。你拿去对照自己的项目能直接用的直接用需要调整的按自己业务改。2. Jev 决策系统的分层架构为什么不能只有一个大模型2.1 单模型决策的三个死穴先讲清楚为什么一个大模型包打天下在生产环境行不通这样你才能理解 Jev 为什么要分层。第一个死穴是不确定性不可控。大模型的输出本质上是概率采样同样的 prompt 跑两次结果可能差很远。在聊天场景里这叫多样性在决策场景里这叫不可靠。你没法跟业务方解释这次审批通过了上次同样的单子被拒了因为模型这次心情不一样。第二个死穴是错误不可定位。一个端到端的模型输入进去、决策出来中间发生了什么你不知道。是意图理解错了是检索到的知识不对还是推理链条断了没有中间观测点排查就是玄学。第三个死穴是能力不可组合。业务需求是会长出来的。今天只要做分类明天要加个规则校验后天要接人工复核。单模型架构下每加一个需求都要重新调 prompt、重新测牵一发动全身。Jev 这类系统的分层思路本质上是把一次决策拆成一条有明确阶段的流水线每个阶段职责单一、接口清晰。下面这张表是我梳理的典型分层你可以对照自己的系统看看缺了哪层。层级职责典型实现出问题时的表现接入层请求归一化、鉴权、限流网关 参数校验脏数据流入下游理解层意图识别、实体抽取、上下文组装小模型 规则答非所问检索层知识召回、证据收集向量检索 关键词事实性错误推理层决策生成、方案比选大模型 约束求解逻辑跳跃校验层规则校验、一致性检查规则引擎 二次模型违规输出执行层动作落地、状态回写业务 API 事务执行与决策不一致观测层全链路追踪、指标采集日志 Trace出事查不到原因这张表不是让你照抄而是让你意识到决策系统的复杂度不在模型在链路。Jev 的架构取向就是把这七层里的每一层都做成可替换的组件而不是焊死在一起。2.2 理解层为什么要独立出来很多人会把理解用户意图和生成决策放在同一个模型调用里做图省事。我早期也这么干过后来发现这是给自己挖坑。原因很简单理解是收敛的决策是发散的。理解用户到底想要什么这是一个相对确定的任务用一个小模型甚至规则引擎就能做到很高的准确率而且结果稳定、可缓存。而决策生成是发散的需要大模型的推理能力。把这两件事混在一起等于让一个擅长发散的模型去做一个本该收敛的任务既浪费算力又引入不确定性。独立出理解层之后你能拿到几个实实在在的好处。第一意图识别结果可以缓存同样的输入不用重复理解。第二意图识别错了可以单独修不用动推理层。第三你可以在理解层做置信度判断——如果意图识别置信度低于阈值直接走澄清流程而不是硬着头皮往下推。实操上理解层的输出通常是一个结构化对象类似这样{ intent: refund_request, confidence: 0.92, entities: { order_id: 20240512001, reason: 质量问题 }, context_refs: [user_history_8823, policy_v3] }这个结构往下传推理层拿到的是一个干净的、带置信度的输入而不是一段模糊的自然语言。这一步做扎实后面整条链路的稳定性会提升一个档次。2.3 检索层与推理层的边界怎么划这是我在实际项目里被问得最多的问题知识到底该在检索层喂给模型还是让模型自己去推理我的经验是事实性知识走检索逻辑性推理走模型。什么意思这个订单的退款政策是什么——这是事实应该从知识库检索出来作为证据传给推理层。这个订单符不符合退款条件——这是推理应该由模型基于证据来判断。划清这条边界的好处是当决策出错时你能快速定位如果检索到的政策就是错的那是知识库问题如果政策对但判断错了那是推理问题。混在一起你永远不知道错在哪。Jev 这类系统在检索层通常会做多路召回向量召回负责语义相似关键词召回负责精确匹配规则召回负责硬性条件。三路结果合并去重后按相关性排序取 Top-K 传给推理层。K 值不是拍脑袋定的要根据推理层的上下文窗口和业务对延迟的要求来算。我一般会从 K5 开始调观察召回率和延迟的平衡点。注意检索层返回的每一条证据都要带来源标识和置信度。推理层引用证据时要能追溯到具体是哪一条。这是后面做可解释性的基础一开始不做后面补起来非常痛苦。3. 让决策可追溯Jev 的观测与干预机制3.1 全链路 Trace 不是可选项生产环境的 AI 决策系统没有全链路追踪就等于闭着眼睛开车。Jev 在这一点上的设计取向很明确每一次决策都要留下完整的执行轨迹。什么叫完整从请求进来的那一刻起到最终动作执行完中间每一个阶段的输入、输出、耗时、置信度都要记录。这不是为了好看是为了出事时能查。我见过太多团队日志只记了最终输入和最终输出中间过程全丢。结果线上出现一个错误决策排查的时候只能靠猜。有了全链路 Trace你能直接看到哦是检索层召回了一条过期的政策导致推理层基于错误证据做了判断。定位时间从几小时缩短到几分钟。Trace 的数据结构设计有个关键点每个阶段要有一个唯一的 span_id并且记录 parent_span_id。这样你才能把一次决策的所有阶段串成一棵树。下面是一个简化的示例{ trace_id: dec_20240512_8823, spans: [ {span_id: s1, parent: null, stage: ingest, duration_ms: 12}, {span_id: s2, parent: s1, stage: understand, duration_ms: 85, output: {intent: refund_request, confidence: 0.92}}, {span_id: s3, parent: s1, stage: retrieve, duration_ms: 120, output: {docs: [policy_v3#sec2, order_20240512001]}}, {span_id: s4, parent: s1, stage: reason, duration_ms: 640, output: {decision: approve, evidence_refs: [policy_v3#sec2]}}, {span_id: s5, parent: s1, stage: validate, duration_ms: 30, output: {passed: true}}, {span_id: s6, parent: s1, stage: execute, duration_ms: 210, output: {status: success}} ] }有了这棵树任何一个环节出问题都能精确定位。而且这些数据积累起来还能做决策质量分析——比如统计哪个阶段的置信度普遍偏低哪个环节耗时最长为优化提供依据。3.2 人工干预点该插在哪AI 决策系统不是要完全取代人而是要把人放在最需要的地方。Jev 的架构里干预点是可以配置的不是写死的。常见的干预点有三个位置。第一个在理解层之后如果意图识别置信度低于阈值转人工确认意图。这个位置拦截的是没听懂的情况。第二个在推理层之后、执行层之前决策生成了但还没执行如果决策涉及高风险动作比如大额退款、账号封禁转人工审核。这个位置拦截的是听懂了但决策有风险的情况。第三个在执行层之后动作已经执行但支持人工回滚。这个位置是兜底。干预点的阈值怎么定我的经验是按业务风险分级。低风险决策全自动中风险决策抽样人工复核高风险决策必须人工确认。阈值不是一次定死的要根据线上数据持续调整。比如你发现某个意图的自动决策准确率只有 85%那就把它的阈值调高让更多请求走人工。这里有个容易忽略的点人工干预的结果要回流。人工改过的决策要作为训练数据存下来用来优化理解层和推理层。不然人工干预就只是成本不是投资。3.3 决策回滚的工程实现回滚这件事说起来简单做起来难。难在哪难在决策和执行往往是分离的执行完了才发现决策错了这时候要撤销已经产生的副作用。Jev 这类系统通常采用补偿事务的思路每个执行动作都配一个对应的补偿动作。退款成功了补偿动作就是撤销退款账号封禁了补偿动作就是解封。执行层记录每个动作的执行状态回滚时按逆序执行补偿动作。关键设计点有两个。第一动作要幂等。同一个补偿动作执行多次结果要一致。这需要在动作设计时就考虑进去比如用唯一事务 ID 去重。第二回滚要有时间窗口。不是所有动作都能无限期回滚超过窗口就只能走人工流程。窗口多长取决于业务金融类可能只有几分钟内容类可能几小时。class DecisionAction: def __init__(self, action_id, do_fn, undo_fn, idempotent_key): self.action_id action_id self.do_fn do_fn self.undo_fn undo_fn self.idempotent_key idempotent_key self.executed False def execute(self): if self.executed: return self.do_fn(self.idempotent_key) self.executed True def rollback(self): if not self.executed: return self.undo_fn(self.idempotent_key) self.executed False这段代码是简化版真实场景还要考虑分布式事务、失败重试、状态持久化。但核心思路就是这个每个动作自带撤销能力回滚就是逆序调用撤销。4. 落地 Jev 式决策系统的实操路径4.1 从哪个场景切入最稳不要一上来就做核心业务决策。我见过团队直接把 AI 决策接到风控主链路上结果一次误判造成大面积误伤项目直接叫停。稳妥的切入路径是从辅助决策开始逐步过渡到自动决策。具体分三步走。第一步影子模式。AI 决策系统跑起来但决策结果不执行只记录。同时人工按原有流程决策。跑一段时间后对比 AI 决策和人工决策的一致率。一致率高说明 AI 靠谱一致率低先别急着上分析差异在哪。第二步建议模式。AI 决策结果展示给人工人工参考后做最终决定。这个阶段收集的是AI 建议被采纳率。采纳率高说明 AI 的建议有价值。第三步自动模式。在低风险场景下让 AI 自动决策高风险场景仍然人工。这个阶段要重点监控的是误判率和回滚率。这三步走下来通常需要几周到几个月取决于场景复杂度。急不得急了必翻车。4.2 数据准备里最容易被低估的活模型能力再强喂进去的数据不行决策质量就是不行。数据准备这块我踩过的坑比模型调优多得多。第一个坑是历史决策数据没有结构化。很多团队的历史决策记录就是一堆工单文本没有标签、没有分类。这种数据拿来训练效果很差。解决办法是先用理解层的能力把历史数据过一遍抽取出结构化的意图和实体人工抽检修正形成训练集。第二个坑是知识库更新不及时。政策变了知识库没更新AI 还在按老政策决策。这个问题的根因通常不是技术是流程——知识库更新没有和业务变更联动。解决办法是建立知识库版本管理每次业务政策变更都触发知识库更新并且记录版本号。推理层引用知识时带上版本号出问题能追溯到是哪个版本的知识导致的。第三个坑是负样本不足。大家习惯收集正确决策的样本但错误决策的样本同样重要甚至更重要。因为模型要学会的是什么情况下不该做某个决策。负样本从哪来从人工干预记录里来从回滚记录里来从用户投诉里来。这些数据要主动收集、主动标注。4.3 上线前的验收清单上线前我会过一遍这张清单缺一项都不发。检查项合格标准验证方式意图识别准确率核心意图 95%离线测试集检索召回率Top-5 召回 90%标注集验证决策一致率与人工一致 90%影子模式对比端到端延迟P99 业务容忍上限压测回滚成功率 99%故障演练Trace 完整率100% 决策有完整链路日志抽查干预点生效阈值触发准确模拟测试成本可控单次决策成本 预算成本核算这张表里的数字是参考值具体要按你的业务定。但每一项都必须有明确的验证方式不能靠感觉没问题。提示压测的时候一定要测异常路径不只是正常路径。比如检索层超时了怎么办推理层返回了非法格式怎么办执行层部分成功部分失败怎么办这些异常路径的处理逻辑才是生产系统稳定的关键。5. 那些文档里不会写的踩坑经验5.1 置信度阈值不是拍脑袋定的置信度阈值这个东西新手容易犯的错是直接定个 0.8 或者 0.9。实际上阈值应该按意图分别定。原因很简单不同意图的识别难度不一样。有些意图特征明显准确率天然就高阈值可以定高一点有些意图容易混淆准确率上不去阈值定太高会导致大量请求走人工成本爆炸。我的做法是先跑一批数据统计每个意图在不同置信度区间的准确率然后按业务能接受的准确率反推阈值。比如退款审批这个意图业务要求准确率 98% 以上那就在准确率达到 98% 的那个置信度点设阈值。低于这个点的请求走人工。这个阈值还要定期重算。因为数据分布会变模型也会更新上个月合适的阈值这个月可能就不合适了。5.2 推理层的输出格式约束让大模型输出结构化结果是生产环境的刚需。但模型不是每次都听话偶尔会输出格式不对的东西。如果不做约束下游解析就会崩。我的经验是三重约束。第一重prompt 里明确给出输出格式的 schema并且给示例。第二重用模型的 JSON mode 或者 function calling 能力从解码层面约束格式。第三重解析层做校验格式不对就重试重试几次还不对就走降级流程。降级流程是什么就是当模型实在给不出合法输出时系统不能崩要有一个兜底决策。兜底决策通常是转人工或者按默认规则处理。这个兜底逻辑一定要有而且要测试到位。5.3 成本控制的几个实操手段AI 决策系统的成本主要花在推理层的大模型调用上。控制成本有几个手段按性价比排序。最有效的是缓存。很多决策请求是重复的或者高度相似的。把理解层的输出缓存起来相似的请求直接命中缓存跳过推理层。缓存命中率做到 30% 以上成本直接降三成。其次是模型分级。不是所有决策都需要最强的模型。简单决策用小模型复杂决策才用大模型。怎么判断简单还是复杂看理解层的置信度和检索层的证据数量。置信度高、证据充分的大概率是简单决策。再其次是批处理。非实时决策可以攒一批一起处理摊薄单次调用成本。实时决策没法批处理但可以做一些请求合并比如同一个用户的多个请求合并成一次调用。最后才是prompt 优化。精简 prompt、减少 few-shot 示例能省一点 token但省得有限。不要本末倒置为了省 token 把 prompt 砍得信息不足导致决策质量下降得不偿失。5.4 模型更新时的回归测试模型不是部署完就一劳永逸的。模型会更新知识库会更新业务规则会变。每次变更都要做回归测试。回归测试的核心是固定测试集。从历史决策里挑一批有代表性的样本人工标注正确答案形成测试集。每次变更后跑一遍测试集看准确率有没有下降。下降了就回滚没下降才发布。测试集要覆盖各种边界情况正常请求、模糊请求、对抗性请求、异常输入。我一般会维护一个 500 到 1000 条的测试集每次变更跑一遍几分钟出结果。这个投入非常值得能拦住大部分更新完效果变差的事故。6. 关于 Jev 这类系统我的一些真实判断聊了这么多架构和实操最后说几句掏心窝的话。Jev 这个概念本身代表的是一个方向AI 决策正在从模型能力竞赛转向系统工程竞赛。谁的模型更强这个问题的边际收益在递减谁能把决策系统做得更稳、更可观测、更可控这个问题的价值在上升。但我也要泼一盆冷水不要为了架构而架构。我见过团队把决策链路拆成七八层每层都做得很精致结果端到端延迟高得没法用。分层是为了解决问题不是为了好看。如果你的场景很简单一个模型加一层规则校验就够了没必要上全套。还有一个判断人工干预不是失败是特性。很多团队觉得 AI 决策系统还要人工介入说明不够智能。这个想法是错的。在真实业务里高风险决策有人工兜底恰恰是系统成熟的标志。追求 100% 自动化在大多数业务场景下既不现实也不划算。如果你正在做类似的事情我的建议是先把观测做扎实再把干预点配好最后才去优化模型。顺序反了后面会非常痛苦。观测和干预是地基模型是装修。地基没打好装修再漂亮也住不了人。这套东西我前后在几个项目里迭代过每次都有新的坑冒出来。上面写的这些是我目前能想到的最实在的部分。你拿去用的时候记得结合自己的业务场景调整别照搬。
Jev决策系统架构解析：从AI模型到生产级决策工程的落地实践
1. 从概念到生产这道坎Jev 到底卡在哪聊 Jev 之前先把一个现实摆出来绝大多数号称下一代 AI 决策系统的东西死在从 demo 到生产环境的路上。不是模型不行是决策链路一旦接入真实业务输入噪声、延迟约束、可解释性要求、回滚机制这些东西会同时压上来实验室里那套输入问题→输出答案的玩法立刻失效。Jev 这个概念之所以值得单独拿出来讲是因为它瞄准的不是再做一个更强的推理模型而是把 AI 决策当成一套工程系统来设计。换句话说它关心的核心问题是一个 AI 系统如何在真实业务里持续做出可追溯、可干预、可回滚的决策而不是偶尔给出一个惊艳的答案。我接触过不少团队他们的典型路径是这样的先用一个大模型 API 跑通一个决策场景效果不错老板很满意然后开始往生产推。推到一半发现三个致命问题——第一同样的输入两次调用结果不一样业务方不敢用第二出了错没人知道是哪一步错的因为整个链路是个黑盒第三成本随调用量线性上涨量一上来预算就崩。这三个问题本质上都不是模型能力问题而是决策系统架构问题。Jev 的价值就在于它试图从架构层面回答这些问题。它把一次 AI 决策拆成若干个可观测、可替换、可验证的阶段每个阶段都有明确的输入输出契约。这样做的好处是你可以单独优化某一个阶段而不必推倒重来你也可以在某个阶段插入人工审核而不影响整体流程。这篇文章适合三类人看一是正在把 AI 能力往业务系统里塞的工程师二是负责 AI 产品落地、被效果不稳定折磨过的产品经理三是想搞清楚AI 决策系统和调个大模型 API到底差在哪的技术负责人。我会尽量把架构讲透把落地步骤讲细也会把我在实际项目里踩过的坑摊开来说。需要先说明一点Jev 目前公开的完整技术细节有限很多具体实现属于各家自研范畴。所以下文里涉及具体参数、模块划分的部分我会基于一个合格的 AI 决策系统在这个环节通常会怎么做来补全并明确标注哪些是通用工程实践、哪些是 Jev 这类系统特有的设计取向。你拿去对照自己的项目能直接用的直接用需要调整的按自己业务改。2. Jev 决策系统的分层架构为什么不能只有一个大模型2.1 单模型决策的三个死穴先讲清楚为什么一个大模型包打天下在生产环境行不通这样你才能理解 Jev 为什么要分层。第一个死穴是不确定性不可控。大模型的输出本质上是概率采样同样的 prompt 跑两次结果可能差很远。在聊天场景里这叫多样性在决策场景里这叫不可靠。你没法跟业务方解释这次审批通过了上次同样的单子被拒了因为模型这次心情不一样。第二个死穴是错误不可定位。一个端到端的模型输入进去、决策出来中间发生了什么你不知道。是意图理解错了是检索到的知识不对还是推理链条断了没有中间观测点排查就是玄学。第三个死穴是能力不可组合。业务需求是会长出来的。今天只要做分类明天要加个规则校验后天要接人工复核。单模型架构下每加一个需求都要重新调 prompt、重新测牵一发动全身。Jev 这类系统的分层思路本质上是把一次决策拆成一条有明确阶段的流水线每个阶段职责单一、接口清晰。下面这张表是我梳理的典型分层你可以对照自己的系统看看缺了哪层。层级职责典型实现出问题时的表现接入层请求归一化、鉴权、限流网关 参数校验脏数据流入下游理解层意图识别、实体抽取、上下文组装小模型 规则答非所问检索层知识召回、证据收集向量检索 关键词事实性错误推理层决策生成、方案比选大模型 约束求解逻辑跳跃校验层规则校验、一致性检查规则引擎 二次模型违规输出执行层动作落地、状态回写业务 API 事务执行与决策不一致观测层全链路追踪、指标采集日志 Trace出事查不到原因这张表不是让你照抄而是让你意识到决策系统的复杂度不在模型在链路。Jev 的架构取向就是把这七层里的每一层都做成可替换的组件而不是焊死在一起。2.2 理解层为什么要独立出来很多人会把理解用户意图和生成决策放在同一个模型调用里做图省事。我早期也这么干过后来发现这是给自己挖坑。原因很简单理解是收敛的决策是发散的。理解用户到底想要什么这是一个相对确定的任务用一个小模型甚至规则引擎就能做到很高的准确率而且结果稳定、可缓存。而决策生成是发散的需要大模型的推理能力。把这两件事混在一起等于让一个擅长发散的模型去做一个本该收敛的任务既浪费算力又引入不确定性。独立出理解层之后你能拿到几个实实在在的好处。第一意图识别结果可以缓存同样的输入不用重复理解。第二意图识别错了可以单独修不用动推理层。第三你可以在理解层做置信度判断——如果意图识别置信度低于阈值直接走澄清流程而不是硬着头皮往下推。实操上理解层的输出通常是一个结构化对象类似这样{ intent: refund_request, confidence: 0.92, entities: { order_id: 20240512001, reason: 质量问题 }, context_refs: [user_history_8823, policy_v3] }这个结构往下传推理层拿到的是一个干净的、带置信度的输入而不是一段模糊的自然语言。这一步做扎实后面整条链路的稳定性会提升一个档次。2.3 检索层与推理层的边界怎么划这是我在实际项目里被问得最多的问题知识到底该在检索层喂给模型还是让模型自己去推理我的经验是事实性知识走检索逻辑性推理走模型。什么意思这个订单的退款政策是什么——这是事实应该从知识库检索出来作为证据传给推理层。这个订单符不符合退款条件——这是推理应该由模型基于证据来判断。划清这条边界的好处是当决策出错时你能快速定位如果检索到的政策就是错的那是知识库问题如果政策对但判断错了那是推理问题。混在一起你永远不知道错在哪。Jev 这类系统在检索层通常会做多路召回向量召回负责语义相似关键词召回负责精确匹配规则召回负责硬性条件。三路结果合并去重后按相关性排序取 Top-K 传给推理层。K 值不是拍脑袋定的要根据推理层的上下文窗口和业务对延迟的要求来算。我一般会从 K5 开始调观察召回率和延迟的平衡点。注意检索层返回的每一条证据都要带来源标识和置信度。推理层引用证据时要能追溯到具体是哪一条。这是后面做可解释性的基础一开始不做后面补起来非常痛苦。3. 让决策可追溯Jev 的观测与干预机制3.1 全链路 Trace 不是可选项生产环境的 AI 决策系统没有全链路追踪就等于闭着眼睛开车。Jev 在这一点上的设计取向很明确每一次决策都要留下完整的执行轨迹。什么叫完整从请求进来的那一刻起到最终动作执行完中间每一个阶段的输入、输出、耗时、置信度都要记录。这不是为了好看是为了出事时能查。我见过太多团队日志只记了最终输入和最终输出中间过程全丢。结果线上出现一个错误决策排查的时候只能靠猜。有了全链路 Trace你能直接看到哦是检索层召回了一条过期的政策导致推理层基于错误证据做了判断。定位时间从几小时缩短到几分钟。Trace 的数据结构设计有个关键点每个阶段要有一个唯一的 span_id并且记录 parent_span_id。这样你才能把一次决策的所有阶段串成一棵树。下面是一个简化的示例{ trace_id: dec_20240512_8823, spans: [ {span_id: s1, parent: null, stage: ingest, duration_ms: 12}, {span_id: s2, parent: s1, stage: understand, duration_ms: 85, output: {intent: refund_request, confidence: 0.92}}, {span_id: s3, parent: s1, stage: retrieve, duration_ms: 120, output: {docs: [policy_v3#sec2, order_20240512001]}}, {span_id: s4, parent: s1, stage: reason, duration_ms: 640, output: {decision: approve, evidence_refs: [policy_v3#sec2]}}, {span_id: s5, parent: s1, stage: validate, duration_ms: 30, output: {passed: true}}, {span_id: s6, parent: s1, stage: execute, duration_ms: 210, output: {status: success}} ] }有了这棵树任何一个环节出问题都能精确定位。而且这些数据积累起来还能做决策质量分析——比如统计哪个阶段的置信度普遍偏低哪个环节耗时最长为优化提供依据。3.2 人工干预点该插在哪AI 决策系统不是要完全取代人而是要把人放在最需要的地方。Jev 的架构里干预点是可以配置的不是写死的。常见的干预点有三个位置。第一个在理解层之后如果意图识别置信度低于阈值转人工确认意图。这个位置拦截的是没听懂的情况。第二个在推理层之后、执行层之前决策生成了但还没执行如果决策涉及高风险动作比如大额退款、账号封禁转人工审核。这个位置拦截的是听懂了但决策有风险的情况。第三个在执行层之后动作已经执行但支持人工回滚。这个位置是兜底。干预点的阈值怎么定我的经验是按业务风险分级。低风险决策全自动中风险决策抽样人工复核高风险决策必须人工确认。阈值不是一次定死的要根据线上数据持续调整。比如你发现某个意图的自动决策准确率只有 85%那就把它的阈值调高让更多请求走人工。这里有个容易忽略的点人工干预的结果要回流。人工改过的决策要作为训练数据存下来用来优化理解层和推理层。不然人工干预就只是成本不是投资。3.3 决策回滚的工程实现回滚这件事说起来简单做起来难。难在哪难在决策和执行往往是分离的执行完了才发现决策错了这时候要撤销已经产生的副作用。Jev 这类系统通常采用补偿事务的思路每个执行动作都配一个对应的补偿动作。退款成功了补偿动作就是撤销退款账号封禁了补偿动作就是解封。执行层记录每个动作的执行状态回滚时按逆序执行补偿动作。关键设计点有两个。第一动作要幂等。同一个补偿动作执行多次结果要一致。这需要在动作设计时就考虑进去比如用唯一事务 ID 去重。第二回滚要有时间窗口。不是所有动作都能无限期回滚超过窗口就只能走人工流程。窗口多长取决于业务金融类可能只有几分钟内容类可能几小时。class DecisionAction: def __init__(self, action_id, do_fn, undo_fn, idempotent_key): self.action_id action_id self.do_fn do_fn self.undo_fn undo_fn self.idempotent_key idempotent_key self.executed False def execute(self): if self.executed: return self.do_fn(self.idempotent_key) self.executed True def rollback(self): if not self.executed: return self.undo_fn(self.idempotent_key) self.executed False这段代码是简化版真实场景还要考虑分布式事务、失败重试、状态持久化。但核心思路就是这个每个动作自带撤销能力回滚就是逆序调用撤销。4. 落地 Jev 式决策系统的实操路径4.1 从哪个场景切入最稳不要一上来就做核心业务决策。我见过团队直接把 AI 决策接到风控主链路上结果一次误判造成大面积误伤项目直接叫停。稳妥的切入路径是从辅助决策开始逐步过渡到自动决策。具体分三步走。第一步影子模式。AI 决策系统跑起来但决策结果不执行只记录。同时人工按原有流程决策。跑一段时间后对比 AI 决策和人工决策的一致率。一致率高说明 AI 靠谱一致率低先别急着上分析差异在哪。第二步建议模式。AI 决策结果展示给人工人工参考后做最终决定。这个阶段收集的是AI 建议被采纳率。采纳率高说明 AI 的建议有价值。第三步自动模式。在低风险场景下让 AI 自动决策高风险场景仍然人工。这个阶段要重点监控的是误判率和回滚率。这三步走下来通常需要几周到几个月取决于场景复杂度。急不得急了必翻车。4.2 数据准备里最容易被低估的活模型能力再强喂进去的数据不行决策质量就是不行。数据准备这块我踩过的坑比模型调优多得多。第一个坑是历史决策数据没有结构化。很多团队的历史决策记录就是一堆工单文本没有标签、没有分类。这种数据拿来训练效果很差。解决办法是先用理解层的能力把历史数据过一遍抽取出结构化的意图和实体人工抽检修正形成训练集。第二个坑是知识库更新不及时。政策变了知识库没更新AI 还在按老政策决策。这个问题的根因通常不是技术是流程——知识库更新没有和业务变更联动。解决办法是建立知识库版本管理每次业务政策变更都触发知识库更新并且记录版本号。推理层引用知识时带上版本号出问题能追溯到是哪个版本的知识导致的。第三个坑是负样本不足。大家习惯收集正确决策的样本但错误决策的样本同样重要甚至更重要。因为模型要学会的是什么情况下不该做某个决策。负样本从哪来从人工干预记录里来从回滚记录里来从用户投诉里来。这些数据要主动收集、主动标注。4.3 上线前的验收清单上线前我会过一遍这张清单缺一项都不发。检查项合格标准验证方式意图识别准确率核心意图 95%离线测试集检索召回率Top-5 召回 90%标注集验证决策一致率与人工一致 90%影子模式对比端到端延迟P99 业务容忍上限压测回滚成功率 99%故障演练Trace 完整率100% 决策有完整链路日志抽查干预点生效阈值触发准确模拟测试成本可控单次决策成本 预算成本核算这张表里的数字是参考值具体要按你的业务定。但每一项都必须有明确的验证方式不能靠感觉没问题。提示压测的时候一定要测异常路径不只是正常路径。比如检索层超时了怎么办推理层返回了非法格式怎么办执行层部分成功部分失败怎么办这些异常路径的处理逻辑才是生产系统稳定的关键。5. 那些文档里不会写的踩坑经验5.1 置信度阈值不是拍脑袋定的置信度阈值这个东西新手容易犯的错是直接定个 0.8 或者 0.9。实际上阈值应该按意图分别定。原因很简单不同意图的识别难度不一样。有些意图特征明显准确率天然就高阈值可以定高一点有些意图容易混淆准确率上不去阈值定太高会导致大量请求走人工成本爆炸。我的做法是先跑一批数据统计每个意图在不同置信度区间的准确率然后按业务能接受的准确率反推阈值。比如退款审批这个意图业务要求准确率 98% 以上那就在准确率达到 98% 的那个置信度点设阈值。低于这个点的请求走人工。这个阈值还要定期重算。因为数据分布会变模型也会更新上个月合适的阈值这个月可能就不合适了。5.2 推理层的输出格式约束让大模型输出结构化结果是生产环境的刚需。但模型不是每次都听话偶尔会输出格式不对的东西。如果不做约束下游解析就会崩。我的经验是三重约束。第一重prompt 里明确给出输出格式的 schema并且给示例。第二重用模型的 JSON mode 或者 function calling 能力从解码层面约束格式。第三重解析层做校验格式不对就重试重试几次还不对就走降级流程。降级流程是什么就是当模型实在给不出合法输出时系统不能崩要有一个兜底决策。兜底决策通常是转人工或者按默认规则处理。这个兜底逻辑一定要有而且要测试到位。5.3 成本控制的几个实操手段AI 决策系统的成本主要花在推理层的大模型调用上。控制成本有几个手段按性价比排序。最有效的是缓存。很多决策请求是重复的或者高度相似的。把理解层的输出缓存起来相似的请求直接命中缓存跳过推理层。缓存命中率做到 30% 以上成本直接降三成。其次是模型分级。不是所有决策都需要最强的模型。简单决策用小模型复杂决策才用大模型。怎么判断简单还是复杂看理解层的置信度和检索层的证据数量。置信度高、证据充分的大概率是简单决策。再其次是批处理。非实时决策可以攒一批一起处理摊薄单次调用成本。实时决策没法批处理但可以做一些请求合并比如同一个用户的多个请求合并成一次调用。最后才是prompt 优化。精简 prompt、减少 few-shot 示例能省一点 token但省得有限。不要本末倒置为了省 token 把 prompt 砍得信息不足导致决策质量下降得不偿失。5.4 模型更新时的回归测试模型不是部署完就一劳永逸的。模型会更新知识库会更新业务规则会变。每次变更都要做回归测试。回归测试的核心是固定测试集。从历史决策里挑一批有代表性的样本人工标注正确答案形成测试集。每次变更后跑一遍测试集看准确率有没有下降。下降了就回滚没下降才发布。测试集要覆盖各种边界情况正常请求、模糊请求、对抗性请求、异常输入。我一般会维护一个 500 到 1000 条的测试集每次变更跑一遍几分钟出结果。这个投入非常值得能拦住大部分更新完效果变差的事故。6. 关于 Jev 这类系统我的一些真实判断聊了这么多架构和实操最后说几句掏心窝的话。Jev 这个概念本身代表的是一个方向AI 决策正在从模型能力竞赛转向系统工程竞赛。谁的模型更强这个问题的边际收益在递减谁能把决策系统做得更稳、更可观测、更可控这个问题的价值在上升。但我也要泼一盆冷水不要为了架构而架构。我见过团队把决策链路拆成七八层每层都做得很精致结果端到端延迟高得没法用。分层是为了解决问题不是为了好看。如果你的场景很简单一个模型加一层规则校验就够了没必要上全套。还有一个判断人工干预不是失败是特性。很多团队觉得 AI 决策系统还要人工介入说明不够智能。这个想法是错的。在真实业务里高风险决策有人工兜底恰恰是系统成熟的标志。追求 100% 自动化在大多数业务场景下既不现实也不划算。如果你正在做类似的事情我的建议是先把观测做扎实再把干预点配好最后才去优化模型。顺序反了后面会非常痛苦。观测和干预是地基模型是装修。地基没打好装修再漂亮也住不了人。这套东西我前后在几个项目里迭代过每次都有新的坑冒出来。上面写的这些是我目前能想到的最实在的部分。你拿去用的时候记得结合自己的业务场景调整别照搬。
