大模型系统性入门：从原理、部署到微调应用的完整路线

1. 为什么你收藏了300个教程，依然觉得大模型没入门

我先讲一个前几天在交流群里看到的真实场景：有人问"大模型怎么入门"，群里立马有人甩出几个网盘链接，里面躺着几百个PDF和视频，说是"全网最全的大模型学习资料"。存完资源的那一刻，大家都觉得安心了，觉得自己已经在路上了。但过了两周，那个下载资料的人又回来了，问的还是同一句话："大模型怎么入门？"这不是个例，而是绝大多数初学者的通病——资料太多、信息太杂、不知道该从哪条线开始学。

大模型这个领域有个特点：它既是一套理论体系，又是一堆工程工具的集合，还夹杂着大量商业话术和热搜词汇。今天你看"世界有哪些知名的大模型"，明天看"ollama部署私有大模型"，后天又刷到"qwen2.5-7b微调行业大模型实战"，每个视频、每篇文章都单独看懂了，但合在一起仍然是一盘散沙。这就是为什么我说"大模型的系统性入门资料"这件事，重点从来不是"资料"两个字，而是"系统性"三个字。

系统性意味着两条线并行：一条是知识结构的搭建，你要知道大模型是什么、能做什么、不能做什么、训练和推理的大致流程是什么；另一条是动手路线的规划，从"用别人部署好的模型"到"自己在本地跑模型"再到"改模型和做产品"，每一步都踩在上一级的肩膀上。这两条线一旦结合，你再看网上的各种教程，就能自动分类——这个是讲原理的，那个是讲部署的，还有一个是讲微调的——你会很清楚它们各自填补了知识地图上的哪块空白。

这篇文章就是奔着"帮你把地图先画出来"去的。我打算按一个真实的入门顺序走一遍：先讲清楚原理层面的核心机制，再给出分阶段的学习路线，然后是模型获取与本地部署的实操链路，接着是微调的本质与边界，再进入提示词工程和上下文工程，最后聊到应用开发和Agent框架。你不需要一次性读懂所有细节，但读完你应该能回答三个问题：现在我处于哪个阶段？下一站该学什么？遇到问题该去查哪类资料？

2. 大模型的工作原理：一个"猜下一个词"的系统怎么会有智能

很多入门资料一上来就堆Transformer架构的公式，把初学者吓退一大半。我觉得没必要。作为系统性入门的第一站，你需要建立的不是数学推导能力，而是一个对工作原理的直觉模型。

2.1 从"预测下一个词"到"涌现能力"

大模型本质干的事情非常简单：给定一段文字，预测下一个最可能的词。你在对话里问"中国的首都是哪里"，模型在训练时见过海量类似文本，它会按概率推导下一个词最有可能是"北京"。这个过程不断重复，模型就一段接一段地"写"出回答。ChatGPT也好、通义千问也好、DeepSeek也好，底层都是这套"自回归语言预测"机制。

但问题来了：如果只是猜词，怎么猜着猜着就会写代码、会推理、会翻译、会总结？这涉及一个叫"涌现能力"（Emergent Ability）的现象。当模型的参数量和数据量跨过某个门槛后，简单任务"预测下一个词"的训练目标，会迫使模型内部形成对语言结构、逻辑关系甚至常识的隐式表征。通俗说，为了把下一个词猜准，模型被迫学了语法；为了在长文本里猜准，模型被迫学了前后文的因果关联。你不需要理解具体的梯度传播细节，但一定要记住：大模型的能力不是显式编程写进去的，而是从海量文本的统计规律中长出来的。这个认知直接影响后面你会怎么理解"幻觉"和"对齐"。

2.2 为什么算力这么重要：参数、Token 和显存

大模型的"智能"存储在参数里。一个7B模型，意思是它有70亿个参数，这些参数在训练时不断调整，最终把训练文本里的统计规律固化下来。你使用模型的过程叫"推理"（Inference），推理时你要把模型的所有参数加载到显存里，这就是为什么本地跑模型首先要看显卡显存够不够。

这里有个粗略的估算公式：模型显存占用约等于参数量（以字节计）的1.2到1.6倍。一个7B参数模型，如果按FP16精度存储，光参数就要约14GB显存，再加上推理时的中间状态，实际需要16GB左右。这就是为什么那些教你"7B模型轻松跑"的教程，都会先问一句：你的显卡是多大显存？如果你拿着一张8GB显存的消费级显卡，直接跑FP16精度的7B模型就会爆显存，得靠量化（把参数从16位压缩到8位或4位）才能塞进去。

