AI、机器学习、深度学习、大模型到底是什么关系?
刚开始接触 AI 时,最容易遇到的第一个问题,不是代码不会写,而是名词太多。
AI、Machine Learning、Deep Learning、Neural Network、Transformer、Generative AI、LLM……
这些词经常出现在同一篇文章里,有时候甚至被混着使用。看得多了,很容易产生一种感觉:好像都和 ChatGPT 有关,但又说不清它们到底是什么关系。
对于 DBA 来说,其实没必要一开始就研究这些技术的严格学术分类。我们更需要先建立一张完整的地图,知道自己现在学的东西处于什么位置,后面再碰到 Embedding、RAG、Agent 时才不会越学越乱。
这就像刚接触数据库时,至少得知道 Oracle、MySQL、PostgreSQL 都属于数据库产品,但数据库这个概念远远不只有 Oracle。AI 也是一样,大语言模型现在很火,但 AI 并不等于大语言模型。
AI 是最大的那个概念
Artificial Intelligence,也就是人工智能,是这些概念里范围最大的一个。
它研究的问题可以简单理解成:怎么让机器完成一些过去需要人类智能才能完成的任务。
比如识别图片里的物体、理解自然语言、下棋、做推荐、语音识别、自动驾驶,这些都可以放在 AI 的大范围里讨论。
所以 AI 并不是 ChatGPT 出现以后才突然有的技术。
早在今天的大语言模型出现之前,AI 已经发展了几十年。早期有专家系统、知识表示和符号推理,后来机器学习逐渐成为重要路线,再往后神经网络和深度学习快速发展,才一步一步走到今天的大语言模型。
Microsoft 的AI-For-Beginners课程里,甚至专门保留了 Symbolic AI、Knowledge Representation 和 Expert Systems。这些东西今天没有 LLM 那么热门,但如果回头看 AI 的发展过程,它们并不是无关紧要的旁支。
这也是为什么把 AI 直接理解成 ChatGPT 并不准确。
ChatGPT 只是我们今天接触 AI 最方便的一个入口。
Machine Learning 改变了什么?
传统程序最容易理解。
假设我们要做一个数据库表空间告警程序,可以直接写规则:
iftablespace_usage>90:send_alert()规则是谁定义的?
DBA。
程序本身不会研究为什么 90% 是风险线,也不会根据过去几年的表空间变化自动总结新的判断方法。开发人员告诉它什么条件,它就按照什么条件执行。
Machine Learning,也就是机器学习,思路有所不同。
我们不一定把所有判断规则提前写死,而是给算法提供大量历史数据,让模型从数据中寻找能够完成任务的模式。
比如我们积累了几年的数据库运行数据,里面包括 CPU、Active Session、IO Latency、DB Time、TPS、等待事件,同时还标记了哪些时间段发生过性能异常。
传统程序可能需要 DBA 自己总结规则:
CPU 超过多少算异常,Active Session 到什么程度算危险,IO Latency 多高需要告警。
机器学习则可以尝试根据历史数据学习这些指标与“数据库是否异常”之间的关系。
当然,真实数据库性能问题远远没有这么简单,这里只是用 DBA 熟悉的场景帮助理解。
真正需要记住的是:
传统程序主要依赖人写规则,机器学习则尝试从数据中学习能够完成任务的模式。
这也是为什么数据在机器学习里如此重要。
如果训练数据本身就是错的,模型很难凭空得到一个正确结果。这一点和 DBA 应该很好理解:统计信息严重失真时,再好的 Optimizer 也可能做出错误选择。
Machine Learning 其实离 DBA 并不远
机器学习听起来像一个和数据库运维距离很远的领域,但如果仔细看,很多数据库产品早就在使用类似技术。
比如异常检测、负载预测、SQL 性能预测、自动参数调整、资源调度,都可以结合机器学习方法。
云数据库厂商这几年大量宣传的 Autonomous Database、智能诊断、异常检测,本质上也都在尝试减少人工规则的比例,让系统根据历史数据和当前状态做更多判断。
当然,这并不意味着所有所谓“智能数据库”背后都是同一种机器学习算法。不同产品的实现方式差别很大。
但方向是比较清楚的:数据库运维正在从完全依赖固定规则,逐渐加入越来越多的数据驱动能力。
Deep Learning 又是什么?
机器学习里面有很多不同的方法。
比如 Linear Regression、Decision Tree、Random Forest、SVM,这些都属于机器学习领域常见的方法。
神经网络也是其中非常重要的一类。
当神经网络的层数越来越多,模型能够学习更加复杂的表示时,就进入了我们经常听到的 Deep Learning,也就是深度学习。
这里的“Deep”,可以先简单理解成网络变得更深。
早期简单神经网络可能只有少量层,而现代深度神经网络可以拥有非常复杂的结构和大量参数。
这也是为什么我们在前面的课程规划里专门安排了几篇文章讲 Neural Network。
不是因为 DBA 以后要天天训练神经网络,而是因为如果完全不知道神经网络是什么,直接学习 Transformer 和 LLM,很多概念会变成死记硬背。
比如以后经常会看到:
Parameter、Weight、Layer、Activation、Training、Inference。
这些词都和神经网络基础有关。
那 Transformer 又是从哪里冒出来的?
神经网络并不是只有一种结构。
不同问题曾经发展出不同的网络架构。
Computer Vision 领域大量使用过 CNN,自然语言和序列处理领域则长期使用 RNN、LSTM 等结构。
2017 年,一篇后来影响非常大的论文《Attention Is All You Need》提出了 Transformer 架构。
Transformer 对今天 AI 最大的影响之一,就是它后来成为现代大语言模型的重要技术基础。
我们熟悉的 GPT,名字其实已经把这件事写出来了。
GPT 的全称是:
Generative Pre-trained Transformer。
Generative 是生成式,Pre-trained 是预训练,最后那个 T 就是 Transformer。
所以 Transformer 并不是一个和神经网络、大语言模型完全独立的新概念。它本身就是一种神经网络架构。
后面我们会单独用一篇文章解释 Attention 和 Transformer。这里暂时只需要知道它在整张 AI 技术地图中的位置。
LLM 到底是什么?
LLM 是 Large Language Model,也就是大语言模型。
这个名字其实已经给出了两个重要信息。
首先是 Language。
它主要围绕语言进行建模,所以非常擅长处理文本。这也是为什么它可以写文章、解释 SQL、总结日志、生成代码。
其次是 Large。
现代 LLM 往往拥有很大的参数规模,也使用大量数据和计算资源进行训练。
我们现在熟悉的 GPT、Claude、Gemini 等模型或模型家族,都属于今天大语言模型生态中的代表。
但有一点一定要注意:
LLM 属于 AI,但 AI 远远不只有 LLM。
这就像 Oracle 属于数据库,但不能说数据库就是 Oracle。
如果把这个关系搞清楚,后面很多概念就不会混在一起。
Generative AI 和 LLM 是不是一回事?
也不是。
Generative AI 是生成式人工智能,关注的是生成新的内容。
它可以生成文本,也可以生成图片、音频、视频和代码。
LLM 主要围绕语言建模,因此属于 Generative AI 里非常重要的一部分,但生成式 AI 的范围显然更大。
比如我们现在使用 AI 生成公众号封面图,这也是 Generative AI,但背后的模型并不一定是一个纯文本大语言模型。
所以如果有人说“生成式 AI 就是 ChatGPT”,严格来说也是把范围缩得太小了。
把这些概念放在一起就清楚了
到这里,其实可以形成一张比较清晰的关系图。
AI 是最大的范围,Machine Learning 是今天实现 AI 的重要路线之一;Deep Learning 又是机器学习的重要分支,神经网络是深度学习的核心技术基础;Transformer 是一种对现代语言模型影响很大的神经网络架构,而 LLM 则是在这些技术长期发展基础上形成的大规模语言模型。
Generative AI 则从“能生成什么”这个角度描述另一类 AI 应用和模型能力,它和 LLM 有很大的交集,但并不是完全等价的上下级关系。
这部分非常适合用一张关系图表达,单靠文字反而容易绕。
如果把这些概念的位置记住,后面再看到 RAG、Agent、MCP 时,还需要再区分一件事:它们并不是和 LLM 同一级别的“模型”。
RAG 更像一种让模型使用外部知识的应用架构,Agent 则让模型能够围绕任务调用工具,MCP 解决的又是 AI 应用与外部工具、数据源之间的标准化连接问题。
这也是为什么我们要先把基础地图画清楚。
DBA 到底需要学到哪一层?
如果目标是做 AI 算法研究,那么机器学习、深度学习、数学和模型训练都值得深入。
但 DBA 没必要把所有方向都学成专业水平。
我们的学习重点会有所取舍。
机器学习和深度学习需要理解基本思想;神经网络要知道模型、参数和训练是怎么回事;Transformer 要理解 Attention 和上下文处理;到了 LLM,则要真正搞清 Token、Embedding、Context Window、Inference 和 Hallucination。
再往后,重点会逐渐转向 AI 应用工程。
因为 DBA 真正容易产生价值的地方,大概率不是自己训练一个几百亿参数的大模型,而是把已经很强的大模型接到企业自己的数据库、监控、文档和运维工具上。
比如让 AI 读取内部 Oracle 故障案例,这是 RAG。
让 AI 查询 PRODDB 当前表空间,这是 Tool Calling。
让 AI 自己判断为了分析数据库性能应该先查负载还是先查阻塞,这是 Agent。
让不同 AI 客户端以比较统一的方式访问 Oracle、MySQL、Prometheus 等工具,则会涉及 MCP。
这样一路学下来,我们不是从 DBA 跳出去重新学一个完全陌生的行业,而是在原来的数据库能力上增加一层 AI 能力。
为什么这一篇值得先讲?
因为后面的很多文章都会不断出现这些词。
如果最开始没有建立整体关系,很容易今天学 Embedding,明天学 Transformer,后天又看到 RAG,最后脑子里堆了几十个英文缩写,却不知道谁属于模型、谁属于数据表示、谁属于应用架构。
DBA 学 Oracle 也不会一上来就背 100 个动态性能视图。
通常先知道 Instance、Database、SGA、PGA、Redo、Undo 大概是什么,再逐渐深入细节。
AI 也应该一样。
先有地图,再往里面走。
现在地图有了,下一步就可以进入一个真正有意思的问题:
所谓“模型”,到底是什么?
AI 并不会凭空获得能力。它需要数据,需要训练,也需要不断调整大量参数。
下一篇我们就来看看,这个过程到底发生了什么。
《AI 到底是怎么“学会”东西的?》
