从零构建Agent智能体系列02-大语言模型是怎么工作的

嗨，我是辉哥，一个致力于使用 AI 技术搞副业的超级个体

大语言模型是当前所有 AI 智能体的核心引擎。它的本质是一个学会了"接龙"的文本生成器——给它一段开头，它就能一个字一个字地续写下去。理解它是怎么工作的、怎么跟它有效沟通、以及它有哪些先天不足，是我们用好它的前提。

本章回答的核心问题：

1. 大语言模型的基本工作方式是什么，它和我们平时用的传统 AI 有什么不同
2. 怎么说话才能让模型给出我们想要的结果
3. 市面上这么多模型，应该选哪个
4. 模型会"编造事实"，这是为什么，怎么应对

目录

• 2.1 大语言模型是怎么工作的
• 2.2 提示工程核心
• 2.3 主流 LLM 选型与 API 使用
• 2.4 LLM 的局限与注意事项
• 本章小结

---

2.1 大语言模型是怎么工作的

要理解大语言模型的工作原理，我们可以从它最核心的想法开始。

大语言模型的核心思想很简单：给它前面的一段话，它预测下一个最可能出现的词是什么。不断重复这个过程，就能生成完整的文章、代码或对话。

听起来简单，但要做到"预测得准"，需要解决几个关键问题。我们先从模型要解决的本质问题说起。

2.1.1 从"死记硬背"到"真正理解"

要理解今天的大模型是怎么来的，我们有必要先看看它走过的路。

早期的语言模型用的是最朴素的方法：统计。

N-gram 模型的思路是——统计语料库中"词与词"相邻出现的频率。比如"天气很好"这个搭配出现得多，那输入"天气很"时模型就会猜"好"。N-gram 要解决的根本问题是：如何预测下一个词？ 它的回答是"查表"——在过去出现过的文本中，统计哪些词经常跟在当前词的后面。这就像一个只靠背题库备考的学生：见过的题能对，没见过的就傻眼。这种方法有两个致命缺陷。

第一，它只能记住见过的搭配。遇到"天气极棒"这种语料库里没出现过的说法，它就傻眼了。第二，它看不到远距离的关系。比如一句话的开头说了"小明"，隔了几十个词后面用"他"来指代，简单的统计模型无法把这两个词关联起来。

后来研究者引入了神经网络，把每个词变成高维空间中的一个向量（叫作"词嵌入"，Word Embedding）。词嵌入要解决的根本问题是：如何让机器理解词与词之间的关系，而不是把它们当作互不相关的符号？ 类比：如果每个词是地图上的一个城市，词嵌入就是给每个城市标上经纬度。"北京"和"上海"在地图上挨得近，"苹果"和"香蕉"也挨得近，但"苹果"和"汽车"离得很远。语义相近的词，在空间中位置也接近。这样模型遇到没见过的搭配时，也能"举一反三"——既然"学"和"习"在空间中离得近，那么理解了"学习"也就部分理解了"研习"。

但词嵌入仍然有一个限制：上下文窗口是固定的。它只能看到当前词前面固定的几个词，再早的内容就看不到了。

循环神经网络（RNN）试图解决这个问题。它维护一个"记忆向量"，每读一个词就更新一次记忆。理论上，这个记忆向量应该包含前面所有词的信息。

不过，理想归理想，实际实现时 RNN 遇到了两个绕不开的难题。

第一，无法并行计算。 RNN 必须一个词一个词按顺序处理，读"你"的时候才能开始读"好"，读完"好"才能处理"吗"。就像一个人只能逐字阅读，没法扫读全文。对于动辄几十亿词的语料库，这种串行方式太慢了。

第二，记不住太早的内容。 当一段话很长时，记忆向量会被后面进来的词反复覆盖，前面的内容逐渐被稀释。这就像人的短期记忆——听完一段十句话的故事，开头讲了什么已经模糊了。

到这里我们已经看到，无论是逐词处理的 RNN 还是只看局部上下文的词嵌入，都无法满足大规模语言理解的需求。

