完整学习LLM(二):大模型到底是什么
好家伙,
上一篇算是把这个系列开了个头.
我当时给自己定了一个目标:
不要只停留在会调 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.
因为项目事实不能只靠模型自己猜.
5.一句话理解大模型
如果先不追求严谨,我现在会这样理解 LLM:
LLM 是一个经过大量文本训练后, 能够根据上下文不断预测下一个 token, 最终生成自然语言、代码、结构化内容的模型.
这句话里面有几个关键词.
第一个:
大量文本训练
说明它的能力来自训练数据和训练过程.
第二个:
上下文
说明你给它什么信息,会直接影响它怎么回答.
第三个:
预测下一个 token
说明它的生成过程不是查表,而是一步步续写.
第四个:
生成
说明它擅长的是组织答案,解释内容,改写文本,写代码,总结材料.
但它不是天然适合做所有事.
6.它适合什么,不适合什么
大模型适合做什么?
我现在会先列这些:
解释概念 总结文档 改写表达 生成代码草稿 根据上下文组织答案 把零散信息整理成结构
这些任务都有一个共同点:
不是只要一个精确值. 而是需要理解、组织、表达.
那它不适合什么?
比如:
精确筛选数据库记录 严格计算金额 判断权限是否允许 直接当唯一事实来源 在没有资料时回答项目内部细节
这些事情不是不能和大模型结合.
而是不能只靠大模型.
比如:
筛选攻击力大于 50 的装备
应该让数据库或配置表查询来做.
大模型可以负责理解用户意图:
用户想筛选装备. 筛选条件是攻击力 > 50.
但最终筛选应该交给确定性的程序.
这就是我之前写 RAG 边界时想表达的东西.
大模型很强,但它不是所有问题的唯一答案.
7.放到项目里怎么理解
如果我要做一个真实的大模型应用,我不会把结构设计成:
用户问题 -> 大模型 -> 答案
这个太简单.
真实一点应该是:
用户问题 -> 大模型理解意图 -> 判断需要什么资料或工具 -> 查知识库 / 查数据库 / 调 API -> 把结果交回大模型 -> 大模型组织最终答案
也就是说:
模型负责理解和表达. 系统负责事实和动作.
这句话我觉得很重要.
因为很多大模型项目出问题,就是把模型当成了整个系统.
但模型只是核心组件.
它旁边还需要:
文档检索 数据库查询 权限控制 工具调用 日志记录 效果评测
这些东西组合起来,才像一个能落地的应用.
8.容易踩的几个坑
第一个坑:
把大模型当知识库.
它知道很多通用知识,但不知道你的私有资料.
第二个坑:
把大模型当数据库.
它可以帮你生成 SQL,但不应该自己凭感觉筛数据.
第三个坑:
把大模型当绝对正确的老师.
它说得很流畅,不代表它一定对.
第四个坑:
以为 prompt 能解决所有问题.
Prompt 很重要,但如果缺少事实数据、工具能力、权限边界,光调 prompt 没用.
第五个坑:
上来就问怎么微调.
很多问题不是微调问题.
可能只是上下文没给够.
可能应该用 RAG.
也可能应该查数据库.
9.总结
这篇先不讲 Transformer,也不讲 Attention.
只先把大模型放到一个比较朴素的位置上:
它不是普通 if else 程序. 它不是数据库. 它不是搜索引擎. 它是一个根据上下文生成内容的模型.
再压缩一下:
普通程序按规则执行. 大模型按上下文生成.
这就是今天最想记住的区别.
理解了这一点,后面很多东西就好接了.
比如:
为什么 prompt 会影响输出? 为什么 RAG 要把资料放进上下文? 为什么模型会胡说? 为什么同一个问题每次回答可能不同? 为什么它是一点点生成答案?
下一篇就顺着这个问题往下走:
为什么大模型本质上是在预测下一个 token?
也就是看看模型生成一句话时,背后到底在发生什么.