另外一个大模型的基础单位是Token。模型不认识整词，它把你的输入拆成一个个Token片元再处理。1个Token大致相当于0.6到0.8个汉字，或者0.3到0.4个英文单词。所有大模型API按Token计费，所有上下文窗口长度也用Token数来标定，所以"Token概念"是理解成本、上下文长度和性能开销的钥匙。

2.3 训练三段式：预训练、微调与对齐

大模型不是做一次训练就完工的。系统性地了解训练过程，能让你在后期理解"微调"和"对齐"时站的起点完全不同。

第一段叫预训练（Pre-training），模型在海量公开文本上学习语言规律，成本极高，动辄需要数千张GPU跑几个月，GPT-4级别的模型单次训练成本以亿美元计。这个阶段决定了模型的"知识上限"和"语言能力底座"。第二段叫监督微调（SFT，Supervised Fine-Tuning），用人工标注的高质量问答对让模型学会"听指令"，知道用户问问题时要像助手一样回答，而不是继续把对话补完。第三段叫对齐（Alignment），通过人类反馈强化学习（RLHF）等方式让模型的回答更符合人类偏好，比如更安全、更有帮助、更少偏见。你现在看到的"这个模型很听话、很安全"的观感，主要来自第三段。

这三个阶段也解释了入门者常见的两个困惑：一是为什么模型会"一本正经地胡说八道"（幻觉），因为它的本质仍然是概率生成，不是查数据库，碰到没有把握的内容就会编造合理的补全；二是为什么开源模型这么多、水平差异这么大，因为基座模型决定了基础智力，但指令微调和对齐的质量决定了它在实际使用中的体验。后一个认知在选型时非常有用——同样是7B模型，一个做了大量中文指令微调的版本，可能比原始基座模型更适合你的中文业务。

3. 学习路线的四个阶段：会用、能部署、会微调、做应用

把原理部分压缩到这个程度就够了，接下来是入门者最关心的：学大模型到底要按什么顺序走？网上很多资料把"大模型学习路线"画成一张巨复杂的知识树，包含几十个分支，看起来很有条理，其实对一个还没入门的人毫无指导意义。我自己的建议是把路线压成四个阶段，每个阶段都有一个明确产出物，做完了再进入下一阶段。

3.1 阶段一：会用（产出物：日常使用大模型解决问题）

最快建立信心的方法是先用起来。找一两个商用大模型产品（例如ChatGPT、通义千问、Kimi、豆包等），刻意在大约两周内把所有日常任务都交给它试一遍：写邮件、整理会议纪要、做Excel公式、翻译外文资料、写简单的Python脚本、给文章起标题。这一阶段的重点不是研究技术，而是建立"大模型能做什么、不能做什么"的体感。

你会很快发现几条边界：它在总结、改写、翻译、生成初稿这类任务上极其强大；它在精确计算、实时信息、多步逻辑推理上经常犯错；它的回答受提示词影响极大，同一个问题换个问法，质量可能天差地别。这些体感是后面学习提示词工程和判断模型能力的宝贵经验基础，比直接背理论有效得多。

3.2 阶段二：能部署（产出物：在你自己的电脑上跑通一个模型）

很多人学大模型最大的问题是"一直停留在用别人产品的阶段"，一碰到"私有化""数据不出域""定制化"这些真实业务需求就两眼一抹黑。所以第二个阶段必须动手部署。我的建议顺序是：先在本地装一个Ollama，用命令行拉取一个7B或13B模型（比如Qwen2.5系列），在本地把对话跑通；然后换用vLLM部署同一个模型，对比一下并发推理性能和显存占用差异；有条件的话再用llama.cpp在纯CPU环境跑一次，感受一下极低配环境下的部署可能性。这一步做完，你对"模型文件、显存、推理框架、API端口"这些词就有了实感，网络上关于部署的文章你也能看懂了。

这里给你一个实操经验：入门阶段别去研究分布式推理、多卡并行、张量并行这些高阶内容。一台消费级显卡（或纯CPU）单机部署一个小模型已经足够覆盖80%的入门需求。过早研究多卡部署不仅搞不明白，还会让你误以为大模型部署门槛极高。

