用专用决策模型减少生成式调用开销

Glean 测试了一种不写文本、只做判断的模型 Jev：识别请求类型、选择专家、筛查风险、挑选后续建议。作者的结论是，答案能提前列出来的环节，可以先试决策模型，不必每次都让 LLM 生成文本再解析。

这组实验值得看，因为它优化的是 AI 应用里反复发生的小调用。不过，各项任务的收益并不一致；分类标签的符合程度，也不能直接当成准确率。

答案能列出来，为什么还要生成一遍

一次 AI 回答背后，可能藏着多次判断：用户要提问、摘要还是执行任务？该交给哪个专家？内容是否安全？下一步推荐什么？

这些输出通常只是标签、布尔值或分数。交给通用 LLM，需要等待它生成文本，再把文本解析成程序能用的结果。

作者测试的 Jev 来自 TypeSafe，属于 System 1 模型。调用时提交提示词、聊天历史或 JSON 等状态，再附上带类型的问题；返回的是带概率的类型化答案，支持是否判断、选项选择和评分，无须解析文本。输入价格为每百万 tokens $0.042，输出免费。

先判断输出能否提前枚举，再决定是否需要生成模型。

作者还给出一种组合方式：决策模型选工具，LLM 生成工具参数。两者分别承担自己适合的工作。

提速来自哪里，数字又说明了什么

安全筛查采用两级流程：先快速检查提示词、工具输出和回答，再让 LLM 复核被标记的内容。Jev 在测试集里检出了 90% 的不安全内容，精确率约为 91%。前者看危险内容漏掉多少，后者看报出的风险有多少是真的。

其中，检索文档里的提示词注入检出率为 99%，回答中的恶意代码检出率为 97%。内部部署累计 2250 万次调用，中位耗时为 137 毫秒；筛查与 LLM 并行运行，作者称用户无须额外等待，月成本从约 $4,000 降至 $2,100。开头所说的「约十分之一秒、约一半成本」，应结合这些具体口径理解。

后续建议的收益更直观。系统每轮最多展示一个建议，也可以不展示。原来没有建议的轮次中，58% 是因为 LLM 排序器超时或返回了不可用答案。

团队把候选建议和「none」一起交给 Jev 选择，中位耗时从 4.67 秒降至 0.67 秒，约快 7 倍；超时率从 10.2% 降至 0.8%，无效答案从 10 个降至 0 个，有建议的轮次占比从 83% 升至 91%。原文没有交代无效答案计数的样本总量。

路由测试使用了 751 条带标签的请求。作者称所有路由的精确率都提高了，其中一个专家从 47% 升至 87%；需要专家处理时，路由调用的中位速度提升了 8.1 倍。这不是整段对话都提速 8.1 倍。

让模型弃答，比强行选一个更实用

查询分类没有出现全面胜出。未经训练的 Jev 与生产标签的一致率为 66.8%，微调过的开放模型为 74.5%。作者概括的「零次训练达到微调模型约 90% 的一致水平」，说的是两者数值之比，不能读成 Jev 的一致率达到 90%。

作者据此认为，标签稳定时，微调更占优势；标签频繁变化时，免训练方案更灵活。但后半句更接近经验判断，原文没有提供标签变化频率与维护成本的对照实验。

概率输出还允许系统拒绝弱判断：最高选项概率为 0.49，阈值设为 0.50，就不展示建议。聊天路径同时设置 2 秒预算、不重试；超时或答案不可用时，沿用现有行为。

这套设计把「不确定」和「失败」都变成了可处理的分支。不过，概率阈值不等于可靠性保证，原文没有说明这些概率经过怎样的校准。

我的判断

我认同作者把生成和决策拆开评估。尤其是有限选项排序，结构化结果可以减少解析失败，也便于设置超时和兜底。

但这些成绩来自 Glean 自己的数据与部署。原文没有完整披露基线模型、测试集构成和成本拆分，不能据此认定 Jev 在一般团队里也有同样收益。对于简单、稳定的判断，规则或普通分类器也值得比较；原文没有给出这类对照。

安全场景还要单独看漏检。首轮检出 90% 不代表安全问题已经解决，而只复核被标记内容的流程，也无法自动补回首轮漏掉的风险。

能拿来做什么

• 梳理 AI 应用中的分类、路由和建议排序调用，把输出能提前列出的环节单独拿出来评测。
• 给后续建议增加「none」选项，同时比较建议质量、超时率和展示率，避免只追求展示数量。
• 在 Node 服务里为决策调用设置时间预算和兜底分支；作者的配置是 2 秒、不重试，具体数值仍需按业务延迟要求确定。
• 用自己的带标签请求比较规则、现有 LLM 和决策模型，同时记录精确率、漏检率、延迟与成本，再决定是否替换。