专栏名称: 共识粉碎机
寻找与共识的不同
目录
相关文章推荐
鲁中晨报  ·  反转了!确认系摆拍 ·  昨天  
山东省交通运输厅  ·  雨、雾、沙尘都要来!山东最新天气预报→ ·  昨天  
鲁中晨报  ·  今天起,淄博人洗完头可以调整一下了! ·  昨天  
鲁中晨报  ·  突发讣告!苦等80多年,她抱憾离世...... ·  2 天前  
51好读  ›  专栏  ›  共识粉碎机

EP20 非常好的LLM保险销售案例(对谈暖哇)

共识粉碎机  · 公众号  ·  · 2024-09-25 17:25

正文

关注共识粉碎机,获取历史讨论会纪要

本期讨 论会参 与者:

莫子皓老师: 互联网保险暖哇科技合伙人

主持人:

周默: 共识粉碎机,前美元对冲基金投资人,曾在腾讯与微软从事战略与投资业务


本文的部分内容也在莫子皓老师的文章中出现过,欢迎关注莫子皓老师的文章和公众号。

莫老师也特别说,离文章讨论过了一个月,行业又有了很大的变化。

戳这里:《 莫子皓:Workflow Based 企业内部大模型落地 Roadmap



1 暖哇与大模型模式


暖哇是国内最大的互联网保险公司之一

  • 暖哇由众安和红杉孵化,有保险经纪牌照。

  • 保费收入一年30+亿,公司收入一年10+亿。

  • 整体的业务形态都在线上获客,线上获客后在线上支付成交,月缴型产品较多。

  • 本期嘉宾莫子皓是暖哇科技合伙人,负责暖哇科技整体产品、投放、运营等各方面工作。

暖哇定义LLM销售为数字员工

  • 目前在LLM销售领域主要有两个概念,Sales Agent与Copilot。

  • 但在暖哇主要从事的互联网保险领域,很难有Copilot这样的中间地带,在座席的日常实践中,只有“发”与“不发”两种选择,不会存在中间修改的流程,不像写代码,存在自动补全的空间。

  • 但同时LLM在暖哇也不是Agent,因为Agent具有自动编排能力,暖哇更多将LLM融入具体的Workflow。

  • 所以暖哇将LLM销售定义为数字员工,会在销售的整体Workflow流程里直接完成一部分日常工作,并且获得业务成果,衡量效果的指标也是业务转化率。

暖哇与客户采用全外包商业模式

  • 客户向暖哇提供线索,暖哇直接交付结果,不是一个SaaS的逻辑。

  • 对于客户来说,也可以对暖哇直接考核线索转化效果,直接为客户带来收益。


2 企业微信LLM产品设计


LLM销售分工需要融入用户生命周期

  • 一般都会通过企业微信添加用户,并在企业微信里面进行加复购、服务以及整体的保险营销。

  • 在企业微信里,暖哇将用户周期分成三段,LLM也会在不同的生命周期进行不同的SOP编排。

  • 将LLM融入Workflow,也不是简单的按销售线索拆解,而应该按照生命周期,去构思一个小时后该做什么动作,只要把动作拆得足够吸,再去评估里面哪些可以依靠LLM完成,那就可以人机结合。

  • 相当于给每一个销售配一个AI的数字员工,举个例子,每一天有100分钟,原来30分钟做最难的关单的事情,70分钟做SOP或揽客等各种各样的事情,现在搭配了一个所谓的数字员工的概念,让AI大模型把原来70分钟需要做的事情都做完了,他就可以花更多时间在最难的关单上,使得他需要花在整理SOP等事情上的时间更少,这样对于销售来说,他的线索没有变、他的时间没有变,但他的单位时间产出会得到大幅提高。


