AI 日报

如何让生成式AI帮助技术团队的每个人发挥价值?

  • By 51ITO
  • Dec 21, 2023 - 2 min read



本文整理自腾讯CSIG技术总监黄闻欣在【WOT2023·深圳站】大会上的主题分享,更多精彩内容及现场PPT,请关注51CTO技术栈公众号,发消息【WOT2023PPT深圳】即可直接领取。

嘉宾 | 黄闻欣

编辑 | 云昭

出品 | 51CTO技术栈(微信号:blog51cto)

研发团队管理是一门常讲常新的老话题。互联网高速发展时期,各大企业的团队规模处于扩张阶段,“996”开始成为了一个热词,管理者更多会去讨论如何去设定愿景,如何创新;疫情后,在降本增效的语境下,团队管理又开始从强调创新,转变为强调“流程和执行”、“时间和成本”。

但问题就在于,当强调“流程”和“执行”的时候,团队成员会慢慢沦为工作上的“螺丝钉”、“工具人”,这并不是管理者所希望的。

团队成员综合能力参差不齐是事实,各有特长也是事实,追求人人都能"独当一面"也不现实。那么,如何让团队中每一位成员发挥其独有的价值呢?

日前,在51CTO主办的WOT全球技术创新大会上,腾讯CSIG技术总监黄闻欣带来了主题演讲《AI武装技术团队:从挑战到突破》,围绕如何用生成式AI武装团队的诸多挑战,详细而生动地介绍了作为一名技术管理者,如何让前沿技术帮助每一位团队成员一步步突破自我,发挥自身独特的价值。

本文将摘选其中精彩内容,统一整理,希望为诸君带来启发。

一、发心:让生成式AI帮助团队每个人发挥价值

2023年,在一次将近4个小时的公司内部分享中,前辈的一句话让作为管理者的我,找回了最初加入腾讯的初心——小团队里面可以让每一个人都发挥最大的价值。

为什么这么说?我加入腾讯某种程度上也是出于这个原因,我希望我们团队每一个人都能发挥价值,而不仅仅是螺丝钉和工具人。但当我制定流程的时候,我的发心就把他们当成了工具人。

然而,流程又是必须的。我们内部的团队非常大,成员的能力也参差不齐,如果没有流程去管控,就会产生严重的问题。产品经理、交互设计、UI设计、测试等等许多角色的各种沟通配合,肯定都需要有对应的流程,划清边界。

它不像精英团队,精英团队中大家的能力都非常综合,不需要太多工作,大家只要一配合,事情就能做成,而且也不需要太多人。

这种上规模的能力分层架构的团队的能力、成本问题又该如何去解决呢?

今年3月,OpenAI发布了GPT-4,那个发布会让我焦虑的同时想到了一个命题:怎么让生成式AI,去帮助这种分层分工的团队去发挥每个人的个人价值,这也正是我近三、四个月在探索和实践的事情。

二、探索过程中的三个障碍

下面分享在探索实践过程中遇到的三个障碍:认知、数据、习惯。

1.认知:经验是突破认知的第一障碍

大部分的中层、基层干部,都有非常多的成功经验。而成功的经验往往会成为让自己接受AI的很大的瓶颈。

比如,通常我们认为,需要调整我们的组织架构去响应业务模型,但却很少会去想这样一个问题:转成一个AI赋能的团队,我们的组织架构要怎么去配合?

图片图片

很多管理岗并没有去思考这个问题,因为大家觉得AI也许就是一个锦上添花的东西,这也是为什么每一次兴奋过后,大部分AI动作都会归于平静。

再比如,很多技术功底比较厚实的同学会认为“AI生成的东西不行”,但问题真是这样吗?也许是你的Prompt写得不够好。所以说,改变认知是一件很难的事情。

当然,也有一个现实情况,大家在心理惯性上或多或或少存在“AI袪魅”的现象。

就像,今年我们看到有许多发布会都讲到了非常丰富的AI功能,看起也很好用,但事实上上手之后发现也就不过如此,所以大家心里面就对AI更加存疑了。

那如何突破认知呢?首先让整个团队都突破认知是不可能的,需要挑选出合适的“先锋官”。实践中,我们从前端、后台团队分别抽调出一位对AI感兴趣的人,在人力盘点、成本结算上面做出相应的调整,给他们一个新的战场。