Transformer 的出现解决了这两个问题。它的核心思路是：与其维护一个会被覆盖的记忆向量，不如让序列中的每个词都能"看到"整句话的每一个词。

RNN 的处理方式（按顺序，无法并行）：
  读 "我"  → 更新记忆
  读 "觉"  → 等"我"处理完，才能继续
  读 "得"  → 等"觉"处理完，才能继续
  读 "天"  → ...
  读 "气"  → 前面的记忆已经变模糊了

Transformer 的处理方式（全部同时处理）：
  同时读入 "我 觉 得 天 气 很 好" → 每个词都能直接看到其他所有词
  → 一步并行完成，没有先后依赖

这就是 Transformer 取代 RNN 成为大模型基础架构的根本原因——它让大规模并行训练成为可能，而并行训练是训练千亿参数模型的前提。但 Transformer 的自注意力机制计算复杂度随序列长度呈平方级增长，处理超长文本时显存消耗巨大。当输入文本极长或计算资源有限时，需要考虑引入稀疏注意力或线性注意力等变体来降低开销。

2.1.2 注意力机制：让每个词都能关注到该关注的词

注意力机制是 Transformer 的核心。要理解它，我们可以从日常阅读的经验入手。

阅读这句话时："小明说他的方案比小红的好。"

读到"他的"时，你需要回头看看"他的"指的是谁。读到"他的方案"时，你自然会把注意力拉回到"小明"上。这就是注意力——让每个词在理解时，重点关注与它相关的其他词。

在模型内部，每个词被表示为三个向量：

• Query（查询） -- 表示这个词"想从其他词那里找到什么信息"
• Key（键） -- 表示这个词"能提供什么信息"
• Value（值） -- 表示这个词"实际携带的内容"

当模型处理某个词时，用它的 Query 去和所有词的 Key 做匹配。匹配度高的词说明与当前词关联密切，模型就分配更多的注意力给它。最终，当前词的输出是所有词 Value 的加权总和——关联越强的词，贡献越大。

这样做的好处是：每个词在输出时都融合了整句话的上下文信息，而且所有词的计算可以同时进行，天然适合 GPU 并行加速。但注意力的计算量随序列长度呈平方级增长，处理长文本时开销急剧上升。此外，注意力权重可能过于分散，导致模型"平均关注一切"而非真正聚焦关键信息。当序列很长时，注意力机制的这种特性可能导致模型丢失对核心信息的聚焦。

2.1.3 多头注意力：多个角度看同一个问题

理解了单一注意力之后，我们来看一个自然的延伸。

单一维度的注意力计算只能捕捉一种关系。但语言中一个词可能同时涉及多种关系。

例如"他用苹果公司的手机看股票。"中的"苹果"：

• 从语义角度，需要关注"手机"来理解是品牌而非水果
• 从语法角度，需要关注"公司"来确定词性
• 从逻辑角度，需要关注"看"来理解这是消费行为

多头注意力就是把注意力计算分成多份，每份在不同的子空间中独立运行。这就好比一个问题的答案需要多个专家共同给出——语法专家关注句法关系，语义专家关注含义关联，每个专家从自己的角度看问题，最后把意见综合起来。但多头注意力增加了参数量和计算开销，且多个"头"之间可能存在冗余——某些头学到相似的模式，浪费了计算资源。当计算资源受限或输入文本很短时，减少头数甚至使用单头注意力可能更合适。

2.1.4 位置编码：给顺序一个存在感

前面我们了解了注意力机制，但它有一个容易被忽视的盲点——它不知道词的顺序。

对自注意力来说，"猫追狗"和"狗追猫"完全等价，因为三个词之间的关联强度都是一样的。但含义截然不同。

为了解决这个问题，模型在每个词的向量上叠加了一个"位置标记"。这个标记对每个位置都是独一无二的。"苹果"出现在第一个位置和出现在第三个位置，叠加不同的位置标记后，输入到模型的向量就不同了。

