前几天OPENAI发布会又成为了AI迷的一场盛宴，最近讨论这个话题的人很多，今天我也来凑凑热闹。其实从CHATGPT 3.5发布的时候开始，我就对生成式AI产生了兴趣，我当时就认为，在DBA和智能化运维领域，生成式AI会带来革命性的技术。我很快就注册了一个CHATGPT账号，并用于解决我日常的一些问题。不过很可惜在几个月后那次封账号浪潮中，我的账号被封了。注册新账号挺麻烦的，同时NewBing开始服务了，我没有再尝试去搞一个新账号，而是用NewBing替代了Chatgpt。

利用大语言模型在智能化运维领域做点事情一直是我的想法，不过因为数据库运维领域的特殊性，因此我一直在寻求可私有化部署的生成式AI解决方案。幸好规模略小的可私有化部署的大模型层出不穷，给了我做尝试的机会。曾经有两三个月，我的主要心思都在构建私有化的数据库智能生成模型上，也尝试了一些PTUNING工作。工作被证明是有效的，不过也被证明不是一般人能干的。训练所需要的硬件资源以及数量不高的高质量的样本集都是需要很高的成本的(这里的数量不高是和大模型相对应的，对于依靠专家人力来制作的模式来说，依然是很大的样本件)。这段时间虽然也尝试了自己训练模型，利用现有大模型生成SPARKSQL等工作，不过仅仅限于现有模型的应用。

相对于能力不够强的可私有化部署的模型，NewBing和ChatGPT这种巨无霸发展的十分迅速。周五我去楼下退房的时候，碰到上海的老薛。他看着酒店大堂里的几个国际时钟说：“时间同步出问题了”，我当时还打趣他说是DBA的职业病犯了，看啥都像DBA在分析故障一样。不过这玩意不经念叨，高铁刚刚开出不久，一个客户就打电话来求救。说是他们正在做Oracle到某国产数据库的复制。复制服务器上的CPU使用率很高，并发上不去，特点是SYS CPU很高。

我让他做一个perf top分析，看看哪些系统调用比较高，很快他就把perf top的截图发过来了。

罪魁祸首居然是apci_pm_read，一个多小时前和老薛打趣的场面让我很快的反应过来，是不是时钟源出问题了。于是让客户查了一下时钟源。果不其然，分布式数据库的节点上的clocksource都是tsc,只有这台复制服务器上的clocksource设置为apci_pm。而且那台服务器上的可用时钟源只有一个-“acpi_pm”，不能将时钟源设置为tsc。这个环境是一台华为的服务器，上面安装了阿里龙蜥操作系统。于是客户咨询了阿里与华为的客服，都无法得到相应的答案。我对硬件也是个半吊子，也想不出如何分析这个问题。于是想起了“万事不决问NewBing”。搜一下就可以了。

NewBing给出的答案还是比较靠谱的，可能是BIOS中关闭了TSC功能，导致了OS只能使用APCI_PM这种比较低效的时钟源了。

另外一个案例则更加神奇了，在我的微信群里，有个朋友问一个PG的SQL执行效率的问题。他发来了一个上百行的执行计划，我当时用试试的想法，问NewBing，作为一个PostgreSQL专家，你认为下面的这个执行计划存在什么问题?

执行计划过于复杂，我只截屏了一部分。

NewBing给出的答案令人惊奇。后来我花了半个多小时认真阅读了整个执行计划。我根据我多年DBA的经验发现的问题居然与NewBing的回答是一模一样的。使用Newbing来辅助我分析问题已经成为了我的工作日常。

我已经习惯了让NewBing作为我的助手，放弃了以前遇到问题找谷歌百度的习惯。谷歌与百度的不专业让我浪费了不少的时间，而NewBing从来没有让我失望，总可以让我在分析和思考某个问题的时候少走弯路。这是生成式AI日常对我的帮助。生成式AI不是万 能的，对于一些ZERO SHOT的问题，幻觉还是很严重的。很多时候生成式AI给出的答案还需要通过经验去分析其准确性。不过作为工作辅助，生成式AI还是十分有效的。

生成式AI的基础能力来自于基础模型的能力，如果基础模型能力不行，那么生成出来的答案就要大打折扣了。这也是利用ChatGPT或者NewBing的使用体验很好，但是在内网私有化部署的环境中效果就要大打折扣的主要原因。

生成式AI今后将会成为工作不可或缺的优秀助手，不过也仅限于助手，完全替代人类专家从事DBA的工作还离得很远。上个月Oracle CAB上，O记也谈到他们在生成式AI上也在加大投入，并会很快在Oracle数据库里推出一些产品。我提了是否会在METALINK中引入大模型，得到的回答是肯定的。这一点，在ASK ANDY环节，也得到了正面的回应。不过不论是ANDY还是其他O记的高管，他们都认为生成式AI存在的不准确与幻觉问题依然是目前很难解决的，因此在使用场景上是有限制的。这一点和我的感受差不多。