跳到主要内容

微语探索决策模型 Jev/Laya：让客服先判断，再回答

· 阅读需 8 分钟
Jack Ning
Jack Ning
Maintainer of Bytedesk

客户说“又扣了一次费，不处理就取消续费”，客服系统首先需要的，可能不是一段流畅的回答，而是识别投诉、找到负责账单的团队，并判断是否需要人工介入。

微语（Bytedesk）计划评估通过 Ollama 接入开源决策模型 Laya，让专门做判断的模型辅助客服意图识别与路由。目前仍是方案评估阶段，尚未实现或上线；本文介绍的是预期价值，不是已验证的产品能力。

微语不会锁定只使用 Laya。 规划中的决策能力将支持按需切换模型，包括通过 API 接入阿里云、智谱等提供方；Laya 是首个验证选项，而不是唯一选择。

Laya 是什么？更像分诊员，而不是话术员​

聊天大模型擅长组织语言、解释问题、生成回复。Laya 则面向范围明确的判断：在预先定义的类别中做选择、判断某种情况是否成立，或按约定的等级打分。

例如，它可以帮助判断：

  • 一条消息更像咨询、投诉、建议，还是其他？
  • 请求与账单、技术支持，还是销售更相关？
  • 客户是否明确提出取消续费或转人工？

Laya 由 Convai Innovations 发布，默认模型约 4.21 亿参数，基于 ModernBERT-large，采用 Apache 2.0 许可证，权重可用于自部署。它不负责生成客服回复，也不会查询真实订单或替坐席完成退款。

有一个重要的语言边界：Ollama 提供的默认 laya 模型仅支持英文。 Laya 项目另有面向 100 多种语言的 laya-multilingual 模型，但它不随 Ollama 的默认模型提供。中文、繁体中文和中英混合客服都需要单独验证，不能因为项目有多语言版本，就宣称当前接入方案已支持中文。

为什么客服系统需要“先判断，再回答”​

一条消息如果一开始就分错队列，后面的回答再流畅，也可能让客户在部门之间来回转接。意图识别的价值，在于让系统先弄清楚“该进入哪一种处理流程”。

现有做法可以是关键词规则，也可以让聊天大模型输出分类结果。前者直观但可能漏掉不同表达，后者灵活但需要考虑推理开销和输出校验。Laya 提供另一种选择：把边界清楚的判断交给小型决策模型，把复杂解释留给大模型或人工。

它并不一定适合所有任务。明确的时间比较、金额计算、权限校验仍应由业务规则和程序处理；跨多轮、多个诉求的复杂问题，也不宜硬塞成一次简单选择。

引入 Laya，微语希望改善什么​

1. 减少不必要的等待和转接​

对于短文本、有限类别的高频判断，专用决策模型有望减少生成式分类的开销。官方公布过特定硬件上的毫秒级结果，但微语真实响应还包含网络、排队、模型加载和后续处理，不能把官方单次推理速度当作客服端到端承诺。

2. 把“不确定”纳入服务流程​

模型返回的分布信息可以帮助系统判断何时自动分流、何时补充信息、何时交给人工复核。但“置信度高”不等于“答案一定正确”，更不等于该分数就是准确率。自动处理边界必须用实际客服样本验证。

3. 输出更受约束，但仍允许犯错​

在已定义的选项中选择，比自由生成一段分类说明更容易接入业务流程。不过，不生成文本不代表不会误判：把投诉分成咨询、漏掉否定表达，同样会影响体验。受约束的输出不能替代业务验证和人工兜底。

4. 为数据留域提供一种部署选择​

自部署有助于让这一步判断在企业内网完成。但是否满足合规要求，还取决于访问控制、日志脱敏、数据留存，以及后续问答和回退链路。如果回退到外部云模型，相关消息仍可能出域，不能只看 Laya 部署在哪里。

5. 更合理地分配算力预算​

把高频、简单的判断从大模型中分离，有望改善整体资源利用率。自托管并非“一次投入、永久免费运行”：硬件、电力、运维、扩容和评测都属于持续成本。是否划算，需要在相同质量和流量条件下比较。

一个客服场景，如何协作​

以重复扣费投诉为例，拟议流程是：识别“投诉、账单相关”的信号，交给现有规则确认处理队列；需要时由坐席或具备权限的业务工具核查账单，再由人工或大模型组织回复。

其中，Laya 提供的是分类或处理建议，不是退款授权。紧急程度、流失风险和转人工建议可以作为后续探索方向；它们不是已经上线的功能，也不能仅凭客户说“退款”就断定客户将流失。

中文业务会继续使用既有处理链路，直到独立的语言与质量验证通过。即使返回“需要人工”，也仍须由微语的工作组、排队与坐席规则完成实际接待。

Laya 与 Jev：如何选择，而不是简单排高低​

Jev 是 TypeSafe 的决策模型，同样面向选择、判断和评分等结构化任务。Laya 的决策接口采用类似的 System One 风格，但这不意味着两者的语言能力、模型效果、阈值或所有功能可以直接互换。

关注点LayaJev
公开接入方式开源权重，可通过 Ollama 自部署默认英文模型官方文档提供托管 API 与 SDK
团队投入自行承担部署、容量规划、升级与质量评估可减少自建推理服务的工作；服务条款仍需评估
数据治理可内网处理；仍须检查日志和回退链路核对数据处理区域、留存、合同及企业部署选项
成本比较计算硬件、运维与评测的总成本以官方当前价格和合同为准，不假定固定计费模式
效果比较在目标语言与业务样本上实测用相同样本、质量要求和端到端指标比较

希望掌握模型部署和运行环境的团队，可以优先研究 Laya；希望减少推理基础设施维护的团队，可以评估 Jev 的托管服务。本文不依据不同硬件上的公开基准宣布哪一个“更快、更准或更便宜”。

不绑定单一模型：让企业保留选择权​

不同团队对语言、效果、时延、预算和数据部署的要求并不相同。微语计划把“客服需要做什么判断”与“由哪个模型完成判断”分开：企业可以选择自部署 Laya，也可以在相应适配完成后，通过 API 选用阿里云、智谱等提供方中适合决策任务的模型或服务；Jev 也是可评估的候选。切换已适配的模型应通过配置完成，不必重写客服意图分类与路由流程。

这里的“自由切换”不等于所有模型天然兼容。各家的接口、语言、输出形式和数据处理条款需要分别核实；通用模型经结构化输出承担判断任务，也不等于它就是 Laya 一类的专用决策模型。本文不宣称阿里云或智谱已有与 Laya 完全相同的接口、概率或置信度能力。

每次切换都应经过业务样本评测和小范围验证。切换到云 API 前需确认数据出域许可；不会因为本地模型失败，就未经授权自动把客户消息发送给另一家服务。

下一步：先验证，再决定上线​

微语拟从供应商无关的决策接口与 Laya 英文协议验证起步，并将阿里云、智谱 API 适配及模型切换纳入分期规划，再开展离线评测、工具路由影子运行、小范围灰度与回滚。中文支持可评估独立多语言模型服务或通过验收的 API 模型，不受限于 Laya；具体型号、接入顺序、会话自动分类、管理后台和实际转人工改造，仍需在规划中确认。

  • 开发者可阅读 Laya 意图识别与路由开发指南。
  • 仓库内的实现规划位于 docs/plans/2026-10-18-laya-intent-routing-plan.md，状态为待确认，不发布到文档站。

方案确认之前，不开始业务代码实现。

相关资源​

本文依据上述官方资料整理；模型发布、服务条款和价格可能变化。外部 Demo 仅用于体验，不应上传未经授权的客户数据。