一、LLM 改变 AI 客服构建知识的过程

LLM现有对客服质量提高主要体现在构建知识上

  • 体现AI客服构建差异主要有几个点:构建的速度和质量,以及AI将答案吐出去的效果和带来的用户体验的提升。
  • **从效果来看,最重要的是工单解决率。**解决率的定义一般是AI回复最后一轮后,用户间隔一段时间不再发文就可视作为工单已解决。在不同行业和客户意图下,解决率的差异非常大。
  • 如3C卖家产品的排故相比游戏攻略咨询的解答难度就高很多,游戏攻略咨询可以轻松达到90%+的解决率,但3C排故解决率做到70%就很难。以3C类的Trouble Shooting为例,目前如果是传统的FAQ Bot,解决率能够达到70%-80%。这是一个比较高的解决率,达成有很多前置关键因素和条件,抛开算法效果优化等,最关键的是FAQ的构建质量。
  • LLM Bot可以做到在70-80%解决率情况下,比FAQ Bot花费更少的构建精力。在知识更新上,比FAQ Bot更加容易。

LLM可以提高知识构建的速度和质量

  • 传统的AI客服需要花费大量的人力进行业务梳理和交付,需要逐条构建出QA List。而大模型本质上是一个生成模型,只要提供合适的语料和设计出COT(Chain of Thought),就能快速地构建知识。
  • 对于大模型来说,输入来源可能是用户历史积攒的语料、用户网站的帮助中心,甚至之前客服的沟通记录,借助大模型可以快速将知识库拉到不错的基线水平。然后基于这个基线水平,再往上做精做细,从而提升知识的质量。
  • 达到相同的解决率,基于大模型的构建ROI会比传统AI客服高很多。例如,如果都需要达到70%的解决率,之前的方案需要花费很长时间梳理和构建知识,需要设计一套Dialog Flow模板配置,此类的模板可能非常复杂。现在基于大模型方便很多,可以用几百条语料做到过去几千上万条语料的效果。
  • LLM可以加速FAQ的构建过程,但目前尚不能实现全部流程的自动化,需要行业的专业客服人员介入一起构建。如果客户对回答质量要求非常高,专业客服必须要介入构建的过程。

在大促和上新快的场景应用大模型构建尤其方便

  • 传统的AI客服构建方法提供知识库给商家,商家按照知识库模板,商品粒度加上每个商品下面挂FAQ的方式构建结构化知识库。例如,一万个商品乘以每个商品对应的上百FAQ,FAQ的整体数量就会到百万级,整体量级太大造成非常难维护。在每次上新和活动期间,也都需要人工去动态配置。
  • LLM将传统非结构化知识变成结构化知识的过程跳过,可以直接基于非结构化知识进行构建。可以通过更原始的生产资料进行构建,例如Excel文档或者DOC文档。
  • 以Excel为例,不同商家和供应商虽然都是Excel,但是表格中每个cell的粒度和内容都不同。行业属性,比如数码行业和服装行业,表格Schema格式不同。传统方法是将Excel转换为FAQ工作,现在可以通过LLM直接消化Excel文件,理解不同表格中的内容的含义以及每个cell的内容,然后就可以通过大模型进行商品信息问答。相当于商家上传Excel后直接基于Excel进行对话,这是工作上的极大简化。
  • **对于很多电商客户来说,运营的时效性要求很高,尤其是大促的时候。**不同电商平台的大促活动相关信息更新频繁,大促期间商品的卖法也会有变化,客户很难及时更新传统的知识库,这已经成为不少商户客服运营时候的瓶颈。LLM的出现可以节省人员和时间,在大促期间可以使知识库的更新更加灵活。

在尝试根据图片来构建,但还无法达到商用效果

  • 现在也有一些尝试使用大模型将图片作为输入直接构建问答,依托商品的规格图和说明书PDF等。
  • 这些图片和PDF没有必要翻译成文字,再翻译成FAQ提供给机器人。LLM模型能够在这个领域实现,可以直接通过看图说话。
  • 这里的商业价值非常明确,但从实际效果来看,测试过许多开源模型,目前效果仍然不能达到商用,需要继续打磨。

二、LLM 客服的其他优势

LLM客服在语言、情绪帮助很大

  • 出海场景上,很多客户需要提供多语言支持,同时需要提供8-9种语言的情况非常常见,LLM天生具备多语言转换能力。在传统的FAQ Bot上,针对不同语言、不同国家都需要重复配置,LLM可以只需配置一次。
  • 特别对于SMB客户,成本不允许其在海外搭建客服中心,对于SMB出海客户的帮助是非常大的。
  • 在不同场景意图下,解决情绪相关的问题也有一定的价值价值,例如在客户投诉意图下,情绪安抚就非常重要。从效果上来看,LLM的效果远远超过过去的NLP情绪识别,在回复上也更加贴合场景。
  • 另外,当LLM识别出用户情绪变得越来越差时候,仍可将其转移到人工客服作为兜底的办法,进一步降低业务风险。

