背景:我不想只停留在会用一开始用大模型的时候,其实很容易满足.打开 ChatGPT,问一个问题,它给你一段回答.接 API,传一个 prompt,拿到一个 response.看起来好像已经会用了.但只要开始做项目,问题马上就出来了.比如做一个项目知识库:用户问问题- 大模型回答刚开始看起来很顺.但真实情况是:1. 模型不知道我的本地资料2. 文档太长,不能全塞进去3. 检索出来的片段不一定相关4. 模型可能一本正经地胡说5. 用户需要来源,不能只给结论6. 有些问题不是问答,而是数据库查询这时候我才发现:会调用 API 只是开始.真正要把大模型用到项目里,需要理解它周围的一整套东西.不是只有模型.还有文档,向量库,数据库,工具调用,权限,评测,部署.所以这次我想慢一点.不急着堆新词.每天只拆一个问题.1.我现在最想搞清楚的几个问题我先把现在脑子里的问题列出来.第一个问题:大模型到底是什么?它不是普通的 if else 程序.但也不是魔法.它到底怎么从一段输入,生成一段输出?第二个问题:Token 是什么?为什么一句话进入模型前要被切成 token?为什么有时候中文、英文、标点都会影响 token 数?第三个问题:Embedding 是什么?我现在大概知道它是把文本变成向量.但这个向量为什么能表示语义?为什么相似的问题能找到相似的文档?第四个问题:RAG 到底靠不靠谱?前几篇已经写了一部分.但还有很多没讲:文档怎么切块?TopK 怎么选?为什么要重排?怎么判断检索结果好不好?第五个问题:微调到底该什么时候用?如果只是想让模型知道我的项目文档,那应该用 RAG.那微调到底适合什么?是风格?是格式?还是某种固定任务?第六个问题:Agent 到底是什么?如果只是模型回答问题,那是聊天.如果模型开始调用工具,读文件,查数据库,执行命令,这才有一点 Agent 的味道.但这里面风险也很大.工具权限怎么控?做错了怎么办?这些都要慢慢拆.2.这次学习不想怎么做我不想写成那种一篇文章塞满术语的东西.比如:TransformerAttentionRLHFLoRARAGAgentEval全放在一篇里,看起来很完整,但看完可能什么都没记住.我也不想一开始就上公式.不是说公式不重要.而是如果直觉没建立,公式看起来就是一串符号.所以我想按这种方式写:先问一个具体问题再解释这个概念为什么出现再用一个例子说明最后总结它能解决什么,不能解决什么比如写 Token,就不从论文开始.先从:为什么一句话会被模型切碎?开始.写 Embedding,就从:为什么 RAG 能找到语义相近的文档?开始.这样更容易跟项目经验连起来.3.准备按什么路线学目前先把路线定成 8 块.1. LLM 基础概念2. Transformer 和 Attention3. 模型训练过程4. Prompt 和模型使用5. RAG 知识库6. 微调 Fine-tuning7. Agent 和工具调用8. 评测、安全、部署这不是为了显得很系统.而是为了避免学习顺序乱.我之前就是乱跳.今天看 RAG,明天看 Agent,后天又看到 LoRA.每个都知道一点,但很难说自己真的理解.这次按顺序来.先把基础概念打稳,再往应用层走.4.第一阶段先学什么第一阶段先从这些问题开始:大模型到底是什么?Token 是什么?Embedding 是什么?上下文窗口是什么?为什么模型是在预测下一个 token?这些东西看起来基础,但后面都要用.比如 RAG 里会用到 Embedding.Prompt 里会受上下文窗口限制.模型生成答案时,本质上还是在一步步预测 token.如果这些没弄明白,后面很多概念都只能硬背.我不想硬背.我想知道它们为什么会这样设计.5.后面会怎么接到项目里这次学习不是纯理论.我还是会尽量和实际项目连起来.比如:RAG 会对应项目知识库数据库查询会对应配置表筛选Docker 部署会对应后端服务Agent 会对应工具调用和自动化流程评测会对应发布前怎么判断答案是否可靠也就是说,最后不是为了写一堆概念笔记.而是为了能回答:如果我要做一个真实的大模型应用,我到底该怎么设计?比如这个结构:用户问一个问题.模型不一定直接回答.它可能要:查知识库查数据库调用工具拿到结果再组织答案这才像一个能落地的系统.6.这个系列准备怎么写我准备给自己定一个简单规则:每天一篇.每篇只讲一个核心问题.不追求一次讲完.能用例子说明就不用空话.能画流程就画流程.每篇文章大概按这个节奏:0. 为什么要学这个1. 先定义一个问题2. 这个概念是什么3. 它是怎么工作的4. 放到项目里会怎么用5. 容易误解的地方6. 总结这样一篇不会太散.也方便后面串起来.7.总结这篇主要是给后面的系列开个头.我现在想清楚的一点是:LLM 不是只学一个模型.LLM 应用也不是只调一个接口.