JEV 场景方案

用 Jev 做语义路由

路由是花小钱省大钱的地方：花百分之一的成本先判断一下，就能决定这个请求要不要惊动那个每次一块多的大模型。前提是判断本身必须又快又便宜——否则路由器自己就成了瓶颈。

为什么这件事适合交给 Jev

文中所有数字来自我们自己跑的 2,390 题实测，方法和局限见 实测报告。

方案 1

该用小模型还是大模型

判断任务复杂度和是否需要推理，决定路由到哪一档模型。

一次调用，问完全部 3 道

把 route 的概率配一个保守阈值：只有明确判为 small 且把握高时才走小模型，拿不准就走大的。路由省的钱远小于答错一次的代价。

看代码
import { experimental_evaluate as evaluate } from 'ai';

const { answers } = await evaluate({
  model: 'typesafe-ai/jev',
  state,                     // 粘一条用户请求
  questions: {
    needsReasoning: { type: 'boolean', instructions: '完成这个请求是否需要多步推理、规划或复杂计算？' },
    complexity: { type: 'score', instructions: '这个请求的复杂程度如何？',
      criteria: ['一步就能完成', '简单但需要一点判断', '需要多步处理', '复杂且开放'] },
    route: { type: 'choice', instructions: '这个请求应当交给哪一档模型处理？',
      criteria: { small: '小而快的模型足够', large: '需要旗舰级推理模型', tools: '需要调用外部工具或检索' } },
  },
});
方案 2

要不要走 RAG

判断这个问题是否需要检索知识库，省掉大量无谓的向量查询。

一次调用，问完全部 3 道
看代码
import { experimental_evaluate as evaluate } from 'ai';

const { answers } = await evaluate({
  model: 'typesafe-ai/jev',
  state,                     // 粘一条用户提问
  questions: {
    needsRetrieval: { type: 'boolean', instructions: '回答这个问题是否需要查询组织内部的、模型不可能知道的资料？' },
    timeSensitive: { type: 'boolean', instructions: '这个问题的答案是否依赖最新数据？' },
    chitchat: { type: 'boolean', instructions: '这条消息是否只是打招呼或闲聊，并不包含实际的信息需求？' },
  },
});
方案 3

HTTP 请求按语义分发

把自然语言请求分发到具体的业务 handler。

一次调用，问完全部 3 道
看代码
import { experimental_evaluate as evaluate } from 'ai';

const { answers } = await evaluate({
  model: 'typesafe-ai/jev',
  state,                     // 粘一条用户说的话
  questions: {
    handler: { type: 'choice', instructions: '这条请求应当由哪个业务模块处理？',
      criteria: { refund: '退款与取消订单', order_query: '查询订单状态', modify: '修改订单内容', support: '需要人工客服', unknown: '意图不明确' } },
    hasOrderRef: { type: 'boolean', instructions: '这条请求中是否包含可以定位到具体订单的线索（金额、日期、订单号等）？' },
    confidence: { type: 'score', instructions: '用户的意图表述得有多清楚？',
      criteria: ['完全不清楚', '需要追问', '基本清楚', '非常明确'] },
  },
});

常见问题

路由器本身的延迟会不会成为瓶颈？

中位 456ms、最慢 1% 不到 0.8 秒。相对于被路由的大模型调用（1.3–1.7 秒，尾部 6–7.6 秒）是划算的，但如果你的下游是本地小模型，这 450ms 可能就不划算了，要自己算账。

和向量相似度路由比呢？

向量路由更快更便宜，但只能按「像不像」分；Jev 判的是「是不是」，能处理「这个请求需不需要多步推理」这种没法用相似度表达的判据。两者可以叠：先用向量粗筛，拿不准的交给 Jev。

路由判断可以和别的判断合并吗？

可以，而且应该。一次调用把路由、是否需要检索、是否闲聊一起问完，成本和问一道差不多。

哪些路由判断不该交给它？

需要数数或算数的。实测计数题 Jev 只有 65–77%，而且错法很典型——会顺着题目里给的数字答「是」。这类判据用代码算。

这么用的真实开源项目

这些项目的源码里都能找到真正调用 Jev 的那一行。更多项目见 awesome-jev-verified。

换成你自己的题

上面的问题是固定的。想写自己的判据、自己的选项、自己的打分档位，去 试验场 里随便改。

打开试验场

其他场景