成本变便宜之后：企业 AI 的分工该重排了

这段时间, AI 圈有一个发布值得所有做企业数字化的人认真看一眼。9月15日, 一家名为 TypeSafe AI 的公司发布了他们的第一个模型 Jev。这个模型不做对话, 不写文章, 不生成代码, 只做一件事: 回答范围明确的判断题。业内把这类模型叫作 System One Model, 名字借自心理学家卡尼曼对快思考与慢思考的区分, 通用大模型承担慢思考, 它专门负责快判断。

看完它的介绍和这几天的公开讨论, 我的第一反应不是又来了一个新模型, 而是这几年在企业现场反复遇到的一个老问题, 终于有人在模型层给出了回应: 企业里大量的智能环节, 其实不需要模型会聊天, 只需要它把一个判断做对, 做快, 做便宜。

一, 企业里的大多数智能环节, 输出只是一个判断

先说自己的观察。制造业数字化项目里, 真正高频的智能需求, 很少是让模型写一篇东西。更多是这样的问题: 这个物料描述对应编码库里的哪一条, 这张报工单的数据异常要不要放行, 这道工序该派给哪条产线, 这处 BOM 差异是设计变更还是录错了。每一个问题背后都连着一段业务流程, 而流程要往下走, 等的只是一个选择, 一个分数或者一个是与非。

拿一个每个企业都有的场景来说: 采购询价。用户甩过来一张配置单, 系统要做的是把里面的说法对应到产品库里的具体型号, 判断配置是否完整, 再触发查询和审批。产品是现成的, 规格有明确选项, 价格有正式来源, 审批有自己的系统。真正需要智能的只有三处: 这句描述对应哪个产品, 这项配置怎么映射, 信息还缺什么。三处全都是判断, 没有一处需要模型写一篇文章。

这类环节有个共同特点: 模型理解的是人的语言, 输出却要接进程序。选哪个, 是或否, 匹配程度几分, 答案一旦清楚, 后面的校验, 计算和执行都由现成系统完成。过去让通用大模型来答, 它会先组织一段推理, 再生成一段文本, 程序再把文本解析回结构化的值。理解这一步是到位的, 输出却绕了一道弯。

更大的成本在等待。一个 Agent 任务往往要连续做多次判断: 先判断调用什么工具, 拿到结果再判断下一步, 中间还可能补充信息或修正参数。每个环节多等一会儿, 串起来就是分钟级的体验。我在项目里的体会是, 用户对智能系统的耐心, 不会因为它背后是人工智能就自动变多。响应速度本身就是产品能力的一部分: 一个两分钟后才给出的正确判断, 在体验上未必胜过三十秒内给出, 指出偏差后马上就能修正的快速判断。

这一条值得写进每个智能环节的设计目标里: 先问用户能等多久, 再问模型能想多深。顺序反过来, 上线后多半会被体验拖垮。

还有一层容易被忽略: 对话和判断的出错代价不一样。聊天回复里有一点冗余或跑偏, 用户自己会过滤; 而一个接进流程的判断, 选错了产品, 判错了异常, 后面的系统会一丝不苟地执行下去。判断环节对稳定性的要求, 天然高于对话, 这也是为什么它不适合用生成文本的方式去实现。

二, Jev 做的事: 把判断从文本生成里拆出来

回到 Jev 本身。它接收一段上下文和一组预先定义好的问题, 直接返回选择, 评分或概率。三种形式分别对应: 从候选项里挑一个, 按给定等级打分, 以及判断某个陈述成立的概率。所有输出并行生成, 不走逐字生成文本那条路。官方口径是, 在这类快判断任务上, 它的判断水平与通用大模型相当, 速度和成本则低一到两个数量级。

发布几天内出现的公开实测, 方向上也支持这个定位。有开发者拿它和关闭推理模式的通用模型做分类对比, 结论是判断质量接近, 略有差距, 但快得多, 也便宜得多; 也有团队把它用作 Agent 的自动评测器, 看中的正是单次判断足够快, 足够便宜, 才舍得在大规模重复检查里用。对一个需要高频调用的环节来说, 速度和成本是按调用次数累积的, 往往比准确率上细微的差距更决定成败。

