上一篇算是把这个系列开了个头.

我当时给自己定了一个目标:

不要只停留在会调 API.

要把大模型从原理到落地这条路慢慢走一遍.

那今天就从最基础的问题开始:

大模型到底是什么?

这个问题看起来简单.

但真要说清楚,其实不容易.

因为它很容易被讲得特别玄.

比如有人会说它在思考.

也有人会说它只是概率接龙.

这两个说法都有一点道理,但如果只记这两句话,还是很难落到项目里.

所以这篇我想换一个角度:

先不急着讲论文.

先拿普通程序和大模型对比一下.

看看它到底和我们平时写的代码有什么不一样.

0.背景:我一开始把它想简单了

刚开始用 ChatGPT 的时候,我其实很自然地把它当成一个更聪明的搜索框.

我问:

Docker 怎么部署 Go 后端?

RAG 是什么?

这个错误怎么解决?

它回答得很顺.

所以很容易产生一种错觉:

大模型 = 一个知识很多的问答系统

但后面写 RAG 的时候,我发现这个理解不够.

因为如果大模型真的是一个知识库,那它应该能精确查资料.

但它不能.

如果大模型真的是一个数据库,那我问:

筛选出所有攻击力大于 50 的装备

它应该像 SQL 一样稳定.

但它也不适合直接干这个.

所以我开始意识到:

大模型不是数据库.

大模型也不是搜索引擎.

它更像一个基于上下文生成文本的模型.

这句话听起来有点抽象.

我们慢慢拆.

1.普通程序是怎么工作的

先看我们熟悉的普通程序.

比如写一个简单的规则:

def check_attack(power: int) -> str:

if power > 50:

return "高攻击装备"

return "普通装备"

这个程序的特点很明确:

规则是人写死的.

输入一样,输出基本一样.

程序不会自己发挥.

它不理解什么叫"强".

它只知道:

power > 50

满足条件就返回高攻击装备.

不满足就返回普通装备.

这种程序很可靠.

只要规则写对,它就会按规则执行.

但它的问题也很明显:

规则没写到的地方,它就不会.

比如你问它:

这件装备适合刺客还是战士?

如果代码里没有写职业判断逻辑,它就回答不了.

普通程序更像这样:

输入

-> 人写好的规则

-> 按步骤执行

-> 输出

2.大模型不是按 if else 在回答

大模型不一样.

你问它:

这件装备攻击力 60,暴击率 20%,适合什么角色?

它不是在代码里找一个固定的 if else.

它更像是在看这段文本:

攻击力 60

暴击率 20%

适合什么角色

然后根据训练中学到的语言规律,项目知识,上下文线索,去生成一个最可能接得上的回答.

流程大概是:

用户输入

-> 切成 token

-> 进入模型计算

-> 预测下一个 token

-> 再预测下一个 token

-> 拼成完整回答

注意这里最关键的是:

它不是一次性吐出整篇答案.

它是一点点生成的.

比如回答:

这件装备更适合刺客.

对模型来说,它不是一下子把这句话拿出来.

而是类似这样:

这

这件

这件装备

这件装备更

这件装备更适合

这件装备更适合刺客

当然真实过程不是按中文词这样切,而是按 token.

但先这样理解就够了.

3.那"大"到底大在哪里

LLM 里面的 L 是 Large.

这个"大",不是说它脾气大.

而是几个东西都很大:

参数量大

训练数据大

计算量大

上下文处理能力越来越大

参数可以先粗暴理解成:

模型内部学到的调节旋钮.

普通程序里,规则是人写的.

大模型里,很多能力不是人一条条写进去的,而是通过大量文本训练出来的.

训练时,模型不断做一件事:

给它前面的文本,

让它预测后面应该出现什么.

预测错了,就调整参数.

调整很多很多次以后,它就慢慢学会了一些东西:

语法

常识

代码格式

问答方式

文章结构

不同概念之间的关系

所以它看起来像会回答问题.

但底层更接近:

根据上下文,生成最合理的后续文本.

4.为什么它能回答很多没见过的问题

这个地方很容易误解.

有人会觉得:

模型回答出来了,说明它训练时见过原文.

不一定.

大模型不是简单背书.

它确实可能记住一部分训练内容,但更重要的是,它学到了大量语言模式和知识关系.

比如它学过很多类似内容:

Docker 用来打包应用

Nginx 可以做反向代理

PostgreSQL 是关系型数据库

Go 可以写后端服务

当你问:

Go 后端怎么用 Docker 部署?

它就能把这些模式组合起来,生成一个看起来合理的方案.

这也是它强的地方.

它不是只能回答固定问题.

它可以组合.

但这也是它危险的地方.

因为它组合出来的东西,不一定就是你项目里的真实情况.

比如它可能会编一个端口:

服务运行在 8080 端口.

但你的项目实际可能是:

服务运行在 8888 端口.

这时候它不是故意骗你.

它只是根据常见模式生成了一个看起来合理的答案.

这就是为什么后面需要 RAG.