数据存储产业服务平台

责任不在大模型,错在我们的使用方式

在报道甲骨文2024全球云大会的时候,我注意到:当我们还在关注大模型应用的时候,Oracle已经将视野扩展到企业应用开发平台(参见:“当我们看大模型应用的时候,Oracle已经将视野扩展应用开发平台”一文),但是我并没有完全清楚所谓企业应用开发平台的构建方式,以及和大模型应用的关系。

1月17日在北京举行的2025甲骨文中国创新峰会令我茅塞顿开,新的企业应用开发平台的核心在于构建以AI为中心的平台架构,旨在生成各类以AI为中心的企业应用。

如果说文字理解起来总是晦涩,也许看图就更容易理解。简单说,开发人员的工作发生了翻天覆地的变化,此前是以人为中心的构建式架构的开发方式,需要通过鼠标和键盘进行交互,强调的是软件即服务。对于用户而言,可以通过购买软件或者SaaS服务来满足需求;但是在大模型的时代,这个模式会被完全颠覆,用户所需要的各种应用交付,完全交由大模型来提供,所谓生成式架构,以数据为中心的生成式开发。

在新的模式下,新的业务应用很难通过软件或者SaaS购买来实现,业务人员甚至可以借助低代码平台组织业务,即使企业拥有开发人员,他们的工作也是以数据为中心的生成式开发,简单说,就是围绕大模型展开的各种应用。

大模型能够担此重任吗?答案是能,也不能。

先说不能,指的是目前通用大模型还不具有直接承担这些任务的能力,让通用大模型做这件事情,得到的可能只有失望;接着说能的含义,其实也并不需要大模型继续进化,现在的通用大模型的能力已经足够了,关键是企业使用构建好的数据开发平台,所谓AI ready for Data,Data ready for AI;后者用于支持行业大模型开发,而前者则支持业务应用。

简单理解,企业准备好数据,然后使用大模型,则企业业务应用将如鱼得水。

关键是如何准备好数据,对此,甲骨文公司副总裁及中国区董事总经理吴承杨指出,一个指导的原则就是让数据管理简单化,而不是复杂化。此前,数据中台、业务中台也服务于这个目的,追求业务应用对于软件模块的复用,但是,在技术路线上选择的是让数据管理复杂的路线。

所谓简单化,就是类似Oracle Database 23ai这样的平台,追求向量+标量数据管理的简单化。简单说,企业拥有的数据,无论是结构化数据,还是现代应用大量使用的JSON数据,多模非结构化数据,只要能组织好这些数据,并通过将数据简单化使其便于通用大模型访问,那么问题将迎刃而解。

在使用大模型的时候,我们有这样的体会,大模型很难正面回答商品价格这类具体问题,总是指引用户参看相关的正规报价。这并非大模型缺乏访问这些数据的能力,而是这些数据通常保存在企业的ERP、CRM等数据库中,相关产品研发、销售和售后的数据资料也通常掌握在企业手里,大模型没有得到相应的接入允许和授权。所以,企业要把这些数据组织好,方便大模型的访问和使用,其中就涉及对向量数据、图数据等进行相关的处理和准备。

责任不在大模型,而在于企业没有准备好数据。

当数据准备好,业务创新和应用就变得轻松了!简单来说,企业只需用声明式语言表达自身对数据的诉求,至于数据的检索或者发现则完全交给大模型来承担,这就是大模型时代,企业的研发应用和管理方式。

正如吴承杨所说:AI项目并不代表企业AI 转型,AI是一场革命,它首要带来的是思维方式和管理模式的变革。以AI为中心的企业应用开发架构,能够为企业发展创造价值。

对此,你意识到了吗?

未经允许不得转载:存储在线-存储专业媒体 » 责任不在大模型,错在我们的使用方式