模型因此获得了感知顺序的能力，而不需要像 RNN 那样按顺序逐个处理。但位置编码的设计并非没有代价：绝对位置编码无法泛化到训练时未见过的序列长度，当输入文本超出训练时的最大长度时，位置信息会失效；相对位置编码则增加了注意力计算的复杂度，每次计算都需要额外处理位置关系。选择哪种位置编码方案需要在泛化能力和计算效率之间做权衡。

2.1.5 残差连接：让深层网络能训练起来

了解完位置编码，我们来看一个让大模型能够实际训练的关键设计。

大模型通常有几十层甚至上百层。层数越多，训练越困难——每经过一层信息都会有损耗，到后面梯度信号就弱到几乎无法更新了。残差连接要解决的根本问题是：如何让信息在很深的网络中不丢失？ 类比：团队接力传话，如果只是每个人把听到的话转述给下一个人，传到后面肯定会走样。但如果在传话的同时，把原始话也抄一份直接递到队尾，即使中间有人传得不好，队尾至少还能收到原始信息。残差连接的思路正是如此：把每一层的输入直接加到输出上，也就是 输出 = 输入 + 这一层的学习内容。

这样做有两个好处。第一，即使某一层没有学到有用的东西，输入信息也不会丢失，因为输入被直接传递下去了。第二，训练时梯度信号可以绕过某些层直接传递，防止深层网络训练崩溃。但残差连接也增加了内存占用——需要保留原始输入用于加法运算。且在某些特殊结构中，过强的残差连接可能导致模型"偷懒"——直接跳过某些层而不学习有用的变换。设计过深的网络时，需要平衡残差连接的强度，确保每一层都能学到有意义的变换。

2.1.6 为什么主流模型都用 Decoder-Only

了解了 Transformer 的核心组件后，我们来看一个实际的架构选择问题。

最初的 Transformer 是为翻译设计的"编码器-解码器"双模块结构。编码器负责"读懂"输入，解码器负责"翻译"输出。

但当任务从翻译变成通用文本生成时，OpenAI 在 GPT 系列中做了一个简化：去掉编码器，只保留解码器。

Decoder-Only 架构的运行方式是自回归的。自回归要解决的根本问题是：如何用一个统一的机制完成所有生成任务？ 它的做法是：给定一段文本，模型预测下一个最可能的词，然后把生成的词追加到末尾，再次预测下一个词。不断循环直到生成完整输出。这就像文字接龙——每接上一个词，这个词就成为下一轮的新起点。Decoder-Only 的简洁之处在于：它只需要学一件事——"下一个词是什么"，就能覆盖对话、写作、代码生成等所有文本生成任务。

为了让模型在训练时不会"偷看"后面的内容，模型内部加入了一个掩码——预测每个词时，只允许看到它前面的词，后面的词被屏蔽掉。

Decoder-Only 成为主流有三个原因：

维度	说明
训练目标统一	唯一任务就是"预测下一个词"，可以在海量无标注文本上训练
结构简单	组件少，更容易扩展到千亿甚至万亿参数规模
天然适合生成	对话、写作、代码生成等任务都是一个词一个词生成的，和自回归模式完全契合

当前所有主流大模型——GPT、Claude、Llama、Qwen——都采用 Decoder-Only 架构。

不过 Decoder-Only 也有代价：由于采用因果掩码，每个 Token 只能看到前面的内容，这使它在需要双向上下文理解的任务（如文本分类、命名实体识别）上不如 Encoder 架构高效。此外，自回归生成是串行的，生成速度受限于序列长度。当任务只需要理解文本而不需要生成时，Encoder-Only 或 Encoder-Decoder 架构通常更高效。

---

2.2 提示工程核心

了解了模型的工作原理，接下来我们看看怎么跟它高效沟通。

提示工程是通过设计好的提示来引导模型产生期望输出的技术。有效的提示遵循三个核心原则：明确任务目标、提供充分上下文、指定输出格式。

2.2.1 Prompt 设计原则

明确任务目标。 直接告诉模型要做什么，避免模糊描述。

