短短3个月,我们在GenAI上的进展

云平台自动化团队的AI实战:从0到1探索GenAI在智能化服务中的角色
本文讲述了云平台自动化团队如何将工作重心转向智能化服务,利用AI如Embedding和LLM模型实现自动化问答、代码辅助等功能。通过实践,团队深入了解了AI的局限性和适用场景,认识到AI作为高效助手而非直接取代人类的角色。

 我们更真实地理解了GenAI能做什么和不能做什么。

d3faf85957edc7332f4bce338108995b.png

01

目标与进展

2024年我们云平台自动化团队的OKR除了继续推进运维和用户服务自动化外,也把重点切换到智能化服务上。

2023年我们通过工单标准化、自动化和自助化服务,把需要人工处理的运维和用户服务的工单量减少了70%。我们在运维和用户服务自动化上已经基本完成使命。

把工作重点切换到智能化服务上,也是希望能借助AI的能力,进一步降本增效,提升用户体验,也让团队有机会接触到最新的技术,培养新的能力。

我们从2024年初开始,从0到1,一群AI门外汉,通过持续学习和实践,已经取得令人满意的进展,规划和完成了一些产品和服务:AI问答机器人自动回复用户咨询和问题、运维工单助手通过AI为运维工程师提供参考答案、通过私有化部署的模型实现代码Copilot,以及AI应用平台工程赋能用户快速构建和运行AI应用。

在这个过程中,我们除了积累了技术,也对AI能做什么和不能做什么有了更深刻的洞见,从而可以根据其适用性,更好地规划以后的产品和服务。

02

技术实践

作为云平台自动化团队,我们的口号是“通过技术使云平台更易用”。

由于我们云平台的整体策略是赋能用户自助服务,而不是通过人来为用户提供“保姆式”的服务,这对用户的知识和技术水平也是有一定的要求的。也就是说,我们期望我们的用户已经能在水里游泳,而不是还需要我们对用户进行下水前的培训。

但一定会不少用户还没掌握游泳技术,会向我们询问很多比较基础和重复的问题。我们海量的文档对用户也不是那么友好。我们希望这类咨询和问题能用AI来先处理了。

第一个用例是,我们需要一套智能系统通过我们的知识库自动回复用户的咨询和问题。

由于我们用的是专有云,还没有像公有云那样具备GenAI的PaaS产品,我们只能尝试开源的LLM模型,部署到我们的GPU服务器上。

一开始,我们的工程师试图对通用大模型进行微调。但通过学习,发现Embedding才是这类内部知识库智能问答系统的有效方法。

Embedding的原理是把知识库的内容进行向量化,保存在向量数据库中。当用户提出问题或提示时,Embedding模型会把它转化成向量,然后通过向量相似度匹配,找出最接近的内容返回给LLM回答用户。

所谓向量化,就是把一个事物或一段内容,通过多维的数字进行表达。

比方说一个苹果,我们可以用数字表述它的形状、大小、甜度、类型、颜色等属性来描述,每个属性在向量里就是一个维度。

可以想象,对一个事物的向量描述是很多维度的数字。向量里的维度越多,对事物描述的属性越多,匹配的准确率越高。

基于这个原理,同类型的不同苹果间的向量应该是接近的。所以我们能用一个苹果作为输入找出其它苹果和与苹果有关的内容。一个橙子的向量和一个苹果肯定不一样,但会比一只鸡接近。

我们有大量的内部文档作为知识库成为Embedding的输入。当然,这里需要对内部文档的内容进行审核。Garbage In,Garbage Out,我们可以想象如果文档内容质量不高或者不更新,AI并不能解决这个问题。

一开始我们试图让智能系统直接回复用户提交的咨询工单,但发现效果很差。

我们想明白了一件事情,我们说要用好GenAI,需要提示工程(Prompt Engineering),所谓工程,就是有门槛,而且是门槛不低的事情。我们希望GenAI能提供更准确的回复,就要求提示足够具体和完整。

而用户在工单上写的内容质量良莠不齐,很多时候都是极度简化、一概而论、含糊、缺乏具体信息的内容,显然无法满足提示工程的要求。而且工单系统是第三方的,我们无法改造成对话模式让AI跟用户持续问答来澄清问题。