3.3 阶段三：会微调（产出物：用一个数据集微调出专属模型）

会用和能部署之后，你会自然遇到一个问题："开源模型虽然强，但它不熟悉我手头的业务数据，怎么办？"这时候进入第三阶段：微调。但请注意，我见过太多人把微调当成学习路线的终点，觉得"学会微调=大模型入门完成"，这是个误区。微调只是众多技术手段中的一种，它的背后是一整套数据处理、训练资源管理、效果评估的方法。目前入门微调的主流做法是学习LoRA和QLoRA——它们通过冻结原模型、只训练一小部分额外参数的方式，大幅降低微调的硬件门槛，让单张消费级显卡也能微调7B模型（具体我在后面第5节展开）。

这一阶段比较推荐的实战项目是：准备一千到两千条领域问答数据（比如法律咨询、医疗科普、某个企业内部FAQ），用Qwen2.5-7B作为基座，用LLaMA-Factory这类开源工具做一次LoRA微调，然后对比微调前后模型在领域问题上的回答质量差异。做完这个项目，你才算真正理解"模型训练"和"模型使用"的区别。

3.4 阶段四：做应用（产出物：一个调用大模型能力的完整应用）

最后一个阶段，是把大模型从"聊天工具"变成"产品能力"。这里的知识栈包括：后端起一个服务封装对模型的调用；通过SSE流式输出让回答边生成边渲染；用检索增强生成（RAG）给模型接上你的私有知识库；甚至用Agent框架让模型学会调用工具、完成任务闭环。市场上主流的Agent框架比如LangChain、LlamaIndex、Dify、Coze，以及各种面向大模型的编排工具，都是在这个阶段出现的。

这个阶段对工程能力的要求明显提高，你需要至少会一门后端语言（Python或者Java/Kotlin都行），理解HTTP接口、异步流式、数据库存储这些常规后端知识。如果你的目标是做AI产品经理或者方案架构，到阶段二其实已经够用；如果你想做AI应用开发工程师，那阶段四是你的主战场。

4. 模型获取与本地部署：选对渠道、工具和显存预算

部署是整个入门过程中坑最多的环节。我见过有人卡在模型下载半个月没搞定，也有人下载了一个几十GB的模型文件后发现显卡带不动。这些问题的根源是同一个：没在动手前把"渠道、工具、显存"三件事想清楚。

4.1 模型从哪里获取：官方渠道与开源社区

开源模型的主流获取渠道是HuggingFace和国内的ModelScope魔搭社区。HuggingFace是目前全球AI模型和数据集最集中的平台，几乎所有主流开源模型的原始权重都能在上面找到；ModelScope上有大量针对中文场景优化的模型，国内访问速度快，注册即用，而且很多模型页面会附带推理和微调的教程，对新手非常友好。

下载模型时有个值得记住的技巧：不要用浏览器直接下载几个GB到几十GB的文件，那样断点续传很痛苦。最方便的方式是用官方提供的命令行工具，比如HuggingFace的huggingface-cli download或ModelScope的modelscope download，它们支持断点续传。Ollama用户则更简单，直接在终端执行ollama pull qwen2.5:7b，它会自动从模型库拉取对应文件并管理好本地路径，完全不需手动找文件。

4.2 显存预算表：先算清楚再选模型

我建议你把下面这张粗略估算表收藏起来，选模型之前先对着算一遍。这是以FP16精度加载模型的保守估算，量化后占用可以减少约一半。

再强调一遍，这个表只是起点。实际占用还取决于推理框架的优化程度、上下文窗口长度（context length）和并发请求数。上下文拉长后，KV Cache会吃掉大量显存，这也是为什么长对话场景下模型响应会变慢甚至爆显存。

4.3 部署工具对新手友好度对比

部署大模型的工具有三巨头：Ollama、vLLM、llama.cpp。它们各有清晰的分工。Ollama是综合素质最适合新手的，一条命令装好，一条命令拉模型，一条命令启动服务，甚至自带OpenAI兼容的API接口，后续你写的应用可以直接对接。vLLM是为高吞吐、高并发场景设计的专业推理服务框架，显存管理做得极其高效，适合把模型做成线上服务，但配置要求稍高，适合在阶段二后半段接触。llama.cpp是纯C/C++实现，不依赖CUDA也能在CPU上运行，对量化支持极好，是低配置设备或Apple Silicon设备上的首选。