对于AI而言,挑选战场至关重要?有太多看似有价值实则无用的事情。

如何挑选一个影响范围大、收益大的战场呢?

下图中我们列举了许多可能的战场,需求设计、代码研发、编译集成等等。

图片图片

在这里,我们发现整个流程产生的数据的展示和分析占据了半边天。那么影响范围最大的战场就呼之欲出了。我们通过AI技术能不能让数据分析和展示的成本进一步降低呢?答案是肯定的,AI做数据分析不要太成熟了。而承载这些数据最多的地方——数据库。因此,我们选择的第一个战场就是很"普通"的Text2SQL。

此外,它还是一个能够帮助深入“敌后”的一个战场。

首先,我们可以站在巨人肩膀上,Text2SQL的收益面大,路径清晰,所以市面上就有非常多的团队在做,有经验分享,有开源的私有化的模型,包括对应的Fine Tune的流程和数据。它们离真实的生产环境有距离。“深入敌后”的意义就在这里,我给"先锋们"提出一个要求:我们做的东西一定是要能落地的,因此要判断你落地到我们在用的数据库平台之后,用户会修改多少个字段,然后这个SQL才能真正执行。

其次,Text2SQL可以让我们减少一道"难关",我们可以尝试打造出来一条全自动化的数据生产流水线,因为Text2SQL的SQL是可以被验证的,SQL、表、插入数据都可以被生成,然后真实地执行验证。

另外,ClickHouse又进一步把我们推到深处。我们很多业务都用Clickhouse,包括我们自身,可惜这些垂直的Text2SQL模型的支持真的是很弱。也很容易理解,因为它要面对严重缺乏元数据的大宽表和一堆独特的函数,但是这也偏偏是Text2SQL本来就需要面对的难题。当时我们就想,Clickhouse这么难的都搞定了,其他什么mysql不是手到擒来。

最后,一个深入区,是因为我们自己是做性能工程的,Text2SQL可以让团队在此基础上有机会做更深水区的AI模型调优,CPU推理,模型裁剪、MOE等性能优化。上述的这些,我们都尝试去面对去实践,老板肯定会问“为什么会做这么跨领域的事情”,因为这是一个很深入敌后的战场,会帮助我们团队走过AI的全流程,验证全部想法,挖掘全部坑点。

小结,找到一个最成熟的领域,一定会有收益、收益最广泛的领域,深入敌后的领域,去完完整整地打穿它,就能让团队的AI能力提升起来。接下来有一个重要的事情,就是分享经验。

分享经验有两点需要注意。一个是AI先锋们要把深度的经验分享出来;另外一个是管理者要塑造出团队氛围。

下图是大致团队分享的情况,先锋队会有类似的3个课程分享,比如《AI原住民的第一节课》,紧接着深水区的经验:比如怎么使用、怎么调优等。

图片图片

深水区的课程都是先锋队“以仗养仗”、边去打仗边总结的内容,然后用他们的案例沉淀出来,在团队内部做分享。

另一方面,还需要营造一个用AI的氛围。比如做一个轻量化的闪电分享,时长限制到三到五分钟,不需要说太多,就分享在工作中用到的一个Prompt、用到的一个AI的tool就OK了。

小结一下,为了突破认知,从管理维度上看,招聘选人的时候,一定要多问AI相关的问题,因为AI肯定是未来研发人员很重要的一项能力,否则就会落伍。接下来是挑选先锋队,带动团队。其次是闪电分享,去打造自己的氛围和培训。

图片图片

通过这样的突破认知的过程,产生的价值也是让我非常自豪的。我们现在有30多场闪电分享,团队内部的成员开始主动地去落地提单和CR,而且成果已经落地到了公司内部非常重要的业务上,比如Text2SQL和数据中台结合。

2.数据:训练AI的数据从哪里来?

众所周知,AI非常重要的是数据。但这里就会有两个问题:一、没流程、没数字化、没有用的数据,二、即便有了数据,但没有饲养的意识。

图片图片

第一个问题的在于都不仅仅是数据孤岛的问题,首先就是数字化这个事情,哪怕是互联网企业本身也不一定做得非常好。举个例子,测试过程真的做到数字化了吗?其实没有。我们只是局部数字化了,测试用例和测试结果数字化了,但是测试过程中是怎么点的、怎么用的、怎么测的,这些都是黑盒。