差：处理这段文字
好：将以下用户评论分类为正面、负面或中性

提供充分的上下文。 如果任务涉及特定领域或需要特定背景知识，在提示中包含相关信息。模型的输出质量与提供的信息量正相关。

具体化而非抽象化。 描述越具体，输出越精准。

差：写个产品介绍
好：写一段 200 字左右的产品介绍，突出三个核心卖点

指定输出格式。 当需要结构化输出时，明确给出格式模板。

请分析以下产品评论，提取产品名称和用户情感，严格按照 JSON 格式输出。

评论: 这款"星尘"笔记本电脑的屏幕显示效果惊人，但键盘手感不太好。
输出: {"product_name": "星尘笔记本电脑", "sentiment": "混合"}

评论: 我刚买的"声动"耳机音质很棒，续航也超出了预期！
输出: {"product_name": "声动耳机", "sentiment": "正面"}

给一个示例再提问。 这就是 Few-shot 的核心思路。

2.2.2 System Prompt（系统提示）

System Prompt 是设置模型整体行为和角色的全局指令，位于对话的最开始。它定义模型扮演的角色、行为边界、输出风格约束等，在整个对话过程中持续生效。

你是一个资深的 Python 工程师。回答技术问题时要：
1. 先给出简洁的答案
2. 再提供代码示例
3. 最后解释原理
如果问题有歧义，先澄清再回答。

2.2.3 主流提示策略

Zero-shot（零样本提示）

不给示例，直接给出任务指令。适用于模型在预训练阶段已经充分学习过的常见任务，比如分类、翻译、摘要等。但 Zero-shot 的输出质量完全依赖模型的预训练知识，对任务描述的表达方式极其敏感。当任务格式特殊、模型从未见过类似模式，或对输出格式有严格要求时，直接 Zero-shot 往往得不到理想结果。

请将以下用户评论分类为正面、负面或中性：
"这款手机的电池续航很好，但拍照效果一般。"

Few-shot（少样本提示）

在指令中加入一到几个示例，展示期望的输入输出格式和风格。适用于以下场景：

• 需要特定格式输出
• 任务比较新颖，模型可能不熟悉
• 需要控制输出的风格和语气

但 Few-shot 也有代价：示例占据大量上下文窗口，增加 API 成本，且如果示例选择不当反而会误导模型。当上下文窗口紧张、任务本身模型已经很熟悉、或找不到高质量示例时，Few-shot 可能不如 Zero-shot 加上清晰指令。

请根据以下规律生成对应城市的天气建议：

输入: 北京，晴天
输出: 适合户外活动，注意防晒

输入: 上海，雨天
输出: 建议室内活动，如博物馆、商场

输入: 杭州，阴天
输出: 适合户外散步，天气凉爽舒适

Chain-of-Thought（思维链，CoT）

对于需要逻辑推理、计算或多步骤思考的复杂问题，直接让模型给出答案容易出错。CoT 通过引导模型"一步一步地思考"来提升推理能力。

实现方式很简单：在提示中加入"请逐步思考"这样的引导语。

一个篮球队在一个赛季的 80 场比赛中赢了 60%。在接下来的赛季中，
他们打了 15 场比赛，赢了 12 场。两个赛季的总胜率是多少？
请一步一步地思考并解答。

模型会先计算第一步赢得的比赛数，再计算总比赛数和总胜利数，最后得出总胜率。显式展示推理过程不仅更容易得出正确答案，也便于人类检查和纠正。但 CoT 的代价也很明显：生成更长的推理链消耗更多 Token，且当模型在推理链的早期犯错时，后续步骤会基于错误前提继续，产生"越推越错"的级联效应。当任务非常简单直接，或对响应速度和成本极度敏感时，CoT 是过度的。

2.2.4 采样参数

掌握提示设计后，我们来看看控制模型输出行为的另一个重要维度——采样参数。

大模型通过调整概率分布的采样策略来改变输出行为。理解这些参数的含义，比凭经验试错更有效。

Temperature（温度） -- 控制模型输出的"创造性"程度。