生命周期第一阶段:新用户35天内

  • 第一天加进来是最热的线索,销售特别珍惜这个线索,所以第一天我们不会对他做任何动作。

  • 但从第二天开始,销售第二天、第三天、第五天、第七天做的工作很难完全达到我们规划的过程要求,因为要追事情太多所以它很容易变形。暖哇也因此通过LLM来参与第二天、第五天、第七天直到第 35 天的SOP 。

  • 举个最简单的例子,第一天加进来的新用户如果没有成交且没有完成一个语音通话来做保单解析,我们会要求坐席第二天再去激活,再给他进行服务,这个SOP的执行率过往可能只有2-30%,暖哇通过大模型,在第二天对不同的用户基于它的保单、生命周期、使用路径,自动完成这一激活的发送,用户如果回复后,会基于用户的回复做意图判断来做自动回复;

  • 或者会让用户看到他是一个正面的回应、他愿意接受这个调度,那么就给座席,让座席来做外呼;

  • 或者用户说现在没时间,就会在第三天再来给他发。所以这一个小单元,是在第二天和第四天中间去完成整个这样的一个任务。后面可能就是服务,比如营销服务等。

  • 到第35天之后,用户热度就下来了,更多的在于有一些续期、续费等,用户可能在我们私域里做了点击或者有些未支付的行为。一个企业微信的销售的私域里整能会有几千个用户,用户每天会在整个私域里面会做很多行为,比如给家人加复购、点击页面、浏览等,这些信息都会变成一个雷达或者工单给到销售,跟他说这个销售机会。但一个销售一天的时间是有限的,他可能只会筛选ROI最合适的销售去做,剩下的部分他可能就不做了。


生命周期第二阶段:35-365天

  • 暖哇会用大模型直接帮助座席,把座席觉得没有价值的任务直接做了。

  • 举个最简单的例子,如果用户在第三期没有缴费,这时会有一个任务工单给到座席,要求座席提醒用户回来缴费,过往觉得一方面这个事情比较难,另一方面解释的事情比较多。

  • 现在用大模型做了整个Workflow的SOP,直接帮座席发送,发送完后如用户回复询问多少钱或者退单等,紧接着会帮助他去做整个意图的识别和回复。


生命周期第三阶段:365天后

  • 关注线索出去的逻辑,因为一个销售,如果只有线索进来没有出去,那么一个销售服务的客户有无上限的增长,过去我们发现一个销售可能有5万或7万客户,需要几个手机不同的企业微信去服务这些客户,但他是服务不过来的,所以说最终要有线索进来、也有线索出去的这个逻辑。

  • 365 天之后,因为线索已经相对比较稳定,它的整个续保、续费也比较稳定,暖哇会把他转到一个托管,在这个托管体系里会让线索转给真人服务的门槛设得比较高,里面整体的运营活动、所有的通知全部用大模型来做,用户完成了一个支付动作之后才会再转给人来做。


信息群

发前也会有专门的筛选

  • 为了保证内容合规

    ,暖哇同时还有一个服务Agent,把控所有内容的发送,所有企业微信群发都要经过这层Agent,Agent主要做三件事。

  • 第一会看这个用户过往有没有任何负向情绪,譬如说投诉、退保,如果有就不能现在发。

  • 第二会看最近发送的频率,因为有的用户可能已经做了很多事情,不希望打扰,那么会给他做一个简单的编排,譬如说一天之内发了两条以上信息,就会把这个发送调度到后面再来发。

  • 第三是指一个很大的key point,非本行业人士可能不太了解,过往所有的私域里都会有一些群发任务,实际上给到座席销售的时候,座席都在下班时候再点。因为如果他跟用户正在聊的时候突然发个节日祝福,就很突兀,所以服务agent一个核心作用在于发消息的时候直接会把正在与用户聊天的这个人筛出来,即正在销售的这个座席不会收到这个群发任务,这样就不会打断他销售节奏。

  • 同时企业微信的整个体系不能直接群发,必须通过座席手动点击才能发送客户。所以在企业微信的后备栏里做了一个智能话术,并且是由企业微信的工作台里直接跳一个任务,任务点进来后直接到智能话术,然后坐席点击发送就可以直接发出去。


让LL

M销

售完