给一个具体的操作路径：在Windows或Linux上装Ollama，执行ollama run qwen2.5:7b即可完成下载并进入对话。或者执行ollama serve启动服务，然后用Python的requests库或openai库访问http://localhost:11434/v1。如果你能把这套流程跑通，就意味着你已经理解了"本地大模型API"是怎么工作的了。

4.4 部署过程中的三个常见坑

第一个坑是模型家族和标签搞混。同一个模型名下有不同大小的版本，比如Qwen2.5有0.5B、1.5B、7B、14B、32B、72B，还有个带-instruct表示指令微调版，带-GGUF表示量化版。下载时看错一个标签，轻则浪费下载流量，重则跑起来直接报错。第二个坑是显存没留余量。根据我整理的估算表选显卡，看起来刚好够，但一用长上下文就崩。解决办法是先把上下文窗口调小（比如4096），跑通以后再逐步加大。第三个坑是Windows环境下的CUDA版本冲突。新手的显卡驱动往往能跑游戏，但深度学习组件（CUDA、cuDNN）版本不匹配导致推理框架起不来。我自己的经验是：Ollama这类一体化工具能很大程度规避这些问题，遇到问题先看日志，再针对性搜索报错信息，不要一上来就重装环境。

5. 微调的真相：大多数人不需要自己微调，但需要理解它的原理

微调是热搜词里的重头戏，什么"大模型微调实战""qwen2.5-7b微调行业大模型""环境配置+模型微调+模型部署+效果展示详细教程"，浏览量都相当可观。但我必须泼一盆冷水：在入门阶段，90%的人完全不需要自己微调模型。你需要的是理解微调是什么、何时才需要微调，以及跑通一次最小微调实验来建立体感。

5.1 微调和提示词工程的分工

你要解决"模型不熟悉业务数据"的问题时，有一个优先级判断：先用提示词把相关背景信息扔给模型（比如把业务文档粘贴到上下文里），看能不能解决；不行，就用检索增强生成（RAG），把业务知识库作为模型回答时的参考资料；都搞不定了，才轮到微调出场。这个优先级背后的逻辑很简单：多数业务知识的载体是文本，而文本是上下文窗口能容纳的；微调是用训练的方式修改模型参数，成本高、周期长、结果不可控，能不动参数就不动参数。

那什么时候真的需要微调？我归纳为三类场景：第一，模型需要学会特定的输出格式，比如从非结构化文本里抽取JSON字段，试了很多提示词都不稳定；第二，模型需要模仿特定的语气和风格，比如让它以你公司客服的口吻回答问题，光靠上下文很难稳定复现；第三，模型的知识需要和你的私有数据深度融合，比如"了解公司内部制度后直接回答员工咨询"，而不是每次把制度文档塞进上下文里。只有这些情况，微调才是正确答案。

5.2 LoRA 和 QLoRA：普通人的微调入口

传统的全参数微调需要把所有模型参数都更新一遍，7B模型光梯度状态就要占几十GB显存，个人开发者基本没戏。所以现在凡是介绍"个人微调"的教程，讲的几乎都是LoRA或者QLoRA。LoRA的思路是：冻结住原始模型的全部参数，只额外训练一小批低秩矩阵（通常只有原参数量的0.1%到1%）。你在推理时把这两个矩阵的产出叠加回原模型，效果上就近似完成了一次"针对特定任务的小型手术"。QLoRA在LoRA的基础上，再把原模型量化到4bit来加载，进一步把显存需求压到原来的一半左右，这就是为什么8GB到12GB显存也能微调7B模型的真相。

实操层面，现在最推荐新手的是开源工具LLaMA-Factory。它提供了统一的数据处理、训练、评测、部署界面，支持LoRA、QLoRA等主流微调方法，一条命令就能跑起来。你准备一份JSON格式的数据集，每条数据包含instruction、input、output三个字段，就能开始微调了。

5.3 一个最小可行微调实验的流程参考

我给入门者建议的微调实验是这样的：基座模型用Qwen2.5-7B（指令微调版），数据量控制在1000到2000条，用QLoRA，训练1到3个epoch。整个流程大致走四步：

