AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


CRM+AI 的思考与实践
发布日期:2024-05-09 15:53:21 浏览次数: 1851


本文3133字,预计7分钟读完。

23年初,AIGC概念开始席卷全球,同年Q2季度,我司启动【AI CRM】项目,旨在探索AI在CRM领域中的潜在应用场景。

笔者有幸能成为其中一员,经过了1年的探索与实践,落地了几款AI应用。

计划通过这个系列的文章,来梳理自己的些许思考,并跟大家分享一些有趣的落地案例。

前言

对于国内SaaS厂商而言,GPT-3.5的面世是AI技术的一个转折点,在此之前SaaS厂商围绕AI领域提供的解决方案,主要是通过传统的机器学习+规则引擎的方式组合成技术底座,期间也取得了一定的成果,但在处理复杂的自然语言(NLP)任务时仍存在一定的局限性。

随着GPT-3.5、BERT等基于Transformer架构预训练语言模型的出现,极大地提升了自然语言处理任务的性能,为软件厂商提供了更加强大的AI能力支持。

23年3月,GPT-4.0发布后,国内的头部科技企业陆续推出了自家的大语言模型(以下统称为LLM),如:百度的文心大模型、科大讯飞的星火大模型、阿里的通义大模型等。

▲陆续落地的大语言模型

作为通用型SaaS CRM厂商,从边际效益角度考虑,入局中游的算法模型产业并不现实,更多应该以国内通用的LLM为基础,聚焦在AI场景应用的探索工作中。

那么,在AIGC的时代,LLM之于ToB软件而言,带来了怎样的改变?
笔者的答案是:交互
交互的改变,背后源于LLM在自然语言处理能力上的显著提升,使得AI可以尝试理解用户的真实意图
以往在CRM系统中,用户执行一个操作(如:搭建报表、写日报、跟进总结等),先要进入到对应的应用模块,并在模块里进行各种点击交互,直至最终进入到落地页(如:报表配置页、日报填写页),再执行一系列操作(如:填写、确认、提交)才可完成业务。
利用LLM的能力,可以尝试把多个页面以及繁琐操作进行简化,比方说:
把产品分为左右两个部分,左边是功能应用页面,右边是一个智能助手。用户可以通过Chat(对话命令)的方式,也就是打字/语音描述需求,完成一个完整的业务操作。

▲智能助手的框架

但如果把LLM之于CRM理解为一个“输入框”,让所有的业务起始于用户的描述,这并不是一个很好的方案。
原因引用白鸦老师有关「AI如何改变产品体验」分享中的一番话:

▲白鸦老师的分享

笔者理解:在ToB软件中,场景是复杂的,有时候用户也不知道该如何描述他们的需求。产品应该利用AI的能力在理解用户的真实意图后,给用户提供选择题(命令)而非填空题。

接下来,笔者以最近参与的一款AI应用「报表智能分析」为案例,分享我的浅薄理解,旨在抛砖引玉。

想法的诞生

这是报表产品一天的活跃轨迹图:

▲智能报表日活跃趋势
可以看出一天中,产品的使用高峰期在17-18点这个时间段,我们不妨问一下AI原因。

▲AI的回答

在这个场景下,用户的使用意图是明确的:在下班前,对当天工作进行数据分析与总结,从而调整次日的工作策略
但目前从打开报表到经过一系列筛选和钻取操作获取初步分析结果,用户需频繁切换多个不同页面,操作过程略显繁琐。
针对这个场景,利用AI的能力,能否浓缩到一个页面中完成呢?比方说:
1点击【总结】得出结果
2、基于结果,提供钻取分析提问

3、面向存在的问题,提供针对性的解决方案

▲侧边栏承接数据总结分析业务

这样,用户就可以在一个页面中通过几次简单的点击,来完成数据分析的完整链路闭环。
技术可以实现吗?
有了初步的想法后,接下来就要考虑如何把想法落地。然而,在落地过程中,历经了不少曲折与摸索。

比方说:数据总结区别于客户跟进总结:

  • 「客户跟进总结」通常以纯文本形式存在,只要在Promot中定义好角色、背景、目标后,把总结内容套进去,AI即可按照Prompt中预设的要求生成总结。
  • 「数据总结」通常以结构化的形式存在,如果转化为纯文本进行描述,会导致信息冗余,并且极大地消耗token。
因此一开始,团队便排除了“调用LLM文本生成接口”这个方案,另辟途径。

庆幸的是,当时合作的LLM刚好上架了ChatFile插件,支持基于doc、pdf的格式传参,这解决了我们的痛点。

