前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于GenAI,要冷静

关于GenAI,要冷静

作者头像
ThoughtWorks
发布2024-05-11 17:35:00
690
发布2024-05-11 17:35:00
举报
文章被收录于专栏:ThoughtWorksThoughtWorks
疯狂的全民大模型

大约一年前,大家热聊的先是LLM,LLM的全称是Large language models,也就是大语言模型,那么它必然有2个特点,一个是自然语言,第二个是大。随后它带来了一个效果,就是能“生成”,可以像人一样发言,不过输出仅限于文本,看起来能够自我输出和自我思考,于是基于这个理念,AIGC这个概念应运而生。

紧接着,围绕它诞生了非常多看起来更加“多模态的东西”,比如文生图,图生文,但是背后实质上是多个模型的配合。当然这无可厚非,因为人也不是单纯靠脑袋在工作,依旧有很多末端神经充当包工头的角色。

然后随之而来的,似乎都不谈LLM了,开始谈GenAI、谈大模型了。仿佛人类想象中能够触达的输出,大模型也都可以。于是各种通用人工智能纷至沓来,“人类被计算机碾压,无数群体即将失业”的舆论被拉起来,整个世界被GenAI裹挟着前进。

大厂不断进行军备竞赛,抢购显卡,跑模型,甚至不知道自己在干嘛,就因为大家都在干,于是自己也得干,而其中甚至多数,抓着开源的代码,站上巨人的肩膀,开始赛跑。

除了基础设施厂商在做模型、在不断演进外,围绕大模型生态的企业也没闲着,通过各种方式,演绎自己的故事,例如大模型既然动脑能力不错,但是动手能力差,那么就安装手和脚,做Agent和MulAgent。大模型无法感知企业内部知识,于是开始做RAG。

实际上,这个周期内,真正赚到钱的,只有卖显卡的和卖课程的。

谁在做大模型

前面提到,LLM有两个特点,一个是自然语言,一个是大,因为大,那么自然不是任何一家企业都能做,真正具备做大模型能力的企业必须满足这样的条件:

  • 拥有足够的硬件
  • 拥有足够的数据
  • 拥有足够的人才
  • 拥有足够的资金

目前叫得上名字的企业都能分别满足这几个维度,但是满足的程度是不一样的。比如nivdia在硬件资源方面的沉淀就非常深厚,而有的企业则拥有更加多和好的数据,但在硬件资源方面则相对欠缺。

不过,即便如此,也能发现一个现象,那就是当谈到大模型的时候,似乎出头的并不是之前已经存在的大厂,而是某些新秀——源源不断的新秀,而之前就已经声名鹊起的大厂,其存在感反而弱了非常多。

这些新秀企业都有非常鲜明的特点,很多企业的成员都非常年轻,且更加优秀,大部分都在大模型领域有非常深的学术造诣,进而步入到大模型的实践落地中。其次相对于纯软件工程来说,在大模型领域,模型精准度优化的重要性会高于代码本身。

当然这种情况在软件工程中也存在,比如当我们赶着推进功能进度的时候,就会降低代码质量要求。然而其不同之处在于大模型领域的代码和最终推理的运行没有必然的联系,此特点从开源生态可见一斑。软件工程开源的是源码本身,而大模型领域开源的是模型。

也就是说,在软件工程领域,软件源码质量会直接影响可运行的软件本身,所以不得不做好软件工程这件事,甚至会过度关注源码质量本身,通过源码的质量来控制最终的交付的功能的质量。很多甲方企业甚至会把软件源码交付质量作为项目验收的条款之一。把这个逻辑映射到大模型领域,交付件是什么?是大模型,一个文件,这个文件可能1GB,可能100GB,可能1TB,当运行这个模型进行推理的时候,没有人关心当时训练出这个模型的那一堆代码到底质量如何,甚至把那堆代码丢掉,也不影响这个模型的后续使用。

因为源码和交付件没有必然关系可能有人会问,难道模型不需要再优化?如果要扩展功能怎么办?且不说站在外围来看,微调已经是标准手法,模型文件里面本身是什么?权重,权重再抽象呢?参数,也就是当你拿到一个模型文件之后,有无之前的代码,并不影响这个模型的持续演进,极端情况下,代码就是一次性产物,是一次性消耗品,既然是一次性消耗,那么就不用过度追求它的可演进。

所以目前真正在投入做大模型的企业,通常是拥有足够硬件的企业,并且有足够人才。在这两个维度满足度较高,那么投入做大模型,就会脱颖而出。

谁在用大模型

既然有人做,那就应该有人用,否则做大模型的厂商就应该消亡了,可是看目前的势头,似乎并没有,那么就意味着,一定有人在用,或者资本看好,认为未来一定有人用,那么会是谁?

