Jev/TEV在意图数量少(几十~几百)且业务边界复杂时优于Embedding,支持零样本、条件判断、并行输出;上限255个选项是硬限制。
不能完全替代,但可以干掉一大半传统 Embedding 意图识别的场景,二者有明确分工,不是简单谁取代谁。
流程:句子 → 向量化 → 向量相似度检索,匹配预先写好的意图库
原理:语义相似度匹配,靠向量空间远近判断属于哪个意图
适合:意图集合固定、提前建好库;意图数量可以很大(几千、上万)
痛点:
Choice/Noul 原生做意图分类,输出校准概率
原理:带指令理解的决策打分,能读懂描述、条件、否定、边界定义。
"route_team": {
"type": "choice",
"instructions":"判断用户诉求",
"criteria":{
"refund":"用户要求退款,订单未超180天",
"complaint":"用户表达不满投诉",
"consult":"普通业务咨询"
}
}
👉 你可以直接在 criteria 里面写业务边界条件,这点 Embedding 做不到。
优势:
短板(致命,决定它不能完全干掉 Embedding):
满足下面,直接上 TEV/Jev,Embedding 那套可以下线:
典型场景:客服工单分诊、Agent 工具选择、风控初筛。
意图规模很大:几百上千甚至上万细粒度意图 > 比如大型知识库问答,几千个问题模板,用 Embedding 做召回是成本最低的;塞给 TEV Choice 不现实。
主要做召回、知识库检索、相似问句匹配 > Embedding 擅长:“找历史最相似的用户 query”,这是检索任务,不是决策分类任务。Jev‑TEV 不是检索器。
大量长尾、冷样本:需要做粗筛召回,再交给决策模型精判。
业务:客服意图识别,总共 120 个意图 → 直接 TEV,Embedding 意图模块可以删掉。
既利用 Embedding 能扛海量候选的优势,又利用 TEV 能理解业务条件、做严谨决策的能力。
业务:企业内部 FAQ,3000 条问答 → Embedding 召回 Top‑8,再喂 TEV 做最终选择校验。
向量有两类用途要区分:
For further actions, you may consider blocking this person and/or reporting abuse