方案大概是:把看板的数据以表格的形式生成一份doc,然后利用ChatFile的能力,让LLM解析doc后再进行总结分析。

▲LLM支持ChatFile插件

刚开始,流程顺利跑通了,但问题又接踵而来,由于插件服务还处于初期阶段,并不支持流式输出,导致每次从上传、解析到总结,平均耗时30秒以上。

▲漫长的30秒
让一个用户在看板页面停留30秒等待结果的生成,是一个糟糕的体验
我们只能重新寻找替代方案,比如:把看板数据转化为纯文字描述的报告,对报告进行分割后存储在向量数据库。基于用户的提问,从向量数据库中检索出最相关的片段,再组装Prompt,调用LLM文本生成接口(后面出于其他因素考虑,也没有采用此方案)。
通过不断地尝试与探索,兜兜转转还是回到起点。把看板的数据经过业务侧的算法模型清洗一遍后,转化为Markdown的格式组装Promot调用LLM。这个方案在确保token消耗可控的前提下,极大地缩短总结时长,平均耗时5秒以内。

意味着技术层面已具备实现的可能性,也算是成功迈出了至关重要的第一步。

选择题而非填空题

对数据看板进行AI总结后,仅仅完成了第一步,解决了用户what的需求。接下来,就要探索有关when、who、why层面的需求。

在报表分析这个场景,简单来说,就是「钻取分析」比方说:
  • when:客户联系跟进趋势如何,哪个时间段是峰值?

  • who:哪些员工业绩数据下滑了?
  • why:业绩数据为什么下滑了?

尽管AIGC时代中,“输入框”的作用很大,能够替代许多传统的点击和页面切换操作,但仅仅依赖打字来描述所有问题并不智能。因为用户仍需投入成本来梳理需求并打字描述问题,这在一定程度上降低了效率与便捷性。

根据LLM返回的初步分析结果,我们基于用户角色、使用轨迹、数据偏好以及看板配置等多维数据进行大数据分析与建模,提炼出潜在的钻取分析提问。在可视化层面上,呈现给用户是一个又一个的选项(命令)。 

▲通过潜在提问帮助用户进行钻取分析

后续的使用过程中,系统会基于用户选择提问类型的频率反馈给权重算法模型,再通过动态调参的方式,持续优化推荐效果。

但并不意味要抛弃输入框,在方案中仍然要保留“输入框”功能来解决用户的个性化问题

应用连接,形成闭环

最后,就是解决how的问题,比方说:作为一名销售管理者,当发现员工数据发生下滑时,该怎么做呢?

基于规则引擎,根据钻取分析的结果,支持连接不同的业务应用来提供针对性的解决方案:

  • 面向数据下滑的员工,创建一个会话讨论;

  • 面向业绩压力大的员工,适当调整销售目标;

  • 面向客户跟进不积极的员工,创建一个客户跟进任务;

▲连接业务应用,形成闭环

从而实现了在1个页面中完成以往需要在4~5个页面以及一系列繁琐操作才能完成的事情。

以下是笔者录制的一个演示视频:

看到这里,也许有伙伴会疑问,接入LLM,是否意味着“后续ToB 软件的产品交互都要由GUI(图形用户界面)统一替换为LUI(语言用户界面)?

但笔者认为,两者之间并非为互相替代的关系,应该是相辅相成,互相融合。毕竟用户看重的是产品能否高效地解决他们的问题,并非产品具体引用怎样的交互。

结语

最后,跟大家分享笔者的两个观点:

  • 近两年,AI的发展不断刷新我们的认知,但在ToB软件层面上,厂商仍需要保持克制,适当控制好LLM的含量。目前来看LLM对于业务的逻辑理解还是不够,并非所有的功能模块都要上AI。作为产品经理,要以“给用户交付的方案是有用、易用、好用”为前提,客观评估功能模块接入AI的实质性价值。

  • AI场景化应用,本质上是AI+场景化应用,大部分软件厂商在AI大模型的选择上,倾向于与LLM厂商合作。意味着,产品的核心竞争力在于「场景化应用」上,这要求产品经理对不同行业用户的业务场景,有足够深刻的理解,能从中挖掘对应的需求;其次,提高「数据思维」,尝试通过厂商沉淀的数据基础来弥补通用化AI模型无法覆盖的能力边界,“AI+大数据”也许是一条不错的路子

最后的最后,跟各位分享一下笔者最近阅读的一本书,杜雨老师、张孜铭老师的《AIGC:智能创作时代》,适合刚开始接触AIGC的同学(这不是一条广告)。
▲分享一本书

以上是笔者近阶段个人的学习与思考,希望能帮到你。







53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询