如果你是一个工程师第一次认真接触大语言模型LLM你多半会经历一个特别拧巴的阶段你说它是数据库吧它会一本正经地编造不存在的知识你说它不懂吧它又能把代码写得像模像样你说它是搜索引擎吧它根本不会实时联网你说它只是高级自动补全吧它又能做分析和规划。这种拧巴根源在于大多数人用了人的思维去理解LLM。我从技术视角把LLM的底层逻辑拆开之后很多疑问其实会自动消失——为什么提示词要那样写、为什么大模型会产生幻觉、为什么temperature能影响输出、为什么需要RAG和Agent这些外围工程。这篇文章就是给准备深入LLM开发、又不想只停留在调API层面的读者准备的目标是用一套清晰且不玄学的框架把大模型的基础知识讲透。1. 先打破一个幻觉LLM并不是真的懂你问的话1.1 它真正的核心能力是预测下一个词把时间拨回大模型最底层。无论参数是70亿还是7000亿无论叫GPT还是叫LlamaLLM在训练时的核心任务只有一个给定一段文本预测下一个最可能出现的词。举个例子。给模型看今天天气很它要预测下一个位置出现好差热冷等词的概率。训练数据里今天天气很好出现得多那么好的概率就高。这个预测任务随着训练数据规模的扩大会在无数个文本片段上反复执行最终模型内部就把人类语言中隐含的语法规则、事实关联、逻辑模式全部压缩成了统计规律。所以严格来说LLM是一个极其擅长接龙的玩家。你给它一个上文它补一个最合理的下文。至于这个下文是不是真实的并不是它关心的第一要务它只关心像不像人类会写的下一个词。1.2 为什么这个认知是所有技巧的根基一旦接受了预测下一个词这个设定你会发现所有上层技巧都变得合理起来。提示词的本质是给模型提供一个更有指向性的上文让它沿着你期望的方向预测。温度参数的调节是改变模型在概率分布上挑词的随机性。RAG检索增强生成的本质是把相关资料先检索出来拼进上下文里让模型在预测时看得见这些内容。连大模型输出JSON格式不稳定这类问题本质上也是它在预测下一个词时对JSON语法结构的概率估计不够高。很多人觉得提示词工程是玄学其实它不是。它是在用模型能理解的方式帮它降低下一个词预测的难度。你给的信息越充分、越结构化模型预测就越容易命中你想要的答案。1.3 会接龙和会推理之间的距离理解了接龙本质你就能解释很多LLM的诡异行为。比如你问GPT-4o9.11和9.9哪个大它可能回答9.11大。因为训练数据里小数比较的样本分布不均匀模型在概率上更倾向于选择9.11这个看似更复杂的数字。这不是它愚蠢而是文本接龙并不等于严格数学推理。再比如你让它算235乘以47它可以演算半天但只要数字稍微复杂一点就翻车。而如果你在提示词里告诉它请逐步计算准确率会明显提升因为步骤引导给了它更清晰的接龙路径。认识到这一点之后我建议所有初学者把心态从把它当成万能大脑调整为把它当成一个知识面极广、语言能力极强但需要你用工程手段去约束和引导的工具。后面所有章节讨论的Token、Context、RAG、Agent本质上都是在做约束和引导这件事。2. 拆开黑盒看结构Token、Transformer、参数与上下文窗口在分工什么2.1 Token模型眼里的文字人类看到的是汉字、单词、标点模型看到的是一串Token。Token是文本处理的最小单元你可以把它理解为模型的文字单位。Token的切分规则有些反直觉英文中一个常见单词可能是一个Token比如apple不常见的单词可能被拆成多个Token比如supercalifragilistic会被切成好几段。中文里一个字在多数主流模型中占1到2个Token常用汉字通常1个Token生僻字可能占2个甚至更多。标点、空格、换行也都会消耗Token。Token数量的影响非常直接它同时决定你调用API的成本、上下文窗口能塞下多少内容、以及模型处理一次请求的延迟。曾经有人拿一份繁体中文PDF去做知识库结果Token开销比简体中文版本高了一大截因为繁体中文字符编码切分后占的Token更多。所以做LLM应用时第一步就学会估算Token一般中文场景下1个汉字约等于1到2个Token英文场景下1000个单词大约等于1300到1500个Token。这套估算能力在后续做RAG的文本切分、控制Prompt长度时非常有用。2.2 Transformer决定上下文里谁重要的机制现在几乎所有主流LLM都基于Transformer架构。这个架构里最关键的是自注意力机制Self-Attention。它的作用用一句话概括让序列中的每个Token动态地决定自己应该关注上下文里的哪些Token。打个比方。你在读一句话小明把苹果放在桌上然后他拿起了它。人读到他的时候会自然联想到小明读到它的时候会想到苹果。自注意力机制做的就是类似的事情——为每个Token和其他所有Token计算一个关联权重然后按权重加权融合信息。前后文里的每个词都彼此看一眼然后根据相关性大小决定要参考谁。这也是Transformer能超越传统RNN循环神经网络的重要原因之一RNN必须按顺序逐个处理词而Transformer可以同时计算所有词之间的关系训练效率高出一大截。所以当你说我的Prompt太长模型似乎忽略了开头的内容时问题的根源可能就出在注意力机制上——开头和其他内容的关联权重在长序列中被稀释了。2.3 参数模型的经验容量7B、13B、70B这些数字指的是模型的参数量。B代表Billion7B就是70亿个参数。参数是模型在训练中不断调整的旋钮你可以把它理解为模型从海量文本中压缩出来的经验。参数越多模型能够记住的模式和知识就越多。但请注意参数多不代表一定更聪明它更像是硬盘容量变大而不是CPU变强。实际使用中一个70B模型在复杂推理上的表现通常优于7B模型但如果你的任务只是简单的分类、提取、格式化7B模型搭配好的提示词效果未必差很多反而速度和成本都友好得多。参数和Token的关系也需要理解模型处理输入时每一层都会把Token序列和参数做大规模矩阵运算这就是为什么参数更大的模型推理更慢、显存占用更高。部署一个7B量化模型大约需要6GB显存而70B模型至少需要40GB以上显存普通消费级显卡根本跑不起来。2.4 上下文窗口模型能同时看到多长的文本上下文窗口Context Window是模型单次能处理的最大Token长度。早期的GPT-3只有2048个Token后来的GPT-4支持8K、32K甚至128K国内不少开源模型也做到了128K甚至更长。上下文窗口决定了模型能同时看到的信息量。比如你要让模型总结一份30页的报告如果窗口只有4K你就得把报告切成几段分批处理如果窗口是128K可以直接把全文塞进去。但窗口大不等于记得住。实测下来当输入接近窗口上限时模型对中间部分内容的注意力会明显下降这就是Lost in the Middle现象。所以我在实际做长文本应用时即使模型支持128K也不太建议真的塞满100K。如果有必要就把关键指令放在Prompt开头和结尾这两个位置模型的注意力最集中。3. 一个模型是怎么炼成的预训练、指令微调与人类反馈对齐3.1 预训练让模型读万卷书大模型的第一个阶段是预训练。在这个阶段模型在海量互联网文本上执行那个核心任务——预测下一个词。数据集规模通常在数万亿Token级别需要的算力也是普通人无法想象的。经过预训练模型获得了语言能力和世界知识。但它有个问题它只会接龙不会对话。你给它一段文字它会续写比如给它总结一下这篇文章它可能真的继续完成这段文字而不是给你输出一个总结。因为训练数据里它见过最多的模式是文章正文继续往下写而不是用户提问—模型回答。所以单纯预训练出来的模型叫Base Model基座模型它并不适合直接面向用户。3.2 指令微调SFT让模型学会回答问题要让模型从续写狂魔变成能对话的助手需要做指令微调Supervised Fine-Tuning, SFT。这一步会用大量人工编写的指令—回答对教模型学会按照用户的指令格式进行回答。这些样本通常长这样指令用一句话解释什么是数据库索引期望回答数据库索引是一种用于加快数据查询速度的数据结构……经过SFT模型学会了用户提问我回答的交互模式也学会了遵循一定的指令格式。这也是为什么同一个开源模型往往有两个版本Base版和Chat/Instruct版。前者用来做续写和嵌入式任务后者用来做对话和问答。作为应用开发者如果你要做一个特定领域的产品可以考虑在开源模型基础上做微调。但请注意微调的成本和门槛都不低而且对于大部分业务场景RAG其实比微调更适合解决领域知识不足的问题这个后面第6章会详细说。3.3 对齐RLHF/DPO让模型说人话、别乱来有了SFT模型已经能回答问题了但还不够。因为基座模型在预训练阶段见过太多乱七八糟的内容它可能生成有害、偏见或不受欢迎的回复。所以还需要最后一步对齐Alignment。最常被提起的方法是RLHF基于人类反馈的强化学习。简单说就是让模型生成多个答案人类标注员给这些答案的好坏排序再训练一个奖励模型去学习人类偏好最后用强化学习方式让大模型学会输出人类更喜欢的答案。近两年流行的DPO直接偏好优化则是更简化的替代方案。对齐阶段追求的目标通常有三个有用Helpful、诚实Honest、无害Harmless。ChatGPT有时候表现得很啰嗦动不动就说作为AI助手我不能……甚至对很多明显无害的问题也过度谨慎这些都是对齐阶段的副作用。对应用开发者来说这意味着你拿到手里的闭源模型无论是OpenAI还是国内大厂API行为习惯已经是被对齐过的。如果你需要一个更放得开、更敢输出的模型开源模型自定义对齐会更可控但成本也更高。4. 生成参数的底层逻辑温度、Top-p与采样策略怎么影响输出4.1 模型输出的是概率分布不是一个固定答案用过API的都知道生成参数里最常见的两个是temperature和top_p。要理解它们先要知道模型在生成时到底在做什么。你在对话框里输入一句话模型并不会直接查出答案而是会在每个生成步骤为词表里的每一个Token算出一个分数再通过softmax转换为概率。比如今天天气很后面好的概率是0.3差是0.2热是0.15……模型只需要从这些候选Token中挑一个作为输出。那么问题来了永远挑概率最高的Token还是按概率随机挑一个这就是采样策略要处理的问题。4.2 Temperature的数学原理Temperature的作用是在softmax之前对概率logits做一个缩放核心公式是[ P_i \frac{\exp(z_i / T)}{\sum_j \exp(z_j / T)} ]其中(z_i)是模型输出的原始分数(T)就是temperature。当T1时概率分布保持原样。当T小于1比如0.2(z_i/T)的值会整体放大导致概率分布变得尖锐——高概率的词概率更高低概率的词几乎被压死模型输出更确定、更保守。当T大于1比如0.8甚至1.2分布变得平坦——低概率的词也有更多机会被选中模型输出更多样、更有随机性。一个容易理解的类比T越小模型越像一个死认一种标准答案的学生T越大模型越像一个思路发散、什么都敢说的创意写手。4.3 Top-p与Top-k采样除了temperature还有两种常见的采样方式。Top-k采样先把所有Token按概率从高到低排序只保留前k个作为候选。比如top_k50那么就算第51名的词概率再高也不会被选中。它的优点是排除掉那些概率极低的垃圾词。Top-p采样也叫核采样从概率最高的Token开始逐个累加直到累计概率超过p比如0.9然后把候选集限定在这些Token中。它比Top-k更灵活如果模型对下一个词很有把握候选集就小如果没把握候选集就大。实际使用中top_p比top_k更常用。你可能会看到很多API文档建议temperature和top_p只改其中一个原因是两者都在控制概率分布的采样范围同时调整容易让输出变得过于随机或过于保守不利于结果稳定性。4.4 不同任务下的参数配置参考我在不同场景下实测下来推荐这样设置任务类型temperaturetop_p说明代码生成0.0~0.20.9~1.0尽量确定性高避免语法错误结构化JSON输出0.0~0.20.9保证字段合法性知识问答/客服0.2~0.40.9平衡准确与自然文案创作/头脑风暴0.7~1.00.9保留多样性代码注释生成0.50.9适度灵活有一个最常见的误解是temperature0每次输出就一模一样。实际上不完全对。模型在GPU上并行计算时浮点运算和批处理会产生一些微小差异即使T0不同请求之间也可能有细微差别。另外如果模型使用了beam search、do_sample等不同解码策略表现也不一样。所以如果你的业务场景要求确定性输出不能只靠调T还需要在工作流里加缓存、校验和重试机制。5. 幻觉问题的工程解法为什么LLM会一本正经地胡说八道5.1 幻觉到底是怎么来的幻觉Hallucination是指模型生成看似合理但实际错误或凭空捏造的内容。它的根源就藏在我们第1章说的预测下一个词里模型的目标是生成流畅、像样的文本而不是验证事实真假。训练数据里的错误信息也会被模型记下来在推理时作为大概率的下一个词输出。更重要的是模型本身没有我记不清的机制——对任何一个问题它都倾向于给一个语法完整、语气自信的回答哪怕它完全没有相关记忆。5.2 哪些任务最容易触发幻觉可以说任何知识型问答都有幻觉风险但有几类情况特别明显时效性信息比如今年最新发布的XX政策模型训练数据里根本没有它就会编一个出来。冷门实体小众公司、非知名人物、特定行业术语训练数据覆盖少模型容易把相似词融在一起。精确数字和引用例如2023年XX市场的规模是多少亿模型会给一个看起来合理的数字但这个数字没有任何出处。跨语言内容特别是小语种与中文之间的翻译和知识问答幻觉率明显高于主流语种。第5.4节我会用一个真实案例演示这类问题的排查链路。5.3 降低幻觉的实战手段从工程角度降低幻觉不是一个单点动作而是一套组合拳。第一RAG检索增强。这是目前最主流的方案。把可信的业务文档切分、向量化后存入向量库用户提问时先检索出相关片段拼到Prompt里让模型基于资料回答。模型看到原文之后编造空间会大幅压缩。第二提示词约束。在系统提示词里明确写如果信息不足请回答不知道并限制回答范围。比如做客服机器人时严格限定只允许基于企业知识库内容回答不要使用模型内部知识。第三降低温度。把temperature调到0.2左右可以减少随机性让模型倾向更保守的输出。第四输出校验。对于结构化输出比如要求模型返回JSON可以加一层规则校验检查字段类型和值域对关键数字或结论可以用程序去数据库里二次比对。第五事实性后处理Fact-check或多模型验证。对高风险场景可以让两个模型互相验证答案或者用一个评审模型来检查回答模型的内容是否与检索到的文档一致。这个方案成本翻倍但效果显著。5.4 一个真实踩坑案例我之前做一个企业内部知识库问答系统知识库里有两份文档分别介绍公司2019年和2022年的组织架构。用户问XX部门现在归谁管模型居然把2019年文档里的负责人和2022年文档里的部门名称融合成了一段看似非常合理的回答其实那个负责人早在两年前就调走了。排查过程我按这三步走第一步检查RAG是否召回了正确文档。我把用户问题和召回片段单独打出来看发现两份文档都召回了旧文档的相似度评分还更高。第二步检查Prompt结构。最初Prompt只是简单写了请基于上下文回答但上下文中两段信息相互矛盾模型没有判断哪个更新而是自动做了一次中间态融合。第三步修复。我的解决办法是两段并行一是给每一段检索结果带上文档日期元数据并在Prompt里强调如果多份资料冲突以日期最新的为准如果仍然无法确定请直接说不确定二是降低相似度阈值避免低相关度的旧文档进入上下文。修复之后类似的张冠李戴基本没有再出现。这个案例的教训是在RAG场景里如果只是简单地把检索结果丢给模型不控制资料冲突和信息时效幻觉率依然会高得吓人。6. Prompt、RAG、Agent、Embedding四个高频术语到底在解决什么问题6.1 Prompt Engineering成本最低的模型行为调节Prompt Engineering也叫提示词工程本质上是在不修改模型权重的前提下通过设计输入文本引导模型输出你期望的结果。几乎所有LLM应用的第一步都是Prompt。它包含几个常用手段角色设定你是一个严谨的税务专家……任务描述请从以下文本中提取实体以JSON格式输出……示例Few-shot给模型一两个输入输出的例子它会模仿你的格式和风格。约束条件如果信息不足请回答不知道不要编造。我个人的经验是把约束写清楚比把任务写有文采重要得多。比如你想让模型写一段广告语与其写请写一段有创意的广告语不如给它三条竞品广告语作为参考再告诉它语气要贴近目标用户是年轻妈妈。给示例的效果通常远好于贴抽象的描述。6.2 Embedding让文本变成可计算的向量Embedding是把一段文本映射成一个高维向量一串浮点数的技术。关键性质是语义相似的文本在向量空间中的距离也更近。苹果不好吃和这个水果很难吃的向量距离会很近虽然它们没有一个字相同。这是因为Embedding模型在海量文本上学习到了这些字词经常出现在相似语境中。Embedding在LLM应用里的用途极广文档检索、文本聚类、去重、推荐、分类。最典型的应用是RAG的检索环节把用户问题和知识库里的文档片段都转成向量然后用余弦相似度找最相近的片段。做Embedding选型时要注意不同Embedding模型的能力范围差别很大。有的擅长处理中文有的对代码能力更强。选型之前最重要的是拿你自己的领域数据做评测而不是只看公开榜单的分数。6.3 RAG把外部知识喂到嘴边RAGRetrieval-Augmented Generation是目前企业级LLM应用里最重要的架构模式。它解决的核心问题是模型不知道你的私域知识、最新知识而且会幻觉。RAG的完整流程可以概括为离线段把业务文档切分成小块每块用Embedding模型转成向量存入向量数据库。在线段用户提问时先把问题转成向量在向量库中检索出最相似的Top-K个文本块。生成段把用户问题检索到的文本块拼成Prompt交给LLM生成最终答案。必须承认RAG和模型训练无关。它是在模型生成之前把相关信息提供给模型让模型的下一个词预测有依据可循。前面第5.4节的案例已经展示了RAG实践中一个最典型的坑检索结果的质量直接决定生成质量。在实际构建RAG系统时你需要调的不只是模型参数还有文本切分大小、重叠长度、检索条数、相似度阈值甚至向量数据库的索引类型。这是一个需要反复实验的过程。6.4 Agent让LLM从说话到干活Agent智能体是目前LLM应用里最热闹的方向。它的核心区别在于不再只是让模型生成文本而是让模型决定采取什么行动。实现这一点的关键技术是函数调用Function Calling/Tool Use的能力。开发者定义好一系列工具比如查天气查订单状态发送邮件执行SQL然后让LLM根据用户的输入自己决定现在应该调用哪个工具、传什么参数拿到工具结果后再综合生成最终回答。一个Agent系统的典型工作流程是用户问帮我查一下明天的天气LLM识别出意图是查天气提取参数明天和位置调用天气API然后根据API返回结果组织语言回复。坦白说Agent的工程复杂度比普通RAG高不少。因为它引入了多步决策而每步决策都有出错概率错误会逐级累积。我的建议是如果你没有足够的时间做日志追踪和流程控制先不要急着上Agent从单轮工具调用开始做跑通之后再逐步加多步骤编排。6.5 选型建议什么场景用什么方案以我的项目经验做一个简单的选型对照表供参考需求类型推荐方案原因让模型具备领域知识RAG知识更新快、无需训练成本让模型改变回答风格/角色Prompt工程最简单直接多轮对话中执行操作查询、下单Agent 工具调用与业务系统联动让模型长期吸收一种固定文档规范微调效果稳定但成本高语义检索、文本匹配Embedding向量化是一切检索的基础微调和RAG从来不是二选一。很多成熟产品的做法是RAG负责喂资料微调负责调风格两者结合使用。至于Agent它适合那些真正需要干活的场景而不是简单问答。7. 给入门者的学习路线与工具选型建议7.1 四步走学习路线如果你是从零开始想把LLM学到能自己做项目的程度我建议走这条路线每一步都需要动手实践。第一步挑一个API跑通最基本的对话。OpenAI、国内的DeepSeek、通义千问都可以关键是先亲手发一次请求感受输入输出的结构。这一步的主要目的是打破大模型很遥远的心理障碍。第二步系统学一遍提示词工程。不要只看网上的咒语大全。做几组对比实验换角色、换示例、换约束条件观察输出的变化建立输入如何影响输出的直觉。第三步做一个带RAG的小项目。比如个人知识库问答把自己平时写的文档、笔记存进去问问题试试。这一步能逼你理解向量化、文档切分、检索召回和Prompt拼接的完整链路。第四步读一篇模型技术报告。选一个开源模型比如Llama或Qwen的论文或技术报告哪怕只看懂一半也能对训练数据、评测指标、对齐方式有更具体的认知。7.2 工具链选型现在的LLM开发工具有很多容易让人眼花缭乱。我的选型经验如下LangChain适合有一定编程基础的人。它把各种LLM调用、Prompt模板、向量库集成成了模块化组件很灵活但抽象层次较高出了问题排查起来有一定难度。Dify可视化LLM应用编排平台适合业务团队快速搭应用。你可以直接在界面上拖拽配置Prompt、知识库、工具调用部署也简单。LlamaIndex专注数据和RAG场景。如果你的核心需求是让LLM和大量文档打交道它比LangChain更顺手。向量数据库小项目用Chroma或pgvector就够数据量达到百万级后再考虑Milvus这类专业向量库。不要一开始就同时上很多框架。选一个主框架跑通一个小项目再决定要不要引入更多组件。7.3 关于本地部署自己的模型很多初学者对本地部署有执念。先泼一盆冷水本地部署的ROI不一定高。如果想体验可以从7B到14B的开源模型量化版开始。以Qwen2.5-7B-Instruct的4bit量化为例处理16GB显存的消费级显卡可以流畅运行。再往上32B甚至70B的模型无论内存还是推理速度都不是普通的家用机器能承受的。本地部署的真正价值在于数据隐私和成本控制但也意味着你不用依赖外部API。如果你只是做验证和产品原型直接用API显然更快。如果业务对数据安全性要求极高或者有高频调用成本压力再考虑本地部署而且要准备好GPU算力预算。7.4 最后一点经验我堆了很多技术名词但最后想给你一个建议——不要从技术名词出发做项目而要从业务问题出发做技术选型。我记得自己早期的一个教训有一个场景用户需要快速查阅某一本操作手册里的具体步骤其实用一个简单的RAG就能解决但我硬要给它加Agent、加多轮工具调用结果链条拉长查询延迟翻了几倍错误率也没降下来。后来砍掉Agent逻辑问题反而简单了。LLM本身只是一个组件。真正决定应用价值的是你如何定义问题、如何组织数据、如何设计校验机制。这是我在文章里反复强调先理解本质再上工程手段的原因。先把这些基础概念吃透你会发现后面那些更复杂的主线任务比如微调、Agent编排、多模态应用会顺畅得多。