准确性与LLM的关联不大

  • LLM的方案仍然是进行知识召回,Ranking排序,然后提炼答案。这套体系在FAQ Bot和LLM Bot上差别不大,仍然是传统排序算法。
  • 基于这套方法论后,最终答案是否出现在Top5或者Top10,称之为最终答案的hit rate,这体现了回答的准确性。LLM的工作主要体现在上游的构建内容,和下游的提炼总结、互动。
  • 归根结底,准确性取决于知识库内的知识准不准,准确性的前提是标准答案存在。

LLM客服更容易获得更高的客户满意度

  • 在关注ROI之外,也需要关注客户满意度指标,客户满意度很难直接用财务体系去换算。
  • 例如LLM客服可以更加人性化,在沟通时候让客户觉得更加舒服,增加了复购,满意度本身的价值比较难量化。
  • 在售前环节,LLM也可以提高转化率,也需要从GMV视角去折算成本。

三、LLM 客服在 Agent 上的探索

LLM客服的Task Bot需要用到Agent

  • AI客服分为FAQ Bot和Task Bot,需要用到Agent,目的是解决用户业务查询和办理的需求。
  • 以Trouble Shooting为例,如果排故排不了,需要补单退货,这时需要用户告知AI订单号,才能继续使用接口识别用户进行处理
  • 许多场景用户可能只能拍一张小票,实际订单号在小票里面,需要通过多模态模型验证订单号,例如现在应用GPT4就可以识别订单号了,就可以把整个流程走完。
  • 因此在Task Agent形态里面,不光Agent非常重要,多模态也非常重要。对于AI客服公司来说,不会去挑战自研多模态这类这么困难的场景,更多是依赖目前领先的商业模型。

Task Bot仍然面临很多技术难点

  • 幻觉在FAQ Bot和Task Bot中都存在,在检索问题和提问问题时候,存在问题未被覆盖时模型开始瞎编的情况,这是所有LLM Bot都会面临的长期挑战,但随着模型迭代,目前看到已经得到了很大幅度的优化。
  • 在业务中,例如售后问题上,需要收集大量信息,去整合信息,并调用大量系统协同完成。以退款意图为例,,需要收集客户信息,包括订单、物流凭证单号等。同时,还需要处理这些单子并进行判责,判断是消费者还是商家的问题。内部还需要串联一系列系统,调用商家后台信息和物流信息,甚至还需要商家和消费者双方的历史信用、交易记录。在判责完成后,可能还涉及打款和结算。
  • 另外,Agent的目的是提高整体的自动化率水平。目前已经有客户上线Task Bot了**(例如安克创新上线了Shulex Task Bot)**,在过程中需要通过邮件来询问用户的订单号和售后地址,中间可能还需要手机验证,每个环节都可能造成流程的中断。这方面的创业软件公司需要摸清楚每个场景下的所有流程,还需要与客户进行甲乙方联调,才能做到好的效果。

四、将 LLM 应用在电销上难度更大

电销有很多AI实践,但LLM替换比例仍然比较低

  • 一个完整的销售链路包括获取客户线索、触达联系客户、客户跟进管理。其中联系客户的环节已经有很多AI用例了。AI电销会用AI机器人联系客户,搜集客户意愿以及其他细粒度信息,然后过滤出意向较高的客户名单交给负责增长的销售进行二次触达。
  • 例如探迹在17年就进入这个领域,经历过好几代技术路线迭代,最初采用规则+机器学习的方式。到18、19年,逐渐替换成以预训练+下游finetune的范式。在LLM出现之后,也正在用LLM将某些环节进行替换。
  • 但总体来看,电销应用LLM的难度比Chat Bot难度更大,替换比例也更低。

LLM替换的难点主要在延迟

  • 延迟对于电销来说,影响最为直接。时间一长就会使得用户产生抵触情绪。而通话的效果又会直接关联到客户中间是否会直接挂断,以及能否搜集客户的有效信息。结合销售线索的利用情况,又会直接关联到ROI。
  • AI客服的延迟有一个经验范围,在900ms-1200ms之内进行回答会比较合适,太快会让客户感觉在抢话,太慢则会让客户觉得回答迟缓很不像真人。
  • 从技术流程上需要ASR(语音转译成文本)→对话模型反馈→TTS。从性能角度来看,TTS已经做了很多优化了,实时TTS不是时间性能瓶颈。甚至过去多数场景是通过FAQ的方式调出提前录制好的声音,节约时间,不需要实时TTS。
  • 那扣掉传输、ASR和TTS的时间,留给模型反馈的时间可能大概在200ms内。这对现在的LLM模型推理都还很困难很有挑战,尝试了各个商用模型都还做不到。
  • 至于Agent也非常适合电销场景,但Agent更加复杂,会增加更多prompt内容和更多的调用LLM次数,导致模型处理的反馈时间更长。
  • 国内AI电销因为各种政策问题,是不能使用OpenAI系列产品的。

