如果你是一个工程师，第一次认真接触大语言模型（LLM），你多半会经历一个特别拧巴的阶段：你说它是数据库吧，它会一本正经地编造不存在的知识；你说它不懂吧，它又能把代码写得像模像样；你说它是搜索引擎吧，它根本不会实时联网；你说它只是"高级自动补全"吧，它又能做分析和规划。

这种拧巴，根源在于大多数人用了"人"的思维去理解LLM。我从技术视角把LLM的底层逻辑拆开之后，很多疑问其实会自动消失——为什么提示词要那样写、为什么大模型会产生幻觉、为什么temperature能影响输出、为什么需要RAG和Agent这些外围工程。这篇文章就是给准备深入LLM开发、又不想只停留在"调API"层面的读者准备的，目标是用一套清晰且不玄学的框架，把大模型的基础知识讲透。

1. 先打破一个幻觉：LLM并不是真的"懂"你问的话

1.1 它真正的核心能力是"预测下一个词"

把时间拨回大模型最底层。无论参数是70亿还是7000亿，无论叫GPT还是叫Llama，LLM在训练时的核心任务只有一个：给定一段文本，预测下一个最可能出现的词。

举个例子。给模型看"今天天气很"，它要预测下一个位置出现"好""差""热""冷"等词的概率。训练数据里"今天天气很好"出现得多，那么"好"的概率就高。这个预测任务随着训练数据规模的扩大，会在无数个文本片段上反复执行，最终模型内部就把人类语言中隐含的语法规则、事实关联、逻辑模式，全部压缩成了统计规律。

所以严格来说，LLM是一个"极其擅长接龙"的玩家。你给它一个上文，它补一个最合理的下文。至于这个下文是不是"真实"的，并不是它关心的第一要务，它只关心"像不像人类会写的下一个词"。

1.2 为什么这个认知是所有技巧的根基

一旦接受了"预测下一个词"这个设定，你会发现所有上层技巧都变得合理起来。

• 提示词的本质，是给模型提供一个"更有指向性的上文"，让它沿着你期望的方向预测。
• 温度参数的调节，是改变模型在概率分布上"挑词"的随机性。
• RAG（检索增强生成）的本质，是把相关资料先检索出来，拼进上下文里，让模型在预测时"看得见"这些内容。
• 连"大模型输出JSON格式不稳定"这类问题，本质上也是它在"预测下一个词"时，对JSON语法结构的概率估计不够高。

很多人觉得提示词工程是"玄学"，其实它不是。它是在用模型能理解的方式，帮它降低下一个词预测的难度。你给的信息越充分、越结构化，模型预测就越容易命中你想要的答案。

1.3 "会接龙"和"会推理"之间的距离

理解了"接龙"本质，你就能解释很多LLM的诡异行为。

比如，你问GPT-4o"9.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代表Billion，7B就是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。

当T=1时，概率分布保持原样。当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_k=50，那么就算第51名的词概率再高，也不会被选中。它的优点是排除掉那些概率极低的"垃圾词"。

Top-p采样（也叫核采样）：从概率最高的Token开始逐个累加，直到累计概率超过p（比如0.9），然后把候选集限定在这些Token中。它比Top-k更灵活：如果模型对下一个词很有把握，候选集就小；如果没把握，候选集就大。

实际使用中，top_p比top_k更常用。你可能会看到很多API文档建议"temperature和top_p只改其中一个"，原因是两者都在控制概率分布的采样范围，同时调整容易让输出变得过于随机或过于保守，不利于结果稳定性。

4.4 不同任务下的参数配置参考

我在不同场景下实测下来，推荐这样设置：

有一个最常见的误解是"temperature=0，每次输出就一模一样"。实际上不完全对。模型在GPU上并行计算时，浮点运算和批处理会产生一些微小差异，即使T=0，不同请求之间也可能有细微差别。另外，如果模型使用了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：把外部知识"喂到嘴边"

RAG（Retrieval-Augmented Generation）是目前企业级LLM应用里最重要的架构模式。它解决的核心问题是：模型不知道你的私域知识、最新知识，而且会幻觉。

RAG的完整流程可以概括为：

1. 离线段：把业务文档切分成小块，每块用Embedding模型转成向量，存入向量数据库。
2. 在线段：用户提问时，先把问题转成向量，在向量库中检索出最相似的Top-K个文本块。
3. 生成段：把用户问题+检索到的文本块拼成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从来不是二选一。很多成熟产品的做法是"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编排、多模态应用，会顺畅得多。