生成式AI的数据开发者体验:性能优化

如果数据性能优化的需求因生成式AI而突然消失,大量熟练的数据工程师该何去何从?

译自 The GenAI Data Developer Experience: Performance Optimization

在科幻作品中,你已看过无数次类似情节,自然会认为这是信息技术发展的方向:你询问计算机,可能是出声提问,要它分析数据,然后很快得到结果——当然是在商业广告开始前。

然而,如果你是数据库工程师或数据科学家,你就会知道进步道路上的一个岔口。自从计算机能接收命令开始,性能优化和加速结果一直是必要技能。这些技能一直关注发现问题或查询最可能采用的模式,并准备或预编程系统以最好地响应这些模式。

生成式AI随之出现,期待你可以随心所欲地向数据提出任何问题(并可能用Majel Barrett的声音听到结果)。现在,性能优化成了问题。模式改变了。你可能需要AI增强的分析工具告诉你数据库用户最可能向AI增强的分析工具提出什么问题。

突然间,那些利用最新半导体技术和处理能力进步的数据库,包括大容量快速DRAM和专用GPU网络(如Nvidia Tensor Core H100),似乎具有先天优势。那些供应商吹嘘他们不需要索引或预优化就能快速响应的系统,带着面向新时代服务器的消息进入新兴即席查询市场:当你结合大语言模型和面向这个新世界的数据库引擎时,性能预优化的需求会消失。

取而代之,我们看到针对实时数据存储的自然语言查询处理。使用所有人都熟悉的自然语言,即时询问收集和处理中的实时数据的能力,乍看起来似乎是一个真正的范式转变。

听起来令人欣喜,前15秒钟左右。但然后小谚语中的分歧呈现了:数据库开发者——其价值到今天为止依赖于提前优化查询性能和可靠性的能力——会发生什么?也许就这一次,科幻小说中最过度使用的套路——AI处理使人类聪明失去优势——看起来更像预言。

“在过去40年左右,许多数据科学家花时间研究自然语言处理,”Neo4j图数据库制造商的开发者产品策略负责人Michael Hunger说。“他们研究每种语言的语法,根据每个领域分隔词汇表。他们花费无数年进行细微调整,为律师、生物学家等建立特定模型。这些现在都因大型语言模型而过时了。”

第11条规则:分布独立性

如果你在数据库领域工作一段时间,你会遇到“即席查询”这个词组。起初它可能听起来有点令人不快。那种感觉过去后,你会发现它指数据库系统方便用户在任何时间生成查询,并及时响应请求的数据。

1985年,E. F. Codd博士——当时已被恰当地确认为关系数据库和SQL的发明者——首次发表了所谓关系数据库的“12条规则”。第11条规则称为分布独立性规则。在一本1990年的书中,他试图向已经自行得出结论的人解释他的推理:

...不仅允许任一站点的所有数据移动到另一个站点,还允许不同站点上的全部数据的完全不同分解成在各站点部署的碎片。

第11条规则以各种自服务和方便的方式重新解释过,但这里是最有意义的解释:用户询问数据库的能力不应受数据的工程方式或分布方式的限制。

Codd后来说,声称是关系型的但不支持分布独立性的数据库应尽快实现这一点非常重要。他提供的四个原因之一是以便数据库为一种当时还不存在的功能让路:“极大地改进执行的自动优化——并在必要时,自动重新优化。”换句话说,即时进行的性能优化,而不是提前由存储过程进行。

Codd没有亲自说,因为他不使用拉丁语句听起来装模作样。然而他不仅预见了数据分片的未来,还为即席查询铺平了道路。直到20世纪80年代,尤其是对供应商演示的接收方来说,数据库似乎快速轻松。通常,是因为演示的查询是数据库预先设计好响应的。从技术上讲,这违反了第11条规则。然而数据以任何方式分布,数据库应该始终准备提供最佳响应。

大型语言模型

数据库与大语言模型(LLM)的结合是一种不可避免的融合——这显然是由第11条规则支持的。此时重要的不仅是它们如何结合,还有就数据库系统架构而言,在何处结合。

去年10月5日的DockerCon大会上,Neo4j与LangChain和语言模型构建器提供商Ollama联合宣布,其图数据库被选为Docker新的GenAI Stack的默认平台——这是用于开发语言驱动AI应用程序的开发者工具包。在那里的一个会议上,Hunger详细讨论了他称之为“使基础扎实”的一种新的涉及LLM的开发过程:

Neo4j产品创新负责人Michael Hunger在2023年DockerCon上演讲。

