一、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的自由度更高了。