想象模型在预测下一个词时，会给所有可能的候选词打分。温度的作用就是调整这些分数之间的差距：

• 温度低时，得分高的词优势更明显，模型总是选择最可能的那几个词，输出稳定但保守
• 温度高时，各候选词之间的差距缩小，一些不太常见但更有创意的词有机会被选中

Temperature 范围	输出特征	适用场景
0 ~ 0.3	精准、确定	事实性问答、代码生成、技术文档
0.3 ~ 0.7	平衡、自然	日常对话、邮件撰写、常规创作
0.7 ~ 1.0+	多样、发散	创意写作、头脑风暴

Top-p（核采样） -- 从候选词中按概率从高到低累加，直到累积概率达到阈值，只在这个截断后的集合中采样。Top-p = 0.9 表示只考虑概率最高的那些词，它们的概率加起来占 90%。

Top-k -- 固定数量截断。取概率排名前 k 个词组成候选集。通常 Top-k 和 Top-p 二选一即可。

max_tokens -- 控制模型最多生成多少个词。对于控制输出长度和成本很重要。

实践建议：对于事实性任务（如技术问答、代码生成），Temperature 设为 0 到 0.3；对于创意性任务，可以适当调高。Temperature 设为 0 时，模型的输出是完全确定的，同样的输入每次都会得到相同的结果。

---

2.3 主流 LLM 选型与 API 使用

了解了怎么和模型沟通，接下来我们看看市面上有哪些常用模型，以及怎么选择。

模型选型是在性能、成本、速度和部署方式之间做权衡的过程。没有绝对最优的模型，只有最适合具体任务的模型。

2.3.1 模型选型的关键维度

维度	关注点
性能与能力	不同模型擅长的任务不同，可参考公开基准测试评估综合能力
成本	闭源模型按 Token 计费；开源模型成本体现在硬件和运维
速度（延迟）	实时交互场景对响应速度要求高
上下文窗口	需要理解长文档或维持长期对话记忆的应用应选大窗口模型
部署方式	API 便捷但数据需外发；本地部署确保隐私但技术要求更高
生态与工具链	主流模型社区支持更丰富，遇到问题更容易找到解决方案

2.3.2 闭源模型概览

闭源模型通常代表当前技术的最前沿，提供稳定易用的 API 服务。

OpenAI GPT 系列 -- 从 GPT-3 开启大模型时代，到 ChatGPT 实现与人类意图对齐，再到 GPT-4 支持多模态能力，持续引领行业发展。2026年 GPT-5.4 已成为最新旗舰，在智能指数（Intelligence Index）上与 Gemini 3.1 Pro 并列榜首（57 分），强化了复杂推理、编程和工具调用能力。同时 GPT-5.3 提供轻量级 API 选项。代价是 API 定价较高，且模型更新节奏不受用户控制。当预算受限或需要完全掌控模型版本时，应考虑其他选项。

Anthropic Claude 系列 -- 以 AI 安全为核心理念，在处理长文档、遵循指令方面表现可靠。2026年 Claude Opus 4.6 和 Claude Sonnet 4.6 均已接入 100 万 Token 上下文窗口，extended thinking（扩展思考）机制在代码生成和多步骤任务规划上持续领先。代价是在创意写作和多模态生成方面相对保守，综合智能指数（53 分）略低于同期 GPT-5.4 和 Gemini 3.1 Pro。当需要极度开放的创意输出或在某些不可用地区部署时，需要考虑替代方案。

Google Gemini 系列 -- 原生多模态模型，统一处理文本、代码、音视频和图像。2026年 Gemini 3.1 Pro 在智能指数上以 57 分与 GPT-5.4 并列第一，在代码生成、科学推理和超长上下文（百万级 Token）上具备显著优势，且定价策略更具竞争力。Grok 4.20 也在同一时期加入竞争。代价是生态工具链相对不够成熟，企业级服务仍在完善中。当项目需要稳定成熟的工具链支撑时，需要评估生态配套是否满足需求。

