最近被问得最多的一个问题是：AI大模型到底该怎么学。
问的人背景五花八门，有做Java后端想转方向的，有刚毕业的学生，也有产品经理和测试想往AI应用开发靠。大家普遍的反应是：资料太多、概念太杂、GPU太贵，打开一篇技术文章看十分钟就关了，刷了几十个教程还是不知道自己下一步该干什么。
我自己的经历也差不多。最早接触大模型的时候，看到Transformers、Attention、Fine-tuning这些词第一反应是头大，然后陷入“理论基础没补完不敢动手”的死循环。后来被一个做算法优化的朋友点醒：别把大模型当数学课学，把它当一个新工具去用，先把模型跑起来，再回头补原理，效率会翻好几倍。
这篇文章我会按照我实际走过的路线来写，从理论、实践、部署、应用开发到进阶学习，尽量把“每个环节该学什么、要学到什么程度、花了多少时间、踩了哪些坑”都讲透。如果你正卡在选择焦虑里，或者已经在学但感觉进度很慢，希望这篇文章能帮你把路线捋直。
1. 先说清楚：为什么这条路线能提升核心竞争力
1.1 AI大模型催生了什么样的新岗位需求
过去一年里，市场对AI人才的需求变化非常明显。早两年大家招的主要是算法工程师，要求数学功底好、能训练模型、能发论文。现在的情况不一样了，真正稀缺的反而是能把大模型用起来的人。
这类岗位的岗位描述里通常写着：熟悉LangChain、了解RAG、会调Prompt、能部署开源模型、懂模型评测。你会发现这些技能没有一个需要你从零训练模型，而是要求你在大模型的生态里做集成、优化和应用落地。
根据我观察到的情况，当前大模型相关岗位大致可以分成几类：
- 大模型算法工程师：做预训练、继续预训练、指令微调、RLHF，需要扎实的数学和深度学习基础。
- 大模型应用开发工程师：做RAG、Agent、工作流编排、外部工具接入，核心是把大模型嵌入业务系统。
- 大模型平台/运维工程师：做私有化部署、推理加速、显存优化、模型服务化。
- 大模型产品/解决方案：设计AI产品功能、评估模型效果、制定落地方案，需要懂技术边界。
这里面需求量最大、门槛相对友好的是应用开发方向。对大多数后端、前端、测试转岗的人来说，这个方向也是最快出成果的切入点。
1.2 学习这条路线要拿到的核心能力
很多人学习大模型的时候目标很模糊，今天看一篇注意力机制原理，明天试一个AI绘画工具，后天又去研究大模型幻觉问题，学了一个月感觉什么都懂一点，但什么都做不出来。这是典型的目标缺失。
我在规划自己的学习路线时，把最终目标抽象成了五个可验证的能力，你可以对照着检验自己有没有及格：
- 能说清楚大模型的基本原理和工作过程，不会被参数、Token、上下文窗口这些概念绕晕。
- 能在一台普通电脑或云服务器上把开源模型部署成可调用的服务，并且知道不同部署方案的优缺点。
- 能调用API或本地模型完成一个完整的AI应用，比如知识库问答、文档总结、对话机器人。
- 能对模型输出质量进行评估，知道模型在什么场景下会出错，能通过Prompt或RAG解决一部分问题。
- 能阅读开源项目的源码和文档，具备持续学习和解决报错的能力。
这五个能力里，考的不是理论深度，而是“能不能把事做成”。只要你能独立把一个小项目跑通，从面试官到业务领导都会认为你具备实战能力。
2. 理论打底：不啃完数学也能吃透大模型原理
2.1 机器学习与深度学习的最小必要知识
一说理论和数学，很多人就害怕，觉得要先把微积分、线性代数、概率论学完才能开始。坦白讲，如果你的目标是做应用开发，根本不需要那么深的数学功底。但有几个核心概念必须理解到位，否则后面读文档和技术文章会非常吃力。
梯度下降是第一个要搞懂的。你可以把它想象成下山：你在山顶，雾很大看不清路，只能感受到脚下的坡度，每次沿着最陡的方向迈一步，就能慢慢走到山谷。模型训练就是在找一个让损失函数值最小的参数组合，损失函数衡量的是模型预测结果和真实答案的差距。
过拟合是另一个高频概念。这相当于学生死记硬背了练习册的所有答案，看起来每次都能答对，可考试题目稍微一变就不会了。模型如果只记住了训练数据，泛化能力就差。遇到这种情况我们通常会用早停、Dropout、正则化、数据增强来缓解。
深度学习的核心是神经网络，大模型本质上就是一个层数特别多、参数特别多的神经网络。你不需要能手推反向传播公式，但对“网络通过前向传播计算输出、通过反向传播调整参数”这个循环要有清晰的画面感。
当我还在补这些基础的时候，其实有点急，总觉得像在做和AI大模型无关的事。后来回头看，这些概念是在后面排错和理解微调时反复要用到的自变量，值得花两周时间稳稳过一遍。
2.2 Transformer架构与注意力机制一次讲透
聊大模型，绕不开Transformer架构。从GPT、LLaMA、ChatGLM到Qwen，主流大模型的基本框架都建立在Transformer之上。想绕开它直接学应用，短期可以，长期必然出问题。
Transformer的核心是自注意力机制。用生活化的方式理解：读一句话的时候，你会刻意关注某些词来理解整句含义。比如“那只没戴项圈的狗在公园里追松鼠”，你会自动把“狗”和“追”关联起来，这就是注意力的作用。自注意力机制让模型在处理每个词的时候，可以同时查看句子里其他所有词，并根据相关性分配不同的注意力权重。
具体实现上，Transformer会把每个词表示成三个向量：Query（查询）、Key（键）和Value（值）。你可以这样想：Q是你在图书馆里提出的问题，K是书脊上的检索标签，V是书的内容。系统先拿Q和所有的K做匹配打分，再用分数去加权提取相应V的信息。所有词并行执行这个操作，就有了多头注意力——相当于同时派出多组“检索员”，每组关注不同的关系维度。
另一个关键设计是位置编码。因为注意力机制本身不在乎词的先后顺序，“狗追猫”和“猫追狗”如果不加位置信息，模型看到的是完全一样的向量集合。位置编码就是给每个词附加一个代表它在句子里位置的标记，模型才能感知语序。
我做了一个简单的对比表帮大家理解传统方法和Transformer的区别：
- 传统RNN：逐词处理，一步依赖前一步，速度慢且长距离信息容易丢失。
- 传统CNN：局部窗口感知，感受野有限，很难直接捕捉全局关系。
- Transformer：所有词并行计算，靠注意力直接建立任意两个词之间的联系，长距离依赖能力强，适合用GPU大规模并行加速。
正文里你只要记住一句话：Transformer让大家可以同时看到全部上下文，并用注意力机制自动决定该关注哪些内容。大模型的很多能力，就好像这句话在参数规模放大之后涌现出来的副作用。
2.3 生成式大模型的关键机制
理解了Transformer，下一个要认清的是大模型到底在做什么。很多人以为ChatGPT是在“理解”问题并“思考”答案，但实际上，绝大多数大模型的核心任务只有一个：预测下一个Token。
Token你可以理解成模型处理文本的最小单位。它可能是一个中文词语，也可能是半个英文单词。模型每生成一个新Token，都是在根据前面已经生成的所有Token，从词表里的几十万个候选项里计算概率分布，挑出最可能的一个或按采样策略随机抽一个。整个多轮对话，就是一个不断循环的“滑动窗口预测”过程。
这个设计就引出了几个关键概念：
- 预训练：先用海量互联网文本训练模型把“下一个词”预测准确，这个阶段让模型学到了大量语言知识和世界常识，类似人的“通识教育”。
- 指令微调：预训练模型只会续写，不一定能回答问题。于是用一批“用户指令-期望回答”的数据继续训练，让模型学会服从指令、格式化输出。
- 人类反馈强化学习：在指令微调之后，再让人类对模型回答排序，用强化学习去优化模型的偏好，让它更符合人类期待的对话风格。
还有一个实践中高频使用的概念：上下文窗口。它指的是模型一次能处理的最大Token数量，超出这部分的内容会被截断或报错。不同模型的窗口大小差异很大，做应用时要提前确认。
最后是温度和采样参数。Temperature越低，模型越倾向于选概率最高的Token，输出更稳定；Temperature越高，随机性越强，输出更有创造性。我在做知识库问答的时候一般设为0.2左右，做头脑风暴或文案生成时会调到0.7以上。
3. 动手实践：从环境搭建到本地部署一个完整模型
3.1 硬件选型与模型参数量级
理论到了这里先暂停，因为如果不实操，上面的概念很快会忘。我的建议是：这一章的内容要尽量跟着做一遍。
本地部署大模型，首先要面对的是硬件问题。很多人一听到“大模型”三个字就觉得必须要有好几张A100显卡才行。其实，那是预训练和全量微调的需求；如果你只是想推理和做应用，消费级硬件完全够用。
决定能不能跑起来的关键因素是显存。模型加载到GPU时，模型参数占用的空间可以粗略用公式估算：显存约等于模型参数量乘以每个参数需要的字节数。比如70亿参数的模型，用FP16半精度加载，每个参数占2字节，那么基础显存就是14GB。再加上推理过程中的KV Cache和CUDA上下文开销，实际需要16GB左右。
但如果你使用量化技术，参数体积会明显缩小。业界常见的做法是把模型量化为4位或8位精度。以70亿参数模型为例，4位量化后模型文件大约只有4GB到5GB，一张8GB显存的显卡也能勉强跑起来，只是速度会慢一些。
我列一个不同参数量模型的选型参考表：
- 1B-3B模型：模型文件3GB-6GB，可在CPU或老显卡上运行，适合文本分类、标题生成等简单场景。
- 7B-9B模型：模型文件15GB（FP16）或5GB左右（Q4量化），推荐16GB以上显存，是目前性价比最高的规模。
- 14B-20B模型：实际运行约需16GB-32GB显存，适合对效果有更高要求的场景。
- 70B及以上模型：模型文件约140GB（FP16）或40GB左右（Q4量化），至少需要48GB显存或多卡并行，个人用户通常借助云服务器。
如果你还没有显卡，可以先用Google Colab的免费GPU或者国内各大云平台的按量付费GPU实例，先跑通流程再考虑买硬件。买卡的话，消费级市场最常用的两张是NVIDIA RTX 3090 24GB和RTX 4090 24GB，二手价格现在也相对合理，是目前玩开源模型的性价比之选。
3.2 本地部署：一行命令跑通开源模型
硬件确认好之后，部署本身没有想象中复杂。我最早接触的部署工具是Hugging Face的Transformers库和命令行工具，后来发现Ollama对新手更友好，它把所有复杂的东西包装成了简单命令。
以Ollama为例，以下是基本步骤：
- 到Ollama官网下载对应系统的安装包并完成安装。
- 打开终端，执行拉取并运行模型的命令。
- 命令执行后会进入交互式对话框，直接输入问题就能得到回答。
- 如果想通过HTTP接口调用，执行以下命令查看API信息。
实际使用中，我用Ollama部署最多的模型是Qwen系列。它是中文场景下综合表现非常突出的开源模型。部署命令很简单：
ollama run qwen2.5:7b第一次执行时Ollama会自动下载模型，之后就是纯离线推理。整个流程熟练后，十分钟就能从零部署好一个能用的对话大模型。
如果你需要更高的并发能力，或者要做到生产级的服务，Ollama可能不够用。这时候推荐考虑vLLM，它实现了高效推理优化，吞吐量通常远超原生实现，但配置也更复杂。大多数学习和个人项目阶段，Ollama完全够用。
3.3 调用大模型接口与参数调优
模型跑起来之后，下一步是通过代码调用它。Ollama启动后会默认在本地的11434端口开放一个兼容OpenAI格式的API，你可以用任何编程语言来调用。
下面是我常用的一段Python示例：
import requests response = requests.post( "http://localhost:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是严谨的AI助手，回答要简洁准确。"}, {"role": "user", "content": "用一句话解释Transformer是什么"} ], "temperature": 0.3, "max_tokens": 512 } ) print(response.json()["choices"][0]["message"]["content"])这段代码里，system字段用来设定角色，temperature控制随机性，max_tokens控制最大输出长度。这都是实践中最常调节的参数。
同样用Python，你也可以使用openai官方库连本地接口，只需要改一下base_url：
from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) chat_response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "介绍一下你自己"}] ) print(chat_response.choices[0].message.content)我踩过的最大的坑是不知道本地模型没有联网能力。刚开始我以为提任何问题模型都能回答，后来发现问“今天天气怎么样”时，模型说得头头是道但全是编的。这其实引出了一个重要概念：大模型的知识是有截止日期的，它的“记忆”来自训练数据，无法实时获取新信息。解决办法是下一章要讲的RAG，通过检索外部资料喂给模型，相当于给它配了一个外挂知识库。
4. 应用开发：学会让大模型真正干活
4.1 提示词工程：这是性价比最高的技能
如果你的目标是做应用开发，那么提示词工程是你绕不开的第一步，也是投入产出比最高的技能。我不认为人人都要背什么“角色+任务+要求”三要素公式，但掌握一些基本设计原则，确实能让模型输出质量提升一大截。
第一个原则是明确角色和输出格式。比如你想让模型输出Markdown格式的工作周报，不要只说“帮我写周报”，要提供你的项目名称、本周重点、下周计划和目标输出格式。
第二个原则是提供示例。少样本提示的效果通常比单纯描述好得多。你给两个“输入-输出”对示例，模型就能迅速学会你想要的样子。
第三个原则是引导思考过程。对复杂问题，可以要求模型“一步一步思考”，这能显著提高推理准确性。
我也经常看到一些人把Prompt写得极其复杂，一个提示词包含几百个条件，最后模型输出反而更混乱。我的经验是：优先用简洁明确的指令，复杂需求拆分成多轮对话或工作流，而不是寄希望于一个万能提示词。
4.2 检索增强生成：让模型接入你自己的知识库
RAG是目前大模型应用开发里最核心的方向。它的作用非常直接：给大模型外挂一个能随时查询的知识库，先根据问题检索相关内容，再把检索结果和问题拼接成Prompt送给模型，让模型基于新资料作答。
为什么要用RAG？因为大模型的训练成本太高，不可能为了你公司的内部知识重新训练一遍模型。而RAG不需要改模型的任何参数，只改造了模型的外部输入，就能让模型“知道”你的私有知识。
一个标准的知识库问答实现流程如下：
- 加载文档：把PDF、Word、Markdown等不同格式的文档读取为纯文本。
- 文本切分：根据段落或固定长度把长文本切成多个文本块，注意保持语义完整。
- 向量化：通过Embedding模型把每个文本块转换成一个高维向量，语义相近的文本在向量空间里距离更近。
- 存储索引：把所有向量存入向量数据库，如Chroma、FAISS、Milvus、pgvector。
- 检索召回：用户提问时，把问题也向量化，从库里找到最相似的TopK个文本块。
- 生成回答：把检索到的文本块和用户问题一起放入Prompt，让大模型基于这些材料回答。
我自己做过一个团队内部的制度问答机器人，用LangChain加本地部署的Qwen模型，总共花了两天时间就完成了第一版。效果虽然称不上完美，但至少能把查找内部制度的时间从半小时缩短到半分钟。
这里必须提醒的是，RAG的效果很大程度取决于Embedding模型和切分策略。如果你发现回答质量差，先别急着怀疑大模型，多半是检索到的内容不对，或者切分时把一个完整语义片段劈成了两半。
4.3 Agent：让大模型自己调用工具和规划步骤
如果说RAG是大模型应用开发的第一站，那么Agent就是最近几个月最热的方向。
Agent的核心思想是让大模型不再停留在“单一对话”层面，而是给它若干工具，让它自主判断需要调用哪个工具、执行哪些步骤、观察结果并进行下一步。比如你问“帮我查一下上海未来三天适合穿什么衣服”，模型会先调用天气API获取温度，再结合穿搭知识生成建议。
实现Agent有一个经典的方法是ReAct模式，核心逻辑是交替执行推理和行动两个循环：模型先思考当前需要做什么工具调用，然后执行行动取得结果，再根据结果继续思考。很多框架如LangChain、AutoGen都提供了现成的Agent机制，你可以定义工具函数并传给模型调用。
我理解Agent是非常强大的技术方向，但它的核心难点不在工程实现，而在可靠性。因为大模型可能会做出错误的工具调用决策，或者进入死循环。实际落地时，我会给Agent限制最大迭代次数、增加人工确认节点、对工具调用结果做格式校验。
初学Agent，我的建议是先用LangChain搭一个简单的工具调用Demo，比如本地文件查询、计算器、数据库查询，感受一下“模型自主决策”的过程，再去研究复杂的多智能体协作。
5. 进阶路线：微调、评测与全栈能力
5.1 微调前先想清楚：这是最优解吗
做到前面这些，你已经能做出不少AI应用了。但工作中经常会遇到两类问题：第一类是Prompt怎么调输出都不够满意，第二类是希望模型学会某种固定格式或说话风格。这时候你可能就会想到微调。
不过我必须先泼一盆冷水：大部分业务场景根本不需要微调。微调成本高、周期长、容易过拟合，而且每次模型升级都要重新做。你完全可以先用提示词工程和RAG解决，只有当这两个手段确实到极限时才考虑微调。
最需要微调的场景通常是这些：
- 需要稳定输出特定格式或特定风格，比如模仿某位作家的文风。
- 模型总是犯某种系统性错误，通过RAG也无法纠正。
- 需要持续学习某些私有术语和缩写，让模型避免出现混淆。
我自己做过一个客服场景的微调尝试，结论是：如果数据量低于几千条高质量样本，微调的提升非常有限，而且还有可能降低模型原有的泛化能力。优先准备高质量、多样性足够的数据，远比追求数量更重要。
5.2 LoRA微调的基本流程
当前最流行的微调方式是LoRA，它不需要修改模型的所有参数，而是冻结原模型权重，只训练一小部分低秩矩阵。这样显存占用大幅降低，普通消费级显卡也能完成70亿参数模型的微调。
LoRA的核心思想可以这样理解：原模型是一个根基牢固的老师，你不想改变他的全部知识体系，只让他额外学会一种新的说话方式。于是你给他附一个小本子，上面记录调整规则，这个小本子就是LoRA层。
实践流程大致如下：
- 收集并清洗训练数据，通常需要整理成对话格式，例如用户消息和助手回复的配对。
- 选择微调框架，我用过比较顺手的是LLaMA-Factory，它提供一个简单的图形化界面，也有命令行模式。
- 加载基座模型，配置LoRA参数，包括秩、缩放系数、训练轮数、学习率。
- 开始训练并监控损失值，同时用小样本做验证。
- 训练完成后合并LoRA权重到原模型，导出为可供Ollama或vLLM加载的格式。
我刚开始训练时总盯着损失值，损失降了就以为万事大吉，结果测试时发现模型只会复读训练集里的句子。后来我才理解：损失值只在训练集上有效，真正要盯的是验证集效果和真实的交互测试。
5.3 模型评测：没有评测就没有优化方向
很多人做完RAG或微调后，会发出“模型好像聪明了也好像变笨了”的感叹。实际工作中，这种模糊感觉绝对不能作为交付标准，必须建立一套模型评测机制。
评测的基本思路是准备一批有标准答案的问题集，比如100道常见客户咨询问题，每道题记录模型回答，然后手工或自动打分。评测维度可以从准确性、完整性、相关性、格式符合度几个方面来打，每一项按1到5分评分。
进阶一点的做法是让一个强模型充当评委，比如把待测模型的输出和参考答案发给一个表现更好的模型，让它按标准打分。这种方法在大模型社区里叫LLM-as-a-Judge，用得好可以大幅减少人工评估成本。
我在做RAG优化时，最大的体会是评测数据要先于系统搭建，不要等系统上线才想起搞评测。否则你会发现每次改动都像盲人摸象，今天改个切分规则感觉好一些，明天改了Embedding又似乎变差，但完全说不清差在哪里。
5.4 全栈知识库与工程化意识
标题里有一个热词叫“AI大模型全栈知识库”，这其实是非常重要的一种学习方法。我在学习过程中，逐渐养成了把学到的所有内容沉淀成自己的结构化知识库的习惯，包括模型对比、部署命令、踩坑记录、可复用的Prompt模板、代码片段。
这个知识库的形式不限，飞书云文档、Notion、GitHub仓库都可以。关键是内容要有结构，我会按主题分成几个大类：
- 模型选型：不同开源模型的总结、参数量、部署要求、适用场景。
- 部署运维：各个工具的安装命令、环境配置、常见报错及解决方案。
- 应用开发：RAG、Agent、Prompt模板、前后端对接示例。
- 学习资料：书籍、课程、官方文档、开源项目的链接与要点笔记。
与其收藏一百篇教程，不如整理一份自己的经验文档。因为当你真正动手写下来的时候，你才会发现自己是不是真的理解了。很多知识点我看的时候觉得懂了，一写就卡壳，写文档的过程本身就是最有效的学习。
6. 学习资源推荐与常见问题避坑
6.1 按难度分级的学习资料清单
网上关于大模型的资料多到爆炸，这里我挑一些自己实际看下来觉得有帮助的，按难度分级推荐，方便你按需食用。
入门级适合完全零基础。吴恩达的《ChatGPT Prompt Engineering for Developers》是很好的起点，短短几个小时就能把Prompt的基本思路过一遍。李宏毅的《机器学习》公开课里深入浅出地讲了Transformer，虽然课程本身比较长，但针对大模型的章节值得单独看。如果英语阅读没有障碍，《Build a Large Language Model (From Scratch)》这本书也很有趣，它手把手教你从零写一个大模型。国内有一本比较新的《大模型应用开发极简入门》也值得一看，覆盖了从Prompt到RAG的完整应用路径。
进阶级适合已经能跑通Demo的开发者。Hugging Face的官方文档是我使用频率最高的参考资料，如果你想理解Transformers库的底层逻辑，它是标准答案。LangChain和LlamaIndex的官方文档也是绕不开的。这两个框架的文档里都附带大量示例代码，直接对照着改效率很高。
项目级推荐去GitHub上找完整的开源应用项目，比如各种基于大模型的知识库问答、Agent项目、本地部署工具。读README，把项目跑起来，再看关键模块的源码，是整个学习路线里最后也最关键的一步。
6.2 不同技术背景的人怎么切入
我经常收到各种背景的朋友咨询，Java转方向的最多，其次是前端、测试。
Java背景的开发者其实有天然优势，你对服务端架构、数据库、缓存、API设计都很熟，而大模型应用开发恰恰需要这些能力。你要补的重点不是Java知识，而是Python基础、深度学习基本概念、Prompt和RAG的套路。All right，推荐路径是：先用Python把脚本写利索，然后跑通一个RAG项目，最后再把模型的调用封装成Spring Boot服务，这样你原来的Java能力就全接回来了。
前端背景的开发者则可以把重心放在AI应用交互层，也可以往AIGC自动化平台方向延伸。模型能力都差不多的时候，谁的产品体验好谁就赢。
测试背景的开发者是一个被严重低估的群体。你们本来就有很强的场景拆解和异常发现能力，而在大模型应用里最缺的就是测试。可以专注做模型评测、数据质量分析、Prompt回归测试，这是一个非常有前景的细分方向。
6.3 常见问题排查与我的避坑心得
最后集中整理一些我在实际学习和部署中遇到的问题，很多都是网上教程不会写但你必须知道的细节。用表格呈现，方便大家保存：
- 报错CUDA out of memory：模型过大或并发过高，换更小模型、开启量化、减少batch size或max_tokens。
- 回答总是跑题/编造：降低temperature，改用RAG提供参考资料，检查Prompt约束是否明确。
- 本地部署速度太慢：确认GPU是否被真正使用，CPU推理的速度会慢很多倍，可考虑GGUF量化加更小的模型。
- 长文档超出上下文窗口：对文档进行摘要，或用RAG切分检索，不要全量塞给模型。
- 微调后模型能力变差：训练数据质量不足或学习率过大，回退到少量高质量数据重新训练，并扩大验证集。
- 调用API时中文乱码：检查请求编码，确保Content-Type为application/json; charset=utf-8。
除了技术排查，还有三个习惯让我受益最多。
第一是绝不光学不练。看到一个框架或一个项目，至少跑一遍官方示例再收藏。那些只收藏从来不跑的教程，本质上就是收藏了一堆焦虑。
第二是先用小模型验证想法。做RAG或者Agent时，不要一上来就调70B的大模型，先用7B模型把流程跑通，再换大模型提升效果。大模型调试时间成本高，过程也痛苦得多。
第三是多看模型卡的说明。每个模型发布时都附带模型卡，里面写清楚了训练数据、支持语言、参数范围、基准评测结果。这个信息看似鸡毛蒜皮，却决定了你在具体场景里选哪个模型。
最后再分享一个我自己的体会：在这个领域里，最大的风险不是没有资料，而是被海量资料淹没后迟迟不敢动手。我从零到完成第一个完整知识库问答应用，核心花了不到三个月，每天大概两小时。路线没有想象中那么长，真正难的是逼自己在每个阶段都结束在“能跑通的成果”上，而不是结束在“看懂了概念”上。
如果你看完这篇还是不知道从哪里开始，那我的建议很简单：先装一个Ollama，跑起来一个7B模型，问它第一个问题。这个动作一旦完成，你就已经站在路上了。