LLM在通知类的场景可以承担语音客服

  • 目前在需要互动的电销和客服场景下都还有延迟困难。
  • 但在一些通知类型场景,或客户回访、催收等,涉及的信息密度不高,不需要频繁互动,LLM场景已经可以落地了。
  • 为了降低延迟,也会尝试在可能落地的场景中将Prompt设计得更短,以满足延迟要求。

LLM电销如果技术成熟想象力会非常大

  • 刚刚主要介绍的都是初次触达客户的环节,所涉及的信息不会复杂,在应用的时候AI客服也会避重就轻,一旦遇到难度更大的问题时,会邀请资深顾问联系客户,约定下次联络的时间,将复杂情况留给真人电销来处理。这也是LLM目前最有希望落地的场景。
  • 后续还有更大的场景可以替代,**长期目标应该是替换90%的电销工作。在电销过程中,LLM可以作为引导者,通过沟通了客户的需求,推荐产品甚至产品组合,最后给出综合报价。**LLM在应用说服客户的时候,也可以结合客户目前的意愿状态,针对性举例过往成功案例。总的来说,是对话逻辑更像真人的销售顾问,能覆盖更复杂的对话问题。
  • 但这个过程还需要Agent能力的长远发展,以及对延迟的要求也会更高。每当延迟进步一点,Agent推理能力进步一点,就可能解锁新的电销能力。
  • 销售流程中的合同环节很难被LLM替代。合同环节绝对不能出错,无论LLM进化得多智能,最终可能都还需要人来把关。但在合同签订之前,所有的环节都有一定的容错能力,LLM都有替代的机会。但整体来看,电销的容错率要求都比客服要高很多,错误积少成多甚至会影响到最后的合同签订环节,客户甚至会认为AI电销某些前后环节有矛盾,最后给人不够专业的印象。

AI电销不能脱离呼叫中心软件

  • 呼叫中心软件的功能很多,不仅包括对话的支持,还有线路管理、预先录制的话题管理和质检等功能,以及工单分配以及AI转人工等。AI在功能层面无法等同于呼叫中心,还是属于呼叫中心的一部分。
  • 呼叫中心软件的供应商有渠道优势,也有语料优势,但缺少技术理解和场景理解。创业公司在做客户案例的时候都需要做很多共创和联调,可以在熟悉的行业里面深度覆盖。
  • 更多的可能还是双方配合。从海外案例来看,包括Five9、NICE、Zoom等也都投资并购或者深度合作了适合的创业公司。

除了电销,LLM更容易应用到获客和分析上

  • 找客户上就很结合LLM。例如探迹的底层就有全国ToB的企业知识图谱,用户其实很难跟复杂庞大的底层图谱进行有效直接的交互,用户需要学习理解图谱里庞大丰富的价值维度,构建复杂筛选条件来找客户。现在通过LLM,可以为两者架起一条以自然语言交互的桥梁。用户用自然语言和对话把用户画像构建起来,通过这种方式进行自动潜在用户筛选。
  • 在海外,也看到了不少创业公司和上市企业,已经通过LLM来完成质检等分析环节,以及将LLM当成实时提词器来使用。

五、交付缩短同时还可以更加智慧

客服交互包括行业模版落地、知识构建、意图挂靠等

  • 不同行业的行业模板会有区别,早先一般是与头部标杆客户一起以SLG的方式打磨出来的,成为标准化方案后再推广到其他行业客户。
  • 在确立客户的行业方向后,会有基础的意图模板。在构建知识时,输出会自动挂靠到一级意图模板。
  • 业务同学会跟进看知识构建是否有问题,是否挂在正确的分类体系下,然后进行下一步校验。
  • **例如Shulex在实施时会通过真实的对话记录训练集构建知识,然后通过验证集尝试回复真实数据。**在真实数据回复完成后,业务同学会进来以行业眼光判断对错。
  • 通过了上一轮验证后,会继续在意图下分部门、品类逐步上线。如果中间出现了问题,那就明确问题来源,继续迭代知识构建,最后达到客户需要的上限标准。
  • 在大模型之前,走完一套流程需要半个月到一个月的时间,有大模型后时间可以压缩到几天时间。