再比如,我们自己有一个比较细节的例子,当我们去做Text2SQL训练的时候,数据上就有很大一个问题,就是没有研发写SQL语句以及这个SQL语句修正的记录。类似这样的很多细节的过程都是没有做数字化。

更内核的是,很多时候,流程是缺失或者失效的。流程是数字化过程数据正确性和标准化的基石,没有流程,没有数字化,哪里来数据呢?没有数据,怎么练AI呢?

我们再来看另一个难点。假定我们有数据了,但很多人也没有喂养的意识。

举一个例子,我之前绩效面谈,我们的一个测试同学遇到一个错误码会去问团队内有经验的大牛,而大牛往往能直接根据错误码找出问题的原因。他一直跟我说,他很羡慕,希望成长成他那样。我当时,不禁反问,这时候其实如果有对应的产品文档的,然后将这个文档“喂养”到AI知识库里,然后再去用你的问题去校验知识库能不能够像大牛那样去回答你的问题,不是更好吗?

大牛回答的问题,知识库也可以回答。例如大家现在用ChatGLM3,再加上Embedding知识库,效果其实很好的。这是“饲养”数据意识的问题。

那么,如何突破这两个点呢?数据如何生产?如何饲喂?

首先,我们设定了三个非常核心的数据自动化产生的链路。愿景是希望令研发等流程中初步沉淀了七八十条精修的数据,通过整个自动化的链路,比如LangChain的链路,可以快速生产过百甚至上千、上万的数据,并且这个数据还是高质量的。怎么去做的呢?

图片图片

我们设定了三个模型。第一个模型,即用真实的执行环节去产生数据,比如代码完成后,代码执行过程中,产生了crash,代码跟crash之间的数据就有了。

第二个,用逻辑去泛化。我们知道金字塔原理,就是演绎推理、溯因推理、归纳推理,不同的推理方式利用生成式AI演进出不同的问题,从而泛化我的数据。

第三个,通过不同的场景去泛化,例如现在做数据库的Text2SQL,之后也可以泛化到工业场景、用户行为场景等等,让它去泛化出来各种不同的数据。

有了生产数据的三个核心链路,然后就是喂养。首先,我们会将每日wiki的数据都会录入到AI知识库,也就是向量数据库里面。然后,你就可以通过企业微信的机器人问对应的问题,直接、快速地得到一个相对高质量的答案。

另一个重要的是,前面提到的闪电分享也是一个重要的宣传途径,把这个能力公开给到团队里面的其他人去使用。这一步一定要做到,否则,就没有形成闭环,大家也不知道原来已经有了这样的能力。

图片图片

总结一下,数据是很重要的,全自动地产生数据更重要。现在,AI发展地速度几乎可以按天计算,但最安稳的其实还是数据,数据为王。

因此,对于AI团队而言,不要以为现在有几百条数据就很满足了,每天能用自动化的流程产生上万条数据,同时这个自动化的流程还要能确保这个数据产生的质量。

3.突破习惯:让AI渗透到习惯中

突破习惯是每个人都要克服的难题,甚至包括本身在开发AI的人。我观察到一个很有意思的事情,我们做AI开发的先锋们,开发AI的应用,但代码还是他自己写的,没有用AI。哪怕是最接纳AI的人,都有一种习惯,觉得自己的直觉和经验更顺手,可以快速去实现。

图片图片

第二个要突破的是,我们总习惯把自己的价值放在自身的领域范围内。但凡一线的人要进一步去拓宽你的价值的时候,你要多走一公里的时候,往往要面对一个问题:你的语言别人是听不懂的。

比方说,我们的研发同学,有很强的技术能力,开发出了功能强大的产品。但是产品没有卖好,你想多走一公里,加速技术变现。但是销售实在听不懂你说的。你用尽权利去描述这技术带来的功能和优势,但是销售想要的其实是"客户收益"。

F.A.B prompt: 
你是销售总监,能帮助我把Feature的描述变成Advantage和Benefit。
#注意:请保持用中文回答;
#思考步骤:
1. 先把Feature的描述变成Advantage
2. 从Advantage中,分别研发、产品经理、技术运维、质量保障的一线员工或主管的角色去脑暴Benefit
3. 再用 MECE 原则会归纳,并用吸引眼球&打动人心的语言和精炼有力的短句的输出
#功能描述:该功能叫热点性能动态分析,程序会调用perf收集程序的热点函数和热点汇编,然后在我们的工具页面中通过火焰图和表格来展示数据,并会自动分析数据给出初步的性能优化建议

