Jev决策模型解析：AI理解与规则引擎如何协同处理高频工单

在客服系统的日常运营中，工单处理一直是消耗人力最大的环节之一。当客户提交一条退款申请，系统需要理解其意图、判断情绪激动程度、评估是否满足自动退款条件——这些在人类看来自然流畅的判断，交给传统技术方案时却常常陷入两难：纯大模型方案理解力足够但延迟高、结果漂移；纯规则引擎方案稳定可审计却无法处理自然语言。Jev决策模型的出现，为这一困境提供了新的解题思路——将理解与决策彻底解耦，让AI只做“选择题”，规则负责“拍板”，拿不准的情况统一转人工处理。

理解与决策为何必须分离

传统的工单处理方案通常面临两条路的抉择困境。第一条路是直接接入大语言模型，理解能力确实强大，但模型判断的准确率如同天气般波动——今天九十分、明天六十分，更关键的是审计时无法提供一条可复现的规则来解释“为何自动退了这单”。此外，聊天类大模型响应一次往往需要数秒甚至数十秒，当每天处理成千上万张工单时，延迟和成本都成为难以承受的压力。第二条路是规则引擎方案，如Easy Rules或Drools这类按“如果……就……”执行的软件，稳定、可审计、毫秒级响应，但规则引擎只认结构化字段，问题在于intent这样的字段从哪来——最后一公里仍然需要人工阅读工单并打标签。本质上，理解是“软”的，决策是“硬”的，这两件事被强行塞进了同一个组件里，导致两边都无法发挥最佳效果。

jev-rules的三层协作架构

jev-rules的核心设计哲学可以用一句话概括：把理解与决策拆开，再用一层薄胶水粘回去。整个架构包含三个各司其职的角色。首先是理解层，由Jev（TypeSafe的System One模型）承担，它是一个只做“选择题”的判断模型——不聊天、不生成文字，只回答“是/否”、“属于哪一类”、“程度到几级”，并附带一个经过校准的可信度分数。其次是决策层，由Easy Rules引擎执行，按人工编写的MVEL规则（if-then条件）进行确定性判断，输出完全可审计。最后是兜底层，当AI拿不准或调用失败时，系统自动转人工处理。这种设计的精妙之处在于引入了“校准”概念——天气预报说降雨概率70%，长期统计下来确实约七成时间下了雨，这就是校准。规则里写“可信度≥0.85才自动退款”，前提是这个0.85真正意味着“历史上大约十次对八点五次”，否则阈值只是拍脑袋的数字。

高频低延迟场景为何特别适合Jev

Jev“只做选择题”的设计带来两个非常实际的优势：速度快、成本低。先看速度，聊天类大模型是逐字生成的，即使只回答一个分类问题也要走完整段生成流程；Jev不写文字，所有问题在同一次调用里并行作答。厂商公布的数据是单次调用约70至500毫秒，而主流聊天或推理大模型的单次延迟动辄3至329秒。再看成本，Jev的输出只是几个选项和数字，厂商对输出不收费，输入价格约0.042美元/百万token，主流模型的输入价格通常是0.2至10美元/百万token，输出价格更是输入的约5倍。以每张工单连同问题共约800token计算，输入费用约0.00003美元，一百万张工单仅需约34美元。这意味着三件事成为可能：高频场景下评论审核、工单分拣、风控初审、线索打分这类每天成千上万次的判断，逐条调用的成本可以忽略，不必为了省钱去抽样或攒批处理；低延迟使得判断可以放入用户等待的同步链路，而不是只能事后离线跑；一次调用可以并行回答多个问题，而不是一个问题调用一次。当然，速度和价格不是白来的——Jev的准确率约67.8%，与一款中档大模型基本持平，低于最强的几款约73%至74%，它是拿一部分峰值准确率换来了速度与成本优势。

机票退票工单分拣落地实践

以机票退票工单自动分拣为例，整个流程分为三步。第一步是用三个封闭式问题“审问”工单，questions.yaml只描述“问什么”而不含任何阈值——refund_requested（是否提出退款诉求，是/否概率问题）、intent（主要诉求是哪一类，封闭选项单选）、frustration（情绪激动程度，有序评分量表）。问题只有这三种类型，全是封闭式的，System One不生成文本，只输出数字和选项，这让输出天然可校准、可审计。第二步是JevEnricher拿着工单原文和这三个问题调用一次System One，然后将答案扁平地写入Facts——refund_requested=0.99表示“要退款”的概率、intent=refund表示主诉求选项、intent_confidence=1.0表示置信度、frustration=0.81表示情绪分值、jev_ok=true表示本轮软判断是否成功。从这一刻起，世界上不再有“自然语言”，剩下的全是数字和字符串。第三步是规则引擎按优先级执行MVEL规则——第一条规则是安全阀，当AI缺席或置信度不足（<0.6）时转人工；第二条规则是高置信度退款诉求自动处理（refund_requested>0.8、intent==refund、intent_confidence>=0.85）；第三条是仅咨询信息的工单走常规应答；第四条是兜底，任何未被明确覆盖的情况一律转人工。这里体现的设计原则是fail-closed——API故障时系统不会假装“客户没要求退款”，不知道就是不知道，直接转人工，好处是出问题时装上自动化的门而不是往规则引擎里塞编造的数据。

任何“文本进、决策出”的流程，只要满足“判断可以被表述为几个封闭式问题、决策可以被表述为几条带阈值规则”的形状，都可以套用这套骨架。不过需要注意几点：数据出域与合规风险需要前置脱敏层处理；人工团队必须真正接得住API故障时的转单流量；阈值必须用自己历史数据校准而非照抄Demo数值；业务事实如金额上限、频次限制等要与AI无关的硬约束叠加在规则层；questions.yaml和rules.yaml分开维护是特性也是坑，改动必须一起回归测试。这套方案特别适合高频低延迟的工单分拣与退款、用户评论审核、风控初审与理赔分级、销售线索打分与路由等场景。