1. 找数据：从开源数据集里挑选一个垂直领域子集（比如法律问答、医疗问答、中文金融问答），或者自己根据某个产品的FAQ人工整理一批问答对。注意一定要做数据清洗：去掉空内容、超长文本、有明显错误的样本。
2. 配置环境：使用Python 3.10以上版本，安装PyTorch（CUDA版）和LLaMA-Factory，创建虚拟环境避免依赖冲突。这里最耗时的是环境兼容性调整，务必看清楚显卡驱动支持的CUDA版本。
3. 启动训练：在LLaMA-Factory的WebUI里选择"QLoRA"和对应的基座模型路径，指定数据集和输出目录，开始训练。观察训练损失曲线：如果在持续下降并最终收敛到一个较低值，说明训练过程正常。
4. 测试评估：训练完成后加载LoRA适配器，用微调前后都回答同一组业务问题，对比输出质量。你也可以准备一个小的评测集，计算回答的相似度或让另一个模型打分，得到更客观的结论。

这个实验做完，你对"微调"的认知会达到一个质变——你会直观看到模型被"掰向"某个领域的过程，也会体会到数据质量对结果的巨大影响。这比看十篇讲微调原理的文章都管用。

5.4 微调的三个反面教训

第一，数据量不够时千万别多轮重复训练。有人拿着500条数据训练10个epoch，结果模型把训练集里的答案背了下来，一到开放问题就胡言乱语，这叫过拟合。我的经验是：数据少就训练少一点，一般1到3个epoch足够。第二，混合场景微调会互相干扰。如果你在一个数据集里既有法律问答又有闲聊对话，模型往往学不好任何一个任务。最好一个数据集只针对一种任务。第三，微调后会损害模型通用能力，这叫灾难性遗忘（Catastrophic Forgetting）。缓解办法是在训练数据里混入一部分通用语料做"回放"。这些都是需要自己踩过坑才深刻理解的细节。

6. 提示词工程与上下文工程：离业务最近的能力

如果你问我在大模型所有相关技能里，哪个最容易被忽视但又最值钱，我的答案不是部署也不是微调，而是提示词工程和上下文工程。原因很简单：多数实际业务问题根本不需要换模型，只需要换提问方式。

6.1 提示词的四个必要组件

一段高质量的提示词，通常由四个组件构成。一是角色设定，告诉模型"你是什么身份"，比如"你是资深的Python后端工程师"，这能激活模型不同的知识面。二是任务描述，把你要模型做的事说清楚，注意要具体到动词级别，"总结这篇文章"不如"用三条要点概括这篇文章的主要观点，并各附一个事实支撑"。三是上下文材料，把模型回答问题所需要的背景信息直接放进提示词里，可以是业务文档节选、日志片段或之前的对话内容。四是输出约束，包括格式（JSON、表格、列表）、字数、语气、是否允许追加提问。

有一个经典示例：你让模型"帮我写一封邮件"，和你说"你是一名销售总监，请帮我给一个三个月未联系的客户写一封简短的跟进邮件，语气礼貌但不要过分热情，并在开头主动提及对方上次提到的发货延误问题"，效果会天差地别。前者模型只能自由发挥模板，后者模型有了明确的行为边界和内容锚点。

6.2 上下文工程：你的"外挂知识库"能装多少

上下文工程和提示词工程的关系，我理解为：提示词解决的是"怎么问"，上下文解决的是"给模型多少材料来支撑回答"。上下文工程的核心约束是上下文窗口大小——也就是模型一次性能"看到"多少Token。目前主流模型的上下文窗口从8K到128K不等，最新的模型甚至有200K以上，看起来很大，实际用起来很快见底：一篇几千字的文档转成Token就要消耗一大截，再算上模型回复的长度，一次长对话很容易触顶。

所以上下文工程的第一原则是只塞必要信息。不要囫囵吞枣地把整本手册塞进提示词，而是提前抽取、截取与当前问题相关的片段。比如做文档问答，你不该把100页文档全部塞进去再问"根据这些材料回答XX问题"，而应该先做一次检索（用文本相似度、关键词或向量检索），找出最相关的3到5段材料，再把它们和问题一起送入上下文。这个"检索+上下文拼接"的流程，就是RAG的核心思想。它是现阶段解决大模型"知识陈旧""胡说八道"问题最可靠的工程手段，也是上下文工程最重要的应用场景。

