火山引擎豆包大模型产品专家 刘一
文末获取直播回放及嘉宾分享PPT
观察:大模型在客服领域的应用趋势
首先从趋势上来讲,今年其实大家会更关注落地的效果,更关注投入的产出比。在交流的过程中,大家提到的模型相关的内容会变少,例如参数等,更关心的是模型的效果、价格、性能。我们从趋势中发现4个大家共性关注的重点。
1.围绕数据
如果更看重落地的效率,落地的路径越短见效越快,那么在质检和VOC这种数据集中的场景里是最适合的,本质上一不需要交互,二和其他的业务系统的交互集成也会比较少。其次,它本身富含的数据价值较多,对有价值的文本信息里的数据资产的挖掘是很重要的,所以我们观察到很多企业在做大模型客服应用的时候,会把第一批的试点场景选做质检和VOC。
2.围绕营收
因为大模型比传统的客服能力有显著提升,包括语义的提取、理解上下文、把握对话的能力,那么如何利用好这些增值的能力去产生新的业务价值也是大家想了解的议题。
3.围绕交互
大模型在客服的应用中是一个强交互的过程。整体的交互体验会直接影响到最终的满意度和落地成效。在这个主题之下,其实企业今天非常关注两个和技术相关的点,第一个就是在很好地理解上下文的情况下,看能不能有一个很好的延迟响应去解决用户体验的问题。第二个就是回答出来的问题是不是足够准确,具备的通用知识的范围是不是足够广。
4.围绕工具
因为客服的场景涉及的子场景是很多的,每一个场景对本身模型能力的要求是不同的,在落地过程中可能需要的配套模型的落地工具也有一些不同。
围绕数据:VOC和质检提供更多业务洞察
在大量的存量对话记录里,其实有非常多的价值点,不论是还原一个完整的用户服务链路,还是去构建一个完整的用户画像,都能够用来提升服务质量,指明业务发展的方向。我们也一直在尝试,从最初的关键词到之后的可能基于政策的规则,再到后来的小模型,但始终难以像人一样去理解一个复杂的规则。
那么在复杂场景下要做质检,其实最原始的还是要人工去做这些工作,需要设定角色、质检项目以及项目之下不同的条件和条件之间的关联。在这种模式下,人工的投入非常大,而且维护成本高,受限于模型能力,它的投入产出比也非常低。
但今天有了大模型之后,我们可以把这套质检的逻辑以自然语言的形式放到提示词里,让大模型去直接执行这个任务,在这个场景之下,其实就对模型提出了第一个要求:模型是否有足够强的综合基础能力去理解输入进去的这些规则。
其次,对坐席的这种服务质量的监督有很多前置条件,必须是在满足某特定情况下。这些复杂的规则之间是有推理关系的,而且它对应的这个证据可能在很长的上下文的不同的段落,所以这背后就对大模型提出了第二个挑战:怎么去处理比较长的上下文。
火山引擎嘉宾分享PPT
针对这两个挑战,豆包大语言模型也在持续地迭代自己的能力。首先从基础模型的综合性能上来讲,如上图左侧是我们9月份发布最新版模型时模型提升的一个指标。首先重点提升了模型的推理治理能力,这个数学的分值背后就代表了推理能力的提升,其次就是在专业知识和综合能力都有25%以上的提升。
针对长的上下文,豆包模型除了主流的4K、32K的窗口,我们也支持256K的窗口,直观理解它大概等于33个小时的通话转写成文字的数量。其次我们看到在很多案例里业务真的非常复杂,在这种情况下,可能要对对话的记录进行分段和分类,这会让整个分析的任务工作量成倍上涨,也会造成成本的上升。
但是在质检和VOC这种离线的场景下,其实很多时候不用实时看到结果,所以结合这两个特点,我们也推出了大模型的离线批量处理的一种功能,它能一天处理13亿的文字,这样就能让企业以一个更高性价比的方式去完成一个更智能的全量的质检。
围绕营收:AI客服的“谈判/销售”能力更进一步
营收核心是利用大模型产生出来的一些传统客服没有的能力,怎么利用这些能力更好地去多做一些任务,释放人的精力,投入到更有价值的业务节点上,一个比较典型的场景就是电销和外呼。
在这个场景之下,传统的智能外呼更多地是做信息的通知和意向的确认,这是整个销售环节中的第一环。大模型具备了一定的磋商、把握对象、把握对话上下文走向的能力,所以它其实可以往后多做一步,对整个销售漏斗的转化会有非常大的提升。
如果还是让人力去做整个的销售环节,有两个问题,其一是成本比较高,其二是很难提高并发。比如我们有一个非常典型的客户,他是招聘行业的一个企业,每年招聘季窗口时间是固定的,就会有大量的外呼任务去找求职者确认求职意向,然后打给企业询问有没有买招聘服务包的这种需求。
在传统模式下,传统外呼只能做一项的确认,后边还要人工大量地去筛选这些线索。但是有了大模型的这种磋商的能力,在外呼的过程中,首先能够更准确地去判断求职的意向,其次能询问到更多求职方向上的信息,更精准地去做职位的推荐和匹配。
此外就是在一些简单的场景,在这些环节中,很多客户已经进行了实际的上线,在交易的高峰期,能够很快地以AI坐席的这种形式去扩大外呼的规模,它整体拉新的成功率,包括磋商的准确率已经在很多场景下达到了跟人一样的水平,甚至更高。在这个场景之下,对模型能力的考察更多的是在能不能利用上下文对话很好地理解用户的问题,把握整个对话脉络的走向。
火山引擎嘉宾分享PPT
从这个角度上来讲,我们可以看到上图左部分是一个公开的测评——中文简短问答,这个问答是公认的难度非常大的测评。大家能看到不同的模型在各个测评象限下的得分,但是豆包整体的排名是在国内第一的一个位置,在全球来说是仅次于GPT的。
在[CC]中国文化这个象限下,豆包的得分是全球最高,这个测评本质上是友商公开做的。从实效性上来讲,右半部分是上个月的最新结果,在排名表现的背后其实是我们在大模型上不断地投入,证明我们整体的技术实力和后劲是非常充足的。
围绕交互:更智能的上下文对话
对话这个场景在客服行业是非常重要的一个场景,要想保证对话的效果,就要能记住更多的上下文。其实现在已经有非常多的方案通过记忆的方式让大模型理解,并去引导整个对话的走向,但这背后就有一个要求,记住的上下文越多对延迟就会有一些影响,其次就是成本的增加。
基于需要,我们专门开发了一个上下文缓存的能力,基于和豆包大模型的配合就能非常智能地记录上下文,可以根据企业的要求丢弃重复的内容,而且对于监测到的重复内容价格也会更低。
其次,对于大家关注的知识回答的准确度,以及回答范围的问题。其实现在大模型这种预训练的方式本身还是对知识的范围有一定限制的,他只能训练数据里有的内容,所以对于实时的新闻和企业独有的业务知识,它肯定是不知道的。
为了解决这个问题,首先我们开发了联网的内容插件去和大模型配合,让它能实时搜索互联网上的最新内容,包括字节系独有的内容。另外针对领域适应性和整体的问题,有了检索增强RAG的技术,将其和提示词进行结合后,就能很好地去解决这样一个问题。
火山引擎嘉宾分享PPT
在背后其实我们也有一整套围绕在大模型外围的一个知识库的方案,可以被集成到这些客服的应用型的系统里,如上图左侧是一个非常典型的怎么去做知识库检索的处理流程。
首先肯定要把这些业务数据上传,具有和飞书一样的这种多类文档的处理能力,不论您的业务知识在word、Excel还是PPT里,都可以很快地上传。第二步就是要让大模型去理解这些知识,我们用到了豆包字眼的Embedding的向量模型去对知识进行向量化。第三就是处理完的这个知识要存在一个向量的数据库里,而不是传统的数据库,这个数据库和字节系的其他应用是完全同源的,它可以在百亿级的知识片段的规模下实现毫秒级的检索,所以不论您的业务知识量有多大,我们都可以保证交互的体验。
围绕工具:更丰富的模型工具,适应不同客服场景的需求
不同的场景有不同的诉求,所以火山也针对性地有非常多的分支供大家从模型层面进行选择。
首先是多模态的大语言模型,不论您在客服的任何场景,都推荐您从豆包通用模型Pro32K这个版本开始做尝试。如果您的场景对延迟有非常高的要求,您也可以尝试通用模型lite版本,花费更低的成本获得一个更快的响应速度。在这两个型号之下,我们还有三个分支模型,首先是做企业知识库挂载非常重要的向量化模型。
第二就是Function Call模型,客服的应用和企业的业务是息息相关的,所以在服务过程中,要和业务系统有很多的交互,比如依据用户的问题去查询订单系统里用户的下单时间,去CRM系统查询用户的沟通记录等,就会涉及和业务系统的交互,为了更好地把用户的自然语言转化成这个机器系统能读懂的API调用的语言,我们专门有一个Function Call模型,去解决函数调用的语言转换的问题。
最后就是在对话过程中,其实有一些场景客服本质上没有办法给出现阶段的解决方案,这受制于产品的形态、市场的要求等,所以在这些场景下,当用户产生一些负面情绪的时候,更多我们要做的是情感的陪伴和安抚,而不是说真的能提供解决方案。在这个场景下,我们也发现有一些企业会尝试把这类场景单独拆解出来,然后用角色模型去构建一个陪伴安抚的一个客服角色。
还有一个是现在在公开测试马上就会正式发布的一个多模态的 vision Pro模型,它能够同时理解用户输入的文字和图片。以上就是针对不同的客户场景下,我们从模型这个层面上做的多样性的能力的提供。
从工具的这个多样性上,大模型落地的过程中有几个非常核心的点,第一个就是提示词,您可能需要一个工具去帮助您去构建提示词,然后去帮助您基于业务的效果智能优化这个提示词。还会涉及众多模型分支、各种温度参数的管理,其实这是需要一整套平台去做的,我们为了让大家有一站式的体验,开发了一套火山方舟平台,在这个平台上可以对模型、提示词、精调的数据有一个端到端的管理,这些能力也逐渐都被集成到我们的客服产品中,在这个工作台上可以获得非常好的一站式的体验。
除了模型本身能力之外,对于落地大家非常关心的还有三个要素。
价格,火山一直都在引领整个国内大模型调用价格的下降趋势。
性能,业内有两个通用的指标,第一个叫RPM——每分钟能接受多少请求,第二个是TPM——每分钟能够处理多少文字。豆包大模型从初始默认提供给用户的数据里,这两个指标都比行业的平均值要高几十甚至上百倍,去支撑大家有一个很稳定的业务的调用。
安全,首先从模型本身内容的安全性上,火山在训练时已经做了充分的对齐,能够去识别对人类有害的内容,然后拒绝回答这些问题,完全符合国内的法律法规的要求,不会生成不合时宜、不合规的言论。对于使用模型甚至精调模型的过程,我们也有非常多的保密机制,保证您的数据只为您所见和所用。
大模型的能力会不断地迭代,期待未来有机会和大家一起打造出有温度、更聪明的AI客服。
年会精彩回放
PLAYBACK
文稿来源 | 2024(第九届)中国数字服务产业发展年会
分享嘉宾 | 火山引擎豆包大模型产品专家 刘一
主题分享 | 豆包大模型:AI客服服务升级的关键密码
整理编排 | 如耶 蔡蔡
↓↓ 了解近期活动资讯请点击下方图片 ↓↓