其他还有,当测试想多走"一公里",如何用"研发的语言"让研发更快解决;当产品想多走"一公里",如何用"技术的语言"达成技术与产品的共振;这时,肯定离不开AI,因为AI是有世界知识的,它可以把你的语言转化成别人领域能理解的语言,这是太自然不过的事情了。

图片图片

接下来,我们怎么改变这种习惯呢?上表中,你会发现我们在数据分类里面除了文档数据和流程数据之外,还有很多平台,平台上会有研发、测试等各个角色。他们在这些现成的平台上已经形成习惯了。我的思路很简单,我们不急着颠覆,去改变原来的"习惯",我们要让AI跟这些平台伴生,去渗透AI的使用习惯。

因此我们开发了一个实验项目,Fibona AI浏览器插件。(Fibona, 取自斐波那契数列的启发,希望表达的是让AI和谐地融合到我们的工作习惯中)

下面有个小视频,里面有两段,一段演示的是在我们现成的腾讯云QAPM客户端性能监控怎么融合Fibona,我们可以不断地添加线索到Fibona里面,然后它就会分析问题,最后分析到究竟是哪一个crash是主要成因。另外一段是,一个研发最难定位的线程安全问题,通过我们的插件,提供多方线索,最终直出解决方案。

,时长00:36

我的愿景是,这种伴生平台会推展到公司内的全部平台,未来也会进一步商业化,比如伴生在某个DevOps的平台上面,去帮助提供这种AI的能力。

图片图片

所以这样看来,我们并不改变习惯,我们通过这种伴生的方式来渗透AI的使用习惯。这里我们突破了三个非常重要的瓶颈,分别是:认知、数据、习惯。

四、我们更进一步看看

这里整体上聊到了很多场景,包括用AI来做数据分析,然后做缺陷的定位解决方案,怎么去通过Text2SQL帮助不懂SQL语言的同事去写SQL语言,怎么用公司内的AI模型给到CR的建议,此外还有刚才聊到的知识库AI大师。

当把这些场景全部放到一个表格里面来看,就会发现非常有意思的事情。

图片图片

1.知识和经验平权

第一个维度,其实是很多AI书中写到的,也是布鲁姆教育目标分类法中提到的:记忆、理解、应用、分析、评估、创造,这是不同的等级。我们大部分提问的问题其实都离不开这六个点。这六个点会对应产生一系列的价值。

例如“理解”,以前团队是做CVM测试的,现在突然要做异构计算的测试,本身对英伟达的理解其实不多,那怎么办?

图片图片

GPT就能理解这个信息的,上图是我们的一个Prompt,这个Prompt也很简单,你是一个什么专家,让它用Markdown格式来输出。

这是团队从0到1突破的一个例子,先不要想象着我能从1做到100分。通过利用GPT去快速地了解,在这个日志文件里面,其实可以暴露出有哪些可以做性能优化的点。接下来只需要基于这个再进一步去提问就可以了。

因此,通过这个例子可以看出,突破已经不仅仅是技术知识了,而是知识和经验的平权。比如在IaaS领域,每一块知识都非常割裂,搞CPU的不懂搞网络的,搞网络的不懂磁盘的,当下你可以快速学习理解甚至运用其他领域的知识。再扩大一点,比如HR不会编程,想自己做的程序来提升工作效率,就只能找程序员帮忙,现在我们可以找AI帮忙,用自然语言就可以帮你写出程序。

图片图片

所以我们通过知识和经验的平权,尝试去给团队成员赋能,你有很特长的部分,例如写代码很厉害,其他的部分,比如沟通、汇报等能力通过AI来帮你补全。

比如邮件输出,给到你一个AI的Prompt模板,给到基本信息,就可以用AI去生成,写出来一个60分~80分的邮件。这就是知识和经验的平权的一个例子。

2.让自动化更自动化

另外一个很重要的部分,就是突破自动化,让自动化更自动化。这里提的更像是一个目标或者要求,让AI这个自动化更自动化一点。

现在大部分AI都有一个问题:它好像做了什么,好像又没做什么。比如:最经典的场景是会议纪要,似乎是归纳了,但是又似乎有遗漏,就是不敢当成邮件内容往外发。