6.3 让模型的输出更可控

入门者往往忽略"约束输出"这个环节。很多业务系统需要模型输出结构化数据（比如抽取客户信息、生成工单标签），如果模型自由发挥，后面的程序就无法解析。这里有两个实用技巧。第一个叫JSON Mode，很多主流大模型API支持在调用时指定response_format={"type": "json_object"}，模型会把回答强制输出成合法JSON。第二个叫示例驱动（Few-shot），在提示词里给模型展示1到3个"输入-输出"的例子，告诉它输入长什么样、输出就该长什么样，比单纯说"请输出JSON"稳定得多。

另外还要提醒一句：提示词不是一次写对的，而是要像调参一样迭代。我的建议是建立一个"提示词-输出"对照笔记，每次修改一个变量（比如角色描述、约束条件、示例数量），记录输出质量变化。行动之前你可以先思考：这个任务到底需要模型具备什么信息、什么身份、什么限制？把这些元素写全，提示词的质量自然就上来了。

7. 从模型到产品：API调用、流式输出、RAG与Agent

如果前三个阶段让你有了"玩模型"的能力，那阶段四就是让你拥有"做产品"的能力。这部分是热搜词里最散的板块——有人问"通过SSE流式输出实现大模型回答实时渲染、配合abort怎么实现"，有人搜"本地大模型实现联网搜索能力"，还有人关心"主流的Agent框架有哪些"——其实它们都在讲同一件事：怎么把大模型包装成一个可靠的服务。我建议你按下面这条线来搭自己的应用开发知识结构。

7.1 统一API接口：OpenAI兼容协议

今天的模型服务商（无论是OpenAI、通义还是本地部署的Ollama/vLLM）默认提供一套兼容OpenAI格式的API接口。请求体通常是：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="local") response = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "system", "content": "你是一名知识渊博的助手。"}, {"role": "user", "content": "用一句话解释什么是大模型"}, ] ) print(response.choices[0].message.content)

这段代码在任何兼容接口上都成立，这就是为什么"本地部署的Ollama可以无缝替换云端API"——你只需要改base_url和模型名。应用层不需要关心底层是云端模型还是本地模型，这给后续的模型切换、降级、私有化部署留下了巨大空间。

7.2 SSE流式输出：让回答"打字机式"渲染

大模型推理是逐Token生成的，一次生成几百字可能需要几秒钟到几十秒。如果让用户干等一个完整响应，体验极差。业界标准做法是用SSE（Server-Sent Events）做流式传输：服务端每生成一个Token就通过HTTP长连接推送给前端，前端边接收边渲染，用户看到的就是"打字机式"的出现效果。后端在FastAPI里的一个简单实现思路是这样的：

from fastapi import FastAPI from fastapi.responses import StreamingResponse from openai import OpenAI app = FastAPI() client = OpenAI(base_url="http://localhost:11434/v1", api_key="local") @app.post("/chat") def chat(messages: list): def event_stream(): stream = client.chat.completions.create( model="qwen2.5:7b", messages=messages, stream=True ) for chunk in stream: delta = chunk.choices[0].delta.content if delta: yield f"data: {delta}\n\n" return StreamingResponse(event_stream(), media_type="text/event-stream")

前端用JavaScript的EventSource或者基于fetch的流式读取即可。注意，如果是使用fetch，需要配合AbortController实现用户手动取消生成，否则用户在网页上点"停止"按钮时，后端请求还会继续跑完。这个细节在真实业务里非常关键——生成回答既消耗Token又占用推理资源，不做中断控制会白白浪费成本。

7.3 RAG：给模型接上你的知识库

RAG已经成为大模型应用开发最核心的工程范式。它的标准流程是：离线阶段把业务文档切片，用嵌入模型（Embedding Model）转成向量存进向量数据库；在线阶段收到用户问题后，同样转成向量，在向量数据库里检索最相关的文本片段，把片段连同原始问题一起作为提示词交给大模型生成回答。这样做有两个显著收益：一是回答可以引用真实业务知识，大幅降低幻觉；二是知识更新只需替换切片文档，不需要重新训练模型。向量数据库领域的常见选项有Milvus、Qdrant、Chroma等，嵌入模型既可以用开源的BGE系列，也可以用商业API。入门时用Chroma加一个封装好的RAG库（LangChain或LlamaIndex）就能跑通最小闭环。