xAI Grok 系列 -- 2026年 Grok 4.20 凭借更大规模训练集群和 DeepSearch/Think Mode 等推理功能，在数学、科学和编程基准上跻身第一梯队。代价是仅通过 X 平台和 xAI API 提供，生态工具链尚在建设中，且主要面向英语场景。当项目需要成熟的中文支持或广泛的第三方集成时，Grok 尚非首选。

国内主流模型 -- 阿里通义千问 Qwen3.6 系列（2026年4月发布，含 Plus / Flash / Max Preview 三款主力，支持百万 Token 上下文和 Agentic Coding 能力）在国内模型中性价比最优；DeepSeek V4 持续优化 MoE 架构，在数学和代码推理上对标国际前列；月之暗面 Kimi（K2）在长上下文理解和深度搜索上持续进化；百度文心、腾讯混元、华为盘古等在各自生态中各有侧重。代价是部分模型在极复杂英文推理和全球生态整合上仍在追赶。

2.3.3 开源模型概览

开源模型提供最高程度的灵活性、透明度和自主性，允许本地部署和定制微调。

Meta Llama 系列 -- 开源大语言模型的重要里程碑，凭借出色的综合性能成为许多衍生项目和研究的基座。Llama 4（Scout / Maverick / Behemoth）引入 MoE（混合专家）架构和多模态能力，旗舰模型在多项基准上逼近闭源前沿。代价是大模型仍需要大量 GPU 资源才能运行，且微调需要专业技术。当没有足够计算基础设施或缺乏 MLOps 能力时，使用门槛较高。

Qwen3.6 系列 -- 阿里通义千问 2026年4月发布的全新系列，包含 qwen3.6-plus（27B 稠密模型，百万 Token 窗口）、qwen3.6-flash（轻量高效）、qwen3.6-35b-a3b（35B/3B MoE，开源）和 qwen3.6-max-preview（旗舰推理版）。qwen3.6-plus 在 Agentic Coding 和工具调用场景上表现突出，API 性价比在主流模型中极具竞争力。当项目需要在中文场景、低成本 API 和本地部署之间灵活切换时，Qwen3.6 是非常务实的选择。

DeepSeek V4 -- 持续优化 MoE 架构和推理能力，在数学、代码和科学推理上直接对标国际前列，是 2025-2026 年间最具性价比的开源模型之一。代价是 MoE 架构的部署复杂度较高，且社区生态仍在快速成长期。当团队缺乏 MoE 模型的部署和运维经验时，可能需要额外的技术投入。

Mistral AI 系列 -- 以"小尺寸、高性能"的设计闻名，在代码生成、推理和跨领域问答等任务上表现突出。代价是模型规模相对较小，在需要极深推理或多模态能力的任务上不如更大模型。当任务复杂度超出了中小型模型的能力范围时，需要考虑更大的模型。

轻量与边缘模型 -- Google Gemma 3、Microsoft Phi-4、Qwen3.6-Flash 等小模型（1B-4B 参数量）专为本地部署和边缘设备设计，在简单任务上性价比极高。代价是在复杂推理、长文档理解和多步骤规划上能力有限。当任务需求超出简单分类、摘要和短文本生成时，应升级到更大的模型。

2.3.4 API 调用示例

使用 Anthropic SDK 调用闭源模型。下面的示例展示了基本的调用流程。关于环境变量的配置方式，请参考《快速开始》文档。

import os
from anthropic import Anthropic

api_key = os.environ.get("ANTHROPIC_API_KEY") or os.environ.get("ANTHROPIC_AUTH_TOKEN")
if not api_key:
    raise ValueError("未设置 ANTHROPIC_API_KEY 环境变量。")

base_url = os.environ.get("ANTHROPIC_BASE_URL")
client_kwargs = {"api_key": api_key}
if base_url:
    client_kwargs["base_url"] = base_url
client = Anthropic(**client_kwargs)

model_name = os.environ.get("ANTHROPIC_MODEL") or "qwen3.6-plus"