“面对LLM的所有这些挑战,我们该如何做得更好?”Hunger向与会者说。“你可以采用现有模型并对其进行微调。但这需要大量工作,而且输出和结果至少在当前对每个人来说还不够好。你可以在与LLM交谈时提供一些例子,但然后基本上需要对这些例子进行硬编码——这实际上并没有什么帮助。”

你可以感觉到第11条规则的制定者在赞同地点头。

Hunger继续说,使基础扎实是一个用户驱动的过程。这里,用户为LLM提供它需要的额外上下文,以给出更准确的响应。LangChain CEO Harrison Chase接过话筒,进一步详细说明了Hunger所说的“开发者的机会”。最重要的是,Chase告诉这些开发者他们不必再是数据科学家。

“我们将使用一些激动人心的工具包,如Ollama,”Chase说,“这些是本地托管的模型,打包起来非常漂亮。你不再需要训练模型。你只需要运行和部署它,Ollama可以轻松完成这些。”

像Ollama构建的或者在Ollama的工具帮助下构建的定制语言模型,会用已经调音到用户最有可能询问的风格和上下文的工作词汇,为数据库提供背景。在去年10月13日的一篇博文中,LangChain维护者Jacob Lee介绍了他的项目,将Ollama LLM与LangChain自然语言组合工具相连接,从任何用户的浏览器中提供提示,启用对用户现有文档的即席查询。

我们越来越接近一个点:数据的分布和结构对想提问题的人来说一点也不重要。可能更重要的是,我们接近一个阶段,这里驱动这些对话的AI可以在客户端而不是服务器端实现。(抱歉,谷歌。)

然而,在数据库的整个历史中,“范式转变”一直停留在起点。Hunger和Chase声称不再必要的任务实际上是工作,被人们占据。我们喜欢相信所需的技能组与技术一样快速发展。但看看今天数据库领域求职岗位的帖子,你会发现它们没有。目前对二三十年前的技能有非常大的需求。

考虑到这一点,我们问Neo4j的Hunger:一旦人们能够提出普通问题并从以前需要工程的数据中获得响应,是否就不需要工程了?

“如果你知道数据库是关于什么领域的,”Hunger回答说,“除了将我的所有文本转化为向量嵌入并让向量索引查找相似的文档或节点之外,你还可以说‘把以下问题转化为Cypher语句。’” 然后可以像平常一样针对Neo4j图数据库运行该语句。(Cypher是Neo4j对应SQL的查询语言,面向图数据库。)

Hunger认为其优势包括让用户得到某种关于Cypher甚至SQL的间接教育。的确,第一次或第二次运行时,新用户可能不明白查询语言语法的结构。但是随着时间的推移,用户将只通过每天使用开始参透细节。Hunger认为这种“民主化”,如他所称,将加强现有的查询语言和查询优化的工作技能,而不是使其过时。

新上下文栈

Michael Hunger在这个理论上并不孤单,而且有人可能正在努力打败他的公司来证明它。

去年8月,Kinetica开始提供访问SQL GPT,这是该公司的向量处理引擎与大型语言模型的组合。利用一种称为检索增强生成(RAG)的概念,该工具的唯一功能是将主题、动词和对象映射到表格、时间序列或地理空间数据库中的符号的自然语言请求进行解释。一个在后台工作的函数利用所谓的上下文——最终用户永远看不到——作为LLM的辅助,将关键词映射到符号。

SQL GPT演示运行自Kinetica Cloud Workbench。

结果是一个SQL查询,可以传递给Kinetica数据库,在很大程度上可能生成某种形式的表、报告、地图或图表,以响应从自然语言请求推断的标准查询。

你已经看过例子,包括我的朋友和The New Stack同事Stephen J. Vaughan-Nichols的ChatGPT提示被要求用Python编写满足英语请求标准的代码片段。SQL GPT与此有几个关键不同,第一个是其语言模型不是用网络数据进行训练的。相反,它是训练生成适用于Kinetica的SQL。其上下文通过与自然语言请求相关的行业、业务或其他功能的相关长指令来补充此训练。

“今天,我们确实有一个API,您可以在不同的语言模型之间进行选择——我们自己的或其他公共LLM,”Kinetica高级副总裁Philip Darringer在接受The New Stack采访时解释道。从那里,他继续说,您将为SQL GPT提供一个上下文,至少应引用您打算使用的数据库表中的符号。 然后,SQL GPT获取映射这些符号到数据库条目的数据描述语言(DDL)信息,完成语言到符号再到配置的连接。

上下文中的说明已经是人类可读的了。因为它们是直接给LLM的,所以是英语。所以,Darringer解释说,LLM以非常精确和明确的语言被告知其工作是生成SQL,然后对如何做到这一点进行彻底解释。 “然后,如果需要,您可以添加对上下文的额外补充,”他继续说道,“以提高生成查询的准确性。您可以添加示例,甚至添加日志的反馈。 如果您可以开始分析Kinetica实例的日志,以查看执行了哪些查询并且人们已经对哪些查询提供了反馈,则可以使用它来提供额外的上下文,以帮助教育模型什么有效什么无效。”

