微信扫码
与创始人交个朋友
我要投稿
↑点击蓝字 关注我们
数据库 + 大模型,是这两年比较火的一个话题。例如早前的 AIOps 智能运维,通过融合 AI 技术,尤其是机器学习和大数据分析方面,试图提升 IT 运维效率与自动化水平。
然而,受限于 AI 自身的发展状况,AIOps 所能掀起的波澜相对有限。
而如今,随着 Chat2DB 、ChatDBA 、DataGPT 等基于 LLM 的新一代对话式工具的出现,让数据库 + 大模型的组合越发成熟,大大提升了 DBA 的工作效率。
本期【开源漫谈】,我们邀请到了腾讯云 TVP 成员杨建荣、爱獭科技创始人姬朋飞、爱可生 AI 创新事业部负责人苏鹏、北极九章 CEO 刘沂鑫,一起来探讨一下,数据库 + 大模型,究竟带来了什么?未来还有哪些可能?
分享嘉宾:
姬朋飞
爱獭科技创始人,开源社区 OG 。
开发的开源产品 Chat2DB 在 GitHub 有 15k+ Stars ,个人的开源项目 Easyexcel 在 GitHub 社区拥有近 30k Stars ,是目前应用最广泛的技术框架之一。
苏鹏
爱可生 AI 创新事业部负责人。
目前在爱可生负责大模型与数据库的创新场景探索,在数据库和算法领域有着丰富的开发经验。Datawhale 开源学习社区上海负责人、LFAPAC Edu SIG member 。
刘沂鑫
北极九章创始人兼 CEO 。
毕业于 UC Berkeley,资深数据科学家和数据产品经理,美国最大的房地产科技公司 CoreLogic 数据产品负责人。作为国内最早的 AI 对话式数据分析探索者之一,带领团队研发北极九章数据智能平台 DataGPT 。
主持人:
杨建荣
《 Oracle DBA 工作笔记》《 MySQL DBA 工作笔记》作者,dbaplus 社群发起人之一。
腾讯云 TVP 成员,现任竞技世界系统部负责人,拥有十多年数据库开发和运维经验,目前专注于开源技术、运维自动化和性能调优。
姬朋飞:
站在开发者的角度,在我们实际做的过程中,最大的一个点就是去生成 SQL 。那生成 SQL 其实可以服务于几类人,第一类是技术开发人员,第二类是业务人员,基于 SQL 再去转化成各类报表。其次,这两年大家可以看到向量数据库很火,说白了还是因为 AI 增强了向量化的能力,就像 Oracle 、Redis 这些数据库都在集成各种向量库的能力。最后就是一些 DBA 人员,给他们提供了很多辅助手段,比如线上报错应该怎么解决。
苏鹏:
主要还是一个运维场景,比如说能自动获取一些系统状态,让大模型自动处理一些事件。在我们自己做的过程中,和还有一个比较重要的场景,就是对 SQL 的优化,对于已经生成好的 SQL 语句,怎么给它进行优化,让它执行得更高效,这个目前大家的需求方向。再有一些,就是对 SQL 的解释,这个也是我们经常看到的,因为 SQL 语句由于某些业务需求,会写得很长,那么大家理解起来就会有一定的复杂性,模型来帮你解释了,其实也能让你更好理解它的含义,知道怎么去优化它、调整它。
刘沂鑫:
我补充一个方面,其实数据库面临的一个很大挑战就是数据质量不行,如何将非结构化数据变成结构化的数据并加以归纳,以前都是人去做这样的工作,但现在 AI 也可以做这样一个工作,甚至它的效率还高于人,去完成这些内容。
姬朋飞:
我先从好的方面开始说,因为有了 AI 之后,其实无论大家在操作数据库,还是查数据、做数据分析时,很多东西都做了简化,然后本身一些可能以前业务不太熟练的人员,可以通过 AI 辅助完成工作,大大提高了工作效率和质量。其次就是智能化运维的操作与管理,都有很多智能工具可以帮你,比如说做一些监控、智能告警,还有非结构化数据整理。比如说客服系统,以前可能要去做很多 FAQ ,抽调很多 FAQ 去回答用户问题,但现在只需要丢一个文档就 ok 了,整体过程交给 AI 帮你完成。
那么在不好的方面,其实很多专业人员都有体会,那么就是 AI 对于整个数据库的运维面临一些不确定,因为大模型本身就伴随着不确定。比如在一些运维操作,不能说有了 AI ,就忽视了人工确认的环境,还是需要认为得去检查一些复杂场景。其次就是资源和成本,因为 AI 要用去大量的 GPU 算力,对于一些创业公司来说,动不动成本就几十万,确实是比较高的。
苏鹏:
太依赖 AI 势必会让人类丧失一定的思考能力,这可能是在人的层面上大家比较担心的点。因为 AI 对于人来说,一个是比较简单,另一个就是它能帮你做你本来就不了解的那一部分工作。如果是这样,你如何去识别 AI 所做的是对的,它做完了你如何去校验它,我觉得这个还是现在大家没有思考完善的一个问题。所以,我觉得从反面来说,我们应该避免过度依赖 AI ,另一方面,还是需要不断提高自身的能力,起码你要能甄别 AI 所输出的内容是否准确。
刘沂鑫:
作为一个产品经理,从产品的角度上说,大家一开始会觉得 “大模型 + 数据库” 拥有很多种可能,这个不仅是团队内部的理解,也是现在很多开发者们的理解,但其实,有些想法是现在 AI 可以解决的,而有很多想法都是不能解决的,甚至,有些想法就不应该让产品来解决。我不认为说 “声音”,就只有对的声音,或者是错的声音,从长期角度来看,数据库 + 大模型是一个大趋势。
姬朋飞:
你要对 “大模型 + 数据库” 这种产品的能力边界有一个认识,就是你要知道它的核心能力在哪里,需要哪些数据,比如说数据库的语法、函数等,这些东西起码是你需要梳理好告诉 AI 的,不然 AI 大概率只能生成一些与你业务不相关的东西。其次,就是在大模型一块的相关测试方式,还是得掌握,让生成的数据更贴合一些真实的业务场景。
苏鹏:
事实上,现在大模型的迭代速度是非常快的,结合数据库领域,我们都需要在使用的过程中,不断去优化自己的知识结构和提升我们的实操能力。再有,只要模型不做大的结构化调整,那么 “提示词” 一定是一个很重要的技能。它是你跟模型交互的一个接口,写好你的提示词,其实也就能更准确地表达你的需求。
我们经常遇到的一个痛点就是,客户出问题了,就找过来让你解决,客户也说不清楚问题出在哪里,反正就是报错了。其实不应该是这样子的,处理问题的过程中往往需要做很多工作,比如查监控、查日志、查很多东西,通过收集这些碎片化的信息,才能找到问题的原因。所以我们在设计产品的时候,也是考虑到了这一方面,希望通过一种引导式的步骤,帮助我们处理在真实场景中所遇到的故障或问题,这一点,不论有没有 AI ,都是需要每一位 DBA 所深入学习并掌握的能力。
刘沂鑫:
我们所思考的一个核心的点在于,如果 AI 必然是未来,那么 DBA 最好当下就要开始学习相关的知识体系或实操技能。其次,数据库是个非常专业的一个领域,即便通过结构化的方式表示该问题,这个问题当中还可能嵌套问题,所以利用大模型未来去处理工作,绝不是问一个问题,就能立马得到非常准确的答案,而是与大模型相互磨合的一个过程。我们也做了大量的工程化结构和自动化提升,最终满足大家的实际需求。
刘沂鑫:
我们看到的一些场景更多是以国央企为主,这些国央企的数据,被认为是个宝贵的资产,需要本地化。这其实就是在 “数据库 + 大模型” 落地过程中的一个挑战,正如刚才姬朋飞老师提到的 20 万甚至是几十万,当需要很多卡时,我们的整个采购流程就会变得非常漫长,并且,这是一个非常昂贵的流程。最先进的模型,对于机器的要求更高,背后所蕴藏的成本也就更大,对于本地化部署的难度就会水涨船高,并且也限制了数据的输出速度。
除此之外,我们刚刚提到技术边界,其实任何一个技术都是有边界的。大模型在梳理数据时,往往会根据语言理解的偏差,没办法百分之百理解你的需求,这就会导致输出的 “非一致性”,这是一个很重要的问题。
最后就是趋势,至少在现在,特别是一个企业环境中,我们看到大家慢慢适应了 “大模型 + 数据库” 这样一个工作模式,就像最开始我们用五笔输入,后来用拼音,然后拼音越来越智能,这都是一个技术发展的路径,并且我们最后都适应了。
补充一点,其实数据库 + 大模型很多时候并不面临技术上的挑战,更多的是合规性的挑战,特别是在大语言模型这个阶段。
姬朋飞:
第一个其实就是数据治理和数据清洗加工,举个例子,业务人员要技术生成一些数据,那么就需要给技术将很多需求,最后他才能生成 SQL 、产出报表,现在换成了 AI ,或许还要跟他更为详细的需求,它才能明白你的意思;第二个是数据隐私和安全性,有了 AI 之后,其实很多企业级数据的权限控制上,就需要做一些调整,才能合规使用。
趋势方面,未来向量数据库可能也是发展的一个范畴,但就目前的算力,其实相对还是比较欠缺的,未来算力成本的进一步下降,将会推动其快速发展。
苏鹏:
前段时间正好看到了微软研发员的一篇 paper ,文章中大概把我们使用的大模型分了几个级别。Level 1 类似于一个检索,Level 2 会根据问题稍微做一点推理,Level 3 对输出做一个设定好的规则,Level 4 又叫做隐形推理,面对一个新的场景,输出内容。随着级别的升高,模型推理能力也不断提升,就数据库的场景来说,未来大概率会使用到 Level 4 这一类的大模型,并且以此为基础,不断迭代,才能满足大家的需求。
END
热门文章
↓分享、在看与点赞~Orz
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-05-28
2024-04-26
2024-08-21
2024-04-11
2024-07-09
2024-08-13
2024-07-18
2024-10-25
2024-07-01
2024-06-17