response = client.messages.create(
    model=model_name,
    system="你是一个有帮助的助手。",
    messages=[
        {"role": "user", "content": "请用三句话解释什么是量子计算。"},
    ],
    temperature=0.7,
    max_tokens=200,
)

# 安全提取文本（LLM 可能返回包含思考块的多部分内容）
text_parts = [b.text for b in response.content if hasattr(b, "text")]
print("\n".join(text_parts))

使用 Transformers 库在本地运行开源模型。与上面的 API 调用相比，这种方式需要更多配置，但数据完全在本地处理：

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "Qwen/Qwen3.6-35B-A3B"
device = "cuda" if torch.cuda.is_available() else "cpu"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id).to(device)

messages = [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "请介绍一下量子计算。"},
]

text = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True
)
model_inputs = tokenizer([text], return_tensors="pt").to(device)

generated_ids = model.generate(
    model_inputs.input_ids,
    max_new_tokens=512,
    temperature=0.7,
)

generated_ids = [
    output_ids[len(input_ids):]
    for input_ids, output_ids in zip(model_inputs.input_ids, generated_ids)
]
response = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0]
print(response)

2.3.5 选型实践建议

• 对于需要快速验证的项目，先用闭源 API 模型，开发速度最快
• 对于涉及数据隐私或需要长期稳定运行的场景，考虑本地部署开源模型
• 不要盲目追求最大最强的模型。小模型在简单任务上性价比更高，把大模型留给真正需要复杂推理的任务
• 关注上下文窗口是否满足业务需求，长文档处理场景优先选择大窗口模型
• 模型选型不是一次性决策，应随需求变化持续评估和调整

---

2.4 LLM 的局限与注意事项

到目前为止，我们了解了模型的工作原理和使用方法。但在实际应用中，认识到模型的局限性同样重要。

大语言模型本质上是在预测下一个最可能的词，而非理解事实或验证真伪。这导致它会生成看似合理但不符合事实的内容（幻觉），同时受限于训练数据的知识截止时间和单次处理的文本量。理解这些局限是构建可靠应用的前提。

2.4.1 幻觉问题

很多初学者第一次遇到幻觉时会感到困惑，其实这是模型设计上的必然结果。

幻觉指的是模型生成的内容与客观事实、用户输入或上下文信息相矛盾。幻觉要解决的根本问题是：为什么一个看似"聪明"的模型会一本正经地编造事实？ 根本原因在于模型的本质——它不是在"回忆事实"，而是在"预测下一个最可能的词"。类比：想象一个记忆力超群但从不核实事实的百科全书编辑，他能流畅地写出任何主题的文章，但如果资料库里没有准确信息，他也会用自己的语言风格编出一段看似合理的内容。模型没有内置的事实核查模块，它只是在概率驱动下预测下一个最可能的词。当训练数据中有错误、或者模型对某个话题不太确定时，它依然会给出一个看起来合理的答案——因为它的设计目标就是"继续生成"，而不是"确认正确后才生成"。

幻觉主要有三种类型：

类型	说明	示例
事实性幻觉	生成的内容与现实世界事实不符	模型推荐一个现实中不存在的景点
忠实性幻觉	摘要、翻译等任务中未能忠实反映源文本	摘要中添加了原文没有的信息
内在幻觉	生成的内容与用户提供的输入直接矛盾	用户说"我有两个孩子"，模型回答"作为独生子女的你"

缓解幻觉的方法：

• 检索增强生成（RAG） -- RAG 要解决的根本问题是：如何让模型在生成答案之前，先查阅可靠的外部资料？ 类比：开卷考试——与其让学生凭记忆答题，不如允许他们先翻书找依据。RAG 正是这个思路：在生成之前从外部知识库检索相关信息，然后将检索到的信息作为上下文引导模型生成基于事实的回答。这是目前最有效的方法之一。但 RAG 也有代价：引入了额外的检索系统复杂度，检索质量直接决定生成质量（检索错误会导致更严重的幻觉），且维护知识库需要持续投入。当任务不需要外部知识（如创意写作、代码生成），或当没有可靠的外部知识源可检索时，RAG 只会增加系统复杂度而没有收益。
• 多步推理与验证 -- 引导模型进行逐步推理，并在每一步进行自我检查或外部验证。
• 引入外部工具 -- 允许模型调用搜索引擎、计算器、代码解释器等外部工具来获取实时信息或进行精确计算。
• 降低 Temperature -- 对于事实性任务，使用较低的温度值（0 ~ 0.3）可以减少幻觉概率。