成闭环

  • 把事情拆解成

    一个个小闭环,一个用户状态和一个线索进来之后,我求大模型判断用户状态和判断下一步应该做什么,然后直接完成这个事情,即生成完后发给他,发完之后在最后有一个结果判断,用户回复后评估是自动在用LLM回复,还是满足一定条件后用人工来做服务,这里就是一个小的闭环。

  • 刚刚拆解的Workflow的三个阶段都是基于这个最小单元粒子来做的小闭环,核心拆三个阶段的区别是什么呢?区别在于第一个阶段我很简单就转给人,第二阶段可能需要有一些正面的回应或者识别不了我才给人,第三个阶段是必须成交一些小的单子再来给人,所以整体是把这个漏斗、基于阶段来做区分,但是整个LLM都是完成闭环。


拆解SOP数量

  • 第一阶段(T+35天)

    大概有5个SOP,刚开始进来需要做用户激活和解析,后面是整体服务的解析、理赔的解析,包含了激活、解析还有自动回复。

  • 35天后,以做的有价值的点大概30-40个,再到后面可能就更多了,可以理解为有点类似T+X的运营策略的迭代和替代。


3 企业微信LLM模型选择


用大模型做比用Bert好

  • 现阶段都是用大模型来做的,原因在于大模型解决了很多原来Bert解决不了的问题。

  • 一是成本问题,包括标注成本和建模的成本。

  • 二是Bert很难去做建模,识别一些用户的意图。举个例子,现在做的意图判断是用户说没有时间、想约再多的时间,用户可能有同类型的保险、用户对保险不信任或者用户对保险公司的品牌可能有疑虑,这一类型的意图其实用Bert是比较难做的,但这类型意图在workflow里又是比较重要的。所以基本上激活时的内容生成全是大模型的,然后中间的一段意图判断即回复等都是用大模型来做的,现在Bert用的比较少。

不同SOP会分多个大模型来做

  • 在做意图判断时候,泛化有价值,在续期续费的节点、激活的节点它的意图判断可能会有类似,这里finetuning的是同一个。

  • 在做内容生成时候,在prompt engineering,在few shots里放很多案例,所以这里不同的模型需要不同的单点表现,更多跟样本相关性比较大。所以都是单独地做单点的finetuning。

  • 不同的模型有不同的北极星指标,衡量的并不是产品做出来怎么样,而是衡量这一个点的模型能力,通过数据迭代、数据闭环能够让模型能力变得越来越强,这个模型能力只在这一个点上有体现。


不同大模型

的原因多数从测

试成本考虑

  • 自己搭了一套线上数据回流,做完线上数据回流后,运营同学来做标注,标注完后,用大模型来做finetuning,做prompt engineering。

  • 然后有大模型表现的批测和prompt的版本管理和批测,批测的意思是因为大模型有幻觉问题和大模型内容生成没有一个很好的判断标准的问题,所以会用同一套prompt、同一套输入,让不同版本的prompt和模型跑100次,然后让运营来看这100次里哪一个做得更好。

  • 在测试和判断效果的时候,如果只修改一个地方,但还是要做全面的回归测试,就很麻烦,现在通过不同的大模型就可以降低成本。

  • 同时在一个单点的一个内容生成的表现,不希望因为它的finetuning导致别的地方受到影响。

  • 所以对于单点,可以理解为是拼积木,现在在每一个点里面做乐高,但不希望做的这个形状的乐高会对原来别的形状乐高有影响。

4 行业Knowhow以及横向拓展


Knowhow对提高模型准确率非常关键

  • 暖哇定义了 13 -14 个简单的保险领域的意图,然后把用户的语料怼进去,让所有的大模型千问、GPT、星火、质朴等去做识别,准确率在65%。

  • 不做任何的prompt engineering、不做任何的微调,在这里其实有一个巨大的差异,整体如果做了微调,可以快速提高到80%,暖哇现在大概是88%-90%。

  • 所以肯定是车险做一套、健康险做一套、卖贷款做一套,但这个成本又没有想象那么高,核心是domain的know how大家到底愿不愿意投入,因为搭一个SCRM、一个几千人的团队,也非常麻烦。

