语音智能体:大模型如何“接管”人类对话?
在人力成本飙升、企业降本增效需求迫切的当下,传统呼叫中心正面临一场静默革命。
云蝠智能创始人兼 CEO 魏佳星向 OSCHINA 透露,通过大模型构建的语音智能体(Voice Agent),已能将单次通话成本从5元压缩至0.5元——这不仅是技术迭代的结果,更是一场涉及多模型协同、工程化落地与组织转型的深度变革。
从药房用药追踪到电力集团调研,从银行不良资产处置到“拟人化”情感互动,这条赛道正以超乎想象的速度重构着企业与用户的对话方式。
开发者们需要关注的是:在开源模型生态爆发之际,如何用工程化思维加速大模型能力转化为可复用的行业经验?而当 AI 意图理解率突破99%时,真正的战场又转向了哪些细节?
5元→0.5元:语音交互的“成本塌陷”与全流程重构
我们主要做的是一种叫做语音智能体的业务,其核心目标是让诸如通义、千问或豆包这样的大型模型能够在电话或语音端完成有效的互动。呼入呼出、业务回访场景下,以往一通电话的综合人力成本是 5 元,大模型可以把这个成本压缩 10 倍。
举个例子,我们为某大药房提供服务,这项服务并非营销电话,而是了解长期购药群体的用药情况和近期身体状况,以及他们之前的购药渠道。
这种业务场景非常合规,类似于回访调研和接听场景。
此外,我们还服务过电力集团,进行用电情况调研,以及为银行进行不良资产催收和解的工作。因此,这个场景实际上是取代了原有的呼叫中心。
当然,这是一个全流程服务,我们不仅仅负责呼叫。在呼叫之前,我们会帮助企业用户建立知识大脑,包括资料包和整个结构化、非结构化的知识档案。
我们不仅要负责呼叫,还要完成两个后续工作:一是后续动作的跟进,比如发送挂机短信告知员工或领导;二是结论的分析,比如分析用药来源是小红书还是抖音,并以 JSON 格式输出具体字段给甲方。因此,这里实际上有多个大模型在协同工作,形成一个智能体。
Voice Agent 主要包括几件事:首先是模型本身,客户可能有垂直模型,或者通过 SFT 进行微调;模型之后就是Promote 和 RAG,为了进一步精准,我们还会引入 Function Call 插件、客户画像和用户记忆等,这其实是一些主流的智能体编排流程;之后更多的压力会落在提示词工程师的交付团队上,因为他们需要根据不同行业的需求搭建不同的 Agent。我认为 AI 是一种能力,只要我们保证这个能力足够全面,那么接下来的主要任务就是交付团队制作大量的行业模板。比如在不良资产这个赛道,当我们服务到第三个、第五个客户时,我们已经可以向客户输出内容观点了。
6-7个大模型如何分工?一场 AI 协同的交响实验
在整个 Voice Agent 训练工作过程中,大概有6-7个 AI 大模型在协调工作:
- 在对话前,第一个 AI 大模型负责对用户的数据集进行整理和归纳;
- 第二步对实时互动的 AI 进行训练,需要两个 AI 大模型,一个伪装成客户,另一个扮演教练;
- 实时互动过程中,也有两个 AI ,一个负责直接与用户交流,另一个则在全程观察对话,帮助校正,最后产生通话结果;
- 最后,还有最后一个 AI 负责数据的总结和分析。
实际上还可以增加一些环节,比如客户口误了,则还需要一个 AI 去纠错,但这个过程会导致延迟,所以我就放弃了。
不同的 AI 承担不同的任务,比如假装是客户的 AI 可以不那么聪明,因为客户不需要深入思考,随便聊聊就行。
但是,负责数据分析的 AI 就需要更聪明一些,因为它对时延没有要求。实时互动的对时延要求很高,所以可能不会使用特别大的模型,因为大模型的反应速度跟不上。
我们通常选择闭源方案,因为开源方案现在有一个很大的问题,不是开源方案本身的问题,而是算力的弹性问题。因此,我会选择像通义、豆包和 Deepseek 这样的模型,通义和豆包负责主要的互动,Deepseek 负责数据分析。
由于 Deepseek 的反应速度跟不上,所以不能让它直接参与互动,这个环节还是由豆包这样的模型来承担,因为它们的效率更高,成本也低。Deepseek 的逻辑是推理型的 AI,所以注定不可能在几百毫秒内做出反馈,这是技术栈的问题,所以它不适合实时互动,而适合于前置的生成工作,比如生成 Promote,以及后续的数据分析,这些环节特别适。
一开始,我们会尝试使用所有的模型,然后在业务侧,由具体的提示词工程师团队在实际与客户打磨中慢慢找到最适合的方案,然后淘汰那些不适合的。最开始,我们会放很多模型,比如智谱、MiniMax等,我们最早的时候都会尝试。
随着时间的推移,我们也会尝试新的方案。比如,有一个端到端的方案,从语音到语音,这样的新技术方案我们也会摸索。
关于 Voice Agent 的评估指标。上一代有很多指标,比如语音识别率等等,现在已经不那么重要了。一个比较有意义的参数是:我们能看到的很多甲方业务里有5%到10%的业务场景能被 AI 直接取代,如客服随访。AI 的意图理解率已达99%以上,错误通常由提示词导致,而非模型问题。即使语音识别出错,AI 也能通过上下文理解意图。
从自研到工程化,研发团队的三次转型
我们是 AI 1.0时代的公司,在2018年创业的初期,以算法为主,会自研语音识别、语音合成和向量数据库等等。但是到了 GPT 时代之后,其实我们慢慢已经快要放弃自研这件事了,完全跟不上,而且也没意义。
以前自研是因为市场上没有开源的替代方案,甲方要本地化部署,所以我们必须具备技术能力。但现在不需要了,开源已经把这些障碍全部突破了,所以现在我们专注在把模型能力放到语音端的工程化上,那这些就是这么多年的行业认知形成的壁垒和经验。
其实业务没变化,但是研发团队一直在调整状态。
想让研发算法的工程师全部放弃自研,转向工程并不简单,工程岗位的薪资没有算发岗位高,这是很现实的问题。在转型过程中我们开了无数次的会。到目前为止,研发部门已经历了三轮改革。
第一轮是推动从传统编码转向 AI 辅助编码,即 Copilot。初期遭到不少老工程师的抗拒,我们采取了许多措施,如报销培训费用、部门试点后推广,最终强制执行。
去年,我们从 AI 辅助编码转向 AI 自动编码,使用 cursor 进行编码,这一环节又遭遇了一批人的抗拒。我们不仅强制执行,还引入了奖励机制,例如完成任何业务需求都有奖金,金额从50元到一两千元不等。这样做的目的是激发员工多写需求以赚钱,而 AI 工具提高了他们的效率。
例如,今年我们为所有程序员更换了 Mac 电脑,配备了 APP4 512G,结合 AI 编码,效率显著提升。同时,我们改革了政策,使员工年薪增长20%至30%,他们自然愿意接受。
管理同样重要,不能只谈 AI。单纯提效可能导致员工完成任务后休息,比如我用大模型快速完成稿子,可能会选择放松。
作为年轻人,我了解员工的反感和需求。将工作量化,像游戏一样,能提高一线员工的积极性,使他们愿意接受变化。当然,总会有人无法适应,那么他们可能会被淘汰。
在推进变革时,必须明确告知员工未来的工作和收益,他们才会安心跟随。同时,要探索新工作点,提前指明方向和相应奖励。例如,工程师团队未来可能转向模板化工作,把以往服务过的几千个行业场全部模板化,每搭建一个模板都有相应奖励。这样,员工知道下一步该做什么,就不会感到慌张。
关于交付团队,我认为逻辑清晰、层次分明的理工科研究生非常适合描述事件,完成这项工作。他们不需要亲自编码,因为智能体的编码工作由 AI 能力开发者完成。例如,我在药房客户演示中全程只需敲文字,无需编码。产品最终应该实现可视化,让不会编码的人也能使用。如果一个产品要靠编码才能交付的话,那它也很难规模化。
我们的产品在客户业务中上线后,后续维护方面,客户可以选择委托我们的提示词工程师团队,也可以自行搭建行业模板。为了提高交付效率,我们正在建立模板市场,将脱敏化、标准化的方案直接纳入市场体系。未来,提示词工程师团队可能更多从事行业探索,而非应对客户交付。
我们相信这种产品会越用越简单。其复用性使得复杂甲方的交付标准能迅速应用于中小型企业,大幅降低成本。老客户也有复购,我们在 AI 调用过程中按笔收费,成本仅为人工的1/10。
让 AI 学会“不完美”
最近,我关注到一个场景,陌陌也在做语音智能助手,要让 AI 与用户谈恋爱,这个挑战远大于我们的任务。我们只完成一个工作,而他们需要实现长期互动。
我仔细观察了他们的效果,虽然觉得还没达到人类水平,但 AI 确实表现出了情感。
人为何有情感?因为人不完美。我们工程师可以故意让 AI 不完美,比如让它算数学题时故意不算,而且还要啰嗦地拒绝。我们在做人机互动产品时,会关注这些人际互动细节,并不断加入其中。那么最终实现突破只是时间问题,而且过程中已经显现出商业化价值。
Voice Agent在落地的过程中最大技术难点是拟人化,不仅仅是音色层面,而是要达到人与人互动的状态。我们现在的对话不是完美的一问一答,而是有互动过程,比如表达倾听、回顾观点等。AI 目前还做不到这一点,它完全是基于流程办事。
拟人化的关键在于让 AI 在语气、语调和互动节奏上接近人类,我们有很多工程细节要考虑。行业里有很多技术探讨,比如让 AI 主动打断啰嗦的客户,这是双向互动的体现。即使这种打断可能是预设的,也有其价值。我的工作难点在于细节无穷无尽,比如 AI 反应速度慢和出现幻觉的。不过,大多数甲方已经能接受幻觉,因为人也会犯错。只要 AI 犯错的概率与人类相当,且错误不致命,就是可以接受的。
以药房的服务为例,我会全程引导对方,不允许 AI 直接给出用药建议。这也是我要与甲方沟通的高风险事件,处方药不能由 AI 开具,但 AI 可以用于用户调研和随访。甲方也理解这里的问题,大家都是有认知的人,可以调整策略,先从第一步做起。
- AI 行业的趋势和变革;
- 营销及销售侧的 AI 应用(面向 AI 的新一代营销体系+如何构建企业知识大脑);
- 呼叫行业的 AI 变革和应用落地;
- 在研发、采购及决策层如何引入AI。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MiniMax GenAI 可观测性分析 :基于阿里云 SelectDB 构建 PB 级别日志系统
"阿里云SelectDB作为MiniMax日志存储服务的核心支撑,为在线和离线业务提供了高效、稳定的查询与聚合分析能力。其支持实时物化视图、租户资源隔离、冷热分离等企业级特性,不仅有效解决了日志场景下PB级别数据查询的性能瓶颈,还通过智能化的资源调度与存储优化,实现了成本与效率的最佳平衡,为业务的高效运转提供了坚实保障。" ------MiniMax可观测架构师 香克斯 可观测日志系统的探索与挑战 近年来,MiniMax在多模态与文本模型领域持续发力,凭借其技术突破和应用创新能力,迅速成为全球人工智能领域的焦点。25年1月,MiniMax发布了多项重磅成果:支持主体参考功能的视频新模型S2V-01、基于大规模线性注意力机制的开源模型MiniMax-01系列,以及支持17种语言音频合成的T2A-01系列语音模型。作为一家成立仅三年但估值已突破数十亿美元的初创企业,MiniMax已然跻身人工智能领域最具潜力的独角兽企业之列。 为了深入洞察模型训练迭代和 AI应用的运行状态,精准定位潜在问题以持续优化模型和业务系统的性能,可观测系统的建设成为MiniMax底层基础设施建设中不可或缺的关键环节...
- 下一篇
GreatSQL 为何选择全表扫描而不选索引
GreatSQL 为何选择全表扫描而不选索引 问题背景 在生产环境中,发现某些查询即使有索引,也没有使用索引,反而选择了全表扫描。这种现象的根本原因在于优化器评估索引扫描的成本时,认为使用索引的成本高于全表扫描。 场景复现 2.1 环境信息 机器 IP:192.168.137.120 GreatSQL 版本:8.0.32-26 2.2 环境准备 通过脚本创建了一个包含 100 万条数据的表,并在 age 列上创建了索引 idx_age,如下所示: #!/bin/bash # 数据库配置 db_host="192.168.137.120" db_user="root" db_pass="xxxx" db_name="test" db_port=3306 table_name="t1" my_conn="greatsql -h$db_host -P$db_port -u$db_user -p$db_pass -D$db_name" # 创建大表 create_table() { $my_conn -e " CREATE TABLE IF NOT EXISTS ${table_name} (...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS关闭SELinux安全模块
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS6,CentOS7官方镜像安装Oracle11G
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作