7.4 Agent：让模型学会调用工具

Agent是当前大模型应用里最热的方向。其核心思想是：不满足于"模型回答问题"，而是让模型像一个"会用工具的助手"——它自己判断需要查天气、查数据库、调用某个API，然后根据工具返回的结果继续推理，最终完成任务。主流框架方面，LangChain和LlamaIndex是Python生态里最普及的；Dify是一个可视化的LLMOps平台，适合快速搭应用，拖拽式编排Agent和知识库；Coze（扣子）也是面向业务人员友好的Agent搭建平台。更轻量、更偏底层的方案是直接给模型提供工具函数列表，由模型自主选择调用哪个工具，装进OpenAI兼容的tool机制。入门Agent，我建议先用Dify或Coze搭一个带工具调用的机器人（比如"根据实时天气推荐穿衣"），理解"模型判断+工具调用+结果再生成"的循环，再回到代码里研究LangChain的AgentExecutor内部的prompt和循环逻辑。

至于热词里提到的"多模态大模型"和"知识抽取框架"，它们属于扩展方向。多模态（能看图、能听声音、能生成图片）是现有大模型体系的分支扩展，入门时了解"文本大模型和视觉编码器联合训练"的思路即可，不必急着深入。知识抽取框架（比如热词里提到的OneKE）本质是"用大模型+约束输出做信息抽取"的专用工具，适合做结构化知识图谱的场景，等到你实际业务需要时再针对性学习也不迟。

8. 半年入门路线的避坑经验与学习技巧

最后这部分，分享几条我在无数次"快要入门又没入门"的反复中总结出来的经验。这一节不系统，但每一条都值钱。

第一条：每个阶段必须有一个产出物，哪怕很小。别看完一个视频就算学完，要逼自己完成一个可展示的成果。"我理解了Transformer"是虚幻的，"我在本地跑通了一个7B模型"是真实的。我建议你建一个作品集目录，里面至少放这四样东西：一个用提示词工程的完整案例、一个本地部署模型的启动脚本和截图、一个微调实验日志、一个调用了大模型API的小应用。这比任何课程证书都有说服力。

第二条：官方文档的优先级永远高于二手教程。开源模型的GitHub仓库和文档更新极快，国内技术社区里过时信息非常多。比如有人还在用已经废弃的LangChain版本教你搭应用，照着敲几遍都跑不通。我的习惯是：先看模型仓库页面的官方README，再搜对应框架的官方文档，最后才看社区教程。遇到报错，直接Copy报错信息去搜索结果页面，大概率能定位到GitHub的Issue区——那里藏着大量前人踩坑后贴出的解决方案。

第三条：不要迷信"大模型排名前十"。排行榜反映的是通用能力，但实际业务看重的是某几个特定维度的表现：中文指令跟随、长文档理解、代码生成、推理速度、成本、私有化能力。选型时最靠谱的方法是"用你的真实任务去测"：准备20到50个你业务中最典型的测试题，在候选模型上跑同一套提示词，做一个简单的评分对比。本地部署场景尤其要考虑推理速度——70B模型再聪明，如果一次回复要等两三分钟，体验就大打折扣。

第四条：把理论学习压缩到最低必要限度。很多人一入门就想精读《Attention Is All You Need》论文、学透PyTorch源码，结果撑不过两周。我见过系统入门最快的一类人，反而是"先用起来、遇到问题再补理论"的实践派。深度学习理论可以在你有了一定实操经验后再补，到那时你看论文会迅速得多，因为你知道每个公式可能在解决什么工程痛点。机器学习基础——梯度下降、过拟合、训练集验证集划分——值得提前掌握，但时间不必占太多。

第五条：找一条持续输出和记录的路。哪怕只是每周写一篇学习笔记，把部署过程、报错解决记录、微调心得写成短文发出来，也能产生两个巨大收益：一是写作迫使你理解得更深，二是这些记录本身就是你作品集的一部分。大模型这个领域，交流群能拉近信息差，但真正拉开差距的还是各自动手的深度。

在跑完第一轮完整的"会用、能部署、会微调、做应用"流程后，再回看网上的各种教学资源，你会发现自己仿佛从"看热闹的人"变成了"能看懂门道的人"。到那时，系统性入门这件事才算真正完成了。