LLM入门实战指南：从核心原理到RAG与Agent应用

经常有朋友跑来问我“LLM 到底该怎么入门”问的人里有刚转行做 AI 的产品经理有写过几年代码但没碰过大模型的程序员也有完全没学过编程、纯粹想知道 ChatGPT 为什么这么聪明的学生。这个问题其实不好回答——不是难而是网上的信息实在太乱了。有人让你先啃三个月深度学习有人让你直接上手 LangChain还有人告诉你“不需要懂原理会调 API 就行”。结果很多人收藏了几十篇教程真正自己要动手的时候还是一脸懵。这篇文章我想用尽量朴素的方式把需要知道的 LLM 入门知识一次性讲清楚。不堆公式不抄文档从“它到底是什么”到“我怎么真正用起来”尽量把这几年的实践体会都说透。如果你正处于“听说过很多名词但串不起来”的阶段这篇文章应该能帮你把散落的概念串成一条线并且给你一条真正能落地的行动路径。1. 先搞清楚LLM 到底是什么以及它为什么值得你入门1.1 AI、机器学习、深度学习与 LLM 的关系很多新手一上来就被“人工智能”“机器学习”“深度学习”“大语言模型”这几个词砸晕。我先用一句话把它们的关系捋清楚AI 是一个很大的目标让机器表现出智能机器学习是实现这个目标的一类方法核心是“从数据里学规律”深度学习是机器学习里目前最成功的一个分支靠多层神经网络来学而 LLM也就是 Large Language Model大语言模型是深度学习在语言这个领域里杀出来的明星路线。所以你会看到聊 LLM 的时候经常提到 Transformer、神经网络、预训练这些词本质上都属于深度学习的技术范畴。而“大语言模型”之所以特别在于它专门针对“语言”做了极致优化——它吃进去的是海量的文本学出来的是语言的规律。打个比方AI 像是“让机器变聪明”的宏大愿望机器学习是一套“从经验中进步”的方法深度学习是这套方法里最锋利的武器而 LLM 则是用这把武器在“理解语言和生成语言”这件事上打出的王牌。搞明白了这个层级你就不会被各种名词绕晕了。1.2 “大”在哪里参数、数据与算力的量级概念很多人会有个疑问以前的聊天机器人也有为什么偏偏这两年 LLM 爆发了答案就在这个“大”字上。它不是指功能多、界面炫而是指三个物理层面的东西呈指数级膨胀。参数规模模型的“脑容量”。从早期 BERT 时代的 1 亿级别到 GPT-3 的 1750 亿再到后来各家开源模型的 70B、上百 B参数的膨胀速度非常夸张。训练数据模型“读过的书”。现在的先进模型几乎把互联网上高质量的公开文本都读了个遍训练数据量级是以万亿 token 计算的。算力成本消化这些数据需要大量 GPU 并行计算一次完整的预训练成本从几百万美元到上亿不等。当这三样东西堆到某个临界点之后模型突然表现出很多“小模型”不具备的能力——比如上下文理解、多步推理、代码生成、角色扮演这些被称为“涌现能力”。这也是为什么 LLM 不是简单的“更大号的聊天机器人”而是被看作一条通往通用人工智能AGI的可能路径。热词里有人搜“llm agi 模型端 推理端”其实就是在关注这个方向。1.3 大模型“会”什么“不会”什么入门阶段最重要的一件事建立对 LLM 能力的正确预期。我见过太多人把 ChatGPT 一类产品当成“万能神器”结果发现它数学题都能算错或者一本正经地编造不存在的文献就大失所望。LLM 擅长的是语言理解与生成、摘要、翻译、改写、代码编写与解释、头脑风暴、知识问答基于训练数据范围内的常识性知识、把复杂概念讲成人话。它在这些事上的表现已经接近甚至超过普通人的平均水平。LLM 目前搞不定的没有持久记忆对话窗口一关它就不记得你这个人了知识有截止日期训练完之后发生的事情它不知道会产生幻觉不确定答案时会编一个听起来很合理的精确计算和多步逻辑依然不稳定数数、复杂推理偶尔翻车缺乏真实世界的感知没有手没有眼睛不知道苹果咬一口是什么口感。所以把它当“博学但偶尔会胡扯、记忆力很差的朋友”最合适。理解了这个定位后面学 Prompt、RAG、Agent 的时候才明白这些技术到底在解决什么问题。2. 预测下一个词LLM 最底层的运行逻辑2.1 核心机制它一直在玩“接龙游戏”如果你只记住一个原理那就记住这句LLM 的核心任务就是“预测下一个词”。给它一串文字它根据自己从海量文本里学到的统计规律计算下一个最可能出现的词是什么然后把这个词拼到原来的内容后面再预测下一个。如此反复整段话就出来了。举个直观的例子。你输入“今天天气”模型内部会估算下一个词的概率分布可能是“真”今天天气真好可能是“怎么样”今天天气怎么样也可能是“预报”今天天气预报说。它按概率采样选一个把结果接上去接着预测下一个 token。但这里有个细节常被忽略模型实际处理的不是“字”而是 token。token 可以理解为“语言片段”一个英文单词可能被切成几个 token一个汉字可能是一个 token。所以你在看上下文窗口、计费、模型长度限制的时候单位都是 token 而不是“字”。理解这一点后面就不会被“为什么这个模型说能处理 128K我却只能放进去几万字”这类问题困扰。2.2 训练三步走预训练、SFT、RLHFLLM 的能力不是天生就有也不是靠人类一条条写规则写出来的。它的训练大致分三步阶段目标数据产出预训练学会预测下一个词掌握语言规律和世界知识互联网海量文本万亿 token 级一个底子很厚但“不太会聊天”的基座模型监督微调 SFT学会“好好说话”按人类习惯问答人工编写的高质量指令-回答对一个能理解指令、能回答问题的基础助手人类反馈强化学习 RLHF / DPO对齐人类偏好让回答更有用、更无害人类对多个回答的排序/评分一个真正可用的聊天助手你会发现模型的底层知识几乎全部来自第一步预训练后面两步更多是在“调教它的表达方式和行为”。这也是为什么很多开源基座模型比如没有经过 SFT 的原始权重用起来“智商在线但不会聊天”逻辑就在这。2.3 实战必须懂的几个参数与概念不管你用 API 还是本地部署以下几组概念是每天都要打交道的temperature控制回答的“冒险程度”。范围一般是 0 到 2。越低越保守稳定适合代码、结构化输出越高越发散有创意适合文案、头脑风暴。日常对话我常用 0.7。如果你发现模型老是胡说八道先看看是不是 temperature 调太高了。top_p另一种采样控制方式保留累计概率达到 p 的候选 token。一般和 temperature 二选一调。新手建议固定 top_p1只调 temperature。上下文窗口模型一次能“看到”的 token 数量上限。这就像一个工作台你放的 system prompt、历史对话、参考文档全都占用这张台子的空间。超出的部分会被截断或遗忘这直接决定了 RAG 的 Chunk 设计策略。system prompt在对话开始前给模型设定角色、规则和风格优先级高于普通对话。很多所谓的“完美提示词”本质就是把 system prompt 写清楚了。它是最便宜的“模型调教”手段也是入门者最值得练的基本功。2.4 模型端与推理端别再傻傻分不清了热词里有人搜“llm agi 模型端 推理端”说明很多人被这两个词卡住了。其实很好理解模型端负责“生产模型”。它涵盖数据收集、预训练、微调、评估、发布权重这几个环节。你听到的“训练一个 70B 模型”“用 LoRA 微调”“模型开源了”都属于模型端的事。模型端产出的是“权重文件”就像一本写满了知识点的书。推理端负责“使用模型”。把训练好的权重加载起来部署成服务接收用户的输入通过前向计算输出结果。你调 API、用 Ollama 跑本地模型、把模型部署到线上都是推理端的事。推理端不更新模型参数只是“照着书里的内容回答问题”。类比一下模型端是培养厨师、给厨师写菜谱的烹饪学校推理端是餐厅后厨按照菜谱把菜做出来端给客人。你作为普通开发者在本地搞的环境搭建绝大部分属于推理端。搞清楚这个边界你在查资料时就不会再被“训练”和“推理”两个词反复绕晕。3. 入门者的三条动手路线对话、API、本地部署从哪条开始最划算3.1 路线一先用聊天产品建立手感很多人一上来就想着“我要部署一个模型到本地”其实最容易犯的错误是跳过了“和模型交朋友”的阶段。我建议你先花几天时间和市面上主流的聊天类产品好好相处——聊学习、让它写方案、让它解释代码甚至故意让它犯错。这个阶段的目标不是完成任务而是建立“模型直觉”它擅长什么、在什么场景下容易翻车、什么样的指令它听得懂、什么样的指令它理解偏。这种直觉是后面所有工程的底座。没有它你写 Prompt 时不知道怎么描述需求做 RAG 时不知道怎么设计检索问题根本调不好效果。3.2 路线二调 API性价比最高的开发起点如果你想做点实际的东西但暂时没有足够好的显卡调 API 是目前性价比最高的路线。不用买硬件不用管部署花几块钱甚至几毛钱就能把主流模型的能力接入自己的程序。以 DeepSeek 这类国内可直接使用的 API 为例一个最小可用的 Python 调用大概长这样from openai import OpenAI client OpenAI( api_key你的API Key, base_urlhttps://api.deepseek.com ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个乐于助人的技术助手。}, {role: user, content: 用一句话解释什么是向量数据库} ], temperature0.7, streamTrue # 流式输出体验更接近真实对话 ) for chunk in response: print(chunk.choices[0].delta.content or , end)这段代码本身没什么难度但它背后有四个细节值得你反复体会第一API 的调用方式其实都长得差不多换模型只需要改 base_url 和 model 名第二system prompt 是控制回答质量性价比最高的杠杆第三streamTrue 能大幅改善交互体验第四temperature 等参数要按场景动态调整而不是一路用默认值。这些看起来是小事但在真实项目里都是决定体验的关键点。3.3 路线三本地部署自己动手跑一个模型隐私敏感或想折腾一下的话完全可以在本地跑模型。目前最友好的方式就是 Ollama一条命令就能把模型拉下来跑起来# 安装 Ollama 后下载并运行 7B 级模型 ollama run qwen2.5:7b跑起来之后默认会监听本机 11434 端口提供 OpenAI 兼容的接口你可以用 3.2 那一节同样的代码调用本地模型只需要把 base_url 改成http://localhost:11434/v1。这就是为什么我建议你先了解 API 再玩本地——你会发现其中逻辑是相通的。光有命令行其实不够舒服可以再装一个 AnythingLLM 或者 Open WebUI 做可视化界面。尤其 AnythingLLM很多人搜“anything llm 知识库”就是因为在本地快速搭一个知识库问答应用它几乎是零门槛的选择。这个我在后面工具链的章节还会展开。3.4 本地部署前先估算你的硬件能跑什么本地部署最大的门槛是硬件而新手最容易忽略的是模型占用资源不只看参数量还看精度和量化方式。粗略估算法则需要的内存GB≈ 参数量B× 每个参数占用的字节数。以 7B 模型为例FP16 精度下大约需要 14GB但经过 4bit 量化常见文件名里的 Q4_K_M之后只需要 4-5GB 左右体验上损失也不算大。我自己实测下来的感受是8GB 显卡或 16GB 内存的电脑跑 7B/8B 量化模型是比较舒服的日常问答、写作、简单分析完全够用想跑 70B 级别的模型基本需要两张 24GB 显存的卡或者直接用内存硬撑速度会很感人。所以入门阶段别好高骛远一台普通笔记本 7B 量化模型足够你跑通整个流程了。4. 从“会聊天”到“能落地”Prompt、RAG、Agent 的分工与取舍4.1 Prompt你的第一项 LLM 工程能力把 LLM 能力变成真实生产力第一步就是写好 Prompt。很多人以为 Prompt 就是“说人话”其实一个高质量的 Prompt 是有结构的。我的常用模板包括四个部分角色你是一位资深 Python 后端工程师任务请审查下面这段代码的并发安全问题要求指出问题、给出修改后的代码、解释修改理由如果没有问题就明确说“没问题”补充代码/背景/限制条件。在此基础上还有两个很实用的技巧。一个是Few-shot 示例给模型几个“问题-答案”的例子它会模仿示例的格式和深度来回答比干巴巴的“你要输出高质量内容”有效得多。另一个是链式思考让模型“一步一步想”在需要推理的场景下能显著降低错误率。但注意不要迷信网上那些“万能 Prompt 模板”Prompt 必须结合你的具体场景反复调谁也没法给你一个放之四海而皆准的句子。4.2 RAG让模型学会用你的知识库Prompt 能改的只是“表达方式”但模型不知道你公司内部的规章制度、不知道你私有文档里的内容、也不知道训练截止日期之后发生的事。要解决这个问题主流方案就是 RAGRetrieval-Augmented Generation检索增强生成。热词里很多人搜“rag增强llm”方向完全正确。RAG 的核心流程可以拆成四步切块Chunking把长文档按语义切成若干小段。Chunk 太大塞不进上下文且检索精度低Chunk 太小上下文碎片化、丢失语义。实践经验是普通文档 300-500 字一个 Chunk并设置适当重叠。向量化Embedding把每个 Chunk 转成一组向量一串数字让语义相近的文本在向量空间里距离相近。检索Retrieval用户提问时把问题也转成向量在向量数据库里找最相似的 Top-K 个 Chunk。生成Generation把检索到的 Chunk 拼到 Prompt 里让模型基于这些资料回答。RAG 的价值不只是“给模型补充知识”它还能大幅缓解幻觉因为模型只需基于给定的参考资料回答而不是凭空编造同时知识可以随时更新换一批文档就等于换了一套知识库不用重新训练模型。对于大多数企业场景和数据敏感场景RAG 是短期内最实用的落地方式。4.3 Agent让模型学会“干活”而不是“说话”如果说 RAG 解决的是“知识不够”Agent 解决的是“能力不够”。LLM 本质上只是个文本生成器它不会查天气、不会订机票、不会操作你的数据库。但 Agent 给了它“手和脚”——让它能调用工具、能做规划、能根据工具返回的结果决定下一步行动。比较经典的框架是 ReAct 模式思考Thought→ 行动Action→ 观察Observation→ 循环直到任务完成。比如你问“帮我查一下杭州下周的天气”Agent 会先生成“需要调用天气查询工具参数是杭州、下周”然后调用工具获得结果再把这个结果组织成自然语言回复给你。实际项目中用 Agent 要注意一个坑它并不是越“聪明”越好而是可控性更重要。我给新手的建议是先用最简单的方式比如一个功能节点里只绑一个工具把链路跑通再逐步增加工具数量和任务复杂度否则很容易出现模型反复调用错误工具、在死循环里打转的情况。4.4 三种模式的选型判断很多人一上来就想搞 Agent但要我说90% 的场景先用 Prompt 和 RAG 就够用了。把它们放在一起对比思路就清楚了模式解决的问题技术门槛适合场景Prompt让模型“好好回答”最低通用问答、文案撰写、代码辅助、头脑风暴RAG让模型“知道你的私有知识”中等企业知识库、产品文档问答、私有数据洞察Agent让模型“自己动手完成任务”较高自动化流程、多步骤任务、工具编排我的经验是先用 Prompt 把模型的“说法”调好然后看是否需要引入知识RAG最后才考虑让它自己动手Agent。次序反了调试成本会成倍上升。5. 工具链选型从 LangChain 到 Dify再到 Codex CLI5.1 为什么 LLM 工具链一直在变入门者最容易困惑的一件事框架太多了今天学 LangChain明天又冒出 Dify后天还有一堆新工具感觉永远学不完。我想先说一个判断工具变化快是正常的因为 LLM 这个领域本身就在高速演化。早期大家想的是“怎么用代码把模型包起来”所以 LangChain 这类编排框架火了一阵后来大家发现“可视化拖拽 配置化”更好用于是 Dify、Coze 这类低代码平台起来了再后来模型能力越来越强工具链又开始往“原生集成”走比如 Codex CLI 直接让模型接管命令行。你不需要追着每个工具跑。工具是技能不是知识用的时候学比囤教程重要得多。真正的核心竞争力是你对模型能力边界、RAG 流程、Prompt 设计的理解这些换哪个工具都不变。5.2 知识库场景AnythingLLM 与 Dify 的定位差异如果你想快速搭一个知识库问答我建议根据使用场景选择工具。热词里“anything llm 知识库”和“dify里的llm怎么设置”都有不少人搜说明这两个是入门者的高频选择。AnythingLLM更适合个人、小团队它主打的是“本地优先”下载安装、把文档拖进去、选一个本地模型比如上面说的 Ollama几分钟就能用起来。它的优势是简单直接适合不想折腾代码的人。Dify偏工程化一些支持更完整的编排能力可视化搭建工作流、配置多个模型供应商、做 RAG 管道、发布成 API 给其他系统调用。如果你的知识库要做成面向多人的服务或者需要和现有系统集成Dify 更合适。5.3 工程化方向的新趋势Codex CLI 这类工具的启发还有一类工具正在改变 LLM 的使用方式那就是 Codex CLI 这类“命令行/IDE 原生化”的工具。它们把 LLM 直接嵌入到开发者的日常工作流里——你在终端里描述需求模型帮你写代码、跑测试、甚至修复报错。热词里有人搜“codex cli 接入llm”本质上就是在探索“把 LLM 当成同事而不是聊天对象”。这类工具给我最大的启发是LLM 能力的释放方式正在从“对话框”转向“接口化、流程化”。以后好的应用可能不再是一个聊天窗口而是把 LLM 拆成各种能力组件嵌入到具体业务流里。这也是为什么我反复强调入门 LLM 别只盯着聊天多想想你在做的事情有没有哪个环节可以被“文本输入-文本输出”的组件替代。5.4 一个实测细节Dify 里怎么让模型不输出思考过程最后说一个很多人在 Dify 里会遇到的实测问题——为什么模型回答前输出一大段“思考过程”这类问题主要出现两种场景一是用了 DeepSeek-R1、QwQ 这类推理型模型它们在最终回答前会先进行长串推理二是模型服务端把 reasoning_content 字段和 content 拼接在了一起。我的处理思路是分三步排查看模型服务端如果用 OpenAI 兼容接口接入了推理模型检查返回结果里是不是多了一个 reasoning_content 字段。这是“思考过程”的真正来源。看 Dify 编排节点在 Dify 的 LLM 节点里确认输出的变量只引用了 content 字段没有引用 reasoning_content。很多情况下模型把思维链作为正常内容输出了只需要在提示词里明确要求“直接给出最终答案不要展示推理过程”。换模型版本如果业务场景不需要深度推理直接用不带思考过程的普通对话模型更省心比如 DeepSeek-chat 而不是 deepseek-reasoner。省 token响应也更快。这类问题看似很小但非常影响用户体验。排查思路比具体操作更值得记下来先分清“模型的输出”和“产品层的展示”再定位是在哪一层需要处理。老实说LLM 入门最大的坑不是资料不够而是永远在“看教程”和“收藏工具”的路上迟迟不真正动手。我自己见过太多人花了一个月逛论坛、对比框架、刷视频最后连一个最小 Demo 都没跑通。我的建议非常朴素今天先注册一个 API 或者本地装一个 Ollama写一个 20 行的脚本让它帮你总结一段文字。哪怕这东西丑得不行、逻辑简陋你也已经迈出了最难的那一步。后面所有的进阶知识都会在你真正用起来之后变得顺理成章。