我的主张是:不强制团队用AI,而且做AI、推广AI的一定要说清楚AI生成内容后,你的下一步动作是什么,是去修改它吗?还是直接使用它?

举个案例,下图是我们生成的一张缺陷单,这是纯粹用AI生成关于真实业务上的缺陷单。

图片图片

每位测试人员的能力其实是参差不齐的,许多工具测完跑出来几千条Benchmark的数据,然后还要耗费4、5个小时去分析这些数据,甚至还存在漏分析、漏提单的情况。

这是一个"脑热"的需求,用AI去分析生成缺陷。当时快速就出了一个版本,大家都很兴奋。当时我说,这个缺陷生成的下一步是"直接提单"吗?当时的回答是不能的。所以第一步,我们先设定我们的期待结果究竟是什么?然后开始打磨Prompt。实话说,比写程序复杂多了,打磨了将近两个星期才出来。除了要按照我们期待的格式和内容输出之外,还有三个难点——

第一,要从几千条数据里面找到问题,没有遗漏;

第二,还要去做聚合,避免重复提单;

第三,就是这个单要准确,可以直接拿来就用。这个时候“评估”就很重要了。一个诀窍就是在AI的Prompt中添加一个置信度的评估。经验上看,有了置信度的评价,再加上内容的生成,往往效果就会更好些。

之后,我们就可以开始落地到流程中去进行下一步。这就是“比自动化更自动化”。

3.跨领域沟通

最后一点,跨领域的沟通很难,如何解决?大家通常会想到一个解决的方案:流程。流程的确能解决非常多的问题,比如上下游的信息传递等等。但问题就在于,流程中的不同角色之间,怎么去相互理解?这如何解决?

回到Text2SQL的例子。没有Text2SQL之前,产品经理用自然语言告诉我们要查一个什么数据,然后告诉DBA,DBA帮它做一个SQL语句,检索出来,告诉他怎样就能搜索出来。

现在有了AI,我们期待的效果是:产品经理直接自然语言告诉AI,SQL语句生成、数据查询出来。

乍看起来让人焦虑,它不仅消灭了沟通的屏障,而是直接把人给消灭了,不用DBA了?其实我们不妨换一个角度思考,正如前面多次提及的,它其实是通过人类的自然语言去调动了跨领域的知识。作为产品经理,我不懂SQL语言,但他要写一个很复杂的SQL语句难度太大。而AI这个助手可以帮助他做到这件事情。

那跨领域知识的价值是什么呢?就是“向价值多走一公里”。尤其是降本增效语境下,大家都在找自己的价值。技术团队一定要多走一公里,比如:性能优化能不能直接给出优化的patch,提单能不能给出根因分析,性能测评的内容能不能给到销售去作为弹药库。当团队去多走一公里的事情的时候,肯定就会用到AI。

这里再举例一个特殊的跨领域沟通的案例,战略讨论会。

图片图片

首先大家懂不懂战略,其次,我们能不能够收集到足够定义战略相关的信息,就像我们在做产品的时候,PESTEL模型、波特五力的模型、核心竞争力分析的模型等等。模型都是需要信息和数据的,这些根本找不到,那怎么办?

当时我们用AI去生成。用AI描述完产品、定位之后,让它给我列举十种飞轮模型,我就有了一个讨论的基础。通过给AI看行业报告,把行业报告灌给AI,让它按照B3C模型,看自己、看竞争对手、看环境、看客户,模型里面都有非常标准化的问题,让AI去输出对应的结果,并且用我们能理解的语言来输出对应的结果。

这时候,没有学过战略的程序员也可以坐在一起讨论战略了,而且不是空讨论。而且在讨论的同时,也会提出来一些问题,比如怎么去更好地了解我们客户的诉求等等。

4.技术管理者追求的价值

在做流程管理、做分层结构、做灵活用工的时候,管理者会发现团队的成员慢慢变成螺丝钉、工具人,这时就值得反思。我能不能用AI赋能的方式、用知识平权、自动化、跨领域沟通的方式,去赋能给每一个技术人员,让他们作为一个平凡但有特长的人,在团队里面也可以发挥自己独有的最大的价值。

图片图片

这也是本人所追求的价值:自己要发挥价值,自己的团队也要发挥价值。