对于SQL GPT的自导演示,Kinetica Cloud提供了一个公共数据流,提供华盛顿特区送货卡车的实时遥测数据(但不包含其内容)。第二张表将DC地标的名称与地理坐标配对。因此,您可以给SQL GPT这样的指示:“显示在过去半小时内经过华盛顿纪念碑的所有卡车。”大约5秒钟后,您会得到一个SQL语句,然后可以将其传递给Kinetica。数据库——已经针对这种语句进行了优化——将在不到1秒内响应结果。

Chrome旧版窗口;Kinetica Workbench

当这种工具准备好广泛采用时,采用它的组织会发生什么变化?Kinetica现在还没有做出那么宽泛的预测,尽管Darringer确实说,他觉得组织中负责采用的人很可能会成为已经在管理机器学习过程的人。 Darringer暗示,这样的人可能是“纯分析师”,他们的科学完全绕过计算,直接扎根于数学。

“你可以想象组织中的数据管理员,”Darringer解释道,“将开始添加和生成这些查询和上下文,以帮助训练和微调模型,这样不太熟练的SQL用户——可能完全不懂SQL的纯粹分析师——可以开始利用数据。”

数据管理员

传统上,数据库供应商认为有两类客户:应用程序开发人员和数据科学家。B2B市场营销人员和技术出版物都将这些团体视为几乎是隔离的、自成一体的实体。前者据说更了解源代码的细微差别;后者与数据有更亲密的关系。

随着生成式AI进一步渗透到组织中,第三类客户可能正在形成。他们可能不是“开发者”这个意义上的开发者,即每天与Python、JDBC驱动程序和JSON文件战斗的人。他们可以在更广泛的意义上是开发者。也许可以给他们一组明确的说明,或者通过YouTube视频一步一步地引导他们生成一两个Python语句。

“12个月前,”Neo4j的Hunger说,“当你与某人谈论机器学习时,这些人大多不是开发者——他们是数据科学家。[...] 现在,这种情况真的发生了改变。所有这些新的语言模型都可以作为API、库、Python库等使用。所以现在,构建应用程序的开发者能够再次使用机器学习模型,因为他们不必自己训练它们。他们不必创建它们。只要使用它们。”

在DeepLearning.ai发布的大量新免费课程的帮助下学习为LLM提供背景和上下文的精细艺术,Hunger指出:“我认为你可以在一个小时左右达到‘Hello World’。” 他说,那些可能没有花多年时间建立数据库管理技能的人可以在工作日结束前展示自己即时生成数据应用程序的能力。

Microsoft Query, circa 1995.

如果这种承诺及其背后的论点对你来说有点熟悉,那不是灵异的感觉。将近30年前,某种“数据民主化”的想法在Microsoft推广一种不起眼的名为Query的工具时起着推动作用,作为进行所谓即席查询的通用前端。

上面的Macintosh截图来自1995年对Microsoft Query的演示,该演示面向密苏里州圣路易斯BJC卫生系统的一组药剂师开发。根据他们的演示文稿和白皮书,利用这种前端工具,药剂师可以在现场做出可能对患者护理至关重要的决定,所有这些都无需“技术协助收集任何必要的患者数据进行分析”。

当时有一个问题:使这些查询工作需要提前实现存储过程——启用药剂师最有可能提出的查询类型。不太像一个拉丁语词组那么即时。

快进到今天:Microsoft Query的残余已经嵌入(有人会说“埋葬”)在Excel中。但存储过程和数据预处理业务,特别是在药房领域,已经蓬勃发展。定制配置的药房数据以及访问它的过程是医疗技术提供商First Databank的成功关键

数据工程和数据科学是不显示脆弱迹象的努力领域。很容易想象最新的即席查询技术演变成定制语言模型行业,也许以Ollama为中心。悬而未决的问题是这条进化路径是否最终导致了整个技能类别——现在已经坚持了半个多世纪——在明天过时。

“这是1000亿美元的问题,”Hunger指出。 “如你可能已经在许多媒体上读到的那样,’开发者在5年内会过时吗?’这是一个每个人都要面对的问题。因为如果你在这里谈论Cypher,你也可以谈论Python、Java或任何其他语言。如果管理者或业务用户描述他们想要的东西就足够好,LLM基本上可以自行构建一切,那么问题就是你是否仍然需要开发者。”

声明:Scott Fulton曾是Neo4j的员工,也是Michael Hunger的前同事。他目前担任Kinetica的内容顾问。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注