限定也要说清楚。官方文档写明当前版本以英语表现最好, 精确计算应当留给代码; 速度与成本的优势数据主要来自官方自测, 实际收益落在哪个区间, 要放进自己的任务集里验证。中文场景的效果, 更需要先做小规模评测再下结论, 这也是我建议任何企业接入前必做的一步。

三, 比模型更值得抄的, 是它背后的分工

我真正在意的其实不是 Jev 这一个模型, 而是它把一件事摆到了台面上: 企业 AI 系统应该分层分工。通用模型负责理解复杂目标, 规划任务和处理例外; 范围明确的选择, 匹配和判断, 交给专门的决策能力承接; 计算, 校验和执行, 由代码与业务系统完成。三层各干各的, 每一层都可以单独评测, 单独替换。

这个分工在企业现场并不陌生, 缺的一直是中间那层。能写清楚的规则, 我们早就写进代码; 需要理解人的表达的地方, 过去只能整体交给通用大模型, 于是就有了前面说的绕路与等待。现在中间多了一个选项: 把人的表达映射到业务动作的那一步, 可以交给又快又便宜的专门判断来完成。

置信度这件事值得单独说。判断类模型的每个输出都自带一个可信程度, 系统就有机会把不确定纳入流程: 置信度高就自动执行, 中间的进人工复核, 低的直接转人工, 阈值按判断出错的代价来定。这比让通用模型生成一段看起来很确定的话, 再由人去猜它到底准不准, 要诚实得多, 也好管理得多。

再往前一步, 工具的用法也可以封装进这一层。过去我们把能力封装成接口, 把使用方法写成说明, 上层模型仍然要读说明, 选命令, 组织参数, 工具越多, 这部分开销越大。更合理的做法是: 专业产品把候选范围, 参数约束和业务规则准备好, 判断层只负责具体选择与匹配, 上层 Agent 交代目标和上下文就够了。每接入一种能力, 上层就少背一部分底层细节。

一句话概括这个分工: 通用模型管理解与规划, 判断层管选择与匹配, 代码管计算与执行。谁的职责越清楚, 整段任务里没人该背的等待就越少。

落地顺序上, 我的建议是从一个判断密集又容错可控的环节切入。先挑那种选错了也不会造成实际损失, 顶多重跑一次的场景, 把判断接进去, 用真实任务攒测试集, 验证判断质量和置信度是否可靠, 再逐步往出错代价更高的环节推进。上来就把核心审批交给模型, 无论用哪种模型, 都不是稳妥的做法。

四, 落到自己身上, 四条清单

不管这类模型最终成熟到什么程度, 分层分工这个方向已经清楚。对企业来说, 我建议先做四件事。

第一, 盘点业务流程里哪些环节只需要判断。把流程拆开看, 标出那些答案只是一个选择, 一个分数或一个是否的环节。它们是最先值得智能化的地方, 也是最容易算清投入产出的地方, 比追着风口上一个大模型实在得多。

第二, 能写清楚的规则坚决不进模型。格式校验, 数量核对, 权限判断, 这些交给代码, 又快又稳定还没有调用成本。模型只接真正需要理解语言的那一段。这条原则不新, 但每次选型都值得重申一遍, 因为把规则塞给模型永远看起来更省事, 事后却最难维护。

第三, 把响应速度当成正式指标考核。给智能环节定一个用户能感知的时限, 超时就换方案, 哪怕方案是牺牲一点判断质量。快速判断加上及时修正, 在大多数业务场景里, 胜过一次想很久的完美判断。

第四, 让判断可评测, 可回溯。每个智能环节的输入, 输出和置信度都留记录, 出了问题能定位到是哪一层的责任; 判断质量单独建测试集, 换模型或调阈值时都有依据。这一条做到位, 上面的分工才真正立得住。

四条清单合起来看, 其实是同一个态度: 不要把企业 AI 的落地押在某个模型的能力上, 而是先把流程拆清楚, 让每一类工作找到合适的承担者。模型市场每个月都有新名字, 分工合理的企业, 换任何一块拼图都只需要动那一层; 分工不合理的企业, 每次模型升级都等于重做一遍。

这几年我们不断完善工具, 收紧规则, 补充评测, 是为了让 AI 真正进入业务流程。现在, 模型也开始朝着软件能直接使用的方向演进。专业软件提供能力, 入口组织工作, 模型按任务分工。智能一旦像其他软件能力一样被反复调用和组合, 企业 AI 的落地故事, 才算真正翻页。