DEEPSEEK出现后在DBA领域有两种声音，第一种声音是伟大的技术进步，以后数据库的AIOPS发展的道路变得平坦了;另外一种声音截然相反，大模型幻觉解决不了，基于大模型的AIOPS还是个玩具。

两种观点都太过极端，第一种想法犯了几年前AI大热时候的相同的错误。当时有一种十分热门的观点，那就是数学家将会替代运维专家，解决运维中的所有难题。遇到问题，不再需要专家绞尽脑汁冥思苦想来了，只需要通过各种AI算法去计算，就能帮助用户解决问题。当时就有一个用户兴奋地和我说，我们可能不需要继续做知识工程就能解决运维中的大部分难题了。事实上，几年后，大家都清醒了，这个伟大的转折并没有发现。AIOPS并没有帮助用户摆脱对运维专家的依赖，甚至有些AIOPS项目因为缺乏高质量的数据而只能长时间作为一个DEMO存在。

在我的一个客户那边交流D-SMART的时候，他突然问我，你的数据能否开放给我的AIOPS平台?后来我们去试了，效果真的不错，他们的AIOPS算法确实是不错的，在专业的数据和专家模型的帮助下，用户的这套以算法为核心的AIOPS系统被盘活了。算法只能提高计算和推理的能力，提高数据分析和处理的效率，离开知识工程，算法就变成了一个纯粹的数学方法，很难把计算结果与运维经验真正的关联起来。

现阶段，想依靠deepseek的能力完全替代专家，和当年AIOPS替代专家一样遥不可及。哪怕是满血的deepseek 671b模型，里面的数据库领域知识恐怕都还是不足以匹敌真正的专家的。更何况在deepseek里，国产数据库的运维知识更加缺乏，哪怕在Oracle、MySQL上有一定的效果，到了国产数据库领域，可能还是需要大规模的知识工程才行。

持第二种观点的人，一般来说就是本地化部署了一个模型，找了几个问题去和它对话了几次，觉得本地化部署的模型能力不行。而企业用户的数据库又无法与互联网互通，无法直接使用互联网上的满血模型，因此他们给出的结论是AIGC因为存在幻觉，因此是无法使用的。

我昨天做了一个实验，在我本地化部署的一个deepseek-r1 32b的模型上，我从运维工具和知识图谱中抽取出了某个问题相关的知识，组成了一个5000多个字的背景介绍，然后让大模型去推理根因，经过背景知识数据后给出的回答比仅仅提出一个简单的问题要准确得多，上面图中的回答基本上把问题分析得挺清楚了，只是后面的归纳还不够收敛和准确。这是因为我给它得相关知识还不够细致与准确。我想随着知识工程的深入，这个回答会越来越好。

deepseek模型不是万 能的，因此你也不能指望它一诞生就无所不能地帮我们去解决所有的问题，一发现它存在缺陷就认为这玩意没用。我们可以通过自己的工程化努力让它更好地帮我们做我们想它帮我们完成的工作。我们不一定有资金去搞自己的数据库领域大模型，不过通过RAG构建知识库或者通过运维知识图谱去获得更高质量的知识，然后再去和大模型对话，很可能能够解决目前大模型存在的大部分幻觉问题。

我今天讨论的问题，就是希望持那些极端观点的小伙伴，可以多看看，多想想办法，如何把能够让deepseek成为你的好帮手，而不是想办法把它打死。它是打不死的，因为它的出现已经为开启一个AIOPS的新时代提供了足够的助力。