站在资本的角度,如果大模型具备人一样的能力,那么就可以把手下的人全部裁掉,采购大模型服务,24小时不间断地上班。那么在这样的业务下,需要满足如下两个条件:

  • 招聘员工的成本比大模型低,否则裁掉不是一笔划算的买卖。
  • 自身业务属于资源生产的上游,最好有垄断,否则最后会变成你和你的朋友,大家都用大模型在搞,最后变成了一堆机器人互玩,不但没有新的资源产生,反而会把资源消耗殆尽。

站在个人的角度,对大模型有没有需求?有,且非常多,各种自媒体视频、文案,还不算灰产那些杂七杂八的东西。

也就是个人自身日常生活需求下,和企业基于自身业务的需求下,都存在对大模型的需求,那么这些需求里面,哪些是正统的,或者真正有价值的?我认为会是以下几类:

  • 服务于C端用户自身的GenAI:如果是C端用户借助大模型提升自己的短板并把这个过程当作内容产物对外输出,这样的场景是没有价值的,最后不外乎所有地方都充斥着大模型产生的内容,甚至可能是同一个模型产生的,所以类似自媒体借助大模型去搞视频这种业务,最后都会如此。唯有大模型的输出,服务于自身个人需求,才会细水长流。
  • 服务于B端的GenAI:只有服务于实体生产,产生真实生活资源的,或者服务于自身对内流程的,才真正有价值,其余的都是昙花一现。可能有人会觉得,很多企业使用大模型做一个客服人员来代替人24小时值班回答客户问题,这类业务场景非常有价值。确实有价值,不过有没有思考过一个问题,很有可能提问的这个“用户”也不是人,而是是一个人的虚拟助理,设置这个虚拟助手和这个企业的客服人员,恰好购买了同一个模型服务?

因此虽然看起来地球上每一个角落,都能找到对大模型的需求,甚至都没有办法反驳它的合理性。但是这些需求,未必都是真正有意义和价值的。

关于GenAI,要冷静

关于GenAI的实施,我劝你冷静。抛开C端用户随意使用大模型生成内容满足自身需求外,在大部分企业中,企业在考虑大模型的时候,有如下问题是没法绕过的:

  • 安全问题:且不提调戏大模型泄漏原始数据这种比较好处理的问题,安全问题的核心是合规,这里的合规是感性的,而非理性的。是定性的,而非定量的。比如你没有办法通过规则穷举所有性别歧视的情况,但是你需要保证模型在你的业务场景下的输出是没有性别歧视的。
  • 绝对正确:大模型输出不可能绝对正确,但是有部分场景,就是要求绝对正确,当没有大模型的时候,就算0.0001%的情况下出现绝对不正确,一定有解决办法,比如通知张三是临时工,张三的领导李四负有直接管理职责,如果是大模型呢?
  • 版权问题:老生常谈。

我们站在三个角色的视角来思考这样一个问题(虽然这个问题目前可以被100%解决):

一个基于大模型做的BI系统上线了,但是这个系统在统计过去1年销售额度的时候,连续问了10次,其中有1次和其余9次不一样。这个BI系统涉及到三方企业:甲方A,大模型厂商B和软件实施方C。A开始就这个P0事故进行追责寻求,C进行一番Debug后发现是因为大模型幻觉问题,于是这个问题划到了B,但是B作为大模型服务提供商,一定不会保证100%不出现幻觉,且这一点一定不会出现在SLA里面,那么这个问题怎么解决?如果非要找一方来承担这个问题,会是谁?

目前来说,期望引入GenAI来服务于对外的业务,相对来说风险较高,而从商业模式来说,以GenAI作为项目交付物,且服务于甲方的客户的交付项目,几乎有着不可评估的交付风险,当然潜在就存在不可估量的咨询潜力。

目前来说,期望引入GenAI来解决企业发展问题,或者解决流程问题,几乎都是不太可能的。

金融学家吴晓求说,IPO的钱不是企业“ICU”的救命钱,它是发展的钱,不是救命的钱,而目前任何把GenAI定位为“IPO”的需求大概率都不会成功。

所以对于GenAI,在全面狂欢之下,反而更应该冷静,因为隐藏在GenAI美好表象后的风险远比想象中要大。

尾声

为了更好地支持企业构建规模化的大模型应用,Thoughtworks 推出了专为企业用户设计的大模型应用平台 Gluon Meson(交界),Gluon Meson的目标不在于模型本身,而在于如何用好模型、更好地管好数据,更好地治理大模型应用,它介于业务和GenAI之间,提供大模型规模化应用需要的能力。接下来Gluon Meson将会正式发布2.0的版本,欢迎大家关注。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2024-05-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 ThoughtWorks洞见 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
腾讯云 BI
腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档