后来我们把设计改成,我们依然保留让AI回答这类工单的内容,但把它作为内部参考,用户不可见,仅接单的运维工程师可见,工程师可以根据用户的请求和AI的回复进行判断。如果AI的回复是满足用户请求,工程师就可以直接粘贴AI回复的内容,然后关单。否则,工程师按照原来的方法处理该工单。

同时,我们构建了AI问答机器人,并引导用户先通过它来进行咨询,不满意回复再提交工单。它的好处是有对话模式,可以与用户进行持续问答,从而提高质量不高的问题最终被准确回答的概率。

另外,我们对用户对AI回复是否满意进行了记录。这就提供了我们持续改进模型和文档内容的反馈机制。

使用Embedding的另一个好处是,我们可以随时更换模型,尝试出更适合我们的模型。

有了这个私有部署的大模型,我们还可以通过它实现代码Copilot。

我们成功在我们的在线开发环境Coder通过插件连接到这个大模型实现代码Copilot,可以通过提示、注释和文档生成代码或测试用例,或者对原代码重构。由于我们的大模型是私有部署的,整个Coder环境也是在没有互联网连接的内网中,不存在源代码泄露的风险。

(Coder提供了在线开发体验。通过与 DevContainer 集成,它提供团队一致的开发环境,无论成员使用哪种操作系统和设备。团队的程序员可以通过 Coder 用简单几步操作即可创建工作区来开始编程工作。)

当然,我认为使用代码Copilot对程序员提出了更高的要求,TA必须有能力读懂和验证生成的代码的有效性和质量,TA依然是代码交付的质量第一负责人。

03

对AI的定位和展望

通过以上实践,我们可以看出,以目前GenAI的能力,它还不能直接取代人类,但它可以是一个高效的助手,而人类依然是最终的负责人和执行者。目前我们对GenAI的引入,会把它定位在仅限内部使用的辅助工具。

但这个实践过程非常有意义,它让我们真实了解到GenAI能做什么和不能做什么,让我们对未来规划有更清晰的基础,也快速积累了知识和技术。

及时行动是第一生产力,我们用了短短不到三个月的时间,从零开始,已经有了一些成品和积累。

我们一开始有一些设想,但只有行动起来,才会发现一些设想并不成立,然后迅速调整,并意外实现其它想法。比方说,我们一开始想让AI直接回复用户的咨询工单,这个通过实践发现不可行;而代码Copilot并不是一开始的规划,但当我们用了模型以后,理解了它的适用性,发现可以这么运用起来。

不管媒体和自媒体对GenAI的能力如何吹嘘,实际用起来,你就会发现它的局限性,离取代人类,还是有距离。但目前这个领域的发展很快,谁也不知道明天、明年会发生什么变化。

我们的父母辈,很多人都经历过因为国企改革而导致的下岗潮。我们这一代人享受了很多时代红利,以后会不会不可避免地经历因为AI的发展而导致的下岗潮呢?

一方面,AI会大幅提升效率,很多工作需要的人手会大大减少;另一方面,有些人说现在要赶紧学会把AI用起来,但是使用AI的门槛也会不断减低,容易的事情人人都会做,更无法体现个人竞争力。所以在这个过程中,绝大部分人都逃不过,包括AI行业的从业人员。

以目前AI的能力,如果从事的是面向物和事的工作,由于边界清晰,可重复,容易模式化和标准化,偏理性,更容易被AI替代;如果从事的是面向人的工作,特别是侍候人的工作,偏感性,相对不容易被AI替代。

觉得文章不错,顺手点个“点赞”、“在看”或转发给朋友们吧。

0724910b521ad429edea5add74c1890a.png

相关阅读:

团队管理者应该参与编程吗?

我们实现OKR的秘密武器是什么呢?

一次成功游说的三板斧

关于作者


e9ba989e344dd3f5bbc8ad8082dec1af.jpeg

关注公众号看其它原创作品

坚持原创高质量软件交付相关文章

觉得好看,点个“点赞”、“在看”或转发给朋友们,欢迎你留言

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值