最近后台收到不少读者的私信问题绕来绕去其实都指向同一个方向大模型LLM到底是怎么工作的为什么同样的提示词有人写出来效果惊艳有人写出来就是一本正经地胡说八道为什么有的应用用RAG就能解决问题有的非要微调为什么我部署了一个开源模型跑起来又慢又吃显存别人却能做到毫秒级响应这些问题看着零散但根子都在LLM的基础知识上。我做了几年大模型应用开发回头看踩过的坑、走过的弯路十有八九都是因为早期没把基础概念吃透。基础这东西日常写代码的时候感觉不到它在帮你有多少好处但一旦涉及性能调优、效果优化、成本控制有没有那层底层认知做出来的东西完全是两个级别。这篇文章适合谁刚入门想系统了解大模型原理的同学做应用开发想搞明白模型调优策略的工程师以及那些已经在用LangChain、Dify这些框架但知其然不知其所以然的朋友。我会把LLM最核心的几个知识点拆开揉碎来讲从模型原理到推理机制从RAG到部署应用再到踩坑经验争取让你读完之后面对市面上大多数LLM相关讨论都能接得住、听得懂、用得上。1. 先从“接龙游戏”说起LLM的本质和它带来的两个直接推论想理解LLM最先要丢掉的一个错误预期是“它是一台会思考的电脑”。真相比这个朴素得多——LLM本质上是一个极其复杂的词接龙器它的核心任务是算出“下一个词最有可能是什么”。1.1 一个最简单的例子给你一句话“今天天气真”让你接下一个词你大概率会说“好”。再给你一句“今天天气真”但如果前面还有一句“同事说我们周末去爬山我说”你接的词可能就变成了“好”或者“棒”。LLM做的事情就是这个只不过它不是在“词”的粒度上做预测而是在“token”的粒度上做预测。一个token可能是半个词、一个词、几个字符不同模型的token切分策略不一样。模型从左到右一个一个地预测接下来的token每预测出一个就拼到原句后面然后再预测下一个这样循环下去一整段话就生成出来了。这个过程叫自回归生成。GPT的全称里面Generative Pre-trained Transformer那个G就是GenerateT是Transformer拆开来看其实就是“用Transformer结构做的预训练生成模型”。这里有个非常关键的推论模型从出生那天起就不是为了“回答问题”而设计的而是为了“让句子接得通顺自然”而训练的。你平时看到的对话、文章、代码、分析本质上都是“接龙接得足够好”的产物。1.2 预训练、指令微调、人类偏好对齐既然模型只会接龙为什么我们用它的时候感觉它是在对答如流这就得说到训练的三个阶段了。第一阶段是预训练。模型被喂入海量的互联网文本任务只有一个预测下一个token。这个阶段模型学到的是语言的统计规律、知识的事实分布、逻辑的常见模式。你可以把它理解为一个人读了很多书但只是默默记在心里你问他什么他不会答因为他只学会了“顺着句子往下说”。第二阶段是指令微调也叫SFT。这个阶段用大量“指令-回答”对让模型学会服从指令的格式用户问一句模型接一个像样回答。这个阶段让模型从一个“接龙机器”变成了一个“会答题的工具人”。第三阶段叫对齐最典型的是RLHF人类反馈强化学习以及它的各种变体。简单说就是让模型输出的答案符合人类的偏好和价值观不胡说八道得太离谱不生成有害内容。所以你今天拿到的一个LLM是“预训练学语言规律指令微调学回答问题对齐学人类偏好”的三合一产物。明白这个之后很多现象就解释得通了。1.3 幻觉从哪来幻觉问题几乎每个用LLM的人都会碰到。模型一本正经地告诉你某本书的观点、某条法律条文、某个历史事件的结果但实际上是编的。为什么因为模型在生成的时候永远在“语言上最通顺”和“事实上最正确”之间做权衡。预训练阶段它看到的文本里有大量事实矛盾的说法互联网上什么都有它学到的是“这些说法经常以某种形式出现”而不是“这些说法哪个在现实世界中是对的”。再加上很多微调数据本身也是人写的人写的东西里同样有错误。模型没有渠道去验证事实它唯一的事实来源就是训练数据里的统计规律。所以幻觉不是bug是统计学习方法的固有副产品。这也解释了为什么当你问模型一个冷门问题、一个超出它知识范围的问题时它宁可编一个像模像样的答案也不愿意说“我不知道”——因为在它的“接龙经验”里“用户问问题”后面跟一个“自信的回答”的概率远大于跟一个“坦诚的不知道”的概率。明白了这个本质你就知道为什么做严肃应用时不能裸用模型直接回答那些对事实要求极高的业务问题你需要RAG、需要工具调用、需要人工审核。这不是模型不够聪明而是我们对它的期望定位一开始就偏了。2. 一次推理的完整链路Token、注意力机制和采样策略聊完训练的本质接下来看推理过程。你输入一段话模型内部到底发生了什么我按照执行顺序拆开讲每一环都能对应到你日常调参和排障时看到的现象。2.1 Tokenizer模型看到的世界和你的不一样模型不认字它只认数字。第一步就是把你输入的文本切分成token序列再映射成对应的id。这一步由tokenizer完成。不同模型用的分词策略不同早期喜欢按词切但按词切会导致词表太大而且处理不了没见过的词。现在主流基本都用BPE这类子词算法它把常见词保留为整体不常见词拆成更小的片段。“unhappy”可能被切成“un”和“happy”两个token“我爱你”在中文模型里可能一个字一个token也可能两个字一个token取决于词表训练时的统计结果。这个细节直接关系到两件事。第一件事是成本。现在主流模型按token计费你发一段中文中文字符切出来的token数量通常比英文要多。一段千字中文大概烧掉七八百个token长对话和长文档处理时token消耗会很快。第二件事是理解边界。模型对拼写错误的容忍度、对不同语言的表达能力差异都跟tokenizer的分词效果有关。有时候你发现某段文本怎么调提示词效果都不好去看一眼tokenizer把它切成了什么鬼样子心里就明白了。用一些在线工具查看实际的分词结果是调试LLM应用的第一步。2.2 Transformer如何理解上下文token序列变成了id列表之后会进入embedding层变成向量再进入几十上百层Transformer模块。Transformer的核心机制是自注意力这里我用一个生活化的类比来解释。想象你在公司开会听到一句话“它坏了需要换新的”。如果你不知道“它”指什么这句话等于白说。自注意力机制做的事情就是当模型处理到“它”这个字的时候它会自动回看这句话前后的所有词计算每个词跟“它”的关联程度。如果前面提到“打印机”且跟“它”距离很近、语法关系很强那么“它”在模型内部的表示中就会带上“打印机”的信息。Transformer里面那套Query、Key、Value的运算本质就是在做“匹配度打分信息提取”Query是当前词想问的问题Key是被关注词展示的名片两者算一个点积就能得到匹配分数然后按匹配度加权提取Value里的信息。整个过程把每个token和上下文其他token两两配对这就是“自注意力”里“自”的含义。这套机制让Transformer能有效捕获长距离依赖关系。这也是为什么它能碾压LSTM那个时代靠门控机制做语言模型的方案——LSTM要按顺序一个一个读距离太远前面的信息早就被遗忘了。Transformer天然能“隔空取物”只要上下文里出现过相关信息注意力就能把它找出来。当然这里说的是推理时行为。训练时Transformer还有一个关键不同它会把整句话的所有token一次性丢进去做并行计算靠mask机制保证每个位置只看到它前面的token这样既能并行训练又不破坏自回归属性。2.3 采样策略与“如何让模型不输出思考过程”模型最后一层输出的其实不是“答案”而是整个词表里每个token的得分。这个得分经过softmax转换就变成概率分布下一个token是“好”的概率是37%“棒”的概率是22%等等。问题来了你选哪个作为实际输出的token这就是采样策略。最稳妥的方案是贪心解码——永远选概率最高的那个。这个方案的好处是稳定、可复现坏处是容易陷入重复和呆板。实际上生成时普遍会加入一定的随机性让模型更灵动。关键控制参数就是Temperature和Top-p。Temperature是缩放概率分布的参数。温度越低概率分布越尖锐高概率token被选中几率越大输出越确定。温度越高分布越平坦低概率token也有机会冒头输出越发散。Top-p又被称为核采样它把累计概率到某个阈值的那批候选token圈出来在这个圈子内部重新分配概率。Top-p0.9意味着只从累计概率90%的token集合里采样把长尾的离谱候选直接排除。这两个参数调起来有口诀代码生成、数据提取这种要精确的任务Temperature设低一些0.1到0.3比较合适。文案创作、头脑风暴可以调高到0.7到0.9。但别用太高超过1.2之后输出基本就开始语无伦次了。有一个问题很多人专门问过怎么让模型不输出思考过程这得分情况。如果你用的是OpenAI o系列或Gemini这类推理模型模型内部会先产生一段思维链再给出答案有些API会把这部分思考内容也返回。OpenAI的API里有一个reasoning_effort参数可以设置为low减少思考内容部分接口也支持关闭思考模式比如Responses API里的reasoning: {effort: low}。如果是DeepSeek R1这类模型API里通常有thinking开关可以关闭输出思维链内容。如果你用的是普通模型但它仍然输出“我的思考过程如下”那是提示词把它带偏了。解决办法是在system prompt里加一条硬性约束比如“直接给出答案不要输出任何推理过程、解释或思考步骤”必要时配合低Temperature让约束更稳定。还有个容易被忽略的细节如果API支持schema或结构化输出把它配上让模型直接用JSON格式回答核心字段也能从形式上逼它跳过碎碎念的过程。3. 上下文窗口、RAG和微调三种补知识的手段该怎么选应用开发中最高频的决策之一是怎样让模型“知道”它训练之后出现的、或者它不知道的知识。共有三种主流手段把知识塞进上下文窗口、用RAG检索并动态拼入上下文、用微调改模型本身的权重。三种手段各有利弊但很多人一上来就选微调这个思路通常是最费钱也最不划算的。3.1 上下文窗口并没有想象中那么大上下文窗口指模型一次能处理的最大token数。几百token的年代已经过去了现在百万级上下文窗口也不稀奇。但“窗口有这么大”和“窗口里的东西都能有效用上”是两回事。你做过长文档问答就会有体会把一个几十万字的产品手册全塞给模型它确实不会报错但问细节问题时经常漏掉藏在文档深处的关键信息。注意力分布是“有限注意力资源”在分配上下文越长真正被重点关注的信息密度反而越低医学上叫“注意力稀释”放到LLM里叫“lost in the middle”。更深一层的是算力问题。Transformer自注意力是O(n²)复杂度上下文长度翻一倍计算量涨四倍。即使模型支持长上下文系统在这些长文本上的处理速度也明显下降、成本大幅上升。所以上下文窗口的正确用法是“刚需再上”。日常业务里把几万字的文档全文塞进去对话往往既烧钱又效果不佳。这时候就该考虑RAG了。3.2 RAG的完整链路和关键细节RAG的核心思路很简单模型不知道的知识你从外部资料库里面先检索出来连同问题一起塞给模型让模型基于给定的资料作答。它把“模型本身知道什么”和“模型回答问题时能参考什么”解耦了。标准的RAG链路大概是这个流程离线阶段把知识文档切成小块每块做embedding变成向量存入向量数据库。在线阶段用户提一个问题先对问题做embedding再到向量库里做相似度检索取出排名靠前的知识块。最后把检索结果和用户问题放入提示词模板交给LLM组织最终答案。听起来简单实际坑不少。切块大小是第一个坑。块太小上下文信息不完整块太大检索精度下降而且浪费token。常见的做法是256到512个token一块同时设置少量重叠避免一句话在切缝处被砍断。实际效果得靠实验没有一劳永逸的通用值。第二个坑是embedding模型的选择。中文场景如果用通用英文embedding模型语义召回效果会非常拉胯。建议测试专门的或中英双语的embedding模型用你自己的领域数据做召回准确率验证。第三个坑是检索完的“融合”。很多系统把这个环节省成一个粗暴拼接把top5的块按顺序贴进提示词这容易导致模型读了一堆无关信息反而干扰回答。更稳妥的做法是让模型明确感知到哪些是参考资料、哪些是用户问题在提示词里给出边界更复杂的做法是加上rerank环节先用向量检索粗召回50条再用一个rerank模型精排到5条。所以你在热搜里看到“RAG增强LLM”这么热门是因为RAG是当前企业落地LLM应用最性价比高的路线。它不需要重新训练任何模型权重数据可以随时更新改一条文档马上生效而且可以精确追溯到模型使用了哪些上下文对合规审计也友好。3.3 RAG与微调的选型对比微调是在模型原有权重上做进一步训练让模型自身的能力偏向某种风格或某种知识体系。它适合的场景是培养稳定的输出风格、让模型学会特定格式比如固定输出JSON结构、强化某个领域的推理套路。但微调有几个不好的面。一是一次性成本不低哪怕用LoRA这类低秩适配方案也得准备训练数据和调参算力。二是更新不灵活知识变了得重新训练。三是微调并不能彻底解决事实不准确模型可能把你给的数据学了个表面模式遇到新问题还是容易编。我个人的选型经验是这张表需求场景推荐手段原因回答企业私有知识库问题RAG更新快、可溯源、成本低稳定输出特定格式微调或强提示词约束微调能显著减少格式错误风格模仿、语气统一微调让模型“变成”某种风格的输出者处理超长专有文档RAG 长上下文动态切片检索比硬塞更可控模型不会某个推理套路微调 少量示例提示词示例不够稳定时用微调固化这里多提一句提示词里的few-shot示例有时能解决很多你以为需要微调的问题。先试提示词再试RAG最后才考虑微调这个顺序能让你的钱和时间花在刀刃上。4. 模型端和推理端部署LLM的基本盘热门搜索里有“llm agi 模型端 推理端”这两个词确实跟LLM使用的两个阶段对应。模型端指的是你选的基座模型本身比如Llama、Qwen、GPT这些。推理端指的是模型运行起来做推理计算的那一套系统。不管你用API还是本地部署都绕不开这两端的知识。4.1 权重、参数量和显存的粗略估算选模型时会看到参数量的说法7B、13B、70BB就是Billion十亿参数。参数越多模型容量越大能学到的模式越复杂但代价是推理时需要更多的显存。怎么估算一个模型推理要多少显存原则很简单参数占用的显存 推理过程的中间状态占用。单精度FP32一个参数占4字节半精度FP16/BF16一个参数占2字节INT8量化一个参数占1字节INT4量化大概0.5字节。所以一个7B模型在FP16下光权重就有大约14GB。加载到显卡上还要加上KV cache和中间激活值实际占用比这个数字高不少。这也是为什么24GB显存的显卡跑7B模型比较舒服跑13B就要用到量化了。70B的模型在FP16下光权重就140GB必须多卡并行加量化才能玩得动。推理框架如果支持量化7B模型在消费级显卡上也能起飞但注意量化会带来轻微的效果损失关键任务上建议量化后做一轮效果验证。4.2 推理框架在解决什么问题光有模型权重文件还不能对外提供服务。推理时有一系列工程问题如何管理KV cache、如何做连续批处理、如何把并发请求组织成高效的batch推理、如何加速算子计算。这些问题超出了模型文件本身需要专门的推理框架来兜底。这也是为什么你直接从Hugging Face拉一个模型用它的model.generate()方法跑速度往往慢得让人绝望——那是给研究用的路径没做工程优化。生产环境里比较常见的推理优化方案有批处理调度把多个请求拼成一个batch同时前向计算GPU利用率大幅提升。请求越多单位成本越低这就是为什么大厂API那么便宜。KV cache管理注意力计算时把历史token的Key、Value缓存下来避免每次重新计算。框架负责管理和复用这些缓存是长对话能跑得快的关键。量化压缩把权重从FP16压到INT8或INT4显存占用和计算量一起下降。常用的有GPTQ、AWQ、GGUF这类方案。投机采样用一个小模型先草拟一批token大模型只花很少的计算量批量验证通过大模型的验证结果来决定接受哪些预测比每一步都让大模型慢慢推理快不少。自己做部署的时候本地小规模试用Ollama一条命令就能把量化过的模型跑起来适合体验。生产环境的并发服务vLLM是目前比较成熟的框架吞吐量优势明显支持OpenAI兼容的API协议配好一行启动参数就能对接下游应用。如果要用多模态模型、对部署形态做深度定制可以考虑SGLang或TensorRT-LLM。4.3 从本地到服务OpenAI兼容API实际做应用的时候大多数人不是自己部署模型而是调用云厂商API。无论你用的是哪个厂家的模型今天几乎都提供了OpenAI兼容的接口。好处是应用端只需要写一套访问代码换模型时改一下base_url和model名就行。这么说吧OpenAI兼容API已经成了大模型界的HDMI接口。你的电脑有大DP口电视大HDMI口中间配一个转换线就能接上。模型服务方提供OpenAI兼容协议框架生态LangChain、Dify这些天然认这个协议你在里面填一个base_url和一个key模型就接进来了。选择接入方式时先算一笔账频繁做原型迭代、并发不高、不想管运维用托管API最划算有数据隐私要求、拥有GPU机器、并发量稳定本地部署VLLM才值得考虑。我见过团队一开始就买了四张卡部署70B模型做内部工具结果月活不到二十人GPU利用率不到百分之三运维复杂度还很感人——这种场景就该老老实实用API。5. LangChain和Dify应用层框架到底帮你做了什么网上关于LangChain和Dify的讨论非常多有人在喷框架过度封装有人在吹效率提升。我的观点是框架的定位是“把LLM应用开发的常见模式固化下来”用得好能省大量时间用不好就会变成debug负担。5.1 LangChain的Tool Selector与函数调用LangChain最核心的启发是它抽象出了Chain、Agent、Tool这些概念。实际开发中最常用的一个能力是Tool Selector——让LLM自主决定调用哪个工具并提取参数。底层机制其实是函数调用。你把工具定义成一段JSON Schema描述清楚函数名、参数名、参数类型、参数含义然后放进请求里发给模型。模型读完用户问题后会判断“这个问题应该调用哪个工具、参数填什么”然后返回一个结构化的工具调用指令而不是直接写自然语言让你去解析。自己做一个Tool Selector的步骤大致是定义好工具列表与每个工具的详细描述描述写得好坏直接影响路由准确率。给每个工具Design一个清晰的参数Schema。在提示词里说清楚路由逻辑当用户意图匹配哪个工具时就调用哪个工具。对返回结果做校验工具不存在或者参数不合法时需要兜底策略。踩过的坑是工具说明写得含糊导致模型好几个工具描述看着都像它就会随机调用。给工具起名和写描述的时候要尽量具体最好附上典型触发语和反例。比如一个查天气的工具描述里明确写“当用户问明天上海温度时调用而不是讨论天气预报节目的场景”。LangChain里还有LangGraph这层状态编排能力适合做复杂多智能体流程。但对大多数项目我建议不要一上来就上重量级编排简单的思维链就够用了。框架降低的是开发时间不是思考成本。5.2 Dify里LLM设置的实际操作讨论Dify时“dify里的llm怎么设置”这个问题出现的频率很高。Dify作为一个可视化LLM应用平台把模型管理、知识库、工作流、Agent编排都做成了可视化的界面。它的应用大概逻辑是先配置模型供应商再在应用里引用模型。模型供应商设置的关键是选对入口。进入设置-模型供应商找到你要用的服务商填入API Key。各个厂家现在都做了兼容接入OpenAI格式的接口可以直接填一个自定义的base URL和API Key。模型设置界面上比较核心的几个参数模型名称必须填对模型的精确名称填错会直接报错或者默认到别的模型。Temperature根据任务类型设置对话聊天可以高一点知识库问答建议低一点。Top-P一般跟Temperature配合使用固定0.85到0.95之间比较稳妥。Max Tokens限制模型单次回答的最长长度知识库问答这个值可以给到2000。System PromptDify里有独立的系统提示词位置这里放角色设定和回答规则。另外提醒一点在Dify里接知识库的时候记得在“检索设置”里选好检索模式和召回数量。默认参数不一定适合你的文档先跑一个测试问句看检索结果是否符合预期再决定要不要开Rerank。5.3 什么时候不需要框架框架虽然是效率工具但它也有成本。隐藏了很多实现细节出了问题排查链路长抽象层多性能损耗不小版本更新频繁接口变动是家常便饭。所以我个人的判断标准是这样的如果应用逻辑就是一层“提问-检索-回答”或者只是封装API做一层prompt模板直接用Python写个几十行的函数可能比包一层框架更快更可控。如果要做多轮对话、计划能力、多工具调度、知识库Rerank结构化输出一套组合拳再考虑上LangChain或者直接上Dify这种生产平台。有一个现象值得注意现在不少新项目开始往回走用更薄的封装层代替重框架。如果你的团队对LLM原理掌握得比较扎实自己写编排逻辑反而更容易定位问题。框架是帮助不是信仰。6. 给入门者的一条LLM学习路线和五个高频坑最后一部分回应一下“llm学习路线”这个高频搜索。我不打算给你列一份十几本书的书单而是给条从零到能干活的最短路径顺带讲几个我亲眼见过无数次的高频踩坑事件。6.1 从零到能干活的学习路线第一个阶段是使用体验期。这是上手最快的一环直接用ChatGPT、Claude、Kimi这类产品大量地聊、大量地尝试。重点感受不同模型的输出差异、Temperature对结果的影响、System Prompt的作用。顺手了解一下Tokenizer和API调用方式写几个脚本把API跑通。第二个阶段是关键做原理补课。去读Karpathy的系列公开课他的讲解风格特别适合工程背景的人。不必一开始就去啃Attention Is All You Need原文先看讲解视频理解Self-Attention、Multi-Head Attention、Positional Encoding是怎么回事。这一阶段的目的不是让你能复现模型而是别人讨论模型机制时你不再是局外人。第三个阶段是做应用项目。选一个真实的业务小场景用LangChain或Dify搭一个RAG知识库问答应用。把文档加载、切块、Embedding、向量检索、Rerank、Prompt模板走一遍。这个项目做完你对整个链路就有了完整的肌肉记忆。第四个阶段往深处走做部署调优。用vLLM在自己机器上跑一个7B模型做量化、配置批量推理参数、对比不同框架的性能。有余力再看一些KV Cache、PagedAttention这类偏底层的技术资料。走到这里LLM相关的日常讨论你基本都能参与。6.2 五个高频坑第一个坑上下文溢出。我见过不少团队做知识库问答为了省事把整篇二十页的PDF塞进上下文结果模型回答质量反而下降。上下文不是内存条插满不意味着能用好建议先用RAG做检索裁剪再考虑塞入。第二个坑Temperature不做任务区分。有人一套参数打天下写代码用默认温度客服机器也用默认温度然后抱怨代码里有神秘输出。要根据任务类型调整温度这个前面讲过但它值得反复强调。第三个坑忽略System Prompt的作用。很多人把精力全花在优化User Prompt上System Prompt一句话都没写。结果应用一换场景就翻车。System Prompt是给模型设定角色和规则的“站立起点”它决定了模型以什么姿态处理你的问题。第四个坑盲目微调。很多问题提示词就能解决偏要花钱微调。微调一个月后线上知识变了还得重新训练。微调应该是最后的手段而不是第一选择。第五个坑不做评估就上线。改动一个Prompt之后不确定实际效果究竟怎么样全凭肉眼感觉。这个坑最隐蔽也最伤。改动模型配置后必须回到固定的评估集上统一跑一遍看效果分否则就是靠运气做产品。6.3 一个容易忽略的好习惯先做评估集这里分享一个做LLM应用最重要的习惯任何项目开始之前先花一天时间把评估集建好。评估集就是一批覆盖主要业务场景的测试样例每个样例包含输入问题和期望输出标准。有了评估集你才能客观判断提示词改动是好是坏、RAG召回是否准确、新模型是否值得切换。我第一次带团队做知识库项目时全组对着一堆Prompt调了快两周每天感觉“好像比昨天好一点”。后来花了半天本来觉得是浪费时间的评估集把样例跑完对比之后发现上一周的很多“优化”其实都在原地打转有些改动甚至把原本对的问答改错了。有了评估集之后每一次迭代都有据可依类似退化问题很快能发现。评估集不需要很庞大五六十条覆盖主要场景的就很不错了。维护成本很低带来的效果却是指数级的。这是整个LLM应用开发里长期最值得投入的一笔时间。我个人的经验是LLM入门最大的门槛不是技术而是概念转变。你没法把它当成传统软件那样用逻辑框图来设计得先理解它的统计本质再用工程手段去约束它的不确定性。把这些基础知识打牢了后面学LangChain、学RAG、学微调就都是在同一个框架里填细节的事。