数据标注也非常依赖Knowhow

  • 最大的成本在数据标注上,最大的难点在于过去这种领域知识一定会产生所谓的意图混淆,或者说不同的人对一个东西的判断不一样,就是我觉得这个话术好、他觉得不好。

  • 这个时候要运营去标注,暖哇的标注也是全职的运营同学在主导,不同的人标同样的数据结果会有巨大的差异。

  • 之前解决这个问题的方式就是只让一个人来做所有这个单点的标注,但一个人能标注数据可能只有这么多,而且他本身也有运营的工作,所以这里面实际在产能上会有一个比较大的影响。

  • 现在会用不同的大模型先去做一轮预标注,预标注有冲突的再去让人做介入。

  • 另外一个点是不同的人,他是双盲的,不同的人标的又不一样,再来去做一个介入,更多地通过一些technical的手段使得这个标注成本越来越低。

  • 数据标注很难,之前很多时间都花在数据准备上,还有Workflow SOP的编排上。同时没有什么东西可以学,大家都是不太成熟的方法论,现在的方法也是自己摸索出来的,摸索成本也花了很多。

数据标注怎么把模型从65分提高到80分以上

  • 譬如说让大模型推动用户续费,怎么标注,以及怎么改善?因为我们不涉及多模态,所以我们的标注实际核心是优化模型的三个能力。

  • 第一个能力是生成能力,生成能力是用户没有跟你说话,你主动的跟用户说话,生成出来的内容文案你会有好不好的标准。将T+X的运营策略说得更多样一点,或者对转化更帮助更高一点。

  • 第二个模型能力是用户回复完后的意图识别,或者说用户整段对话的意图判断和意图识别,以及这里卡点的判断,都统一把它分类为分类问题。

  • 第三类模型能力在于分类完后或者说用户回复完后的回复问题,前置输入不仅仅单纯是用户的状态和用户的画像,还有用户之前跟你说话的问题,他是期待你做回复的。

  • 对这三个东西的标注都不一样,第一个是生成的好不好,好是怎么样;第二个是分类的准不准,第三个是回应的得对不对。

  • 这个好不好的概念是对大模型生成的语料做标注。如果不对大模型做的语料做标注,你没法做SFT。说白了现在大模型做的是70分,做了100次,把这100次里面做得好的挑出来,做得不好的告诉它为什么不好,他应该怎么样变好。

  • 通过SFT它就能够变成 65分、70分、75分、80分,你是让他把更多的他原本不具备的知识通过 SFT 的方式压缩给他,那么它就能够更趋近你标注的人的能力。标注的人90分,大模型60分,通过标注来把我的领域知识压给他。

对数据标注的人和管理的要求也很高

  • 暖哇目前现在都是运营和产品的同学在领导标注业务。本很高,但是如果成本很低的话,做完就没什么壁垒。

  • 标注的需求也与短视频等标注需求完全不一样,视频的标注,更多的在于它是什么内容或者是什么标签,最终用于搜广推。但LLM标注主要用于生成或者分类,标注用户对保险意愿强不强、用户是否对价格有疑虑,是完全不一样的领域和要求。

  • 同时,也需要积累大量的数据,要做整体的会话存档,最好过往也对此有标注积累。

  • 标注的管理流程也非常互联网。上线、上线完后有数据、有数据后做SFT、SFT完后做不同版本SFT 出来模型的批测表现和衡量,最终再做一个迭代。期望的迭代开发的版本像我互联网的动态发布,即可以不用开发去调数据,promp和模型上线后,能够实时看到数据回流,实时得看到做标注,标注完后直接可以改prompt、直SFT,上线完后立马可以看到结果。就等于把整个workflow的闭环压缩到1-2天。整体有点像动态发布一样,就等于持续发布,现在其实我们还是按周的,其实可以压到1-2天。

拓展到其他险种难度还好,但拓展到非保险有难度







请到「今天看啥」查看全文