某省电信用大模型改造客服中心，日接听量从2万暴涨到8万—

要说客服中心的技术改造，呼叫中心AI是去年以来落地最猛的方向之一。但大部分AI客服做出来是什么效果？用户听了三遍"转人工请按0"，血压直接拉满。

某省电信（以下简称A省电信）的做法不太一样。他们没有找大厂买一套现成的"AI客服机器人"往线上一挂，而是自己找了外包团队——基于开源大模型做了整套私有化部署的方案。结果呢？日均热线接听量从2万通涨到8万，一次性解决率从52%提到78%。今天不扯概念，直接拆他们的技术选型和落地路径。

问题到底出在哪

A省电信的客服中心有1000个坐席，日均呼入量2万通。听起来比例不错对吧？但实际情况是：

高峰时段排队超过15分钟，用户挂断率高达40%
坐席离职率30%，新人培训3个月才能上岗，刚上手又走了
重复性问题占65%——查话费、查流量、宽带故障报修、改套餐，每个坐席每天回答同样的东西几十遍
夜间和节假日只能留20%人员值班，响应速度断崖式下降

这不是A省电信独有的问题。全国运营商都面临同样的困境——人工成本涨、招聘难、用户对服务体验的要求却越来越高。

技术选型：为什么没选大厂SaaS方案

项目启动时团队调研了三类方案：

方案A：大厂全托管SaaS

优点：上线快，不用管底层
缺点：数据要上传到对方云端，运营商的信息安全要求直接否掉；另外按调用量计费，量一大成本吓人

方案B：第三方ASR+NLU平台

优点：技术成熟
缺点：基于传统规则引擎+小模型，长尾问题理解能力差，用户说"我手机最近卡得要死是不是该换套餐了"这种复合句直接挂

方案C：开源大模型私有化部署（最终选择）

基于LLaMA 2的中文微调版本（当时DeepSeek V2还没全面铺开）
4张A100 80G做推理，2台国产服务器做向量数据库和业务逻辑
整体预算控制在80万以内（含开发人力）

最终选了C。原因很简单：数据不出门、可控、长期成本远低于按量付费。

系统架构长什么样

简单的说，整个流程是这样的：

用户来电 → ASR语音识别（本地部署Whisper Large V3）→ 意图识别+实体抽取（微调后的LLM）→ 分流

分流逻辑分三层：

高频标准化问题：直接回答。查话费调BSS接口、查流量调计费系统，结果直接语音播报。这部分占整体话务量的45%。
中频问题：半自动处理。比如改套餐，LLM根据用户消费习惯生成方案A/B/C，坐席看一眼一键发送确认。不需要打字，缩短单通时长70%。
低频/复杂问题：全量转人工，但LLM会把用户刚才说的内容自动整理成上下文摘要，坐席接过来直接看摘要就知道发生了什么，省掉"您好请问有什么可以帮您"这个开场确认环节。

核心思路是用LLM做分流，而不是替代人。简单问题机器直接处理，复杂问题帮坐席打好草稿再转过去，本质上是给每个坐席配了一个AI助手。

落地过程中的几个坑

坑1：语音识别和方言

开局用某开源ASR模型，普通话准确率95%，但到了粤语区和闽南语区直接掉到60%以下。最后换成了本地化部署的Whisper Large V3，并且在A省电信自己的录音数据上做了1000小时的微调，方言准确率拉到88%。这一步属于"不上线不知道，一上线才慌"的典型教训。

坑2：知识库检索召回率低

最开始用传统的BM25做知识匹配，用户说"我流量用超了咋办"，系统死活匹配不到"流量套餐超量扣费规则"这个文档。后来切换成Embedding+向量数据库方案（bge-large-zh做embedding，Milvus存向量），同义句的召回率从62%提到91%。

坑3：幻觉控制

最怕的是LLM瞎编。用户问"我这个月话费多少"，如果知识库里没查到，模型可能会自己猜一个数字生成回答。解决方案是给LLM下硬约束——对需要查数据的意图，LLM只负责生成SQL和参数，不参与数据生成，实际数据由后端真实API返回后拼装成回答。这样LM就变成了"路由+调度"的角色，不碰真实数据。

效果数据

上线半年后的关键指标对比：

指标	改造前	改造后
日均接听量	2万通	8.1万通
一次性解决率	52%	78%
15秒内接通率	35%	82%
坐席日均处理时长	6.2小时	3.5小时（专注处理复杂问题）
用户满意度	82%	91%