摘要
Jev 是 TypeSafe AI 开发的专用 AI 决策模型,通过 API 服务对外提供,面向分类、评分和流程路由等边界明确的任务。它与生成式 LLM 的差异,主要体现在训练目标、输出机制和工程接口上。本文从核心定位、输入要求、底层机制、性能成本和应用架构展开分析,解释哪些任务需要预设候选答案,以及如何在业务系统中组合使用决策模型与生成模型。
一、先明确概念:Jev 是模型,通过 API 服务提供
Jev 是 TypeSafe AI 开发的 AI 模型。API、SDK 和控制台,是调用与使用这个模型的方式。
模型和产品不是互斥关系:模型可以通过服务进行产品化,但不能因此把模型名称与整个服务平台混为一谈。
几个相关概念的层级如下:
| 名称 | 含义 |
|---|---|
| TypeSafe AI | 模型与服务的提供方 |
| Jev | AI 模型名称,包含具体版本 |
| jev-1.13.0 | 一个具体的 Jev 模型版本 |
| System One | TypeSafe 对这类决策模型使用的类别命名 |
| API、SDK、控制台 | 调用模型的接口与工具 |
官方将 Jev 定位为面向软件的结构化决策模型,接收状态与类型化问题,返回程序可直接使用的结果。
还需要注意:LLM 是一类模型的统称,Jev 是具体模型名称,两者不处于完全相同的概念层级。
因此,本文实际比较的是:
Jev 所代表的专用决策模型,与常见的自回归生成式 LLM,在任务分工和工程使用方式上的区别。
Jev 可以承接部分原本由 LLM 完成的判断任务,但不能替代 LLM 的全部能力;两者也不必在每个系统中同时出现。
二、核心定位与输入要求:必须提供问题,但不一定要列出答案
2.1 LLM:通过生成序列完成多种任务
本文讨论的 LLM,主要指常见的自回归生成式大语言模型。
它们可以生成回答、代码、摘要,也可以进行分类、规划和工具选择。其用途并不局限于"表达层"。
例如,下面两种任务都可以交给 LLM:
- **开放式生成:**分析这次服务故障的可能原因,并给出排查步骤。
- **有边界的判断:**判断这张工单应该交给财务、技术支持还是销售。
支持结构化输出的 LLM,还可以通过受约束解码,使结果符合指定的 JSON Schema。因此,"LLM 必须输出长篇自然语言,再靠正则提取答案"并不是准确的描述。
2.2 Jev:针对明确问题返回结构化判断
Jev 的使用方式可以概括为:
待判断的内容 + 要判断的问题 + 输出类型及必要约束
↓
结构化判断结果
它不会像聊天模型一样,收到任意一句话就自行组织一段开放式回复。开发者需要告诉它:
- 判断什么内容;
- 要解决什么问题;
- 应以什么类型返回结果。
按照当前 HTTP API,请求包含三个主要字段:
| 字段 | 作用 |
|---|---|
| model | 指定模型版本或别名 |
| state | 提供待判断内容,可以是文本或结构化数据 |
| questions | 定义一个或多个需要判断的问题 |
使用 SDK 时,部分配置可以采用默认值,例如默认模型名,不一定需要每次手动填写。
2.3 三种问题类型,对候选答案的要求不同
Jev 提供三类基础问题:
| 类型 | 用途 | 开发者必须定义什么 | 主要返回内容 |
|---|---|---|---|
| Choice | 从候选项中选择一个 | 问题及候选选项 | 选中项、概率分布、置信度 |
| Score | 按有序等级评分 | 问题及评分等级 | 分数、等级概率分布、置信度 |
| Noul | 判断一个是非命题 | 明确的判断问题 | 答案为"是"的概率 |
所以,"Jev 的输入必须包含问题和可选答案"需要进一步区分:
- **Choice:**必须提供候选项。
- **Score:**必须提供有序评分等级。
- **Noul:**不需要手动枚举"是/否",答案空间已经由类型定义。
问题也不一定要写成疑问句,可以写成明确的任务指令,例如"判断用户是否明确申请退款"。
2.4 一个不需要手动列选项的例子
下面是使用 Noul 的完整请求体:
{
"model": "jev-latest",
"state": "这件衣服太小了,我想退钱。",
"questions": {
"refund_requested": {
"type": "noul",
"instructions": "用户是否明确提出退款?"
}
}
}
这里没有提供候选项列表,因为问题类型已经限定为是非判断。
返回结果中的 noul 可能是 0.98,表示模型对"是"的概率估计。这个数值仅用于说明返回形式,不是实际调用结果,也不代表判断必然正确。
2.5 用户输入和模型输入不是一回事
在实际应用中,终端用户通常只需要输入自己的需求:
用户输入:"这件衣服太小了,我想退钱。"
应用程序负责补齐模型调用所需的信息:
程序预设的问题: 用户的主要诉求属于哪一类?
**程序预设的候选项:**咨询、退款、投诉、其他
最终发给 Jev 的内容是:
用户消息 + 程序配置的问题 + 候选项
终端用户不需要每次填写模型参数。问题、候选项和评分等级,可以由开发者提前配置,也可以根据业务上下文动态构造。
预设候选集约束的是当前这次判断的输出空间,并不意味着这些类别必须在模型训练时就固定下来。
三、底层机制:不能简单理解为 "同一个大脑换输出头"
市面上一种非常流行的简化理解:Jev 就是标准大语言模型,只是拆掉自然语言输出头,直接输出决策选项与概率。这个类比极具误导性。二者的差异不局限于输出层,体现在训练目标、推理链路、输入约束、输出形态多个层面,但受公开信息限制,部分内部细节无法确认。
3.1 LLM 的 CoT 不只是答案的冗余展示
一个常见误解:LLM 在向量空间内部已经算出最终答案,思维链 CoT 只是把已经确定的结果 "口述出来",不会改变模型判断。
该观点忽略自回归生成的本质:模型逐 Token 生成,已经生成的推理文本会并入上下文,直接参与后续计算,能够改写最终结果。CoT 不是事后复述。
实验证明:显式中间推理可以提升算术、符号、复杂常识推理效果。但 CoT 不是万能,简单分类任务不需要冗长思考;是否启用推理步骤,应当由任务评测决定。
这一点是理解二者差异的铺垫:通用 LLM 的决策往往依附文本自回归链路;而 Jev 不走文本生成这条主干道。
3.2 Jev vs 通用 LLM:确定差异与不可证实猜想
TypeSafe 将 Jev 的训练范式命名为 RLCD:Reinforcement Learning for Calibrated Decisions,面向决策输出、概率校准做强化学习优化。
通用 LLM 的训练目标,则是拟合人类文本分布,优先生成通顺、符合人类习惯的自然语言。
✅【确定、可观测的真实差异】
训练目标不同
通用 LLM:主目标是下一个 token 预测,追求文本流畅;决策、概率输出是副产物。
Jev‑RLCD:以决策正确性、概率置信度校准为核心目标,不优先优化文本流畅度。
推理执行路径不同
通用 LLM:走完整自回归文本生成链路。哪怕你只要一个 JSON / 标签,模型依然是逐个 token 吐出字符,再由业务代码从文本里抠出决策结果。
输入上下文 → 自回归逐 Token 文本生成 → 自然语言 / JSON 字符串 → 业务代码解析提取决策
Jev:走专用决策推断链路,绕过自由文本生成环节,直接输出结构化选项、打分、概率分布。
输入状态 + 类型化约束 → 专用决策推断 → 选项、分数、概率 → 业务代码直接组装结果
输入约束偏好不同
LLM:接受任意自然语言上下文,弱类型。
Jev:更偏向结构化、类型化输入,任务本身就定义好候选决策集合。
❗【仅外部观测,无法证实的猜想,不能当成事实】
仅凭公开接口行为,我们不能断言下面这些说法成立:
- Jev 的底层模型内部推理能力等价于通用 LLM;
- Jev = 普通 LLM,仅仅移除语言输出头改造得到;
- 所有任务都可以单次前向计算完成;
- 不生成文本,就代表模型参数量必然更小。
**核心结论:**二者看到的行为差异,一部分来自训练目标的定向塑造,一部分来自推理链路的设计,不一定只是改输出层这么简单。不能拿 "拆输出头" 当作事实来解释 Jev。
3.3 "不生成自由文本"不等于"零解析成本"
Jev 的结果仍然需要通过 API 传输和反序列化,程序也需要处理超时、限流等异常。
它减少的是从自由文本中恢复业务含义的工作,例如从一大段回复中提取模型究竟选择了哪个部门。网络通信、JSON 处理和业务校验并不会因此消失。
四、六个维度比较 Jev 与生成式 LLM
| 对比维度 | 生成式 LLM | Jev |
|---|---|---|
| 核心定位 | 通用生成、理解、推理与交互 | 有明确边界的结构化判断 |
| 底层机制 | 通常通过自回归生成完成输出 | 官方强调专用决策训练及并行评估 |
| 输出机制 | 自由文本,也可生成受约束的结构化数据 | Choice、Score、Noul |
| 性能成本 | 受模型、输入长度、输出长度和推理配置影响 | 减少文本解码开销,仍有输入与服务成本 |
| 适用场景 | 对话、写作、代码、复杂分析,也可分类 | 分类、路由、筛选、评分等 |
| 工程集成 | 设计提示、输出约束及结果处理 | 设计问题、选项、等级、阈值及回退流程 |
表中的 Jev 能力来自其官方接口;LLM 的结构化输出能力取决于具体模型和平台。
工程选型需要比较具体模型和配置,而不是仅凭"生成模型"或"决策模型"的名称下结论。
五、准确率与置信度:格式正确,不代表判断正确
5.1 三个指标必须分开看
假设候选项只有:
billing technical sales
模型返回 billing,只能说明它选择了一个合法选项。至于工单是否真的属于财务问题,还需要验证。
| 指标 | 回答的问题 |
|---|---|
| 格式有效性 | 输出是否符合接口约定? |
| 重复一致性 | 相同或相近输入是否得到稳定结果? |
| 任务准确率 | 判断是否符合事实与业务标准? |
模型完全可能"稳定地选错"。
Jev 官方也明确列出了当前版本在数学计算、日期比较、多层间接推理、无关长上下文和对抗性输入上的局限。类型约束不能替代业务验证,也不能自动消除提示注入影响。
5.2 confidence 不等于"本次答案正确的概率"
Jev 的 Choice 和 Score 返回两个容易混淆的字段:
- **probabilities:**选项或等级的概率分布;
- **confidence:**根据分布形状计算出的置信度指标。
Noul 返回"是"的概率,没有单独的 confidence 字段。
因此,不能直接把:
confidence = 0.9
解释为:
这次判断有 90% 的概率正确
概率校准描述的是一组预测的统计表现。例如,对一批具有代表性的预测,被赋予约 0.8 概率的事件,其实际发生比例应接近 80%。这不保证某一个答案正确,也不保证迁移到新领域后保持同样表现。
阈值应使用真实业务验证集确定,并同时观察自动处理覆盖率与错误率。
六、性能与成本:比较完整业务链路
6.1 加速数据必须带上测试条件
TypeSafe 的发布文章展示了特定工作流中约 193.6 倍加速、444.6 倍降本的结果,同时说明这些数字可能处于实际收益较高的一端,其 LLM 对比方案还需要输出概率。
这些数据可以作为评估线索,但不能写成"所有分类任务都快近 200 倍"。
公平的比较至少需要做到:
- 使用相同输入、候选项和业务标准;
- 明确是否要求概率、解释或额外推理;
- 为 LLM 设置合理的短输出或结构化输出;
- 记录网络区域、并发量、缓存和重试策略。
6.2 单次调用便宜,不代表系统一定便宜
截至本文核实日期,官方列出的 Jev 1.13 价格为每百万输入 Token 0.042 美元,输出 Token 免费。英文是其主要训练语言,中文场景需要单独验证效果。 https://docs.typesafe.ai/models
增加决策层后,平均模型调用成本可以近似写为:
C分层 = C决策 + p × CLLM
其中:
- C决策:每个请求的平均决策层成本;
- CLLM:后续一次 LLM 调用的平均成本;
- p:经过决策层后,仍需调用 LLM 的请求比例。
这个简化模型未计入人工复核、维护、重试和误判损失。
假设决策层成本为 1 个单位,LLM 为 20 个单位,只有 30% 的请求需要进入 LLM:
C分层 = 1 + 0.3 × 20 = 7
相比每次直接调用 LLM 的 20 个单位,才体现出明确收益。
如果每个请求最终仍然调用同样的 LLM,且后续调用成本没有降低,新增决策层反而会增加成本。
串行执行时,平均延迟也有类似关系:
E[T分层] ≈ T决策 + p × TLLM
进入后续 LLM 的请求,通常仍需要承担前置判断的等待时间。因此,不能把"决策模型很快"直接等同于"所有用户请求都会更快"。
七、场景选型:规则、分类器与 LLM 都应进入候选范围
以下建议适合作为评测起点,并不是无条件的模型排名。
| 任务 | 优先考虑的方案 | 判断依据 |
|---|---|---|
| 查询订单状态 | 数据库或业务 API | 状态来自权威数据源 |
| 检查用户权限 | 权限系统与确定性规则 | 授权条件必须明确 |
| 执行固定类别意图识别 | Jev、分类器或结构化输出 LLM | 比较准确率、延迟与成本 |
| 高频工单路由 | 专用决策模型或分类器 | 适合明确、重复的判断任务 |
| 检索结果相关性判断 | 重排模型、决策模型或 LLM | 按检索质量与延迟评测 |
| 多步骤复杂分析 | 推理型 LLM 配合工具 | 需要展开和验证中间步骤 |
| 回复、摘要、文案及代码生成 | 生成式 LLM | 需要构造新的内容 |
| 精确计数、计算与日期比较 | 普通程序 | 可直接计算的任务无需模型猜测 |
对于稳定标签体系和大量已标注数据,传统分类器、小型编码器模型也值得比较。
同样,使用模板回复的工单系统可以只接决策模型;调用量较低、需求变化较快的原型,也可能直接使用结构化输出 LLM 更省开发成本。
八、工程架构:代码控制流程,模型承担局部判断
可以采用下面的分层方式:
#mermaid-svg-dUivrxM8HYjq4RcE{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-dUivrxM8HYjq4RcE .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-dUivrxM8HYjq4RcE .error-icon{fill:#552222;}#mermaid-svg-dUivrxM8HYjq4RcE .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-dUivrxM8HYjq4RcE .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-dUivrxM8HYjq4RcE .marker{fill:#333333;stroke:#333333;}#mermaid-svg-dUivrxM8HYjq4RcE .marker.cross{stroke:#333333;}#mermaid-svg-dUivrxM8HYjq4RcE svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-dUivrxM8HYjq4RcE p{margin:0;}#mermaid-svg-dUivrxM8HYjq4RcE .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-dUivrxM8HYjq4RcE .cluster-label text{fill:#333;}#mermaid-svg-dUivrxM8HYjq4RcE .cluster-label span{color:#333;}#mermaid-svg-dUivrxM8HYjq4RcE .cluster-label span p{background-color:transparent;}#mermaid-svg-dUivrxM8HYjq4RcE .label text,#mermaid-svg-dUivrxM8HYjq4RcE span{fill:#333;color:#333;}#mermaid-svg-dUivrxM8HYjq4RcE .node rect,#mermaid-svg-dUivrxM8HYjq4RcE .node circle,#mermaid-svg-dUivrxM8HYjq4RcE .node ellipse,#mermaid-svg-dUivrxM8HYjq4RcE .node polygon,#mermaid-svg-dUivrxM8HYjq4RcE .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-dUivrxM8HYjq4RcE .rough-node .label text,#mermaid-svg-dUivrxM8HYjq4RcE .node .label text,#mermaid-svg-dUivrxM8HYjq4RcE .image-shape .label,#mermaid-svg-dUivrxM8HYjq4RcE .icon-shape .label{text-anchor:middle;}#mermaid-svg-dUivrxM8HYjq4RcE .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-dUivrxM8HYjq4RcE .rough-node .label,#mermaid-svg-dUivrxM8HYjq4RcE .node .label,#mermaid-svg-dUivrxM8HYjq4RcE .image-shape .label,#mermaid-svg-dUivrxM8HYjq4RcE .icon-shape .label{text-align:center;}#mermaid-svg-dUivrxM8HYjq4RcE .node.clickable{cursor:pointer;}#mermaid-svg-dUivrxM8HYjq4RcE .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-dUivrxM8HYjq4RcE .arrowheadPath{fill:#333333;}#mermaid-svg-dUivrxM8HYjq4RcE .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-dUivrxM8HYjq4RcE .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-dUivrxM8HYjq4RcE .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-dUivrxM8HYjq4RcE .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-dUivrxM8HYjq4RcE .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-dUivrxM8HYjq4RcE .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-dUivrxM8HYjq4RcE .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-dUivrxM8HYjq4RcE .cluster text{fill:#333;}#mermaid-svg-dUivrxM8HYjq4RcE .cluster span{color:#333;}#mermaid-svg-dUivrxM8HYjq4RcE div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-dUivrxM8HYjq4RcE .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-dUivrxM8HYjq4RcE rect.text{fill:none;stroke-width:0;}#mermaid-svg-dUivrxM8HYjq4RcE .icon-shape,#mermaid-svg-dUivrxM8HYjq4RcE .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-dUivrxM8HYjq4RcE .icon-shape p,#mermaid-svg-dUivrxM8HYjq4RcE .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-dUivrxM8HYjq4RcE .icon-shape .label rect,#mermaid-svg-dUivrxM8HYjq4RcE .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-dUivrxM8HYjq4RcE .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-dUivrxM8HYjq4RcE .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-dUivrxM8HYjq4RcE :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 有
无
否
是
标准业务
需要生成
用户请求
身份校验与上下文准备
已有确定性处理路径?
业务代码或业务 API
程序组织问题与输出约束
Jev:分类、评分或是非判断
类别覆盖且置信度达标?
补充信息、推理模型或人工复核
处理方式
LLM:分析与内容生成
结果校验与输出
这种结构的重点,是为不同请求选择合适的处理方式。官方意图路由示例也将处理目标分为确定性代码、专用 LLM 和人工处理。
8.1 明确模型与业务系统的职责
- 模型识别意图,业务系统验证事实。
识别"用户想退款",不等于确认"用户满足退款条件"。订单归属、退款期限、支付记录和重复退款检查,仍由业务代码负责。 - 允许模型表达当前选项不适用。
候选项应包含必要的 other 或 unknown 出口,避免将范围之外的输入强行归入已有类别。 - 局部判断与业务动作分开。
模型可以分别判断"是否提出退款""是否描述重复扣款",再由代码组合结果。真正的付款、删除和权限变更,仍应经过对应业务校验。
8.2 Python 接入示例
下面演示工单分类与低置信度回退。接口写法依据官方 Python SDK;示例未进行真实 API 调用,阈值仅用于展示流程。
安装依赖,并通过环境变量 TYPESAFE_API_KEY 提供凭证:
pip install typesafe-sdk
from typesafe_sdk import Choice, TypeSafeClient
# 演示值;生产环境需要使用验证集确定。
MIN_CONFIDENCE = 0.85
HANDLERS = {
"order_status": "order_service",
"product_question": "product_llm",
"refund_request": "refund_workflow",
}
def classify_ticket(client: TypeSafeClient, message: str) -> dict:
response = client.system_one(
state={"message": message},
questions={
"intent": Choice(
instructions=(
"根据 message 判断用户的主要诉求。"
"无法明确归类、多项诉求无法确定主次,"
"或不属于已列出的类别时,选择 other。"
),
criteria={
"order_status": "查询发货、物流或订单进度",
"product_question": "咨询产品功能、用法或适用性",
"refund_request": "明确申请退款或退货",
"other": "其他诉求、信息不足或主要诉求不明确",
},
)
},
)
intent = response.answers["intent"]
if (
intent.choice == "other"
or intent.confidence < MIN_CONFIDENCE
):
handler = "review_queue"
else:
handler = HANDLERS[intent.choice]
return {
"handler": handler,
"intent": intent.choice,
"confidence": intent.confidence,
"probabilities": intent.probabilities,
"model": response.model,
}
if __name__ == "__main__":
with TypeSafeClient(
model="jev-1.13.0",
timeout=5.0,
) as client:
result = classify_ticket(
client,
"订单已经三天没有物流更新了,帮我查一下。",
)
print(result)
这个例子中,用户只提供消息,程序负责提供问题和候选项。
返回的处理器名称由应用继续消费:
- order_service:校验订单归属后查询业务 API;
- product_llm:准备产品资料,再调用 LLM 生成回复;
- refund_workflow:进入退款资格检查;
- review_queue:补充信息或人工复核。
上线时还需接入异常记录、限流和服务故障回退。SDK 的重试行为也应纳入整体延迟预算。
如果阈值针对某个版本调优,应记录并固定模型版本。使用 jev-latest 时,别名可能随发布更新,原有评测结论也需要复查。
九、上线前如何判断分层方案是否值得采用
至少建立三组基线:
- 当前业务方案;
- 短输出或结构化输出 LLM;
- Jev 决策层加后续处理器。
使用相同测试集比较:
| 评测项目 | 应关注的结果 |
|---|---|
| 分类质量 | Macro-F1、关键类别召回率、误路由率 |
| 自动处理效果 | 自动处理覆盖率及其中的错误率 |
| 概率表现 | 预测概率与实际结果是否匹配 |
| 用户体验 | 端到端 P50、P95 延迟 |
| 业务成本 | 每千次请求的模型、重试与人工成本 |
| 输入变化 | 中文、口语、省略、多意图及未知类别表现 |
| 服务异常 | 超时、限流、版本变化后的处理行为 |
先使用验证集选择问题描述、候选项和阈值,再使用独立测试集评估,避免把调参效果误当成泛化能力。
灰度阶段可以让 Jev 只记录建议路由,暂不改变现有流程。确认真实流量下的质量、成本和延迟符合目标后,再逐步扩大自动处理范围。