幻觉问题短期内难以完全消除，但通过上述策略可以显著降低其发生频率。

2.4.2 上下文窗口限制

上下文窗口是模型能一次性处理的词的数量上限。理解上下文窗口需要明确以下几点：

以 Token 计数，而非字符或字数。 Token 是模型处理文本的最小单位，可以理解为"词的碎片"。模型不直接读"字"或"词"，而是把文本切分成 Token 再处理。英文中一个 Token 大约是一个单词的片段，中文中一个 Token 大约对应 0.5 到 1 个汉字，但具体取决于分词器的设计。比如"人工智能"可能被拆成两个 Token，也可能是一个 Token。同样一段文字，在不同模型下 Token 数量可能相差很大。模型的上下文窗口（如 8K、128K）就是按 Token 数量计算的。

API 成本按 Token 计费。 大多数模型 API 按输入和输出 Token 总量收费。了解文本会被如何分词，是预估和控制运行成本的关键。

模型对长上下文的理解能力不均。 即使模型支持 128K 上下文窗口，也不意味着它能同等好地处理窗口内任意位置的信息。研究表明模型对开头和结尾的内容关注度更高，中间部分的信息容易被忽略。关键信息最好放在提示的前部或后部。

2.4.3 知识时效性

大语言模型的知识来源于训练数据，这意味着模型掌握的知识截止于训练数据收集的时间点。对于训练数据之后发生的事件、新出现的概念或最新的事实，模型无法正确回答。

知识时效性影响的典型场景：

• 查询最新新闻或事件
• 了解新发布的产品或技术
• 涉及法律法规的变更
• 最新科研成果的讨论

应对策略：

• 对于时效性敏感的任务，结合检索增强（RAG）或让模型调用搜索工具获取实时信息
• 在 System Prompt 中明确告知模型当前的时间和日期
• 设计系统时对模型无法回答的问题设置降级方案

2.4.4 其他注意事项

训练数据中的偏见。 模型在包含人类社会偏见的数据上学习，不可避免地会吸收并反映这些偏见。在面向公众的应用中，需要关注模型输出是否存在偏见或不当内容。

模型能力与任务难度的匹配。 不是所有任务都需要最强的模型。简单的文本分类、信息抽取可以用小模型或专用模型完成，把大模型留给真正需要复杂推理的场景。

---

本章小结

回顾一下本章的核心内容：

• 大语言模型的本质：一个学会了"文字接龙"的生成器，它通过注意力机制让每个词都能关注到整句话的相关词，从而做出合理的预测。Decoder-Only 架构凭借简单的结构和统一的训练目标，成为所有主流模型的基础
• 提示工程的核心原则：明确任务、提供上下文、指定格式。Zero-shot 适用于常见任务，Few-shot 通过示例引导格式和风格，CoT 用于复杂推理。Temperature 和 Top-p 控制输出的创造性程度，需根据任务类型调整
• 模型选型是在性能、成本、速度和部署方式之间做权衡。闭源模型开箱即用，开源模型可定制部署。选型不是一次性决策，应随需求持续调整
• 模型的核心局限：幻觉（概率预测而非事实核查）、上下文窗口有限且注意力分布不均、知识有时效性。RAG、工具调用和多步推理是缓解这些问题的主要手段

掌握了这些基础后，下一章我们就可以进入更有趣的部分——学习智能体的三种经典工作范式：ReAct、Plan-and-Solve 和 Reflection。它们将本章学到的模型能力与工具调用、执行循环结合起来，形成完整的智能体架构。