减少对客户经验沉淀的依赖,将很多人的智慧提取成大模型的智慧

  • 很多大公司客服做得好是因为有长期的培训和实践,得到了知识+经验的组合。但也有很多客户的经验是靠口口相传,甚至不同的客服小组有内部沉淀的经验文档但不会跨组分享。
  • 对于经验沉淀较少的客户,过去的AI客服搭建的时候都需要花很多时间去沟通,梳理成合适的FAQ。但现在对于LLM客服可以通过对话记录去提取经验,而不再仅依靠经验文档。
  • 以及在很多的场景,例如退款场景,客服的规则性文档只会讲什么时候不能退款,什么情况是用户的责任而不是商家的责任。但对用户不买账的时候,如何劝服客户却很少有相应的经验规则。这些经验虽然在沉淀的文档中没有,但在对话的历史记录中有案例,那LLM就有机会把很多人的智慧提取成大模型的智慧。
  • 但从历史对话训练上来看,仍然很有挑战性。这是因为客服对话中有大量的重复数据,很多是基于客服的对话模版套用的,如果直接进行训练模型其训练效率就很低。在拿不到一手数据的情况下,如果要基于二手数据去训练,去提取人的经验,不光是销售经验,还是服务经验,形成一个大模型可用的知识库,都很具有挑战性。

六、模型选择

Turbo在成本上有明显变化,同时也没有看到质量和稳定性下降,延迟略有提升

  • 明显感到Turbo的成本下降,过去GPT的单条回复成本很贵,甚至超过了部分客户的人工客服成本,成本下调后明显客户群受众变大了。
  • 一般在与客户沟通的时候,都会帮客户算经济账,例如会首先看下他们一年的客服成本是多少。然后如果应用了AI方案,解决率能到多少,能节约多少成本。或者如果明年客户的用量翻翻,能不能在不增加人力的情况下服务弹性的需求,现在更多的客户也能算得过来了。
  • 效果层面略有提升,质量和稳定性没有下降,Function的识别准确性略有提升,延迟也略有优化。
  • 除了成本和效果,另一个关键变化是3.5 Return Type的调整,过去返回经常不是一个严谨的Json格式,需要做数据清洗很多打补丁的工作,现在新版本出来后全部都解决了,对开发者非常友好。

模型选择可以结合商用模型和自研模型

  • 在意图识别环节,如果一开始积累的数据不够,先用通用大模型分类,数据多了之后然后用小型的大模型进行意图的识别。
  • AI Bot答案吐出来后续处理有几个环节,包括意图的识别、问题的总结、问题的改写、Embeding、召回、合并、排序、知识答案的提炼。在这个过程中,开源的方案和自研大模型是一个平衡使用过程。把最后有挑战的Agent交给商业大模型完成,剩下的一些环节去积累数据逐渐由自研大模型来完成。
  • 在业务跑POC的时候,经常会先用GPT4快速跑通Demo和POC,如果POC验证成立,再投入资源到自研模型中,这样也更节省时间,避免无效投资。

Agent只能适用OpenAI,但分析场景可以用到Claude

  • 需要用到Agent的场景,目前只有OpenAI很好的在原生层面支持Function Call,没法选择。
  • 在分析场景,Claude可以做到200K,是目前Context Window最长的,而且知识性问答也不错,可以使用Claude。
  • Gemini现在听到的客户Use Case还比较少,可能在多模态上会有场景。

七、客户眼中的 LLM 客服与落地仍然有预期差

LLM在构建知识的过程中还无法全知全能

  • 很多客户对大模型的效果预期是高估的。比如有客户需要做自动化的提炼,会提供大量培训资料、产品文档、CAD 文档、PDF资料、图片等。希望通过LLM全自动构建FAQ,但实际上是没法这样实现的,还需要人工配合,是一个Human in Loop的过程。
  • 评论分析里面涉及大量的通用任务,比如分类、标签体系、情感识别、做摘要等等。这些任务一开始用大模型去做ROI不一定高,需要很多次交互才能完成,可能先进行初步的处理,再输入大模型ROI才会越来越高。

客户对LLM的容忍度也比传统AI客服要低

  • 以前FAQ是运营自己配置的,如果答案错了要不然就是FAQ配置错了,要不然就是模型识别错误,很容易定位原因。
  • 现在应用大模型的话,客服很难讲是识别错误、配置错误还是模型能力错误区分,就会笼统的认为是模型问题,反馈定位的效果会降低。
  • 同时因为很多沟通语法是Pre Train的,不易实时更改,在客户体验上更像一个黑盒。

未来对LLM客服的评价应该有一套新的标准

  • 过去的主要评价标准是意图覆盖率、识别是否准确,归纳到最终指标是解决率。
  • LLM客服的标准应该夹在人类客服和传统AI客服质检,更多考核其服务态度怎么样,是否有给客户过度承诺。
  • 弱化对于机器的标准,增强对于人的标准,因为LLM的自由度更高了。

关联文章:medical-beauty-aigc-agent